Jump to content

Sine and consine gives erroneous values for large arguments


Recommended Posts

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.

Link to comment

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.

post-10515-1221169123.png?width=400

Link to comment

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

Link to comment

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.

Link to comment

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

Link to comment

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

:unsure:

Shane.

Link to comment

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

Link to comment

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

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.