Taylorh140 Posted November 29, 2017 Report Share Posted November 29, 2017 I noticed something inconsistent today with case selector, specifically the inclusion of the sequence terminators. Guess the outputs for Q1-4. The purpose of this post is mostly to help others not make this (seemly easy) mistake. Also to ask how is this discrepancy useful? Quote Link to comment
ensegre Posted November 29, 2017 Report Share Posted November 29, 2017 you mean "String ranges: A range of a..c includes all strings beginning with a or b, but not c." which is known and stated? I read time ago a discussion about its rationale, but I don't remember where. Quote Link to comment
Taylorh140 Posted November 29, 2017 Author Report Share Posted November 29, 2017 Absolutely, I find it weird. It doesn't match the Integer notation and even more so it includes the first item but not the last. I was using to match numeric 0-9 which yes you could use a regex but its a range 0-9 simple case statement should work. its weird to put "0"..":" I had to reference my ASCII table just to know which one to use. And I do agree it is stated in the reference above, but I generally dislike inconsistency especially with logical concepts that should be transferable; just because something is known doesn't mean it cannot be incorrectly inferred or forgotten. That being said, I would really like to know the rationale, however if there has to be a discussion it doesn't bode well for the "feature". Quote Link to comment
drjdpowell Posted November 29, 2017 Report Share Posted November 29, 2017 With integers you can do ranges like <=3 and >=4, and there is no gaps. But with non-integers you cant: <=3 and >=4 misses out all numbers between 3 and 4. But you also can't do <=4 and >=4, since then 4 falls in both ranges. So you have to do <4 and >=4, and thus have a range (<4) which does not include its endpoint, confusingly. Strings are actually more like floats, than like integers; between "c" and "d" is "ca", "cz", "czzzzzzzzzzzzzzzzzz", etc. Even if "a..c" included "c", it would not include "ca". There is no way to do non-overlapping-but-complete ranges with strings without not including one endpoint. Unfortunately, people intuitively think of "a..c" as anything starting with "a" to "c", but it isn't. Quote Link to comment
Darren Posted November 29, 2017 Report Share Posted November 29, 2017 rolf's explanation is the best discussion of the string range rationale I've seen: https://forums.ni.com/t5/LabVIEW/Darren-s-Weekly-Nugget-03-09-2009/m-p/867644#M392955 Quote Link to comment
ShaunR Posted November 30, 2017 Report Share Posted November 30, 2017 I've been doing C++ recently after a very long time. I'd almost forgotten how much pain is circumvented with LabVIEW case structures. With no multi-line literals (can't just paste a key into a page). No "switch" [case statement] with strings.....period. Case sensitive whether you like it or not. Thank god it's almost over and then I can control it with LabVIEW. Quote Link to comment
Taylorh140 Posted November 30, 2017 Author Report Share Posted November 30, 2017 I see what your saying now. When looking at a single ASCII character it would make sense to include the last point just like they do with integers. however there is not a character type only a character array type (string), and in an effort to make the case statement ranges more useful in the string realm they made a notation that is essentially a begins with function. (regex would probably be more useful/but slightly slower). This does explain it a bit though. @ShaunR I am also glad it is not C++. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.