Group Abstract Group Abstract

Message Boards Message Boards

0
|
1.1K Views
|
33 Replies
|
18 Total Likes
View groups...
Share
Share this post:

Modulo reduction of input for trigonometric functions

Posted 3 months ago

For reducing such input from a range (-infinity; +infinity) to the target interval (-π; +π] on which trigonometric functions shall operate, the original input must be taken modulo 2π. Performance of such a modulo reduction on limited hardware systems depends on the number of digits you provide for 2π. Said number may be in the order of some hundred to some thousand. How can I specify this number for WolframAlpha?

WolframAlpha understands my request to give me, e.g., 700 digits of 2π and returns them properly. But if and when I try to compute a given real number modulo (700 digits of 2π) it fails to decode my wish and, alas, doesn't advise me what to do instead. Any hint in this matter is appreciated. Thanks in advance.

POSTED BY: Walter Bonin
33 Replies
Posted 3 months ago

Just found a nice WA function called SetPrecision which seems to do what I was looking for at the beginning.

POSTED BY: Walter Bonin
Posted 3 months ago

And there's one more called WorkingPrecision. :)

POSTED BY: Walter Bonin
Posted 3 months ago

At the bottom line, WA help is not as bad as it may look at begin - you just have to know what you can ask it - which is a challenge when you're new.

POSTED BY: Walter Bonin

In Mathematica, there are many ways to query W|A:

WolframAlpha[
 "mod((5.319372648326541416707296656673541083813\[Times]Power[10,255]), floor(2\[Pi],1e-300))",
 {{"Result", 1}, "Input"}]

(*
HoldComplete[
 N[2326715750885135227722015087503208099776282190279020699009796281454\
1713726221167400498290727918991932135286754788638449926119522518934068\
2632613210895362232864883270098925229597751205823812489250286643791841\
0121858725583746190999935773720362130194788700541276799300257996675410\
58021507834662746151623/
   6250000000000000000000000000000000000000000000000000000000000000000\
0000000000000000000000000000000000000000000000000000000000000000000000\
0000000000000000000000000000000000000000000000000000000000000000000000\
0000000000000000000000000000000000000000000000000000000000000000000000\
0000000000000000000000, 301]]
*)

This yields a 301-digit answer.

POSTED BY: Michael Rogers

Apparently, W|A replaced 5.319372648326541416707296656673541083813 with the rational number

5319372648326541416707296656673541083813*10^(-39)

which, mysteriously to me, is not the same as

Rationalize[5.319372648326541416707296656673541083813, 0]

and the numeric output is from

Mod[5319372648326541416707296656673541083813*10^(-39)*10^255, 
 Floor[2*Pi, 1/10^300]]
N[%, 301]

The number line plot comes instead from the original unrationalized floating point input. Two different strategies.

POSTED BY: Gianluca Gorni

Right. That's what I meant about "not relying on W|A to treat input as Mathematica does." It might treat a string of digits as an exact decimal fraction or as a floating-point number.

I think that W|A probably uses Wolfram Language's NumberLinePlot[] for the number line plot. NumberLinePlot[] seems to work only in machine precision. So you get the error in the W|A plot just as you described. I tend to agree with Walter, though: Why doesn't W|A use the "Result" as the number to plot in the number line plot?

Rationalize[x0, 0] uses the continued fraction expansion of x0 and its precision to compute the fraction. In theory, any denominator is possible. Obviously, the denominator of a decimal fraction has only 2 and 5 as prime factors. You can use Round[x0, 10^-Ceiling[Accuracy[x0]]] to get a decimal fraction; however, there are edge cases where Floor needs to be substituted for Ceiling. One can use Round instead, also, but it's not always right, either.

POSTED BY: Michael Rogers

I asked Wolfram Alpha this

mod((5.319372648326541416707296656673541083813×Power[10,255]), floor(2π,1e-300))

from within Mathematica. The input was interpreted as

