LabVIEW
Translating a string into a number (Homework Help)
Solved!
@Paddle_to_the_sea21 wrote:
I have saved it for the 2016 version hopefully this works!
It is extremely inefficient and tedious to maintain a case structure with 11 cases, Not really scalable and many places of buts to hide.
See if this can give you some ideas.
(And yes, you could create a map for even simpler code).
@altenbach wrote:
(And yes, you could create a map for even simpler code).
Here's how that could look like!
You can figure out how to create that map constant from the earlier array of clusters 😄 )
@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.
It's not just the size of the collection. It's also the number of times it's called.
For this homework assignment it's completely irrelevant, but still a fun topic.
Search LabVIEW like a graph! 
@altenbach wrote:
@Paddle_to_the_sea21 wrote:
I have saved it for the 2016 version hopefully this works!
It is extremely inefficient and tedious to maintain a case structure with 11 cases, Not really scalable and many places of buts to hide.
See if this can give you some ideas.
(And yes, you could create a map for even simpler code).
I like the OP solution simply because they wrote it themselves. It's a successful effort in line with their experience.
@billko wrote:
@altenbach wrote:
@Paddle_to_the_sea21 wrote:
I have saved it for the 2016 version hopefully this works!
It is extremely inefficient and tedious to maintain a case structure with 11 cases, Not really scalable and many places of buts to hide.
See if this can give you some ideas.
(And yes, you could create a map for even simpler code).
I like the OP solution simply because they wrote it themselves. It's a successful effort in line with their experience.
Yes, the OP clearly showed some effort and the remaining problems (e.g. the empty string confusion) have been solved. Once the code does what it should, we can offer improvements and comments, just as a learning experience and encouragements to dive just a little deeper. 😄
Basically, we can show that sometimes less is more. Scalability, (e;g; ease of making changes if the cypher changes), readability are all useful foundations that will help making 100x more complex programs possible with only 5x the effort. 😄
@altenbach wrote:
@billko wrote:
@altenbach wrote:
@Paddle_to_the_sea21 wrote:
I have saved it for the 2016 version hopefully this works!
It is extremely inefficient and tedious to maintain a case structure with 11 cases, Not really scalable and many places of buts to hide.
See if this can give you some ideas.
(And yes, you could create a map for even simpler code).
I like the OP solution simply because they wrote it themselves. It's a successful effort in line with their experience.
Yes, the OP clearly showed some effort and the remaining problems (e.g. the empty string confusion) have been solved. Once the code does what it should, we can offer improvements and comments, just as a learning experience and encouragements to dive just a little deeper. 😄
Basically, we can show that sometimes less is more. Scalability, (e;g; ease of making changes if the cypher changes), readability are all useful foundations that will help making 100x more complex programs possible with only 5x the effort. 😄
Oh, yes. I completely agree. I just hope they use their homegrown solution because they earned that one. 🙂
