Re: [Maxima-discuss] sometimes 1//2 =/= 1/2

[Richard F. <fa...@gm...>]

Having written the bigfloat code about 50 years ago, I'm probably to blame
for such things.
Resetting the global bf values for one, zero, half   are cheap.  Values for
e and pi and other
constants may not be so cheap.   I think some computations are done by
bumping up the
precision slightly and then rounding down, so re-doing e,pi, etc at each
change may not
be a great idea. But if they are memoized, maybe it doesn't matter, and it
doesn't matter if
functions producing the values are used in places, instead of the values
themselves being stored.

Note that the precision used for a bigfloat op like fpplus is the global fp
precision, and is NOT
governed by precision of the arguments.  Also there is a Maxima variable
$fpprec , initially 16,
supposed to be number of decimal digits,  and a lisp variable  ?fpprec,
initially 56, the corresponding
number of binary bits in the "fraction" part of the bigfloat.

Whether it is a feature or a defect, it is unclear:  since there is no
limit on the value of the exponent,
"underflow"  or "overflow"  by exceeding that range is not possible, and so
bigfloats do not
have NaN  (Not a Number) as do IEEE754 standard floats.  Maxima has inf,
und, ind, which might
be "allowed" as bigfloats, if someone cared to do that, figured out the
consequences, and it was acceptably fast.

RJF




On Fri, Dec 5, 2025 at 10:41 AM Robert Dodier <rob...@gm...>
wrote:

> On Fri, Dec 5, 2025 at 4:58 AM Barton Willis via Maxima-discuss
> <max...@li...> wrote:
> >
> > Another thing:  Although bfhalf automatically updates when  fpprec
> changes, some special variables defined in globals.lisp do not.
>
> I wonder if any specific bigfloat values should be functions instead
> of constants, so that changing fpprec causes a different value to be
> returned. Or maybe baking the prevailing fpprec into the symbol name,
> something like BIGFLOAT-%PI-FOR-DEFAULT-FPPREC or whatever.
>
> Speaking strictly for myself, I can't keep it straight in my head when
> some constant is no longer valid in some context ... if developers are
> supposed to "just know", then it's likely that I'll mess it up at some
> point. YMMV as always.
>
> Robert
>
>
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>