Mod[5.319372648326541416707296656673541083813`40.7*10^255, 
 Floor[2*Pi, 1/10^300]]

and gave this output:

0.*10^215

or, in InputForm,

0``-215.0258604158598

which means zero with an uncertainty of 10^215, or something like that. Meaningless output to meaningless input.

POSTED BY: Gianluca Gorni
Posted 3 months ago

I concur assessing this as an irritating return. I fail in finding a reason why WA returns such rubbish.

POSTED BY: Walter Bonin

Your floating point input was deeply ambiguous. W|A gave two incompatible answers because of two different interpretations of the input. Try giving an exact input, as in

mod((5319372648326541416707296656673541083813*10^(-39)×Power[10,255]), floor(2π,1e-300))

and W|A will give a number line plot consistent with the numeric answer.

POSTED BY: Gianluca Gorni
Posted 3 months ago

Thanks! Well, yes in principle but, alas, WA obviously doesn't know your claim and deviates: enter image description here

POSTED BY: Walter Bonin
Posted 3 months ago
POSTED BY: Walter Bonin

I think @Gianluca Gorni was suggesting using no decimal point in the input:

W|A link

POSTED BY: Michael Rogers
Posted 3 months ago
POSTED BY: Walter Bonin
Posted 3 months ago

Just FYI, said problem was solved elsewhere meanwhile. So I solemnly declare this discussion closed, thanking all participants for their constructive contributions.

POSTED BY: Walter Bonin

The number 5.319372648326541416707296656673541083813*10^255 is a floating point number, with an accuracy of something like 10^216. For such a number it makes no sense to ask mod(x,2Pi), if it is divisible by 6, its cosine, or similar things.

POSTED BY: Gianluca Gorni
Posted 3 months ago

Yes in principle but this is just to test our calculator algorithm for modulo reduction as sketched in the OP.

POSTED BY: Walter Bonin

You can't rely on W|A treating input like Mathematica does. Just what it does is a mystery to me, and I wouldn't trust it to check a high-precision algorithm.

For instance, the W|A query

mod((5.319372648326541416707296656673541083813×Power[10,255]), floor(2π,1e-1100))

yields the same 1101 digits as the following code does in Mathematica (ditto for the 301 digits using the exponent -300):

RealDigits[
  Mod[FromDigits@RealDigits[
     5.319372648326541416707296656673541083813*Power[10, 255]], 
   Floor[2 \[Pi], 1*^-1100]]] // N[FromDigits[#], Length@First@#] &

While 5.319372648326541416707296656673541083813×Power[10,255] is a floating-point number in WL and the following code fails in Mathematica, W|A treats the input differently:

Mod[
  5.319372648326541416707296656673541083813*Power[10, 255],
  Floor[2 \[Pi], 1*^-1100]] // InputForm
(*  0``-216.  *)
POSTED BY: Michael Rogers
Posted 3 months ago

Hmmh. Please excuse my ignorance but what did you want to tell me? Please explain like to a 4-years old.

POSTED BY: Updating Name

I was pointing out to Gianluca why I think W|A is not using floating-point numbers in this case. A four-year-old does not know what floating-point numbers are — I didn't know until sometime after high school. Nor is a 4yo likely to be able to run WL code, but I think Gianluca can. I guess I'd tell the 4yo not to worry about it. (?)

POSTED BY: Michael Rogers
Posted 3 months ago

Hope dies last. ;)

POSTED BY: Walter Bonin
Posted 3 months ago

Being at it, is there anything like a 'working space width' in WA? Heard that somebody set the 'working space' to 1000 digits - does this make any sense to you? If true then how do you do this? WA doesn't know that term.

POSTED BY: Walter Bonin

This worked for me:

Mod[239,2Pi] with 700 decimal digits
POSTED BY: Gianluca Gorni
Posted 3 months ago

Thanks! But this does not the same: it computes modulo with full (infinite) precision and then returns 700 digits of the result.

POSTED BY: Walter Bonin
Posted 3 months ago

Is there any chance that this might do what you want

mod(239,floor(2 pi,10^-700))

That tries to do mod on 239, over the first 700 digits of 2 pi.

I just randomly picked 239 and chose 700 digits because you mentioned 700 digits above.

Before you trust this I urge you to try this with much smaller numbers and see if you get exactly the result that you are expecting. Please test this multiple different ways to try to make sure this is correct. The limited testing that I have done seems like it is doing this correctly.

POSTED BY: Bill Nelson
Posted 3 months ago

Thank you! Seems to work. What's irritating, however, is that the result of mod( r, floor(, 10^(-n))) for r being some 10^260 stays constant from n = 300 to 1100 digits of . Looks like a precision limit in WA to me. Do you have an idea?

POSTED BY: Walter Bonin
Posted 3 months ago
POSTED BY: Bill Nelson
Posted 3 months ago

Two examples as requested:

mod((5.319372648326541416707296656673541083813×Power[10,255]), floor(2π,1e-300))

mod((5.319372648326541416707296656673541083813×Power[10,255]), floor(2π,1e-1100))

I expect different results for obvious reasons but WA returns identical ones.

POSTED BY: Walter Bonin
POSTED BY: Michael Rogers
Posted 3 months ago
POSTED BY: Walter Bonin
Posted 3 months ago

What's confusing for the most precise reduction modulo 2π, however, is that WA returns 0...×10^201 immediately, then 0...×10^135, then 0...×10^64, and then 3.7227... - you have to press [more digits] three times to get the "true" result, and the previous zeros are just misleading.

Furthermore, the number line is completely off: no idea what the programmer meant here: the 'number line' is completely off

POSTED BY: Walter Bonin

The number line plot represents what is obtained when the calculation is performed with floating-point numbers. I guess that's how the number line was computed. Perhaps this is what Gianluca was referring to. (I had ignored it until you brought it to my attention.)

POSTED BY: Michael Rogers
Posted 3 months ago

Wonder why WA displays a number line which is definitly wrong - it shows a dot in an entirely different ballpark. They should at least update it when the numeric result is updated.

POSTED BY: Updating Name
Posted 3 months ago

This problem is solved now - please see above.

POSTED BY: Walter Bonin
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
Attachments
Remove
or Discard