From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
09-24-2021 09:58 AM - edited 09-24-2021 09:58 AM
@rolfk wrote:
As to coerced returning the limit despite it being excluded, that is very logical for floating points values. What is the logically correct next smaller value to return in that case? The Limit - Machine Epsilon? Or the Limit - 1% of it? Or something totally different? The easiest is just to coerce the range simply always to the limits and don't try to be smart about well or not subtracting/adding something if the according limit is excluded.
Sure, it makes sense for floats, and it's clearly documented, but that doesn't mean I got didn't get bit by assuming it coerces to in range and got an array out of bounds error the first time I tried it 🙂
09-25-2021 12:44 AM
@rolfk wrote:
There are many reasons for the function to be like it is.
The default of not including the upper limit is for mathematical reason quite correct. That statistics don't always seem to favor what we flawed humans consider common sense is another story, but there are good reasons for this.
Yes I also usually use this function with both limits included, except for floating point values where I usually don't want that value included.
And if you exclude one of the ends you don't need to use different constants if you stack two of those nodes to get two consecutive ranges. If both limits are included you could get values that belong to both ranges.
As to coerced returning the limit despite it being excluded, that is very logical for floating points values. What is the logically correct next smaller value to return in that case? The Limit - Machine Epsilon? Or the Limit - 1% of it? Or something totally different? The easiest is just to coerce the range simply always to the limits and don't try to be smart about well or not subtracting/adding something if the according limit is excluded.
Most of these choices are not arbitrary but done after days and days of debating in the development team. And if an issue is controversial, the mathematical correct way almost always wins over the arbitrary human common sense.
Of course they aren't arbitrary, but 98% of the time I only use this function singly, without stacking. I think most people here do the same thing, so I was curious what led the dev team to believe they would most likely be used in a stacked way? To me it seems to be defaulting to an almost corner use case.
It is interesting that you find that you usually don't include the limits when using FP numbers. I do the opposite. What is the reasoning behind this? Maybe I am going about it wrong.
And the reason for the naming of the "String to Decimal Value" and it's reverse - let's not even go there. 😄