Limit error on trig Circle functions

[Joshua Y]

Why does J hit a limit error with sin/cos/tan on values larger than 596313653?

   1 2 3 o. 596313653
_0.0510929 _0.998694 0.0511597
   1 2 3 o. 596313654
|limit error, executing dyad o.
|a system limit was exceeded
|   1 2 3     o.596313654

This limit doesn't appear in any other language I tried.

This is happening in the current beta, as well as on the Playground which is running version 902, so it appears it's not new.

[Clifford Reiter]

I think there was a discussion of this a couple decades ago (smile)

I don't recall why this particular limit occurs, but there is a problem that can be illustrated.

We expect floating computation to be good to about 14 decimal places since comparison tolerance is 2^_44

2^_44

5.68434e_14

a=:596313653.0

]s1=:1 o. a

_0.0510929

]s2=:1 o. a-2p1*<.a%2p1

_0.0510929

s1=s2

0

s1-s2

1.37748e_8

To unsubscribe from this group and stop receiving emails from it, send an email to forum+un...@jsoftware.com.

[Clifford Reiter]

Sorry, accidental premature send.

But we see we can only trust far fewer decimal places when taking trig values of large numbers.

Yes, Mathematica gets the same s1-s2 and will let you use larger a and be aware of how little you can trust the result.

I take it as an annoyance but a reasonable alert(!) too.

Best, Cliff

[Henry Rich]

Cliff has it right. Float has only 17 digits of precision; if you put 9 of them into the discarded integer part not much is left for the sin result. Think of it as a precision warning, which you are free to override by taking the remainder of the argument mod 2p1. 

The float16 type has more precision in the sin, but you would need to create a precise float16.

Henry Rich

[Joshua Y]

Thanks for the info Cliff (and Henry).

I figured it would be an accuracy thing, as the only result I could find when searching that number online was this short article on estimating pi, where it specifically mentions values larger than 596313653 being a limitation

https://egandunning.com/piday2018.html

I personally stumbled across it while playing playing around generating some graphics... so in this situation, even an inaccurate value that doesn't crash would be preferable.

I worked around it by clamping the values at that maximum

load 'viewmat'
Limit =: 596313653&{{ x <. (-x) >. y }}
Tan =: 3 o. Limit
F =:  {{ Tan (- y) % >./ (x-50),(y-50),(49-x),:(49-y) }}
viewmat 15 (17 b.) <. F/ |: (#: i.) ,~ 100

As you said, it's a minor annoyance... but I think at least the documentation should probably mention this limit.