4

While solving a simple puzzle that asked for a few calculations in plane geometry, I ended up with this expression:

$-\frac{55}{2}+\frac{\sqrt{27233}}{2}+\frac{1}{2}(55-\sqrt{27233})$

Or, in InputForm:

-55/2 + Sqrt[27233]/2 + (55 - Sqrt[27233])/2

Obviously, the result is an exact 0. But the expression just sits there (Mathematica 10.1.0 64-bit, Win7) and looks at me challengingly instead of being evaluated to zero. Let's help it along a little:

-55/2 + Sqrt[27233]/2 + (55 - Sqrt[27233])/2 // Apart
(* 0 *)

Good. Together, Simplify and probably a bunch of other functions deliver the same small incentive that Mathematica needs to get cracking. But the original expression that I encountered was larger, and the relevant portion was this (note the absolute-value function):

$\left|{-\frac{55}{2}+\frac{\sqrt{27233}}{2}+\frac{1}{2}(55-\sqrt{27233})}\right|$

Or, in InputForm:

Abs[-55/2 + Sqrt[27233]/2 + (55 - Sqrt[27233])/2]

Expected result: Still 0, of course. Actual result:

N::meprec: "Internal precision limit $MaxExtraPrecision = 50.` reached while evaluating -(55/2)+Sqrt[27233]/2+1/2 (55-Sqrt[27233])."

Clearly, applying Simplify, Together or any other operation to the expression inside Abs[] will make this work, as long as the expression's structure is changed in some way, as that will collapse the expression to zero.

What puzzles me is why Mathematica wouldn't evaluate it on its own? I always thought that Mathematica does an automatic "light-weight Simplify", so to speak, which would cover such a simple case.

The real question is, though, whether this is a bug. After all, unless I manually start editing intermediate results, this perfectly good evaluatable expression remains unevaluated, botching the rest of my puzzle solution. :)

J. M.'s missing motivation
  • 124,525
  • 11
  • 401
  • 574
Felix Kasza
  • 817
  • 4
  • 18
  • 1
    I think you answered your own question, haven't you? It's obvious that 1-1 evaluates to zero, but also that more complicated expressions require "user intervention" such as Simplify. So what's the question here? – yohbs Sep 20 '15 at 06:51
  • Your title is misleading. This is not a question about the arithmetic of rationals. Sqrt[27233] is not a rational. – m_goldberg Sep 20 '15 at 06:59
  • @yohbs The question is, "The real question is, though, whether this is a bug." Inside Abs[], the subexpression is suddenly evaluated numerically, when the subexpression evaluator is (cf. example outside Abs[]) quite capable of recognising and eliminating the common subexpressions, leaving an exact 0 instead of scratching its head about the number of bits it will need to figure out an irrational root. – Felix Kasza Sep 20 '15 at 07:06
  • @m_goldberg Thanks for pointing that out: it's fixed. Meta-question, why is it important to write "Mathematica" (and in italics, too) as opposed to plain "MMA"? – Felix Kasza Sep 20 '15 at 07:09
  • @yohbs There is another reason why "user intervention" is not a good choice here: The expression arises as the result of EuclideanDistance[p1,p2]. I wouldn't know how to slip a Simplify into the result; Hold[EuclideanDistance[…]] will not let anything happen, and Inactivate[EuclideanDistance[…],Abs] will only inactivate Abs if it is explicitly present in the input, not if it is generated in the output. And when I think about it, that makes the entire result wrong, not just mildly inconvenient, because there is no way to correct it. – Felix Kasza Sep 20 '15 at 07:25
  • Felix, I do not follow what you are describing regarding EuclideanDistance -- why can you not use EuclideanDistance[p1,p2] // Simplify or something similar? – Mr.Wizard Sep 20 '15 at 09:24
  • 1
    what-should-we-do-about-the-abbreviation-mma – Sjoerd C. de Vries Sep 20 '15 at 11:00
  • 1
    The Abs issue is listed in the Possible Issues section of its help page: "Abs can stay unevaluated for some complicated numeric arguments:". The example include the error message you list in your question. – Sjoerd C. de Vries Sep 20 '15 at 11:06
  • 2
    Quick answer: It's not a bug. – Daniel Lichtblau Sep 20 '15 at 22:27
  • @Mr.Wizard EuclideanDistance[] comes down to $\sqrt{(x1-x0)^2+(y1-y0)^2}$. Squaring makes nasty little minus signs go away, but Mathematica wraps the argument to be squared in Abs[], which fails to evaluate symbolically before Simplify[] ever has a chance to do its thing. Since this is simple planar geometry, I just apply Mr. Pythagoras myself now. That still leaves open why EuclideanDistance[] forces numericization instead of returning the Abs[] unevaluated, which I would have preferred. – Felix Kasza Sep 21 '15 at 10:29
  • @DanielLichtblau Thanks! With shame, I admit that I should have looked there; it just never occurred to me that something this simple might fall into the "cannot evaluate" category. – Felix Kasza Sep 21 '15 at 10:33
  • @SjoerdC.deVries Thanks! As I replied to Daniel, it never occurred to me that this might be expected behaviour; I didn't regard the expression as "complicated", clearly a wrong expectation on my part. As far as MMA vs. Mathematica is concerned, I am so glad that we no longer have this confusing mixture of posts on Mathematica and on Mixed Martial Arts on this site. (But italics? No. I don't do logotypes, the same way I refuse to paint a little blue oval whenever I mention Ford.) Anyway, "Mathematica" it is, from now on. Thanks again! – Felix Kasza Sep 21 '15 at 10:36
  • 1
    By the way, there is support for zero testing in this case. `In[188]:= -55/2 + Sqrt[27233]/2 + (55 - Sqrt[27233])/2 == 0

    Out[188]= True`. Even that much was a not-very-simple undertaking.

     – Daniel Lichtblau Sep 21 '15 at 15:34
  • Sometimes, simplification is not at all obvious. See for instance the constant problem. – J. M.'s missing motivation Oct 07 '15 at 14:16
  • 2
    I'm voting to close this question as off-topic because the question is rhetorical rather than real -- this is just a rant about something doesn't like about Mathematica's evaluation process. – m_goldberg Oct 28 '15 at 17:01

0 Answers0