LabVIEW
How to convert Hexadecimal String to comma separated Binary number
Solved!
@altenbach wrote:
wiebe@CARYA wrote:
A search is (O), a binary tree search is log(O), an index in an array (1). For this example (a LUT of 16 elements), it hardly makes a difference. But in general "I want speed > use a map" doesn't hold.
Big O notation does not say anything about speed, just the limiting behavior how it scales with the input size. You can have an O(1) process that takes years and TB of storage and a O(N²) process that completes in milliseconds for reasonable inputs.
No argument there...
I think benchmarking will show O(1) will be faster than log(O) in this case, but you're right, you never know until it's actually been benchmarked.
@altenbach wrote:I probably would have used the 256 entry LUT too (>10x larger!), but using the map is cooler and jogs the memory of readers that we now have this great data structure! 😄 I guess that was the main purpose of my suggestion.
I see maps come up as solutions for speed. They are neat, but I fear that they will be used inappropriately. I've actually seen variant attributes been used inappropriately a lot. If we (or I) don't point out that they are not always the fastest solution, maps will become the metaphorical hammer.
Search LabVIEW like a graph! 
I've been very happy with maps, especially since they result in very readable code (variant attribute solutions always look exotic ;)).
Even with 2^31 entries (i.e. the max array size, but maps can go even larger. At least I think they can, on 64bit LabVIEW of course)!, the map speed will only be about 30x slower than a map with only one entry, and since a map lookup is highly optimized, speed is not really of concern. Once you have a LUT of that size, you need to worry about other things too. 😄
I've just completed a larger project where I extensively use maps and it performs great.
(Also my very old caching application (variant attributes) would be impossible to do with a plain LUT, because the keys are hundreds of bytes (infinite possibilities!). I only want to keep the most recently accessed 4k entries, expiring the oldest as new entries arrive.)
I agree that maps make a better general solution than LUTs. LUTs are great when they fit, terrible when they don't. Maps are OK everywhere.
@altenbach wrote:(Also my very old caching application (variant attributes) would be impossible to do with a plain LUT, because the keys are hundreds of bytes (infinite possibilities!). I only want to keep the most recently accessed 4k entries, expiring the oldest as new entries arrive.)
How does a map help with that? It seems to me you'd still need 'something ordered' to tell the chronology?
I've been through a few caching situations myself, but based on position, not chronology. A LUT worked pretty good, but the nr of positions is limited to a few kb.
wiebe@CARYA wrote:
How does a map help with that? It seems to me you'd still need 'something ordered' to tell the chronology?
Well, the actual implementation is much more complicated. The map key is a flattened long string, while the map data is just an I32 index into an external arrays: A fixed size 2D array containing the actual data, a fixed size 1D array of keys, and a fixed size 1D array of "ages". This lets me find the oldest key to be deleted. (That's how it currently works, but I have some ideas for improvements. Performance is a nonissue, because a cache operations are 100+x faster than a recalculation, so even making it 1000x faster would gain much less than 1% overall. :D)
