[sage-devel] Re: SageMath packaging status update
Nice, thanks for forwarding. I forwarded in turn to - the dormant "debian-sage" list [1], - the recently created "sage-packaging" list [2], where even more people might be interested. I also updated the "Distribution" wiki page [3] to mention the newly created "debian-science-sagemath" list. [1] https://groups.google.com/forum/#!forum/debian-sage [2] https://groups.google.com/forum/#!forum/sage-packaging [3] https://wiki.sagemath.org/Distribution -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: FriCAS installation fails
Also, we have an old version of FriCAS, current is 1.2.7. I just opened https://trac.sagemath.org/ticket/21209 (update the package) On Wednesday, August 10, 2016 at 5:46:55 PM UTC+1, Dima Pasechnik wrote: > > > > On Wednesday, August 10, 2016 at 4:43:27 PM UTC+1, Daniel Krenn wrote: >> >> On my SageMath 7.3 on Linux Mint 17.3 the command "sage -i fricas" >> fails. Part of the logfile is below. If someone wants more of the >> logfile, do not hesitate to ask. >> >> Any ideas what goes wrong? >> > > ECL does not use uffi: prefix any more, it's ffi: instead, according to > their docs. > Replacing all the uffi: with ffi: in src/lisp/fricas-lisp.lisp makes > compiler happy. > > Currently running the build, takes a while... > > > >> Best >> >> Daniel >> >> >> [...] >> ECL (Embeddable Common-Lisp) 16.1.2 (git:UNKNOWN) >> Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya >> Copyright (C) 1993 Giuseppe Attardi >> Copyright (C) 2000 Juan J. Garcia-Ripoll >> Copyright (C) 2015 Daniel Kochmanski >> ECL is free software, and you are welcome to redistribute it >> under certain conditions; see file 'Copyright' for details. >> Type :h for Help. >> Top level. >> > >> ;;; Loading >> "/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-package.lisp" >> >> >> ;;; Loading #P"/local/dakrenn/sage/7.3/local/lib/ecl/cmp.fas" >> #P"/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-package.lisp" >> >> >> > >> ;;; Loading >> "/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-config.lisp" >> >> >> #P"/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-config.lisp" >> >> >> > >> ;;; Loading >> "/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-ecl.lisp" >> >> >> #P"/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-ecl.lisp" >> >> >> > >> ;;; Loading >> "/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-lisp.lisp" >> >> >> >> Condition of type: SIMPLE-ERROR >> There is no package with the name UFFI. >> Available restarts: >> >> 1. (RESTART-TOPLEVEL) Go back to Top-Level REPL. >> >> Broken at SI:BYTECODES. [Evaluation of: (LOAD "fricas-lisp.lisp")] >> >> >> echo timestamp > do_it.ecl >> make[4]: Leaving directory >> `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp' >> >> make[4]: Entering directory >> `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/boot' >> >> Building stage 0 >> [ -d stage0 ] || ../../config/mkinstalldirs stage0 >> mkdir -p -- stage0 >> rm -rf prev-stage >> rm -f stage0/ptyout.o stage0/btincl2.o stage0/btscan2.o stage0/typrops.o >> stage0/btpile2.o stage0/typars.o stage0/tytree1.o >> rm -f stage0/ptyout.clisp stage0/btincl2.clisp stage0/btscan2.clisp >> stage0/typrops.clisp stage0/btpile2.clisp stage0/typars.clisp >> stage0/tytree1.clisp >> make OBJECTS="stage0/ptyout.o stage0/btincl2.o stage0/btscan2.o >> stage0/typrops.o stage0/btpile2.o stage0/typars.o stage0/tytree1.o" >> stage0/bootsys >> make[5]: Entering directory >> `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/boot' >> >> /local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/scripts/build_helper >> >> >> --compile_lisp --debug=no >> --use=/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/build/x86_64-unknown-linux/bin/lisp >> >> >> --output=stage0/ptyout.o compiled/ptyout.clisp >> /local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/scripts/build_helper: >> >> >> 13: >> /local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/scripts/build_helper: >> >> >> /local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/build/x86_64-unknown-linux/bin/lisp: >> >> >> not found >> make[5]: *** [stage0/ptyout.o] Error 127 >> make[5]: Leaving directory >> `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/boot' >> >> make[4]: *** [stage0/stamp_bootsys] Error 2 >> make[4]: Leaving directory >> `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/boot' >> >> make[3]: *** [all-boot] Error 2 >> make[3]: Leaving directory >> `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src' >> make[2]: *** [all-src] Error 2 >> make[2]: Leaving directory >> `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src' >> Error building fricas. >> >> real0m3.101s >> user0m1.528s >> sys0m0.528s >> >> Error installing package fricas-1.2.4 >> >> Please email sage-devel (http://groups.google.com/group/sage-devel) >> explaining the problem and including the relevant part of the log file >>
[sage-devel] Re: FriCAS installation fails
On Wednesday, August 10, 2016 at 4:43:27 PM UTC+1, Daniel Krenn wrote: > > On my SageMath 7.3 on Linux Mint 17.3 the command "sage -i fricas" > fails. Part of the logfile is below. If someone wants more of the > logfile, do not hesitate to ask. > > Any ideas what goes wrong? > ECL does not use uffi: prefix any more, it's ffi: instead, according to their docs. Replacing all the uffi: with ffi: in src/lisp/fricas-lisp.lisp makes compiler happy. Currently running the build, takes a while... > Best > > Daniel > > > [...] > ECL (Embeddable Common-Lisp) 16.1.2 (git:UNKNOWN) > Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya > Copyright (C) 1993 Giuseppe Attardi > Copyright (C) 2000 Juan J. Garcia-Ripoll > Copyright (C) 2015 Daniel Kochmanski > ECL is free software, and you are welcome to redistribute it > under certain conditions; see file 'Copyright' for details. > Type :h for Help. > Top level. > > > ;;; Loading > "/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-package.lisp" > > > ;;; Loading #P"/local/dakrenn/sage/7.3/local/lib/ecl/cmp.fas" > #P"/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-package.lisp" > > > > > ;;; Loading > "/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-config.lisp" > > > #P"/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-config.lisp" > > > > > ;;; Loading > "/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-ecl.lisp" > > > #P"/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-ecl.lisp" > > > > > ;;; Loading > "/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-lisp.lisp" > > > > Condition of type: SIMPLE-ERROR > There is no package with the name UFFI. > Available restarts: > > 1. (RESTART-TOPLEVEL) Go back to Top-Level REPL. > > Broken at SI:BYTECODES. [Evaluation of: (LOAD "fricas-lisp.lisp")] > >> > echo timestamp > do_it.ecl > make[4]: Leaving directory > `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp' > > make[4]: Entering directory > `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/boot' > > Building stage 0 > [ -d stage0 ] || ../../config/mkinstalldirs stage0 > mkdir -p -- stage0 > rm -rf prev-stage > rm -f stage0/ptyout.o stage0/btincl2.o stage0/btscan2.o stage0/typrops.o > stage0/btpile2.o stage0/typars.o stage0/tytree1.o > rm -f stage0/ptyout.clisp stage0/btincl2.clisp stage0/btscan2.clisp > stage0/typrops.clisp stage0/btpile2.clisp stage0/typars.clisp > stage0/tytree1.clisp > make OBJECTS="stage0/ptyout.o stage0/btincl2.o stage0/btscan2.o > stage0/typrops.o stage0/btpile2.o stage0/typars.o stage0/tytree1.o" > stage0/bootsys > make[5]: Entering directory > `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/boot' > > /local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/scripts/build_helper > > > --compile_lisp --debug=no > --use=/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/build/x86_64-unknown-linux/bin/lisp > > > --output=stage0/ptyout.o compiled/ptyout.clisp > /local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/scripts/build_helper: > > > 13: > /local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/scripts/build_helper: > > > /local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/build/x86_64-unknown-linux/bin/lisp: > > > not found > make[5]: *** [stage0/ptyout.o] Error 127 > make[5]: Leaving directory > `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/boot' > > make[4]: *** [stage0/stamp_bootsys] Error 2 > make[4]: Leaving directory > `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/boot' > > make[3]: *** [all-boot] Error 2 > make[3]: Leaving directory > `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src' > make[2]: *** [all-src] Error 2 > make[2]: Leaving directory > `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src' > Error building fricas. > > real0m3.101s > user0m1.528s > sys0m0.528s > > Error installing package fricas-1.2.4 > > Please email sage-devel (http://groups.google.com/group/sage-devel) > explaining the problem and including the relevant part of the log file > /local/dakrenn/sage/7.3/logs/pkgs/fricas-1.2.4.log > Describe your computer, operating system, etc. > If you want to try to fix the problem yourself, *don't* just cd to > /local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4 and type > 'make' or whatever is appropriate. > Instead, the following commands setup all environment variables > correctly and load
[sage-devel] FriCAS installation fails
On my SageMath 7.3 on Linux Mint 17.3 the command "sage -i fricas" fails. Part of the logfile is below. If someone wants more of the logfile, do not hesitate to ask. Any ideas what goes wrong? Best Daniel [...] ECL (Embeddable Common-Lisp) 16.1.2 (git:UNKNOWN) Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya Copyright (C) 1993 Giuseppe Attardi Copyright (C) 2000 Juan J. Garcia-Ripoll Copyright (C) 2015 Daniel Kochmanski ECL is free software, and you are welcome to redistribute it under certain conditions; see file 'Copyright' for details. Type :h for Help. Top level. > ;;; Loading "/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-package.lisp" ;;; Loading #P"/local/dakrenn/sage/7.3/local/lib/ecl/cmp.fas" #P"/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-package.lisp" > ;;; Loading "/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-config.lisp" #P"/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-config.lisp" > ;;; Loading "/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-ecl.lisp" #P"/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-ecl.lisp" > ;;; Loading "/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp/fricas-lisp.lisp" Condition of type: SIMPLE-ERROR There is no package with the name UFFI. Available restarts: 1. (RESTART-TOPLEVEL) Go back to Top-Level REPL. Broken at SI:BYTECODES. [Evaluation of: (LOAD "fricas-lisp.lisp")] >> echo timestamp > do_it.ecl make[4]: Leaving directory `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/lisp' make[4]: Entering directory `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/boot' Building stage 0 [ -d stage0 ] || ../../config/mkinstalldirs stage0 mkdir -p -- stage0 rm -rf prev-stage rm -f stage0/ptyout.o stage0/btincl2.o stage0/btscan2.o stage0/typrops.o stage0/btpile2.o stage0/typars.o stage0/tytree1.o rm -f stage0/ptyout.clisp stage0/btincl2.clisp stage0/btscan2.clisp stage0/typrops.clisp stage0/btpile2.clisp stage0/typars.clisp stage0/tytree1.clisp make OBJECTS="stage0/ptyout.o stage0/btincl2.o stage0/btscan2.o stage0/typrops.o stage0/btpile2.o stage0/typars.o stage0/tytree1.o" stage0/bootsys make[5]: Entering directory `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/boot' /local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/scripts/build_helper --compile_lisp --debug=no --use=/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/build/x86_64-unknown-linux/bin/lisp --output=stage0/ptyout.o compiled/ptyout.clisp /local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/scripts/build_helper: 13: /local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/scripts/build_helper: /local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/build/x86_64-unknown-linux/bin/lisp: not found make[5]: *** [stage0/ptyout.o] Error 127 make[5]: Leaving directory `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/boot' make[4]: *** [stage0/stamp_bootsys] Error 2 make[4]: Leaving directory `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src/boot' make[3]: *** [all-boot] Error 2 make[3]: Leaving directory `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src/src' make[2]: *** [all-src] Error 2 make[2]: Leaving directory `/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4/src' Error building fricas. real0m3.101s user0m1.528s sys 0m0.528s Error installing package fricas-1.2.4 Please email sage-devel (http://groups.google.com/group/sage-devel) explaining the problem and including the relevant part of the log file /local/dakrenn/sage/7.3/logs/pkgs/fricas-1.2.4.log Describe your computer, operating system, etc. If you want to try to fix the problem yourself, *don't* just cd to /local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4 and type 'make' or whatever is appropriate. Instead, the following commands setup all environment variables correctly and load a subshell for you to debug the error: (cd '/local/dakrenn/sage/7.3/local/var/tmp/sage/build/fricas-1.2.4' && '/local/dakrenn/sage/7.3/sage' --sh) When you are done debugging, you can type "exit" to leave the subshell. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options,
Re: [sage-devel] Re: Should warnings display a traceback?
On 2016-08-10 17:02, Travis Scrimshaw wrote:
However, this does have a problem that if we
don't enable them by default interactively, we get different output
behaviors.
We already have that for normal exceptions, where IPython does fancy
formatting of tracebacks.
Command-line:
---
ZeroDivisionError Traceback (most recent call last)
in ()
> 1 Integer(1)/Integer(0)
/usr/local/src/sage-config/src/sage/rings/integer.pyx in
sage.rings.integer.Integer.__div__
(build/cythonized/sage/rings/integer.c:12743)()
1841 if type(left) is type(right):
1842 if mpz_sgn((right).value) == 0:
-> 1843 raise ZeroDivisionError("rational division by zero")
1844 x = Rational.__new__(Rational)
1845 mpq_div_zz(x.value, (left).value,
(right).value)
ZeroDivisionError: rational division by zero
Doctest:
Traceback (most recent call last):
File
"/usr/local/src/sage-config/local/lib/python2.7/site-packages/sage/doctest/forker.py",
line 499, in _run
self.compile_and_execute(example, compiler, test.globs)
File
"/usr/local/src/sage-config/local/lib/python2.7/site-packages/sage/doctest/forker.py",
line 862, in compile_and_execute
exec(compiled, globs)
File "", line 1, in
Integer(1)/Integer(0)
File "sage/rings/integer.pyx", line 1843, in
sage.rings.integer.Integer.__div__
(build/cythonized/sage/rings/integer.c:12743)
raise ZeroDivisionError("rational division by zero")
ZeroDivisionError: rational division by zero
Nobody has ever complained about this. So I don't think that it's an
issue if warnings would look different in doctests.
Jeroen.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Should warnings display a traceback?
On Wednesday, August 10, 2016 at 8:33:33 AM UTC-5, Jeroen Demeyer wrote: > > On 2016-08-10 14:36, Travis Scrimshaw wrote: > > To clarify, I did not say doctests. > > Well, you replied on a paragraph from me about doctests, so I assumed > that we were talking about doctests. Ah, sorry, I wasn't paying attention to the context. > So again, what's your opinion then? > For doctests...hmmmI lean towards enabling them so elsewhere in the code, someone doing deprecations can much more easily see what is using the newly deprecated code. However, this does have a problem that if we don't enable them by default interactively, we get different output behaviors. This was something we have avoided in the past. So that is why I don't necessarily want to fully commit to having it on by default for doctesting. Best, Travis -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Dealing with libc math differences
Jeroen Demeyer wrote: > If the error is 1 ulp or more for a basic function (like log) on a > reasonable non-pathological input (like 3.0), I would consider that > an upstream bug. Quite a few implementations only provide accuracies of 3-4 ulp for speed reasons (it may make it possible to use double precision internally for intermediate operations that would otherwise require some kind of extended precision). -- Marc -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: '# distutils: libraries' in src/sage/libs/*.pxd
On 2016-08-10 16:14, leif wrote: Jeroen Demeyer wrote: On 2016-08-10 15:25, leif wrote: Is there a specific reason that for example mpfr.pxd and mpc.pxd lack a distutils directive? No. Are you willing to open a ticket, or should I? I don't care much. This would just be doing something for the sake of doing it. But if you write the code, I might review it. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: '# distutils: libraries' in src/sage/libs/*.pxd
Jeroen Demeyer wrote: > On 2016-08-10 15:25, leif wrote: >> Is there a specific reason that for example mpfr.pxd and mpc.pxd lack a >> distutils directive? > > No. Are you willing to open a ticket, or should I? > But just adding the "# distutils" directive might not be the right thing > to do either. I usually split up the type declarations from the function > declarations, see for example > src/sage/libs/gmp/types.pxd and src/sage/libs/gmp/mpz.pxd Yes, I know. (But for the two given, there's currently just one pxd.) > Then only the file declaring the functions should have the "# distutils" > directive. This reduces the number of modules which are linked against > the library: typically, a lot more files use the types and only a few > modules actually use the functions. Yep. (More work still, and /may/ require splitting upstream headers AFAIK, unless you "duplicate" e.g. type definitions.) -leif -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: '# distutils: libraries' in src/sage/libs/*.pxd
leif wrote: > Is there a specific reason that for example mpfr.pxd and mpc.pxd lack a > distutils directive? Also, the library_order in module_list.py is slightly wrong by the way: gmpxx should precede gmp, mpc should precede mpfr, and m should come almost last (just like stdc++) I think. (But that usually doesn't really matter, as we in most cases use shared libraries anyway, besides that most (GNU) linkers do not really care about order anyway, i.e., "remember" previously seen symbol definitions.) -leif -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] '# distutils: libraries' in src/sage/libs/*.pxd
On 2016-08-10 15:25, leif wrote: Is there a specific reason that for example mpfr.pxd and mpc.pxd lack a distutils directive? No. But just adding the "# distutils" directive might not be the right thing to do either. I usually split up the type declarations from the function declarations, see for example src/sage/libs/gmp/types.pxd and src/sage/libs/gmp/mpz.pxd Then only the file declaring the functions should have the "# distutils" directive. This reduces the number of modules which are linked against the library: typically, a lot more files use the types and only a few modules actually use the functions. Jeroen. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Should warnings display a traceback?
On 2016-08-10 14:36, Travis Scrimshaw wrote: To clarify, I did not say doctests. Well, you replied on a paragraph from me about doctests, so I assumed that we were talking about doctests. So again, what's your opinion then? -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] '# distutils: libraries' in src/sage/libs/*.pxd
Is there a specific reason that for example mpfr.pxd and mpc.pxd lack a distutils directive? -leif -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Dealing with libc math differences
On 2016-08-10 13:38, Erik Bray wrote: 1) Is it worth investigating the reason for the difference? No, but it is worth determining how bad the error is. In all cases, I would say that an error of less than 1 ulp is totally acceptable. If the error is 1 ulp or more for a basic function (like log) on a reasonable non-pathological input (like 3.0), I would consider that an upstream bug. Still, it would not necessarily be a problem for Sage if the error is a few ulp. 3) Or should the test just be updated to ignore the last couple digits of the result, and if so how (ellipses?) The best way is to use # (rel|abs) tol in the doctest. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Dealing with libc math differences
Erik Bray wrote: > Hi all, > > Sorry if this has been discussed ad-infinitum before--I looked around > a bit but didn't find a definitive answer. > > I have one (well at least one) test that's failing on Cygwin due to > tiny difference in the last digit of the result of log(3). > > This leads to to several questions: > > 1) Is it worth investigating the reason for the difference? I thought you had already tracked it down to "libc math" (= libm I guess). Which log() btw.? logf(), log(), logl()? (Presumably not clog*().) -leif > 2) Is it worth trying to provide a workaround for the difference? > 3) Or should the test just be updated to ignore the last couple digits > of the result, and if so how (ellipses?) > > Thanks, > Erik -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: doc.sagemath.org gone from google
William Stein wrote: > I'm googling for links to the sage reference manual, e.g., > > > https://www.google.com/search?q=sage+Elements+of+Quotients+of+Univariate+Polynomial+Rings=1C5CHFA_enUS691US691=sage+Elements+of+Quotients+of+Univariate+Polynomial+Rings=chrome..69i57j69i64.1153j0j7=chrome=UTF-8 > > and they now **all** go to combinat.sagemath.org.I had expected to > find links such as > > > http://doc.sagemath.org/html/en/reference/polynomial_rings/sage/rings/polynomial/polynomial_quotient_ring_element.html > > but nope. Shouldn't it be *docs*.sagemath.org anyway? Like docs.python.org, docs.cython.org, etc. (The former has an alias though, redirecting to docs.) -leif -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Dealing with libc math differences
Le 10/08/2016 à 13:38, Erik Bray a écrit : > Hi all, > > Sorry if this has been discussed ad-infinitum before--I looked around > a bit but didn't find a definitive answer. > > I have one (well at least one) test that's failing on Cygwin due to > tiny difference in the last digit of the result of log(3). > > This leads to to several questions: > > 1) Is it worth investigating the reason for the difference? > 2) Is it worth trying to provide a workaround for the difference? > 3) Or should the test just be updated to ignore the last couple digits > of the result, and if so how (ellipses?) > > Thanks, > Erik > Hello, What do you mean by log(3) ? Is it log(3.) or log(RDF(3)) ? With log(RDF(3)), this is classical; changing the library version, or the compiler version often changes the way some expressions and functions are computed. As floating point arithmetic is not associative, this is classical. With log(3.) (RealField()), I don't know. When we wrote the book "Calcul Mathématique avec Sage", we had this problem: after some release (some months) some doctests of the chapter on numerical algebra and floating point numbers failed. The only work around we found was to truncate the last digit in the output, to try to test what should remain constant. Note that: sage: log(RDF(3)) 1.0986122886681098 sage: log(3.) 1.09861228866811 But: sage: log(RDF(3)).n(prec=53) 1.09861228866811 sage: log(3.).n(prec=53) 1.09861228866811 sage: log(RDF(3))==log(3.) True as we also know that: sage: RDF.prec()==RealField().prec() True So in this case it is only a problem of rounding output. Good luck. Yours t. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. <>
Re: [sage-devel] Re: Should warnings display a traceback?
On Wednesday, August 10, 2016 at 3:24:23 AM UTC-5, Jeroen Demeyer wrote: > > On 2016-08-10 00:48, Travis Scrimshaw wrote: > > a typical user who just wants to run some simple code. > > If he is running doctests, that is already beyond a "typical user". > To clarify, I did not say doctests. I was thinking of something like a small(ish) .sage file that has a few functions for, say, demonstration or verification purposes of a computation/result. However, as Leif points out, we recommend running Sage's testsuite after a build from source. Best, Travis -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Dealing with libc math differences
Hey Erik, It seems like what you want is # rel tol XYZ or # abs tol XYZ. For an example, see rings/real_double.pyx. Best, Travis On Wednesday, August 10, 2016 at 6:38:59 AM UTC-5, Erik Bray wrote: > > Hi all, > > Sorry if this has been discussed ad-infinitum before--I looked around > a bit but didn't find a definitive answer. > > I have one (well at least one) test that's failing on Cygwin due to > tiny difference in the last digit of the result of log(3). > > This leads to to several questions: > > 1) Is it worth investigating the reason for the difference? > 2) Is it worth trying to provide a workaround for the difference? > 3) Or should the test just be updated to ignore the last couple digits > of the result, and if so how (ellipses?) > > Thanks, > Erik > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Dealing with libc math differences
Hi all, Sorry if this has been discussed ad-infinitum before--I looked around a bit but didn't find a definitive answer. I have one (well at least one) test that's failing on Cygwin due to tiny difference in the last digit of the result of log(3). This leads to to several questions: 1) Is it worth investigating the reason for the difference? 2) Is it worth trying to provide a workaround for the difference? 3) Or should the test just be updated to ignore the last couple digits of the result, and if so how (ellipses?) Thanks, Erik -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Should warnings display a traceback?
Jeroen Demeyer wrote: > On 2016-08-10 00:48, Travis Scrimshaw wrote: >> a typical user who just wants to run some simple code. > > If he is running doctests, that is already beyond a "typical user". So potentially anyone building from source is an untypical user? -- 8. Optional, but highly recommended: Test the install by typing ./sage --testall. This runs most examples in the source code and makes sure that they run exactly as claimed. To test all examples, use ./sage --testall --optional=all --long; this will run examples that take a long time, and those that depend on optional packages and software, e.g., Mathematica or Magma. Some (optional) examples will therefore likely fail. Alternatively, from within $SAGE_ROOT, you can type make test (respectively make ptest) to run all the standard test code serially (respectively in parallel). Testing the Sage library can take from half an hour to several hours, depending on your hardware. On slow hardware building and testing Sage can even take several days! -- (Excerpt from [1].) -leif [1] http://doc.sagemath.org/html/en/installation/source.html#general-procedure -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Should warnings display a traceback?
On 2016-08-10 00:48, Travis Scrimshaw wrote: a typical user who just wants to run some simple code. If he is running doctests, that is already beyond a "typical user". -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: fast_callable interpreter for MPC?
On Tuesday, August 9, 2016 at 6:22:06 PM UTC-7, Nils Bruin wrote: > > A quick inquiry: > > I noticed that fast_callable(...,domain=RealField(...) ) results in > instances of RRInterpreter, which is nice and fast. On the other hand, > fast_callable(...,domain=ComplexField(...)) results in a more generic type > (and something that is considerably slower, at least for polynomials). > This is now https://trac.sagemath.org/ticket/21198 It has a branch attached. Comments welcome. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
