solve et spkg

[frederic han]

Bonjour,
J'ai un probleme avec la version de giac compilee avec les librairies de sage comme par exemple pour le spkg:

http://people.math.jussieu.fr/~han/xcas/giac-0.9.8.spkg


si je fais
sage -sh

puis giac alors cette version me donne:


0>> solve(cos(x)>0)
[x<0,x>0]
// Time 0.01


alors que le binaire ou la version sous freeBSD marchent.

Est ce que vous arrivez a le reproduire ou est ce chez moi?

Quelle librairie me manque t'il pour que ca ait change d'algo?
ldd /usr/local/sage-5.0.1/local/bin/giac
linux-vdso.so.1 => (0x00007fff679ff000)
libgiac.so.0 => /usr/local/sage-5.0.1/local/lib/libgiac.so.0 (0x00007ffd20cb2000)
libreadline.so.6 => /usr/local/sage-5.0.1/local/lib/libreadline.so.6 (0x00007ffd20a6b000)
libgsl.so.0 => /usr/local/sage-5.0.1/local/lib/libgsl.so.0 (0x00007ffd20646000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ffd20406000)
libcblas.so => /usr/local/sage-5.0.1/local/lib/libcblas.so (0x00007ffd201e7000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ffd1fee6000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ffd1fcd0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffd1f913000)
libntl.so => /usr/local/sage-5.0.1/local/lib/libntl.so (0x00007ffd1f53e000)
libpari-gmp.so.3 => /usr/local/sage-5.0.1/local/lib/libpari-gmp.so.3 (0x00007ffd1eebc000)
libgslcblas.so.0 => /usr/local/sage-5.0.1/local/lib/libgslcblas.so.0 (0x00007ffd1ec82000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ffd1ea79000)
liblapack.so => /usr/local/sage-5.0.1/local/lib/liblapack.so (0x00007ffd1e1b5000)
libatlas.so => /usr/local/sage-5.0.1/local/lib/libatlas.so (0x00007ffd1dc24000)
libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007ffd1d90c000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ffd1d708000)
libpng12.so.0 => /usr/local/sage-5.0.1/local/lib/libpng12.so.0 (0x00007ffd1d4d3000)
libmpfr.so.4 => /usr/local/sage-5.0.1/local/lib/libmpfr.so.4 (0x00007ffd1d27a000)
libgmp.so.7 => /usr/local/sage-5.0.1/local/lib/libgmp.so.7 (0x00007ffd1d00a000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ffd1cd10000)
/lib64/ld-linux-x86-64.so.2 (0x00007ffd21ac7000)
libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007ffd1cad9000)
libz.so.1 => /usr/local/sage-5.0.1/local/lib/libz.so.1 (0x00007ffd1c8c2000)

Fred

[parisse]

Ca ressemble fort à un problème que j'avais rencontré il y a quelques années de mauvais ordre de chargement des fichiers objets lors du chargement de la libgiac, qui fait que pi est évalué en 0.
Est-ce que pi s'évalue en pi?
Quelle configuration as-tu? Le flag de compilation important est GIAC_GENERIC_CONSTANTS (cf. usual.cc), essaie de le definir ou de le désactiver pour voir si ça change.

[frederic han]

lors de la compilation je vois bien des -DGIAC_GENERIC_CONSTANTS
(en 64bits)
j'ai:
CPPFLAGS="-I$SAGE_LOCAL/include"; export CPPFLAGS
LDFLAGS="-L$SAGE_LOCAL/lib/"; export LDFLAGS

et
./configure --prefix="$SAGE_LOCAL" --disable-gui


eval(pi) donne pi

0>> solve(sin(x)>0)
donne bien
[((x>0) and (x<pi))]

1>> solve(cos(x)>1/2)
[((x>((-pi)/6)) and (x<(pi/6)))]

mais
solve(cos(x)>0) ne marche pas.

[parisse]

je ne vois pas. Il faudrait executer au debuggueur. Je suppose que quand tu as lance un calcul avec giac, il y a un executable qui tourne? Si oui, il faudrait lancer gdb et faire attach no_de_process, puis mettre un point d'arret par exemple dans in_solve de solve.cc pour voir ce qu'il fait.

[frederic han]

C'est peut etre du cote d'acos:

le spkg me donne cela:

22>> acos(1)
0
// Time 0
23>> acos(0)
0
// Time 0
24>> acos(-1)
0

Fred

[parisse]

Que dit asin?
le code de acos est essentiellement de renvoyer pi/2-asin.
Si asin marche, ca doit etre la constante cst_pi_over_2 qui pose probleme (peut-etre parce que la constante pi n'est pas encore chargee lorsqu'il definit pi/2, il faudrait essayer si tu peux compiler sans GIAC_GENERIC_CONSTANTS, sinon controler l'ordre de chargement de identificateur.o et usual.o, par exemple en inversant l'ordre dans le Makefile.am), ou alors normal().

[frederic han]

Ca y est,

J'ai fait cette permutation:

diff Makefile.am Makefile.am~
9c9
< pari.cc cocoa.cc unary.cc identificateur.cc usual.cc gen.cc tinymt32.cc first.cc \
---
> pari.cc cocoa.cc unary.cc usual.cc identificateur.cc gen.cc tinymt32.cc first.cc \

et cette fois cela marche

Fred

[parisse]

bon, mais le probleme c'est que je ne peux pas generaliser ca, car l'ordre de chargement en fonction de l'ordre du Makefile depend de l'OS (de ld je suppose)

[parisse]

J'ai fait un changement dans le chargement de pi, qui devrait le forcer a etre correct independamment de l'ordre de chargement des .o. Tu peux tester si ca marche?

[frederic han]

Salut,

non ca ne marche pas.

D'un autre cote c'est peut etre plus simple de patcher le spkg vu que je dois deja le faire a cause de lapack?

Fred

[parisse]

Oui, c'est plus simple de patcher. Mais es-tu sur que le patch fonctionne sur différentes machines?

[frederic han]

Salut,
en fait j'ai teste sur une autre machine et la effectivement le spkg n'avait pas de pb sans avoir a patcher.

Ca me semble donc plutot etre un probleme avec ma compil sous ubuntu. La c'est une 12.04.

a+
Fred

[frederic han]

est ce que c'est un probleme similaire a celui ci:
http://sourceware.org/bugzilla/show_bug.cgi?id=13720

d'un cote j'ai ld version 2.20 et de l'autre 2.22

Fred