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

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.

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.

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.

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.

... and this doesn't help either:

Aha! I overlooked the missing decimal point (btw, commas are slightly better visible ;)). Here we go! Now, N[[Mod[5319372648326541416707296656673541083813*10^216, floor[2 Pi, 10^(-1071)]]], 34] returns 3.722745201416216364355224140005133 - so no difference. (Please excuse my sloppiness, making an elementary math errror here four days ago).

Anyway: Thanks @https://community.wolfram.com/web/gianlucagorni, @https://community.wolfram.com/web/mroge02, and @https://community.wolfram.com/web/dontdont9 who brought me here (now I must just learn how to address them properly ;) )!

Please allow me to ask another question while we're at it (for unknown reasons, I'm unable to reply here, so I've to edit my old post):

For the same input number as above (5 319 372 648 326 541 416 707 296 656 673 541 083 813×10^216), I've got a black box returning 3.108 149 925 373 277 281 586 944 287 054 011 after the modulo 2π reduction (with a finite number of digits for 2π). Is there any way to find out what it did or does?

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.

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

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.

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

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?

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.

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!

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

This problem is solved now - please see above.