LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Range of strings as a case element is not inclusive

Solved!
Go to solution

I was using the following bit of code to translate some string characters into a Base36 but I discovered that the case element with a string range is not inclusive.  For example the following code executes the default case for a "Z" character.  Why is the string range element "A".."Z" not inclusive of its last element but a numeric range 1..10 would be?  Is this a bug?

 

0 Kudos
Message 1 of 7
(4,081 Views)
Solution
Accepted by paulmw

From the LV help:

 

For each case, use the Labeling tool to enter a single value or lists and ranges of values in the case selector label at the top of the Case structure. For lists, use commas to separate values. 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.

 

Edit:  A completely separate discussion is whether this is the desired behavior.  I am inclined to say no, but I am still curious why this behaviour was chosen in the first place.

Message 2 of 7
(4,065 Views)

I can confirm the behavior in 2010 as well.  

Maybe someone can explain why it behaves this way, it seems to be a bug to me.  But the workaround for it, is to add an additional conditional to include the last element.

IE: "a..z" , "z"

 

This resolved the issue, but I think you are right.

 

I stand corrected


Paul
0 Kudos
Message 3 of 7
(4,064 Views)

Thanks Darin,

Didn't see that part of the VI help.  I did look but it was a little hidden.

0 Kudos
Message 4 of 7
(4,049 Views)
Perhaps you should post this little tidbit to the micro-nugget thread.
0 Kudos
Message 5 of 7
(4,029 Views)

@Darin.K wrote:
Perhaps you should post this little tidbit to the micro-nugget thread.

Certainly! Another thread is LabVIEW Minutiae (that may bite you someday), which specifically focuses on potential "gotchas" such as this.

0 Kudos
Message 6 of 7
(4,016 Views)

@Darin.K wrote:

From the LV help:

 

For each case, use the Labeling tool to enter a single value or lists and ranges of values in the case selector label at the top of the Case structure. For lists, use commas to separate values. 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.

 

Edit:  A completely separate discussion is whether this is the desired behavior.  I am inclined to say no, but I am still curious why this behaviour was chosen in the first place.


I ran into this today, and the behavior suprised me at first. But I think I figured out why it makes sense this way.

 

Say you want to match all strings that start with the letter "a", and suppose to the contrary that the range in the case selector was inclusive for strings (so, the second boundary matched like it does for numerics, the way I expected it to). How do you write an inclusive range for all strings that start with "a"?

 

Turns out you can't. For the same reason, you cannot write the maximum number that is less than 2; there is no maximum number that is less than 2, and there is no last string that starts with "a". So, behind the scenes, the case selector is implemented to check (string >= lower) AND (string < upper).

 


@paulmw wrote:

I was using the following bit of code to translate some string characters into a Base36 but I discovered that the case element with a string range is not inclusive.  For example the following code executes the default case for a "Z" character.  Why is the string range element "A".."Z" not inclusive of its last element but a numeric range 1..10 would be?  Is this a bug?


 

Above is why it makes sense for the string range to not be inclusive. Why is the numeric range inclusive, then? The same problem exists where you cannot write the maximum number less than a boundary, doesn't it?

 

The difference is that case structures only let you use integer numerics, so you actually can write the maximum; say the boundary is 2, the maximum integer less than it is 1.

0 Kudos
Message 7 of 7
(2,657 Views)