Why does Q&R take doubles if it can't handle them properly?

[max_]

I want to find the remainder of the division of 2 floating point numbers.

The quotient & remainder vi happily takes 2 dbls. Not even units are a problem. Great, this seems to be possible...not:

And sure enough, the documentation states that precision can cause problems.

But why can I wire double values to this vi if it cannot handle them properly?

It's really hard to find precision problems because the probes don't have enough precision to show the difference. (as seen in the image)

[Norbert_B]

Well, you are running into a race condition. You are using a conditional probe (or static breakpoint) as probe #12. Hitting that breakpoint will immediatly stop VI execution. Hence it is possible that probe #13 is not yet updated!

Please use stepping to verify all values for the iteration of the for loop instead of a single "random probe shot" of the Q&R function.

Also note that i was not able to reproduce the values of your probes using Q&R outside a loop with a full VI execution (no breakpoint) using LV 2014.

Norbert

[max_]

I bundled both output values from Q&R into a cluster and stopped there, this should prevent any race condition.

The result is the same:

How did you try to reproduce the values without knowing them?

The probes do not show the full precision of the numbers.

[Norbert_B]

I took the values you have in the probes in the screenshot. If these do not match the exact numbers you are passing, please provide them here.

thanks,

Norbert

[GerdW]

Hi max_,

the precision of floating point numbers (or the lack of) has been discussed several times before. Also the usage of QR function with DBLs was discussed in long threads before!

The result of "3" as modulo result is perfect in line with expected result: "0.02" cannot represented with floating point numbers and will most likely be something like "0.01999…97" internally. "0.005" cannot be represented as float too and results in "0.0050…011". The QR operation gives you 3 as integer part and "0.00499…98" as fractional part…

Your ideal world operation: 0.02 \ 0.005 = 4, remainder 0

Real world scenario: 0.0199…98 \ 0.0050…01 = 3 remainder 0.00499…98

That's not the fault of the QR function. It's the fault of the programmer not handling known issues of the used datatype, described in scientific papers and IEEE standards!

[max_]

dear Norbert,

thanks for helping, but I'm not sure what you are after.

As I stated in my first post, this is a precision problem and that's what makes the Q&R fail.

I'm not asking "Why does the Q&R fail?".

I am asking "Why can I use floating point values with Q&R if they don't always work properly (due to precision)?"

I also want to know how to change the displayed precision of probes to identify these problems more clearly and easily.

As you experienced yourself, the probes do not show what's going on exactly.

This makes debugging very difficult.

[GerdW]

Hi max_,

Why can I use floating point values with Q&R if they don't always work properly (due to precision)?

As stated before: the programmer is responsible of it's work. When you use QR operation it's your task to ensure correct results.

It is the same for a simple division (or any other simple math operation): always think about float precision! Try to add numbers like 1E19 and 1E-19 using DBL: it will fail due to precision…

QR can be used for floats as you may store integer values in floats. Floats could also be accurate, when they just store "nice" numbers (aka numbers expressible as float). QR operation is defined for floats…

how to change the displayed precision of probes

Create your own custom probes…

[max_]

thanks Gerd for trying to help me out here,

I'm aware of issues caused by floating point numbers, I stated that this is the cause of the results of the Q&R vi in the very first post.

I'm asking why it takes double values despite those "known issues of the used datatype, described in scientific papers and IEEE standards"

[GerdW]

Hi max_,

I'm asking why it takes double values

That's why I wrote "it's your task to account for problems"!

When you ask for the QR operation you need to ask for other operations too! Even a simple ADD will give you wrong results as noted above! Do you want to ban the ADD operation too from using floats?

The point is: FLOATs have limited precision - with each operation. It's YOUR task to account for that limited precision.

[JLewis]

As Gerd says, the precision issues are an inherent tradeoff with using binary computing in a base 10 world. Computers simply can't compute the same numbers we see in the display (unless you use a decimal data type, which is common in the financial industry but not in science and engineering applications).

Operators have no control over these precision issues--the best we can do is to define how they operate on the data that is presented to them. In that sense, the Q&R operator perfectly meets its specified behavior per IEEE standards. It has no control over the incoming data, which is by definition an approximate mapping to some real-world value. Even if we made everything work exactly in base 10 arithmetic, you would still have issues because there would still be no way to represent the value 1/3 exactly.

Your point about debugging being difficult without enough probe precision is valid, but on the other hand, these types of errors are so ubiquitous that you also need to be able to recognize that in general values you see in a decimal display will not be represented exactly if they can't be expressed as a sum of power-of-2 terms.