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

Camm Maguire <[email protected]> Sat, 22 Feb 2025 13:22:01 -0500
Newsgroups gmane.lisp.gcl.devel,gmane.comp.mathematics.maxima.general
Message-ID <[email protected]>
Greetings!

David Scherfgen <[email protected]> writes:

> Hi Camm,
>
> Camm Maguire <[email protected]>:
>
>  If anyone has any extremely minor suggestions in the
>  next week or so please send them my way.
>
> I don't know if this counts as "minor", but as I already posted on the GCL list (without receiving a response), I'd suggest updating the copy of libgmp that comes
> bundled with the GCL source. It's a very old one.
>

Please accept my apologies for missing your post there.

I was actually thinking of removing the convenience copy of gmp, as it
appears virtually everyone is dynamically linking against the system gmp
shared library.  I would love to hear opinions to the contrary if any.
But in any case I really am unsure of how to handle a subproject source
in git.  What is considered best practice -- a commit of a binary source
compressed tar file?  Or a massive commit diff involving thousands of
files? Or even a reference to source found externally?

Take care,


> Using an up-to-date version of libgmp fixes an annoying bug where certain bigfloat errors cannot be caught in Lisp or Maxima (they always terminate the
> process).
>
> A particular example:
>
> In GCL: (expt 2 (expt 2 62))
> In Maxima: 2^2^62;
>
> (Note: with the exponent 63 it works, libgmp's overflow check is bugged)
>
> This just terminates the program with the error message "gmp: overflow in mpz type", and there's no way to catch the error.
>
> In a more recent version of libgmp, this bug has been fixed. There are also some speedups in the more recent versions.
>
> Best regards
> David Scherfgen
>

-- 
Camm Maguire			     		    [email protected]
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah