11-20-2014 11:37 AM
I thought the whole idea of rounding was ending up with an integer?
11-20-2014 11:44 AM - edited 11-20-2014 11:45 AM
Most likely the reason is to avoid mixing data types. Presumably, if you're rounding something, it's often because you want to keep using the new value with additional calculations. If you wired it to other nodes which accepted floating point values, you would just get coercions.
Also, the ranges for the integer data types (certainly when the rounding primitives were added and the most you had was U32) are not large enough to cover all the values that floats can have, so that's another good reason.
Some numeric primitives can have their properties set to output a specific data type. I don't know if the rounding ones do, but it should be easy enough to check.
11-20-2014 05:49 PM
This would make it useless for comparing to a true integer, though - by itself, anyway. But you reminded me of something when you mentioned coercion. I can just use something from the conversion palette to do whatever I want with the result.
11-21-2014 03:53 AM
It returns whatever datatype you input in it. Makes a whole lot of sense as anything else would require allocation of a new data value in memory.
11-21-2014 09:03 AM
@rolfk wrote:
It returns whatever datatype you input in it. Makes a whole lot of sense as anything else would require allocation of a new data value in memory.
Returning the same datatype sounds fine and dandy - until you think about it carefully (from the user experience side of it). Why would you put anything but a fractional number into it? So it's always going to return an approximation of an integer unless you actually plug an integer into it? It just seems silly - strictly from a user standpoint - that you have to take one more step to get an actual integer. To me, it's unexpected behavior, no matter how much sense it makes technically. Again, though - all you have to do is coerce it to whatever you need it to be and only generate a new data value only when you have to.
I feel a little like I'm X. right now. 😄
11-21-2014 09:13 AM
I understand your reasoning but think about it one more moment.
What should LabVIEW return then: int32? Nahh a double float can easily overflow that, an int64? Naaah, I have an application that only can have positive values so give me an uInt64 please, or what the heck my value range is only -+127 so give me an int8!!! You'll see you will often end up with an additional conversion anyhow so what LabVIEW does now is not only technically correct but also logically. The resulting output datatype is always guaranteed to be big enough if the incoming datatype could already handle the value.
11-21-2014 09:37 AM
@rolfk wrote:
I understand your reasoning but think about it one more moment.
What should LabVIEW return then: int32? Nahh a double float can easily overflow that, an int64? Naaah, I have an application that only can have positive values so give me an uInt64 please, or what the heck my value range is only -+127 so give me an int8!!! You'll see you will often end up with an additional conversion anyhow so what LabVIEW does now is not only technically correct but also logically. The resulting output datatype is always guaranteed to be big enough if the incoming datatype could already handle the value.
And of course the small point rolf failed to hit... Rounding operations on floating point numbers are part of the IEEE 754 standard. By definition per IEEE 754 the ouput is an IEEE 754 floating point number. (Of COURSE it is not "Right!" to any 3rd graderstudent but, it IS correct as approved by all those phd's)
11-21-2014 09:47 AM - edited 11-21-2014 09:49 AM
Hi billko,
It just seems silly - strictly from a user standpoint - that you have to take one more step to get an actual integer.
It may seem silly to you - but not for the "average" user…
Use cases:
- round to certain accuracy: multiply your float by scaling factor, round to nearest "integer" value, divide by scaling factor. (Beside rounding errors) you you will get a float with a certain number of decimal digits and the whole way through you want to keep it a float.
- you can keep integer numbers also in float representation. A SGL can store integers with 23 bit mantissa, a DBL uses 52bits mantissa and an EXT keeps 64bits of mantissa… When you use arrays to store numeric values you can easily store I32/U32 values in a DBL array!
11-21-2014 09:57 AM
@billko wrote:
So it's always going to return an approximation of an integer unless you actually plug an integer into it?
Floating point datatypes represent integers exactly and the output of any rounding operation is thus guaranteed to be an exact whole number, indepedent of datatype. There is no "approximation" and the generic warnings about comparing floating point numbers can be ignored here. No need to convert to integer, which could cause other problems. Ignore the coercion dot!
Comparing it with an integer datatype is safe as long as long as you remain within the valid datarange of each.
11-21-2014 11:10 AM
@altenbach wrote:
@billko wrote:
So it's always going to return an approximation of an integer unless you actually plug an integer into it?Floating point datatypes represent integers exactly and the output of any rounding operation is thus guaranteed to be an exact whole number, indepedent of datatype. There is no "approximation" and the generic warnings about comparing floating point numbers can be ignored here. No need to convert to integer, which could cause other problems. Ignore the coercion dot!
Comparing it with an integer datatype is safe as long as long as you remain within the valid datarange of each.
That's very interesting. Actually, everything posted was very interesting and it led me to a deeper understading of fractional numbers. I should probably give a round of kudos to everyone for replying.