Make datatypes of "Quotient and Remainder" VI consistent.

[WG-]

I would suggest that NI makes the datatypes of the "Quotient and Remainder" VI consistent.

If you now wire a double to the VI the outputs are of the datatype "double" however in my opinion this is not consistent with the mathematical definition of quotient, floor(x/y) and remainder, x-y*floor(x/y). The output of the VI is always a integer and should therefore also be of that datatype, thus one of the following datatypes (I64, I32, I16, I8).

[WG-]

Oh and the same counts for "round" "ceil" "floor".

[altenbach]

If x is a fractional value, R is also a fractional value. Try it!

For round, ceil, floor, it is also often better to keep it DBL for further computations to avoid coercions.

Still, I think NI should add an output configuration option to these functions so we can set the output datatype.

[WG-]

@Altenbach oh yeah sorry your right. I was a little to quick on that. But I agree with you that we should have at least an option were we could choose the datatype. It's a better solution because as you meantion sometimes you rather want to have the result the datatype double to prevent coercien dots and sometimes you don't and just want to have the integer value. 

[GregSands]

I'm not keen on making this the default case, but would definitely support being able to change the output type, as you can for Divide and a number of other math functions.  Often I want to keep working with the result as a floating point number (and sometimes not).

[kegghead]

If this were to happen, I agree it would need to be optional. A double could produce a I64 I suppose. Don't have documentation handy, but would we run into trouble with extended precision? Is it a 64 bit significand in addition to a sign bit for the EXT? Or is it a true quad in LabVIEW? Either way none of the integer types will hold those data sizes.

[AristosQueue (NI)]

I think the node is much more usable as it stands today, where the programmer is responsible for doing the coercion to the data types that he/she wants where needed. When I imagine what this looks like on the diagram, it seems to me that adding coercion modes to the node just makes what's happening more obscure, without significantly helping the speed or correctness of programming.

[GregR]

The issue is a range issue and you don't have to use extended to run into it. The largest integer (I64) only handles a range of around -1e19 to 1e19. The smallest floating point (SGL) handles a range around of -1e38 to 1e38. Granted the floating point values won't have full integer precision at these ranges, but the number could be that big both for the quotient and rounding. If we converted to integer, then we would pin these values to the range of whatever integer we chose.

I have often had the same thought, but the full range of values simply cannot be represented in any integer format.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.