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

1I 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 – 2015-09-20T06:51:22.903Your title is misleading. This is not a question about the arithmetic of rationals.

`Sqrt[27233]`

is not a rational. – m_goldberg – 2015-09-20T06:59:28.210@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 – 2015-09-20T07:06:14.090@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 – 2015-09-20T07:09:18.037@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 – 2015-09-20T07:25:40.810Felix, I do not follow what you are describing regarding

`EuclideanDistance`

-- why can you not use`EuclideanDistance[p1,p2] // Simplify`

or something similar? – Mr.Wizard – 2015-09-20T09:24:16.6971what-should-we-do-about-the-abbreviation-mma – Sjoerd C. de Vries – 2015-09-20T11:00:51.020

1The

`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 – 2015-09-20T11:06:33.5372Quick answer: It's not a bug. – Daniel Lichtblau – 2015-09-20T22:27:25.843

@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 – 2015-09-21T10:29:54.070@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 – 2015-09-21T10:33:35.963

@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 – 2015-09-21T10:36:34.750

1By 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 – 2015-09-21T15:34:12.573

Sometimes, simplification is not at all obvious. See for instance the constant problem.

– J. M.'s ennui – 2015-10-07T14:16:53.0372I'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 – 2015-10-28T17:01:07.600