update Giac to v1.9.0-53

[dimpase]

Also, we finally have a stable location for stable giac tarballs

[dimpase]

ImportError: /home/scratch/scratch2/dimpase/sage/sage/local/lib/libgiac.so.0: undefined symbol: png_create_write_struct

it builds, but does not work.
Indeed, it has --enable-png=no - no wonder.

[mkoeppe]

we finally have a stable location for stable giac tarballs

How so? No more patches for autotools sources needed?

[dimpase]

we finally have a stable location for stable giac tarballs

How so? No more patches for autotools sources needed?

I mean, we now have something for upstream_url= in checksums

[mkoeppe]

We don't -- unless we no longer need to use the spkg-src script.

[dimpase]

we no longer need to use the spkg-src script

it appears we don't need this any more.

[mkoeppe]

Note that part of spkg-src is to remove non-GPL material from the tarball.

[dimpase]

@parisseb --disable-xft is broken. I.e. it's ignored by ./configure

[parisseb]

@parisseb --disable-xft is broken. I.e. it's ignored by ./configure

What should I change in configure.ac? The only line I see relative to xft is line 452
AC_CHECK_LIB(Xft, main)

[dimpase]

@parisseb --disable-xft is broken. I.e. it's ignored by ./configure

What should I change in configure.ac? The only line I see relative to xft is line 452 AC_CHECK_LIB(Xft, main)

well, if any of the many X11 libraries you need are not available, you should not try building a GUI-enabled Giac - it's doomed to fail (the build succeeds, but Giac is not fully functional - some of our tests fail).

Just having these macros there is not enough, you need to process what they output.

An easy fix (although not too user-friendly) would be to error out. AC_CHECK_LIB() has 5 arguments, last 3 of them optional,
so AC_CHECK_LIB(Xft, main, [], [AC_MSG_ERROR(exiting, as libXft cannot be found)]) would do the job.
(And only do these checks if building the GUI).

[dimpase]

Note that part of spkg-src is to remove non-GPL material from the tarball.

I see a seemingly unmodified GPL 3 in the main directory of the package (file COPYING).
@parisseb - is this correct, everything there is under GPL now?

In doc/README I see

Documentation in English is released under the GPL version 3, 
for other languages see specific conditions

but I don't see any "specific conditions" anywhere.

[dimpase]

we should disable micropython with --disable-micropy I believe.

ah, we already do that.

[parisseb]

Note that part of spkg-src is to remove non-GPL material from the tarball.

I see a seemingly unmodified GPL 3 in the main directory of the package (file COPYING). @parisseb - is this correct, everything there is under GPL now?

The source files in the src directory are under GPL, except maybe the 3d implicit plot code (I can not find the original reference, 404 error).

In doc/README I see

Documentation in English is released under the GPL version 3, 
for other languages see specific conditions

but I don't see any "specific conditions" anywhere.

My own manuals (algo.pdf/algo.html in doc/fr) are under GPL, but most of the French documentation is (c) by Renée De Graeve and may be distributed freely for non commercial use. Some parts of the English documentation are (c) by their respectives authors and there are also translator rights (for example Jay Belanger did the translation of a part of the French documentation in English). For example the graph theory manual or the optimization/signalprocessing sections are (c) by Luka Marohnić, they can of course obviously be distributed inside the Xcas distribution, but I don't know what licence Luka choosed, the best would be to ask him.

[parisseb]

What about AC_CHECK_LIB(Xft, main,[], [AC_MSG_ERROR(exiting, as libXft cannot be found. Hint: you can run ./configure --disable-fltk to compile without GUI)])?

[dimpase]

What about AC_CHECK_LIB(Xft, main,[], [AC_MSG_ERROR(exiting, as libXft cannot be found. Hint: you can run ./configure --disable-fltk to compile without GUI)])?

But --disable-fltk won't have the desired effect - you need --disable-gui instead.

[parisseb]

What about AC_CHECK_LIB(Xft, main,[], [AC_MSG_ERROR(exiting, as libXft cannot be found. Hint: you can run ./configure --disable-fltk to compile without GUI)])?

But --disable-fltk won't have the desired effect - you need --disable-gui instead.

