1
$\begingroup$

While looking at implementing floating point modulus in double-precision on an x86 CPU, I found the FPREM instruction and proceeded to test the practical precision in some cases, one being

1e48 mod 1.5

The FPREM implementation returns 1 as result, which looked "right" to me (as 1e48 is not a multiple of 3).

Then I checked against Wolfram Alpha but it returned 0 (http://www.wolframalpha.com/input/?i=1e48+mod+1.5%29)... now I am having doubts, is Wolfram failing or are FPREM and my expectation wrong?

Also in case Wolfram is failing, is there an online high-precision resource I could use to compare floating point modulus precision?

$\endgroup$
1
  • 1
    $\begingroup$ Even Wolfram Alpha shows 1 if you use the definition $x \pmod y = x-\lfloor\frac{x}{y}\rfloor y$, e.g. if you enter 10^48-floor(10^48/1.5)*1.5 $\endgroup$
    – gammatester
    Oct 29, 2015 at 14:15

2 Answers 2

Reset to default
2
$\begingroup$

The true value of $10^n$ mod $1.5$ is $1$ for all positive integers $n$. Wolfram Alpha gets it right for $n \le 16$, and wrong for (it seems) all $n \ge 17$.

Wolfram Alpha gets 1e17 mod 3 right, but 1e17 mod 3.0 wrong. So a loss of floating-point precision is to blame.

$\endgroup$
1
$\begingroup$

It might be worth pointing out that you can use WolframAlpha to get the correct result by simply specifying greater precision. You can specify 1.5 to 50 digits of precision like so: 1.5`50. So your query would be:

1e48 mod 1.5`50

You can even specify exact precision:

1e48 mod 3/2

$\endgroup$
4
  • 1
    $\begingroup$ Interesting, is there a reference about WolframAlpha custom precedence rules? "1e48 mod 3/2" is understood as "(1e48 mod 3)/2" under usual precedence rules, which place modulus alongside multiplication & division, with a left-associativity. $\endgroup$
    – Eric
    Nov 2, 2015 at 10:37
  • $\begingroup$ @Eric I agree, but I don't think it's just a simple matter of precedence. Keep in mind, the vision of WolframAlpha is not to be a calculator but to actually understand natural language. In that context, "mod" is a word and the input mod returns information about the 1960s British subculture with four alternative possibilities. Given this broad objective, WA really can't look at your input and jump straight to evaluation. Furthermore, "1e48 mod 3/2" is not valid Mathematica syntax; the natural language parser parses it to Mod[10^48,3/2]. A similar thing happens for "1e48 mod 3+2", in fact. $\endgroup$
    – Mark McClure
    Nov 2, 2015 at 12:06
  • $\begingroup$ I get your point, but by that natural language interpretation "3-1 multiplied by 4" should be understood as "(3-1) * 4" but WA interprets it as "3 - 1*4", applying regular precedence (this also illustrates that natural language is quite ambiguous and unusable mathematically-speaking), so this look more like a plain old bug for precedence of modulo $\endgroup$
    – Eric
    Nov 3, 2015 at 13:23
  • $\begingroup$ @Eric I'm not sure I agree with your interpretation of "3-1 multiplied by 4"; I don't see why we wouldn't assume that multiplication should take precedence over subtraction. I guess this ambiguity is exactly why natural language is difficult to deal with. To be clear, though, the point of my original comment was not to indicate that the interpretation should be one way or another but simply to source of the discrepancy. $\endgroup$
    – Mark McClure
    Nov 3, 2015 at 13:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .