Re: 0^0 oh no!

On Mar 14, 8:40 am, Christopher Creutzig <christop...@xxxxxxxxxxx>
wrote:
G. A. Edgar wrote:
In article <47d9a9b1$0$6735$9b4e6...@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Christopher Creutzig <christop...@xxxxxxxxxxx> wrote:

I regard testing for equality on
floats in general a user error

It follows that 0^0.0 should not be simplified to 1.0
Even if 0^0 *is* simplified to 1

Yes and no. There *are* floats which are identical. After all, we would
not want an object o for which o == o was false. (In terms of numerical
analysis, I have to admit I disagree with IEEE for NaN here.) This is
why I said "in general". But I would only want this simplification for
an exponent that is *exactly* a floating point zero.

It might be my general conditioning, but I'd also not want to see
0^0.0 to be 1.0 or anything other than either unevaluated or a flavor
of NaN. I have the impression there is agreement on this, even if we
might come to the conclusion for different reasons.


It is, in my opinion, acceptable (though certainly not the preferred
way) to use something like s == s+t as a stopping condition when summing
up a series of decreasing numbers numerically. but I only have
experience with multi-precision numerics in terms of fixed precision, I
never worked with significance arithmetics myself. What I regard as
problematic, however, is to have two objects o1 and o2 which some system
claims to be identical, yet invoking some function such as SetPrecision
with exactly the same parameters on them results in two definitely
different objects.

--
if all this stuff was simple, we'd
probably be doing something else. -- Daniel Lichtblau, s.m.symbolic

I'm not convinced this is a bad thing, so much as a bad usage of
SetPrecision (in Mathematica; I suspect there are similar functions in
other programs). What it can do is to expose guard bits, in the sense
of claiming "regard these bad bits as good bits". Returning to the
example I have used:

diff = quot-101/100;
diff2 = quot-1011/1000;

I had inadvertantly forgotten to display this next one.

sum2 = 1/100+diff2;
sum2plus = sum2+1/1000;

In[27]:= sum2plus==sum2
Out[27]= True

Next we see an example of the phenomenon you mention.

In[28]:= SetPrecision[sum2plus,5] == SetPrecision[sum2,5]
Out[28]= False

But these new objects really ARE different, because we promoted bad
bits to become good bits.

In[29]:= InputForm[{SetPrecision[sum2,5],SetPrecision[sum2plus,5]}]
Out[29]//InputForm= {0.01`5., 0.011`5.}

I do not see the behavior as wrong, so much as a problematic (and, I
hope, unlikely) usage of SetPrecision.


Daniel Lichtblau
Wolfram Research
.