Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2001
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2001

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Zero does not equal zero et al.

  • To: mathgroup at smc.vnet.net
  • Subject: [mg31604] Re: Zero does not equal zero et al.
  • From: "Alan Mason" <swt at austin.rr.com>
  • Date: Fri, 16 Nov 2001 06:38:09 -0500 (EST)
  • References: <9stc03$3df$1@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

Hello,
Well, there is definitely something wrong.  Perhaps WRI can explain what is
going on in the following notebook (v4.1, Windows).

There are two blocks of statements; I have commented where I think the
results are wrong -- they are certainly inconsistent.  I prefer the output
from the second block; except for the first True, it gives what I would
expect and recommend.

Concerning === versus ==, it's very inconvenient to use === in tests
involving symbols because it gives False too often; it is only occasionally
appropriate.  As things now stand, I'm forced to use it to get the results I
need for approximate numbers.  This compels me to make a tedious distinction
in my code between purely symbolic and numerical quantities.  Shouldn't
Mathematica be able to integrate the two without putting this burden on the
programmer? What I meant by pattern matching is that a rule such as x_
f[y_]:> y Sin[x] /; y = = z may involve Equal.  So problems with = =  *do*
affect the operation of rules.  And of course, one can no longer substitute
equals for equals if they are numeric.

I think the results show that Mathematica's behavior has become
schizophrenic due to pollution from the floating point side.  Much valuable
work has been done on both the numeric and symbolic aspects of Mathematica,
but more thought needs to be given as to how the two pieces are going to fit
together, both in terms of correctness and in terms of how programmers will
ultimately use Mathematica.  It's time for the quartermaster.

Alan

In[1]:=
\[Epsilon] = 1.0 10^-16; (* float*)
num = 145/247;
num2 = num + \[Epsilon];
num \[Equal] num2
num^83 \[Equal] num2^83
num^84 \[Equal] num2^84 (*
  Shows we can't substitute "equals" for "equals".
      This is a bit of an embarassment in a symbolics program!  *)
f1 = Expand[(x - num)^2]
f2 = Expand[(x - num2)^2]
f1 \[Equal] f2
e1 = Expand[(x-num)^84]; e2 = Expand[(x - num2)^84];
e1 \[Equal] e2 (* This should not be True -- num^84 \[NotEqual] num2^84 *)
10^16 (num2 - num)

Out[3]=
True

Out[4]=
True

Out[5]=
False

Out[6]=
\!\(21025\/61009 - \(290\ x\)\/247 + x\^2\)

Out[7]=
\!\(\(\(0.3446212853841238`\)\(\[InvisibleSpace]\)\) -
    1.1740890688259111`\ x + x\^2\)

Out[8]=
True

Out[10]=
True (* should be False, dammit! *)

Out[11]=
1.11022

In[12]:=
\[Epsilon] = 1 10^-16; (* exact.  This is the only difference from the
previous code *)
\[Epsilon] \[Equal] 1.0 10^-16
num = 145/247;
num2 = num + \[Epsilon];
num \[Equal] num2 (* would expect this to be True,
  since it was True in the previous code where \[Epsilon] = 1.0 10^-16,
  and \[Epsilon] \[Equal] 1.0 10^-16 is True. Is equality not transitive? *)
f1 = Expand[(x - num)^2]
f2 = Expand[(x - num2)^2]
f1 \[Equal] f2
e1 = Expand[(x-num)^84]; e2 = Expand[(x - num2)^84];
e1 \[Equal] e2
10^16 (num2 - num)

Out[12]=
True

Out[15]=
False

Out[16]=
\!\(21025\/61009 - \(290\ x\)\/247 + x\^2\)

Out[17]=
\!\(2102500000000000716300000000000061009\/\
6100900000000000000000000000000000000 - \(1450000000000000247\ \
x\)\/1235000000000000000 + x\^2\)

Out[18]=
\!\(21025\/61009 - \(290\ x\)\/247 + x\^2 ==
    2102500000000000716300000000000061009\/\
6100900000000000000000000000000000000 - \(1450000000000000247\ \
x\)\/1235000000000000000 + x\^2\)

Out[20]=
 (* OMITTED -- just a huge expression giving the two expansions with == in
between them *)

Alan



  • Prev by Date: Re: JLink installation w95
  • Next by Date: Re: Re: Limit question
  • Previous by thread: Re: Zero does not equal zero et al.
  • Next by thread: Re: Re: Zero does not equal zero et al.