In the latest giac versions, disable-gui should not work anymore (since FLTK is shipped inside the giac archive) and the Xft check is done inside if test "$CONFIG_FLTK" = "yes"; then ...

[dimpase]

This is what giac's ./configure -h says:

--enable-gui            The disable-gui option has no more effect because
                          FLTK 1.3.8 is now included in Giac/Xcas. If FLTK
                          compilation fails or if your local FLTK install is
                          incompatible, you should configure with
                          --disable-fltk
 --enable-fltk           enable FLTK [[default=yes]]

[dimpase]

OK, I'll postpone dealing with GUI to another PR, which most probably will need CI changes, doc changes, etc.

[dimpase]

2023-06-09T18:12:07.1979854Z **********************************************************************
2023-06-09T18:12:07.1980371Z File "sage/calculus/calculus.py", line 1691, in sage.calculus.calculus.laplace
2023-06-09T18:12:07.1980687Z Failed example:
2023-06-09T18:12:07.1981210Z     laplace(5*cos(3*t-2)*heaviside(t-2), t, s, algorithm='giac')
2023-06-09T18:12:07.1981489Z Expected:
2023-06-09T18:12:07.1981849Z     5*(s*cos(4)*e^(-2*s) - 3*e^(-2*s)*sin(4))/(s^2 + 9)
2023-06-09T18:12:07.1982073Z Got:
2023-06-09T18:12:07.1982417Z     Giac crashed -- automatically restarting.
5*(s*cos(4)*e^(-2*s) - 3*e^(-2*s)*sin(4))/(s^2 + 9)

the only failed test.

[parisseb]

I can not reproduce. Running with giac native laplace(5cos(3t-2)Heaviside(t-2), t, s);
returns (5scos(4)exp(-2s)-15exp(-2*s)*sin(4))/(s^2+9)

[dimpase]

OK, re-running doctests produced a clean run.

[mkoeppe]

This one definitely needs to go through portability testing...

[tornaria]

Also on musl libc, 1.9.0-55 fails on chk_fhan16 due to:

0>> solve(x^3-2*x^2-20*x+48.0=0, x)[2];
4.0+1.19293241367e-46*i

The expected is the correct 4.0 which is what it gives when built using glibc. In 1.9.0-49 this gives 4.000000000000000000 regardless of which libc.

Again, without published source history, is much harder to bisect what causes the change.

[parisseb]

In any case, it would be easy to appease the sanity check by doing the shift before the access.

I'm not certain, because if vector size is smaller then 4, then doing &v[v.size()-4] would also raise an abort from your checking system. Or &v[0]+v.size()-4 if v is empty. And anyway, I do not want to modify working code at several locations, why should I risk an error?

They're enabled in the OS. I could force them off for giac, but I would really rather leave them on if the user has chosen a profile that favors security over performance. They help prevent common security bugs; and in this case I think it's preventing undefined behavior from sneaking in.

Can you explain how? The pointer is used at one location
longlong * ptr= &buffer[C],*ptrend=&buffer[cmax]-4; const int *ptrN=&Nline[C]; for (;ptr<ptrend;ptrN+=4,ptr+=4){ ...

[parisseb]

• To build 1.9.0-55 I'm using https://xcas.univ-grenoble-alpes.fr/forum/viewtopic.php?f=3&t=2875#p12762

  • For the failure in chk_fhan4 (pari stack overflow) I'm using https://github.com/void-linux/void-packages/blob/master/srcpkgs/giac/patches/giac-pari-2.15-test.patch to set the pari size to 2M before running the test.

  • I don't think I ever saw the failure in chk_fhan17.

  • I 'm also getting some failures in chk_fhan0 (I think since 1.9.0-53) due to float precision, my patch is https://github.com/tornaria/void-packages/blob/giac/srcpkgs/giac/patches/fix-chk_fhan0.patch.

There are other issues with the testsuite that have been around since long and never fixed.

* For instance https://xcas.univ-grenoble-alpes.fr/forum/viewtopic.php?f=4&t=2102 fails since pari 2.11.

Well, I do not update pari myself, and the direction for giac is to become independant on PARI (I would say it's about 99.9% now). The link will be kept of course for users doing an explicit call to PARI with a pari() command. This was one reason for me to rewrite the univariate polynomial rooter code which was calling PARI for large degrees (a few hundred). This explains that checks involving the polynomial rooter may fail, due to precision. They should be rewritten to be more stable (I'm updating them to work on my own devel PC).

* Another one is using `gammaf()` instead of `tgammaf()` which is the correct one (`gammaf()` is deprecated in glibc and is missing in musl libc).

Actually, it depends on the compiler/platform, I have #ifdef in first.h to call tgammaf. Maybe they should be modified ? Giac is used with some compilers that are relatively old (e.g. closed-source compilers targetting ARM).

* Using `mallinfo()` guarded by `HAVE_MALLOC_H` but having `<malloc.h>` doesn't ensure `mallinfo()` is available (it is on glibc, but it's not on musl libc).

How should it be guarded? Anyway, it's not a big concern, it's only used once in Xcas GUI source code.

A github repo would allow contributed PR with fixes like these, as it is now with tarballs is very difficult to follow releases and contribute upstream. Also submitted PR could be automatically checked in different environments, etc.

I'm afraid I'm too old to change my way of working. There is a github repository for Giac source files at Geogebra, that I maintain with svn commits (Geogebra has set up an automatic translation tool) because I find myself tortoise svn easier to use than git.
https://github.com/geogebra/giac
This is probably the best location for people used to git to follow giac development.
If you want to propose change to giac, send me an email or post it at the Xcas forum.
By the way, I find phpbb forum much easier to read/write than this thread on github, with a much too small window to enter text, and which pollutes my email account every time something new is posted.

[orlitzky]

Can you explain how? The pointer is used at one location longlong * ptr= &buffer[C],*ptrend=&buffer[cmax]-4; const int *ptrN=&Nline[C]; for (;ptr<ptrend;ptrN+=4,ptr+=4){ ...

A priori there's no reason you would expect to be able to do that pointer arithmetic with the addresses of the entries of the vector. For it to be valid, you need several guarantees: the underlying memory must be contiguous, arranged in the correct order, of fixed size, etc. The C++ standard makes a very specific guarantee in that regard:

it obeys the identity &v[n] == &v[0] + n for all 0 <= n < v.size().

Specifically it does not guarantee that &v[v.size()] has any meaning.

[dimpase]

I have #ifdef in first.h to call tgammaf.

The correct way to check which gamma() to use would be to do a check in ./configure.

I'm too old to change my way of working

I am 60 y.o., and can testify to rejuvenating features of git and GitHub ;-)
I don't get any more how I ever lived with CVS and then SVN.

I find phpbb forum much easier to read/write than this thread on github,
with a much too small window to enter text,
in the bottom right corner of the edit window there is a "triangle" which you can pull on, and at least get as many rows as you want. (Also, you can just send emails, from the comfort of your email client...)

and which pollutes my email account every time something new is posted.
You can adjust notification settings. E.g. you can turn emails off completely, etc.

[parisseb]

Specifically it does not guarantee that &v[v.size()] has any meaning.

I can't imagine why it could be different from &v[0]+v.size(). Can you please configure giac disabling these security features and confirm if han17 works or not. I think it would also be a good idea if you could specify how to disable these security features.

@dima: I'm certainly different from you. I hate doing all "management" tasks, that are wasting a lot of my time, because of inadequate documentation that would require me to become an expert just to do simple tasks. I'm not comfortable at all with software that do not explain in plain text what they do, all these pictures do not mean anything for me and I really much prefer to have a large edit window from start, and that do not eat newlines in a "code" block.
I tried once to use tortoise git, and find svn more comfortable because you just need one operation to do a commit. Moreover I do not want to use one tool for one project and another one for another project. I will certainly not create a repository for giac myself.

