Modulo reduction of input for trigonometric functions

Questions
, ,
1

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.

2

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.

3

This worked for me:

Mod[239,2Pi] with 700 decimal digits
4

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

5

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

6

Could you come up with one specific value for r and two specific values for n where the result should be different for those two values of n and why those two results should be different instead of the same? With that I can try to pound on this and see if I can reproduce your result and try to understand why there should be two when we only get one.

7

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.

8

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.

9

I got different results (on www.wolframalpha.com). Did you click the “More digits” button until it stopped giving more digits?

10

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

11

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.  *)
12

Thank you! For 300 digits I get ca. (!)

3.722 745 201 416 216 364 355 224 140 005 132 959 642 051 504 446 433… and for 1100 ca.

3.722 745 201 416 216 364 355 224 140 005 132 959 642 051 504 066 160 399 498 386 359 332 206 916 372 615 337 792 914 822 164 141 536 669 592 572 913 802 661 649 426 913 660 900 401 089 023 614 495 237 483 652 367 439 010 459 876 046 110 302 024 612 788 810 659 670 268 883 715 965 420 981 525 994 843 979 323 818 177 250 917 590 316 459 633 842 477 689 089 143 834 661 724 596 684 131 067 935 104 986 444 229 148 913 577 347 452 990 829 860 860 563 605 904 139 363 925 213 618 906 673 333 609 798 991 161 222 966 240 248 277 376 097 321 289 798 248 637 582 375 914 401 859 197 754 025 787 748 734 447 524 203 422 913 383 180 227 769 818 295 182 646 214 894 368 791 043 360 587 914 955 595 251 698 787 379 102 754 074 083 634 385 076 040 270 341 743 006 122 682 201 890 242 163 630 707 437 007 077 194 079 489 899 502 247 255 980 904 806 987 338 631 666 245 418 431 916 102 034 573 478 248 355 568 392 284 494 345 276 094 983 048 870 926 917 189 405 460 909 285 283 873 566 596 553 969 751 531 680 188 687 901 121 976 444 093 522 725 965 820 953 828 919 931 172 080 610 428 143 273 955 434 166 058 573 179 231 450 950 369 059 754 513 …, i.e. a difference of some 4×10^(-46) if I counted correctly. Those 800 digits more lead to a precision of 10^(-845) since for an ‘infinite’ precision of 2π (whatsoever) the modulo reduction returns ca.

3.722 745 201 416 216 364 355 224 140 005 132 959 642 051 504 066 160 399 498 386 359 332 206 916 372 615 337 792 914 822 164 141 536 669 592 572 913 802 661 649 426 913 660 900 401 089 023 614 495 237 483 652 367 439 010 459 876 046 110 302 024 612 788 810 659 670 268 883 715 965 420 981 525 994 843 979 323 818 177 250 917 590 316 459 633 842 477 689 089 143 834 661 724 596 684 131 067 935 104 986 444 229 148 913 577 347 452 990 829 860 860 563 605 904 139 363 925 213 618 906 673 333 609 798 991 161 222 966 240 248 277 376 097 321 289 798 248 637 582 375 914 401 859 197 754 025 787 748 734 447 524 203 422 913 383 180 227 769 818 295 182 646 214 894 368 791 043 360 587 914 955 595 251 698 787 379 102 754 074 083 634 385 076 040 270 341 743 006 122 682 201 890 242 163 630 707 437 007 077 194 079 489 899 502 247 255 980 904 806 987 338 631 666 245 418 431 916 102 034 573 478 248 355 568 392 284 494 345 276 094 983 048 870 926 917 189 405 460 909 285 283 873 566 596 553 969 751 531 680 188 687 901 121 976 444 093 522 725 965 820 953 828 919 931 172 080 610 428 143 273 955 434 166 058 573 179 231 450 950 369 059 753 539 806 505 011 529 239 940 497 342 216 851 482 427 7…

Holy cow!

13

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

14

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:

number_line.PNG
number_line.PNG907×293 34 KB

15

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. (?)

16

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

17

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.

18

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.

19

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.

20

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.