Re: [Maxima-discuss] +-Inf and NaN

[Camm M. <ca...@ma...>]

Greetings!

Richard Fateman <fa...@gm...> writes:

> I think that using exactly the same argument conventions and names as the library would be best.
> so you overwrite one (or more) of the inputs, for the same reasons as mpfr does it,
> to save memory allocation when possible.  
>
> Possible glitch:  it assumes you will only pass arguments that are in memory, not on a stack.
> Thus for actual use you may need to have a functional style program interface that puts the
> arguments in memory.  I think that mpfr number structures have a size [maximum length] and
> an actual size in use. So numbers and comparisons of them etc. must be
> done by mpfr.

Yes this is the rub, and I believe the basic issues are the same with
floats as integers.  GCL stores immediate fixnums in one format, other
fixnums in another, and bignums in a format directly accessible to gmp.
We could expose both the raw gmp interface and the 'functional'
interface which would load the first two into the third, but whether
done under the hood or by the user directly, there is nothing to
overwrite if fixnums are supplied as output arguments.  At the C level
we have 5 bignum 'registers' which we do not expose to lisp, as if they
contain fixnums the logic pertaining to the same will fail.  I suppose
an expert user could make use of the registers and be careful not to
refer to them until the gmp calculation is done.

Take care,

> RJF
>
> On Wed, Feb 28, 2024 at 12:55 PM Camm Maguire <ca...@ma...> wrote:
>
>  Greetings!
>
>  Richard Fateman <fa...@gm...> writes:
>
>  > Several of us here have worked on arbitrary-precision floats in Lisp
>  > (generally used for longer than double, though I suppose shorter could
>  > also be specified...), and I think the real win would be to make use
>  > of the mpfr library (written in C with various assembly-language hacks
>  > for different CPUs).
>
>  mpfr would be a straightforward extension to GCL, as we already use the
>  gmp integer library, integrate it with our gbc/memory management, and
>  export the functions at the lisp user level:
>
>  >(gmp:mpz_mul most-positive-fixnum most-positive-fixnum)
>
>  85070591730234615847396907784232501249
>
>  The only sensible way to interface to a library like this is to keep all
>  the function names and calling syntax the same.  GMP is written with
>  'side-effects', i.e. destructive modification of the supplied arguments
>  one or more of which are considered outputs.  This is so the savvy user
>  can avoid unnecessary allocations, which are effectively all that matter
>  for performance.  Lisp is so functionally oriented, however, that it
>  seemed better to me to take only input variables as arguments.  The
>  natural alternative to the call above would take three arguments,
>  overwrite the first, and return no values.  Your thoughts?
>
>  Take care,
>  -- 
>  Camm Maguire                                        ca...@ma...
>  ==========================================================================
>  "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
>

-- 
Camm Maguire			     		    ca...@ma...
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah