10 replies to this topic

[mike5]

Here is a little something I found today:



and the VI that demonstrates it. Run this, and

String 1="bug"
String 2="z"

Change zip->yip and String 1 becomes "y".

Nice, ha?

Br, Miha

The workaround is "a".."z", "z"



Br, Miha

Attached Files

•  bug.vi   7.33K   51 downloads

[crossrulz]

It's actually not a bug. The case structure is just not range inclusive for strings.

[mike5]

It is a bug, since either it is or it isn't. But this one isn't just in the first case. In case of a constant it is.

Br, Mike

Also, it also works for any string beginning with "a", so my guess is still it's a bug.

Br, Miha

[Saverio]

From the LabVIEW Help:

For numeric ranges, specify a range as 10..20, meaning all numbers from 10 to 20 inclusively. You also can use open-ended ranges. For example, ..100 represents all numbers less than or equal to 100, and 100.. represents all numbers greater than or equal to 100. For string ranges, a range of a..c includes all strings beginning with a or b, but not c. A range of a..c,c includes the ending value of c.

Not a bug.

[Samapico]

How does that explain string 2 being "z" ? The two results appear to be contradictory... According to the help, String 2's result would appear to be a bug...


But I'm still wondering: why would they make string ranges non-inclusive? In what case is it useful? Considering numeric ranges are inclusive, this really seems to be counter-intuitive.

Edited by Samapico, 14 October 2011 - 01:54 PM.

[Saverio]

Sorry, I was explicitly referring to the "inclusiveness" in terms of whether it's a bug or not. You seemed to be implying that the non-inclusiveness is a bug. In actuality, the bug is that in the second case, LV 2010 is not behaving correctly. When you wire in a constant it does one thing, but when you wire in an output of a string function it does something else. That seems to be a compiler issue. In LV 2011 it behaves correctly, i.e., according to the documentation. You may disagree with it, but that does not make it a bug.

I do not know the reason why the string range was made non-inclusive. That's something you'd need to ask NI. You can always lobby to have the behavior changed by posting an idea in the LabVIEW Idea Exchange.

[Darin]

Just slap an 'Always Copy' node after the constant in the second case and it is all good (LV10). They should probably change the icon of that function to a band-aid. (Of course the number of places you need this is supposedly declining, but it is still good to know for those of us stuck with old versions).

[mike5]

From the LabVIEW Help:

For numeric ranges, specify a range as 10..20, meaning all numbers from 10 to 20 inclusively. You also can use open-ended ranges. For example, ..100 represents all numbers less than or equal to 100, and 100.. represents all numbers greater than or equal to 100. For string ranges, a range of a..c includes all strings beginning with a or b, but not c. A range of a..c,c includes the ending value of c.

Not a bug.

Thanks. I guess it's just one of those things where you never actually read the docs, because you use the thing every day.

Br, Mike

[Gary Rubin]

So I can make all my bugs go away by simply describing the behavior in mydocumentation? Awesome!

[Saverio]

So I can make all my bugs go away by simply describing the behavior in mydocumentation? Awesome!

Who knows, maybe NI meant it to work that way. Inquiring minds would like to know...

[Darin]

Who knows, maybe NI meant it to work that way. Inquiring minds would like to know...

For better or for worse (separate discussion), LV has no notion of a 'char', only strings or byte arrays. The selector has to be interpreted as a string, and therefore one of the limits must not be inclusive (upper one makes slightly more sense). Otherwise you would sometimes need to write the "biggest" string which starts with b, is it bzzz or bzzzz or bzzzzz.... This is also what currently precludes floats from the selector.

I wish we could specify the inclusiveness of either bound using standard '[' versus '(' conventions. You could then write ["a".."c"] or ["a".."c") or ("a".."c"]. This would also allow floats to be used which would be very cool IMO, you could have NaN, +Inf, -Inf, [0..3), [3..6), cases.