Sine and consine gives erroneous values for large arguments

[Anders Björk]

Dear all

Sin and cos functions gives non bound values if the argument is large than 9.2e18 then it will output a value in the same region. This could introduce large error if labview would be used for certain simulations. I also note the there is not a word in the help text about this.

I have tested it in both 7.1.1 and 8.5.1. I hope it doesnt work this way in 8.6.

[Francois Normandin]

It's happening in 8.6 too.

We're at the limit of resolution of the algorithm. In DBL precision, this happens around 1E+14 or so.

I tried to wrap the Large EXT control to 0-2pi interval and I should have gotten the full EXT resolution (see pic)

Except that the division seems to be suffering from the same problem and it doesn't work. Since the sine and cosine are most probably calculated using some Taylor series (x^n/n! type of equation), we run into serious problems with 9E18^n/n!. I don't know which "n" is being computed, but if you compute until you converge, it could explain the algorithm becoming unstable.

[brian]

We basically pass the number directly to the "fsin" x87 instruction, and depend on it to produce a reasonable result.

The Intel processor does not, when the input is large.

For example, if I have "1e19" at the top of the floating point stack, and execute the "fsin" instruction, the top of the floating point stack is supposed to change to the result of sin(1e19). Instead, it just leaves the top of the stack alone. LabVIEW reflects the results of the instruction, even though the instruction doesn't do the right thing. Note that Intel documents that the domain of fsin is +/- 2^63.

We've known about this for some time, and were unsure whether the performance tradeoff was worth it. (Of checking the domain or range and doing a different algorithm.) We'll look at it again.

Note that non-Intel processors generally behave better in this area.

Brian

[Anders Björk]

Brian

Ihope you are not using the same code for the math scripts, because it would indeed give strange results when moving code from matlab to the math script. Matlab handles large arguments well.

How does other major program languges handle this case with large arguments to sine functions?

[shoneill]

QUOTE (brian @ Sep 12 2008, 05:36 PM)

We basically pass the number directly to the "fsin" x87 instruction, and depend on it to produce a reasonable result.

The Intel processor does not, when the input is large.

For example, if I have "1e19" at the top of the floating point stack, and execute the "fsin" instruction, the top of the floating point stack is supposed to change to the result of sin(1e19). Instead, it just leaves the top of the stack alone. LabVIEW reflects the results of the instruction, even though the instruction doesn't do the right thing. Note that Intel documents that the domain of fsin is +/- 2^63.

We've known about this for some time, and were unsure whether the performance tradeoff was worth it. (Of checking the domain or range and doing a different algorithm.) We'll look at it again.

Note that non-Intel processors generally behave better in this area.

Brian

Maybe a reason to go for a Phenom instead of a Core2Quad then...... That and 16GB RAM support? When's LV 64-bit coming out?

Anyone have a comparison between an Intel and AMD chip in this regard?

Shane.

[Phillip Brooks]

QUOTE (shoneill @ Sep 17 2008, 04:04 AM)

Maybe a reason to go for a Phenom instead of a Core2Quad then...... That and 16GB RAM support? When's LV 64-bit coming out?

There is a http://forums.ni.com/ni/board/message?board.id=170&thread.id=319502' target="_blank">pioneer beta program for 64 bit LabVIEW that you can sign up for...

[brian]

QUOTE (shoneill @ Sep 17 2008, 03:04 AM)

When's LV 64-bit coming out?

Anyone have a comparison between an Intel and AMD chip in this regard?

I tried 64-bit LabVIEW on Windows Vista, and it yields the same result as 32-bit LabVIEW.

I have not tried an AMD processor, but I predict it will match Intel.

Brian

[shoneill]

QUOTE (brian @ Sep 17 2008, 04:19 PM)

I tried 64-bit LabVIEW on Windows Vista, and it yields the same result as 32-bit LabVIEW.

I have not tried an AMD processor, but I predict it will match Intel.

Brian

Well then which processors were you referring to with "Note that non-Intel processors generally behave better in this area.".

Shane.

[brian]

QUOTE (shoneill @ Sep 17 2008, 10:23 AM)

Well then which processors were you referring to with "Note that non-Intel processors generally behave better in this area.".

What I meant, and I now realize is incorrect, is PowerPC, SPARC, and PA-RISC. All of those are RISC processors, and don't have sine instructions built into them.

So at the processor level, I guess we'd have to go back to the MC680x0/6888x processors, which I believe handled this situation better.

On the RISC processors, we depended on math libraries to implement the transcendentals. Sun's, based on BSD, was particularly good. HP's was particularly bad, so we used a free math library instead. I don't recall how good Apple's were; I think it depended on the compiler we were using at the time.

Brian

[Edit: I'll add that we don't use Microsoft's libraries for this level of floating point work, because it doesn't support the IEEE-754 Extended Precision encoding.]

[shoneill]

QUOTE (brian @ Sep 17 2008, 08:30 PM)

What I meant, and I now realize is incorrect, is PowerPC, SPARC, and PA-RISC. All of those are RISC processors, and don't have sine instructions built into them.

So at the processor level, I guess we'd have to go back to the MC680x0/6888x processors, which I believe handled this situation better.

On the RISC processors, we depended on math libraries to implement the transcendentals. Sun's, based on BSD, was particularly good. HP's was particularly bad, so we used a free math library instead. I don't recall how good Apple's were; I think it depended on the compiler we were using at the time.

Brian

[Edit: I'll add that we don't use Microsoft's libraries for this level of floating point work, because it doesn't support the IEEE-754 Extended Precision encoding.]

OK. Thanks for the clarification. I was kind of hoping you're let something slip about LabVIEW on a Cell processor :ninja: .......

Shane

[jpdrolet]

First, at 9e18, the precision of a double is 1024, e.g. 1024 is the lowest increment you can change a number that large.

Since 1024 is much larger than 2pi you can't expect any precision of sine function for numbers that large.

Second, sine(2pi) gives -2.44921E-16 not because the imprecision of the function, but on the precision of DBL(2pi) itself.

DBL(2pi) is not exactly 2pi so the sine is not absolutely 0. You can change the representation of the constant 2pi (use Right Button Menu) to make it an EXT. Sin (EXT(2pi)) is then improved to 1.0842E-19.

[Anders Björk]

Now I have check the mathscript node and it also gives wrong results... I conclude that the mathscript node is not matlab compatible for basic trigometric calculations, octave does this better than Labview...