This does produce inconsistent user-visible behavior in some cases, e.g.
block([fpprec:100], b1: bfloat(1))$
1.0b0^x => 1.0b0
b1^x => 1.0b0^x
x^1.0b0 => x
x^b1 => x^1.0b0
and there is no obvious way to fix the result: bfloat(x^b1), expand(x^b1),
etc. all return the same thing. Only bfloating with a larger fpprec correct
the problem.
On the other hand, I am not sure that x^1.0b0 and for that matter x^1.0
should be simplifying to x in the first place.
Currently (5.9.3), x*1.0 => x*1.0 but x+0.0 => x. I wonder if we should try
harder to preserve the approximate nature of results in cases like this.
The check for equal-bigfloatzero is appropriate if it is just an
optimization, though it seems like an awfully obscure case to optimize,
unlike checking for integer 0.
-s
On 7/25/06, Richard Fateman <fateman at cs.berkeley.edu> wrote:
>
> I've notice a bunch of places in simp.lisp where there are tests to see
> if a number k is zero or one, and someone added an extra consideration,
> namely, is k equal to bigfloatzero or bigfloatone.
>
> This test is not adequate,...
>