RE: specfun and bigfloats



W. Kahan here at Berkeley has been worrying about
this stuff for decades, and trying to influence
(mostly) Maple people.  The arithmetic of elementary
functions is not maintained correctly in branch
cuts by the symbolic systems (Macsyma somewhat
worse than the others, which have been patched up
more recently).  But the IEEE floats attempt to
encode things that we can encode by CL rationals
(e.g. inexact flags for non-rationals..)

A complete re-do of this area is going to take
a fair amount of effort, but looking at Kahan's
home page may help,  http://www.cs.berkeley.edu/~wkahan

RJF


Stavros Macrakis wrote:
>>Any time the same value comes into the computation more than
>>once, it should be the SAME error in the same direction.
> 
> 
> Understood.  Is there any sort of consensus about good techniques in
> this area?  (Affine arithmetic, etc.)
> 
> 
>>>Ideally, we'd rework Maxima so that it generalizes its
>>>notion of number to include not just integers, rats, and
>>>bigfloats, but also complexes, intervals, etc.  Not trivial, but....
>>
> 
>>Some of these require no more than using the underlying Lisp numbers.
> 
> 
> The problem is not in implementing the operations, it is in getting
> Maxima to use them appropriately, and to treat these objects sensibly.
> Right now, most parts of Maxima handle the closed set of known numeric
> types (integer, float, RAT, bigfloat) ad hoc.  That is, there is no
> information hiding, so it is very painful to add a new numeric type.
> There are known places which don't do it right. (A major one: the RAT
> package doesn't support bigfloat coefficients.)
> 
> Assumptions are made about the properties of numbers.  For example:
> Everything that is numberp is assumed real (unlike #C(1.23 -2.45)).
> Every number that is not integer or RAT is assumed approximate (not #C(2
> 1) or 23/47 or #C(1/2 2/3) or finite continued fractions).  Trichotomy
> is assumed to apply to all numbers (not true of intervals, complexes,
> and IEEE floats with NaNs).  Numbers are assumed finite (not true of
> IEEE floats with NaNs and infinities, for projective numbers, and
> nonstandard numbers (infinitesimals etc.)).  And so on.
> 
> I don't think it's possible to make all of Maxima work with all these
> kinds of numbers everywhere -- there are too many basic *mathematical*
> assumptions in too many places, trichotomy for example.  But it might
> well be time to go through Maxima systematically and generalize the
> number system -- while of course preserving efficiency!
> 
>        -s
> 
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima