Re: +-Inf and NaN

Hi Camm,

No problem!
First of all, I made the mistake of looking only at the directory name
"gmp4" and drawing the conclusion that the bundled version of GMP was 4.x,
which would indeed be "antique". But it's actually 6.0.0. Still, that's
almost 11 years old by now.
There are some still supported LTS releases of Ubuntu that come with fairly
old GMP versions, e.g. Ubuntu 16.04 LTS only gets GMP 6.1.0 (released in
2015) and Ubuntu 18.04 LTS gets GMP 6.1.2 (released in 2016). Only Ubuntu
24.04 LTS gets the up-to-date version 6.3.0. I don't know about other
distributions.
If GMP was developed using Git, using a submodule would be an option. But
they use Mercurial (hg). I don't know which one of the other options would
be considered best practice ...
One more thing: GCL comes with a "gmp.patch" file that makes some
modification to GMP (the bundled version, I guess?). Is this still needed?

Best regards
David Scherfgen


Am Sa., 22. Feb. 2025 um 19:22 Uhr schrieb Camm Maguire <
[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
>

_______________________________________________
Maxima-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maxima-discuss