Translating a string into a number (Homework Help)

[mcduff]

This seems made for Maps. A lot less elegant and performant than Altenbach's solution, but will easily allow you to change the key to different letters, symbols, or even non-printing characters if needed.

snip.png

[wiebe@CARYA]

Maps are certainly faster than a linear search (like log(O) vs (O), although IIRC theoretically log(log(O)) is possible).

A sorted array is also a valid option. Still log(O), but searching a sorted array is faster than searching a map (as a map search has to traverse the pointers of the binary tree, a sorted array doesn't). Inserting into a sorted array is slower, but there's none of that in this exercise.

But a (simple array index) LUT is much faster than both (something like (1) vs log(O)).

As the character is treated (for now) as a U8, a LUT would still be clear and the fastest.

I'd certainly make sure the code lives in something contained, like a vilib or lvclass  By hiding the implementation and making low level functions private, you make sure you can change (and test) the implementation without problems.

[altenbach]

For a map with 10 elements, the difference between a plain search O(N) and a map O(logN) does not justify the map overhead. That only starts to matter for larger collections. A LUT is O(1) and the max size here is tiny (256 elements) that can be constant folded.

[Paddle_to_the_sea21]

Awesome thank you! So I ended up trying a different approach to this (attached). Now my problem is I can't seem to get the right output but it may be because of my case structure. As well, for the message I switched it so that it isnt a,b,c etc but can be other characters. I have attached a screenshot as well as the VI that I am currently working on for this problem. 

Paddle_to_the_sea21_0-1741189574878.png

[mcduff]

---

@altenbach wrote:

For a map with 10 elements, the difference between a plain search O(N) and a map O(logN) does not justify the map overhead. That only starts to matter for larger collections. A LUT is O(1) and the max size here is tiny (256 elements) that can be constant folded.

---

I get it that a LUT is faster, but don't completely understand "does not justify the map overhead". Are you referring to setting up the map, populating the map, reading elements from map... 

[altenbach]

---

@mcduff wrote:

---

@altenbach wrote:

For a map with 10 elements, the difference between a plain search O(N) and a map O(logN) does not justify the map overhead. That only starts to matter for larger collections. A LUT is O(1) and the max size here is tiny (256 elements) that can be constant folded.

---

I get it that a LUT is faster, but don't completely understand "does not justify the map overhead". Are you referring to setting up the map, populating the map, reading elements from map... 

---

A map is an advanced data structure and while only about log2(N) comparisons need to be made for a lookup, it is a more expensive operation per comparison. (In this case, the map is fixed and insertion and deletion operations are irrelevant).

(For more details, have a look at my 2019 NI-Week presentation)

Big O complexity Says nothing about speed, just about the limiting behavior as a function of N.

[altenbach]

---

@Paddle_to_the_sea21 wrote:

Awesome thank you! So I ended up trying a different approach to this (attached). Now my problem is I can't seem to get the right output but it may be because of my case structure. As well, for the message I switched it so that it isnt a,b,c etc but can be other characters. I have attached a screenshot as well as the VI that I am currently working on for this problem. 

---

If you want more people to look at your VI, do a "save for previous" (2020 or below) before attaching. I currently cannot open it.

Form the picture, there is a lot of "code smell".

• Apparently the problem has changed and now you have two characters per symbol.
• The result must be an integer, not a floating point number. There should be nothing orange!
• No matter what numeric output data type you pick, you'll quickly run out of bits for longer inputs. You cannot have a scalar numeric output for a general solution

[Paddle_to_the_sea21]

I have saved it for the 2016 version hopefully this works!

[NIquist]

You are on the right track.  One good debug trick is to turn on the little light bulb so you can watch your code run on the block diagram.  

NIquist_0-1741199703116.png

You can also right-click a wire and use a probe.  Try probing the string output of you loop before the String to Number VI to see why it can't decode a number.  (you should also be using the DECIMAL string function, not the Fractional 😉).

Hint for your problem:  Using two quotes that look like an empty string is NOT an empty string.  Erase them or use the empty string constant in the string palette.

NIquist_0-1741199385591.png

[NIquist]

Also don't forget to verify your attempt to ignore undefined characters by concatenating a -1 into your string.  How is the string to number conversion going to like a dash in the string???  And what happens when there are many undefined characters?  Your loop iterations are not taking them into account are they?  Try some long strings with a mix of good and bad inputs.  Use probes and the light bulb to see what's happening in your code...