Ok, life is short, I have a lot of work waiting for me. If you need to have git access to giac, just look at geogebra repository. If you want to send constructive comments or report bugs, please send me a mail or post to Xcas forum (don't expect me to learn new tools like PR because it would be more comfortable for you :-))
Thank you

[orlitzky]

Specifically it does not guarantee that &v[v.size()] has any meaning.

I can't imagine why it could be different from &v[0]+v.size().

Because an instance of the vector class isn't a C array. With a C array, it would be guaranteed to work, because the array offset is translated literally into a memory offset. But asking for the nth element of a vector with n-1 entries is meaningless. It may happen to work if the easiest way to implement it agrees with the behavior of a C array, but that can change at any time.

Can you please configure giac disabling these security features and confirm if han17 works or not. I think it would also be a good idea if you could specify how to disable these security features.

I'm sure it works if no one else has reported the problem. We would need to append -U_GLIBCXX_ASSERTIONS to CXXFLAGS to override the default.

[tornaria]

Well, I do not update pari myself, and the direction for giac is to become independant on PARI (I would say it's about 99.9% now).

Fine, but 2.11 was released in 2018, and you still ship a check that fails with 2.11+. If you won't apply https://xcas.univ-grenoble-alpes.fr/forum/viewtopic.php?f=4&t=2102, then just remove the test.

The link will be kept of course for users doing an explicit call to PARI with a pari() command. This was one reason for me to rewrite the univariate polynomial rooter code which was calling PARI for large degrees (a few hundred). This explains that checks involving the polynomial rooter may fail, due to precision. They should be rewritten to be more stable (I'm updating them to work on my own devel PC).

Is this why we are getting some tests with weird precision failures? One problem for us is that you don't communicate which releases are supposed to be stable and which ones are not, and there is no detailed changelog, etc. so we just have to guess when to update or not.

Actually, it depends on the compiler/platform, I have #ifdef in first.h to call tgammaf. Maybe they should be modified ? Giac is used with some compilers that are relatively old (e.g. closed-source compilers targetting ARM).

Can you use autoconf to test for tgammaf, then just use that?
I think

AC_CHECK_FUNCS(tgammaf)

in configure.ac, then you can use

#ifdef HAVE_TGAMMAF

* Using `mallinfo()` guarded by `HAVE_MALLOC_H` but having `<malloc.h>` doesn't ensure `mallinfo()` is available (it is on glibc, but it's not on musl libc).

How should it be guarded? Anyway, it's not a big concern, it's only used once in Xcas GUI source code.

Maybe same as above, AC_CHECK_FUNCS(mallinfo) then #ifdef HAVE_MALLINFO ?

I think the point of using autoconf is that you don't need to add knowledge about which systems have or have not a certain function, header, etc, but let autoconf do that work for you, then your #ifdefs are simpler.

There is a github repository for Giac source files at Geogebra, that I maintain with svn commits (Geogebra has set up an automatic translation tool) because I find myself tortoise svn easier to use than git. https://github.com/geogebra/giac This is probably the best location for people used to git to follow giac development.

That repo doesn't seem fully self contained, it's certainly different than the tarballs you publish and we use to build giac, and releases are not tagged. Maybe I'm missing something?

Is there a public svn repo for giac? That would be more useful.

If you want to send constructive comments or report bugs, please send me a mail or post to Xcas forum (don't expect me to learn new tools like PR because it would be more comfortable for you :-)) Thank you

The point of PR is that it should be easier for you. If you want patches, here are my current patches: https://github.com/tornaria/void-packages/tree/giac/srcpkgs/giac/patches.

Some are taken from your forum (https://xcas.univ-grenoble-alpes.fr/forum/viewtopic.php?f=3&t=2875#p12762, https://xcas.univ-grenoble-alpes.fr/forum/viewtopic.php?f=4&t=2102).

[dimpase]

I hate doing all "management" tasks, that are wasting a lot of my time

Who does tell you that I enjoy them? I'm not paid for these, I'm paid for writing papers: https://zbmath.org/authors/pasechnik.dmitrii-v
(just as well most probably you are paid for https://zbmath.org/authors/parisse.bernard)

I hate such tasks too, and not being able to use git to report issues and propose fixes is wasting my time, and your time as well, due to the ambiguity that gets in patches which are not tightly coupled to the source tree.

[parisseb]

Specifically it does not guarantee that &v[v.size()] has any meaning.

I can't imagine why it could be different from &v[0]+v.size().

Because an instance of the vector class isn't a C array. With a C array, it would be guaranteed to work, because the array offset is translated literally into a memory offset. But asking for the nth element of a vector with n-1 entries is meaningless. It may happen to work if the easiest way to implement it agrees with the behavior of a C array, but that can change at any time.

But I can't see any reason why someone writing a vector class template would change that, except for checking bounds, and then he would provide a way to avoid this if needed, and that's exactly the case for giac.

Can you please configure giac disabling these security features and confirm if han17 works or not. I think it would also be a good idea if you could specify how to disable these security features.

I'm sure it works if no one else has reported the problem. We would need to append -U_GLIBCXX_ASSERTIONS to CXXFLAGS to override the default.

OK, thanks! I'll add it in configure.ac.
CXXFLAGS="$CXXFLAGS -U_GLIBCXX_ASSERTIONS"

[parisseb]

@tornaria : I'm also adding in configure.ac AC_CHECK_FUNCS(tgammaf) and I make a change AC_CHECK_HEADERS(malloc.h,AC_CHECK_FUNCS(mallinfo))
I also modify the TP11-sol.cas with a call to pari("primecert")(p,1).
About svn/git: there is no svn repository for giac. You have either the tarballs I make when I release a new version from time to time, or the geogebra git that contains the Giac part (not the Xcas part, but this part does not change often).
PR would not save me time, because I would have to learn how it works, and I would probably make errors. Working like 20 years ago is the best way for me not to make errors.

@dimpase : I already spend a lot of time managing Giac for Xcas, Xcas for Firefox (wasm target), Geogebra, the HP Prime (Giac is the builtin CAS) and other calculators ports, each port has its own managing system and I'm alone to do that. Now consider that I'm not a Sage user, Sage is a competing CAS to Xcas, Sage is using some of the code I have optimized during years. Moreover Sage does not support a full version of Giac since it is configured without GUI. Therefore I'm ok to collaborate but I won't change my way of working.

[orlitzky]

OK, thanks! I'll add it in configure.ac. CXXFLAGS="$CXXFLAGS -U_GLIBCXX_ASSERTIONS"

The worst possible take. I give up. I'll patch it myself.

[dimpase]

I tried once to use tortoise git, and find svn more comfortable because you just need one operation to do a commit.

tortoise is some kind of Windows git frontend, no? No idea what it does, compared to plain git - probably it is meant for people uncomfortable with shell.

git commit foo.bar commits the changes in foo.bar, in one command - and this is all very well documented, by the way.

[parisseb]

FYI I'm developping with commandline, emacs, tarballs and scp. I find tortoise svn very useful to send my changes to geogebra because I don't have to remember any command and it displays the changes in a very clear manner, that way I'm sure not to make errors.

Geogebra does not react like that. They respect my work, they certainly would not require me to change working code at several locations, nobody would describe adding U_GLIBCXX_ASSERTIONS as the worst way to handle this issue. They facilitate my collaboration, for example when they migrated to git, they kept a way for me to synchronize with svn.
I would really appreciate more tolerance here.
Bye!

[dimpase]

@parisseb - we've put up with your interesting ways of doing work for years, all these vague version changes, renamed tarballs, patches god knows where to apply, etc etc.

Here we have an example of your interesting code:

longlong * ptr= &buffer[C],*ptrend=&buffer[cmax]-4; 
const int *ptrN=&Nline[C]; for (;ptr<ptrend;ptrN+=4,ptr+=4){ ...

It would not pass any sort of code review anywhere, it's, just, well, hmm, not how one writes C++.
(hint - use references, don't use pointers, it's C++, not C).
And, unsurprisingly, it breaks on some platforms.
Just adding U_GLIBCXX_ASSERTIONS is not a good way to fix it.

Yet, people spend time debugging this for you, because we value giac.
Do you want us to remove giac from Sage and leave you alone?

[parisseb]

Please don't reverse things, I spent some hours trying to debug what seems not to be a Giac bug, but an inadapted configuration.
I never pretended to write C++ code, I write C-like code using sometimes C++ facilities in order not to have to deal with memory allocation. The code we are discussing is an optimization to inline a loop, I did not write it for fun, but to speedup Groebner basis computation. One thing I have learned after more than 20 years working on Giac is that I should not modify working code unless there is some really good reason. I'm sorry, but security checking is not a good reason here, because if you change this location, then you should also change all other locations and there are many occurences of this kind of loop inlining in my code, there is a high risk of making an error and/or forget one and at some point you would get an error. Moreover these security checks are slowing done the code.
Life is short, I won't spend time modifying working code risking errors, I have other interesting things to implement.
BTW, I would of course not be happy if you decide to remove giac from the sage distribution, but I'm not really worried, I would not be alone as you say, Geogebra has millions of users, Xcas and various ports on calculators have thousands of users.
The really impacted people would be some sage users that are using giac either implicitly or explicitly. That's why I'm trying to fix what you report and that's why I would appreciate more tolerance and respect on your side.

[orlitzky]

With @tornaria's patch for the pari test, and after replacing the UB, both chk_fhan4 and chk_fhan17 now pass. Problem solved. No offense, I'm just not in the mood to argue all day about whether or not undefined behavior is "working code."

[tornaria]

@parisseb thanks. I'm still getting two test failures that seem to come from some precision trouble in roots() as in:

0>> roots(x^3-2*x^2-20*x+48.0);
[[-4.60555127546,1],[2.60555127546,1],[4.0+1.19293241367e-46*i,1]]
1>> roots(4*x^6+8*x^5+9*x^4+9*x^3+9*x^2+5*x+1.0);
[[-0.50000000000000423695020762139072415632649460476116514103247668021485588860239-0.31797400722558614463582272906881240871924499768158244356057150473500445334981e-15*i,1],[-0.49999999999999788328925430029686609811928022330776429539642815014895119703600,1]]

In the first one, the root is really 4.0, the imaginary part is getting there for some reason, which is weird given that this is supposed to return real roots only. Note this one I can only reproduce with musl libc but not with glibc.

In the second one, the roots are really -0.5 twice, for some reason it's giving the result with a lot of digits but only 2e-15 precision. The first root is again giving a complex value except now the imaginary part is not so small as before. This one gives the exact same numbers on musl libc and on glibc.

BTW, my interest on this is that I package giac for void linux, and I ship the whole thing with fltk support and all (see here: https://github.com/void-linux/void-packages/blob/master/srcpkgs/giac/template). For all my packages I try to upstream patches as much as possible (both because I think it's helpful for upstream and it's easier for me not to maintain a lot of patches).

[parisseb]

@tornaria : I can not reproduce the first small imaginary part with my latest devel version, I get [[-4.60555127546,1],[2.60555127546,1],[4.0,1]]
Maybe you have some non default configuration ? Try to rename ~/.xcasrc if it exists and run again, with the latest version of giac.
In your second example, the root -0.5 is of multiplicity 2, this will be detected before calling the rootfinder if the input is exact, in other words if you replace 1.0 by 1 for the constant coefficient. If the input has at least one approx coefficient, then the numeric rootfinder is called without trying to find multiplicities (because 1.0 may also represent 1.0-1e-18, and if it's the case there are 2 roots, not one) and you get the raw output of the rootfinder. It could be improved using the fact that the input is real, I'll have a look...

[dimpase]

Maybe you have some non default configuration ?

you need musl libc to reproduce.
I'm not sure how to get musl libc on a glibc-based Linux system, perhaps something to dig up on
https://wiki.musl-libc.org/

[parisseb]

geogebra/giac@d260eb5
should remove tiny imaginary parts, wherever the libc comes from

[mkoeppe]

@dimpase Then probably the best option is that we create a GitHub clone of https://salsa.debian.org/science-team/giac/-/tree/upstream?ref_type=heads, in which we can run the portability actions and create the tarballs that would become our "upstream".

I've created the fork at https://github.com/sagemath/giac

[orlitzky]

I've got a new PC that can't run any version of giac. The path of least resistance: #38668

[parisseb]

If you don't give any details ("a new PC" is not really sufficent), I can't help...

[dimpase]

RISC V machine?

[orlitzky]

RISC V machine?

Yeah, RISC-V International was nice enough to send me one of these: https://milkv.io/pioneer

[parisseb]

By default, Giac has many low level optimizations that will work on arm64 or amd64 but may fail on other 64 bits processors. For example the SMARTPTR64 define.