7
$\begingroup$

I'm handling some mixed-numeric-analytic expressions, and I feel I'm missing some subtleties of how Mathematica handles simplification of such expressions.

In particular, I was initially puzzled by the fact that

0. + a

(with a undefined) will not simplify to a, but of course this forgets that 0. and 0 are not the same, and that if, say, one later on sets a=1 then 0+a will return an exact result but 0.+a will return a float.

However, if one takes this a bit further, to the expressions

0. + 1. a

and

1. (0. + a)

then they will still be returned intact. By the criterion above, simplifying them to 1. a and 0.+a would be functionally equivalent, so I feel I'm missing something. Does Plus[0.,expr] only simplify further if expr is a numeric expression? Does Mathematica decide not to delve into the depths of expr, potentially taking some overhead in complicated expressions, to save some complicated analysis? Or are the different expressions not actually equivalent?

Or am I just over-reading into this?

Improve this question
$\endgroup$
7
  • $\begingroup$ 'a' is exactly precisely 'a', no uncertainty or approximation or error involved. '0.' is approximately zero, only within the uncertainty and approximation and error that all machine precision floating point numbers have. If you really want to do it then Chop can make approximate 0. go away in most cases and Rationalize can make approximate 1. go away in most cases. All this is only approximately true. $\endgroup$
    – Bill
    Commented Sep 17, 2015 at 21:05
  • 2
    $\begingroup$ If I read your 1.(0.+a) as "approximately one times the expression approximately zero plus exactly a" then maybe I could justify that as being the same as "approximately zero+approximately one times a" and Expand[1. (0. + a)] returns 0. + 1. a if you like that any better. But it seems that anything MMA does or doesn't do is often met by two camps, one of which are unhappy it didn't do more and the other who are unhappy it did it at all. Trying to get it to not do something often seems more difficult than getting it to do something. $\endgroup$
    – Bill
    Commented Sep 17, 2015 at 22:51
  • 4
    $\begingroup$ You might do a little pencil and paper experiment. Consider 1. is 1 plus/minus something less than 10^-16, 0. is 0 plus/minus something less than 10^-16 and 'a' is exactly 10^(10^9). Then what is the uncertainty? And repeat the exercise with 'a' being exactly 10^(-10^9). You want to check whether each of your various expressions that seem the same to you have the same uncertainty as the original expression did, no matter what value 'a' might have. Note: I'm fudging a little with that uncertainty of zero, but it should be good enough for you to understand. $\endgroup$
    – Bill
    Commented Sep 17, 2015 at 23:12
  • 1
    $\begingroup$ Some functions which you might want to try and play around with (if you haven't yet) are Expand and Chop. $\endgroup$
    – Kagaratsch
    Commented Sep 18, 2015 at 3:48
  • 1
    $\begingroup$ I guess it's because the FullForms of 1. (0. + a) and 1. (0. + a)// Expand have same length? $\endgroup$
    – xzczd ♦
    Commented Sep 18, 2015 at 8:46

1 Answer 1

Reset to default
2
$\begingroup$

Try this:

  0. + a // Chop

(*  a  *)

Have fun!

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.