in range and coerce oddity

[elset191]

From the v. 8.6.1f1 help file

---

To change whether the function includes the value wired to upper limit or lower limit, right-click the function and select Include upper limit or Include lower limit from the shortcut menu to include or remove the value in the range. These options only affect the result of In Range?. The function always coerces x to the exact values of upper limit or lower limit, regardless of whether you select Include upper limit or Include lower limit from the shortcut menu.

---

Is there a reason for this?  I was trying to coerce something and it took me a fair amount of time to realize what was happening and to look into the help file.  Frankly, I'm kind of surprised I haven't run into this yet.

[smercurio_fc]

Well, if you think about it, it kind of makes sense. The function defaults to work with DBLs. Let's say you're talking about the upper limit and you leave it as a hollow diamond and wire in a DBL constant of 3.5. What's the function supposed to coerce a DBL X to on the upper side? 3.49? 3.4999999? 3.49999999999? That's the problem with DBLs.

[elset191]

Oh, yeah, doubles.  Makes sense now, thanks

[GeoffF]

Sorry to re-activate a very old thread, but I've just run into this oddity myself.  In my not-so-humble opinion, if the top of the range is not included, the coerced value should be to the max minus one LSB.  Of course, with floats that creates issues with underflow, but that's not insurmountable.  (For the min, there's the overflow issue, of course.)  For integer values, it would be really useful if we didn't have to throw in a decrement on the Array Size function before using the index.  The image below indicates the sort of use I'd like to be able to do without the index wandering off into la-la land:

 

Regards,

Geoff

[Intaris]

If your array size is 10, you're telling the function to coerce between 0 and 10 which are actually 11 elements.

That's wrong.  I understand what you're trying to do with the "do not include upper limit" but that's not what it is there for.  It's there for only the "In range" portion of the "In range and coerce".

Just input a -1 before the in range and coerce function and you're all set.

The function works exactly as it says on the box.  Adapt and survive.

Plus, you openly admit that your "solution" creates additional problems.  This is far too small an issue to warrant revising how a quite frequently-used primitive should behave.  If you want you can create your own sub-VI (inline it if you want) to do exactly what you're looking for.  This, at least, won't break everyone else's software who uses this function properly.

Shane.

[GeoffF]

Not a bad idea at all, Shane.  I've put that sub-VI in my task list.  I'd put it into our electronic suggestion box (Kaizen) system as well, but the scope of application is too narrow for it to be worth broadcasting to our largely non-LabVIEW-literate organisation.