LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

why is the output of rounding functions a double?

I thought the whole idea of rounding was ending up with an integer?

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 1 of 16
(2,979 Views)

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.


___________________
Try to take over the world!
Message 2 of 16
(2,975 Views)

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.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 3 of 16
(2,929 Views)

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.

Rolf Kalbermatter
My Blog
0 Kudos
Message 4 of 16
(2,893 Views)

@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.  😄

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 5 of 16
(2,860 Views)

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.

Rolf Kalbermatter
My Blog
Message 6 of 16
(2,855 Views)

@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)


"Should be" isn't "Is" -Jay
Message 7 of 16
(2,850 Views)

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!

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 8 of 16
(2,844 Views)

@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.

 

Message 9 of 16
(2,835 Views)

@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.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 10 of 16
(2,813 Views)