Sage 6.4.rc0 released

[Volker Braun]

Notable changes are 

* OSX 10.10 support

* SageNB now can do 3d plots without Java, so it is usable again in chrome.

Please test, especially if you are a notebook user! 

As usual, pull the "develop" git branch or download the self-contained tarball http://sage.sagedev.org/home/release/sage-6.4.rc0.tar.gz

Mini-changelog:

d990119 Updated Sage version to 6.4.rc0

b2092bb Trac #17020: Update jmol to the latest version

2283698 Trac #16004: Update notebook to utilize pure javascript JSmol for default live 3-D

de7c38e Trac #17242: Uniform random generation  of Composition of a given size

9d8dc84 Trac #15914: Add the option to compute the fox derivative in a specific ring.

3f8b3d0 Trac #17238: Increase Precision in Failing Doctests

ba493df Trac #17169: Upgrade to GCC 4.9.1

94231d3 Trac #17199: doc cleanup in multi_polynomial_ideal

93d3dbf Trac #17244: Add a doctest for closed ticket #8005

522a6f8 Trac #17233: Uniform  random generation  of StandardTableau of a given size

05e978b Trac #17047: Isomorphism of incidence structures

535c980 Trac #16983: Fix finite field modulus handling

35ae4fd Trac #16706: Update IML to 1.0.4

e8696ab Trac #17241: Uniform random generation  of BinaryTree of a given size

cbb76f8 Trac #17216: Poset / LatticePoset: [meet|join]matrix algorithm

2524913 Trac #17179: TIDES interface should convert exact parameters to floating points.

cb14c36 Trac #17204: OSX Yosemite libtool version detection

fb25c13 Trac #10843: Faster listing of number field homsets

77cd34c Trac #16234: Assorted fixes and optimizations in sage-combinat (mostly partitions and tableaux)

5c934c4 Trac #17170: Sagenb graphics displayhook

a46bc25 Trac #16922: find_brouwer_van_rees_with_one_truncated_column

59e5eec Trac #17224: Fix pickling of NC rings with weighted term order

edbd263 Trac #17196: Relax assumptions on bitset operations

a554edb Trac #16719: replace gap.eval with libgap calls in combinat/combinat.py

d6feebb Trac #16313: easy-to-fix mistake in the stein-watkins optional database docs

91adf37 Trac #16493: Sage --dev tests broken for non-interactive shells

1e1cc3b Trac #16278: MPFI's spkg-install overwrites CFLAGS

7ae7117 Trac #17212: OSX zeromq testsuite

93741be Trac #17154: Comparison of WeylGroups

0718d27 Trac #17008: Give affine schemes unique representation (needed for elliptic curves and forking)

94164b6 Trac #17209: allow the use of distinct edgecolor and color for polygons in 2D

9ee40d7 Trac #16470: Add optional distance in BFS

8bdc755 Trac #17157: Improve formula for Bell numbers

4dc3c36 Trac #17203: Make sage -notebook=ipython land by default in pwd

7f934ea Trac #17195: Upgrade Cython to 0.21.1

c7053a5 Trac #15300: Clifford algebras and differential Weyl algebras

633b90e Trac #17202: IPython depends on pyzmq

419ad8e Trac #17186: LatticePoset: faster is_modular

311d9ef Trac #17189: Upon the first pass of the documentation compilation, undefined label warnings should not trigger an exception

ca7cc5e Trac #16396: upgrade Sphinx to 1.2

b5ed445 Trac #16919: mistake in sage/src/bin/sage-bdist, OSX app is always built 32-bit

56543ca Trac #16568: remove desolve_system_strings()

566d834 Trac #17112: Reorganize developer's manual table of contents

56eec8a Trac #9827: Intermittent doctest failure in sage/interfaces/psage.py

67ef668 Trac #17182: random spanning trees using the Aldous-Broder algorithm

f2ad04d Trac #17162: Error in semi-symmetric graph documentation

27a6d50 Trac #17078: Fix documentation in partition.py

810d34a Trac #16999: Fixing documentation typo.

2062d9d Trac #17193: Adding a hash function to weak and strong tableaux

2dbf16b Trac #16920: New V(m,t) vectors

be309e8 Trac #16911: Update sagenb

f68e873 Trac #16559: Brouwer-Van Rees version of Wilson's decomposition

c4e8674 Trac #17181: Poset.__repr__ should mention the linear extension

309f6cd Trac #17140: Remove usage of deprecated scipy.linalg.expm2 and expm3

050af2d Trac #16917: Deprecate cuspform_lseries() and modform_lseries()

a6e111e Trac #17103: Random failure in coercion/index.rst

de46432 Trac #17073: Documentation for Facade Sets

7ea8673 Trac #17168: Fix Cython "except" values in various places

fe042ce Trac #17167: Fix Cython "except" values in matroids

6b5ff95 Trac #17104: IncidenceStructure.relabel() (no arguments)

d9cd1a5 Trac #16233: Exceptions ignored by LeanMatrix operations

9b0995d Trac #17118: Added multiplier computation to affine morphism

22f3e28 Trac #17163: Speed improvement for DiGraph.in_degree

669107e Trac #14019: equality is broken for Posets

0270e9f Trac #17156: Creating a graph from a immutable digraph raises an error

402cfd8 Trac #11945: Throw exception instead of printing error in c_graph.pyx

6cb56e4 Trac #17152: Cython depends on setuptools

2490136 Trac #17126: Floating-point precision issues fail matrix2.py doctests

7c12f2c Trac #17148: Update ATLAS to latest stable 3.10.2

2407e08 Trac #17091: Update to git 2.1.2

4a2b592 Trac #16428: Cleanup/reorganization of FLINT imports

f9f642c Trac #15203: error in LLL method with delta=1

d0f2e7d Trac #10668: Refactor category support for morphisms (Hom is not a functorial construction!)

a4a6579 Trac #16340: Infrastructure for modelling full subcategories

dc64312 Trac #16998: Documentation conflict on is_graded()

bde9a75 Trac #16936: Hecke triangle groups (non-stub implementation)

bb85e22 Trac #17138: LatticePoset: complements() is broken

d82b80c Trac #17095: No documentation for random_element_plancherel()

794df00 Trac #17023: Adding width() function to poset

5e0c8d7 Trac #17119: Disallow pari(None)

599d03e Trac #16933: Remove deprecated code

[Thierry]

Hi,

thanks for this rc release (built without pb on Debian wheezy i686).

It could be nice to have #17155 merged in the stable one to ease
automatic building of custom binaries.

Ciao,
Thierry

> --
> You received this message because you are subscribed to the Google Groups "sage-release" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-release...@googlegroups.com.
> To post to this group, send email to sage-r...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-release.
> For more options, visit https://groups.google.com/d/optout.

[William Stein]

On Thu, Oct 30, 2014 at 7:12 AM, Volker Braun <vbrau...@gmail.com> wrote:

> As usual, pull the "develop" git branch or download the self-contained
> tarball http://sage.sagedev.org/home/release/sage-6.4.rc0.tar.gz

On Ubuntu 14.04 + *Opteron* -- "make ptestlong" worked fine except for
*one* test failure due to numerical noise, which is easy to fix (just
change that # tol 2e-14 to # tol 2e-13 below, and the test passes).

Running doctests with ID 2014-10-30-17-21-56-e997a143.
Doctesting 1 file.
sage -t --long --warn-long 65.1 src/sage/matrix/matrix_double_dense.pyx
**********************************************************************
File "src/sage/matrix/matrix_double_dense.pyx", line 3843, in
sage.matrix.matrix_double_dense.Matrix_double_dense.exp
Failed example:
A.exp(algorithm='eig') # tol 2e-14
Expected:
[-19.614602953804923 + 12.51774384676257*I 3.7949636449582016 +
28.883799306580997*I]
[-32.38358098092227 + 21.884235957898433*I 2.2696330040935084 +
44.90132482768484*I]
Got:
[-19.61460295380491 + 12.517743846762583*I 3.7949636449582247 +
28.88379930658099*I]
[-32.383580980922254 + 21.88423595789846*I 2.2696330040935564 +
44.90132482768484*I]
Tolerance exceeded in 1 of 8:
2.2696330040935084 vs 2.2696330040935564, tolerance 2e-14 > 2e-14
**********************************************************************
1 item had failures:
1 of 11 in sage.matrix.matrix_double_dense.Matrix_double_dense.exp
[642 tests, 1 failure, 1.34 s]
----------------------------------------------------------------------
sage -t --long --warn-long 65.1
src/sage/matrix/matrix_double_dense.pyx # 1 doctest failed
----------------------------------------------------------------------
Total time for all tests: 1.6 seconds
cpu time: 1.3 seconds
cumulative wall time: 1.3 seconds

> --
> You received this message because you are subscribed to the Google Groups
> "sage-release" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-release...@googlegroups.com.
> To post to this group, send email to sage-r...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-release.
> For more options, visit https://groups.google.com/d/optout.

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

[Samuel Lelièvre]

Buiding Sage 6.4.rc0 fails on gcc on a Mac with OS X 10.9. Logs at:

http://carva.org/samuel.lelievre/t/20141030_osx109_s64rc0_gcc491p0_config.log.tgz
http://carva.org/samuel.lelievre/t/20141030_osx109_s64rc0_install.log.tgz
http://carva.org/samuel.lelievre/t/20141030_osx109_s64rc0_logs_pkgs_config.log.tgz
http://carva.org/samuel.lelievre/t/20141030_osx109_s64rc0_logs_pkgs_gcc491p0.log.tgz


2014-10-30 15:12 GMT+01:00 Volker Braun <vbrau...@gmail.com>:
> [sage-release] Sage 6.4.rc0 released

[Volker Braun]

You have crap in /usr/local. Homebrew?

[kcrisman]

Thanks for this release!

Notable changes are 

* OSX 10.10 support

* SageNB now can do 3d plots without Java, so it is usable again in chrome.

Please test, especially if you are a notebook user! 

For those testing, another thing to test is whether the Mac App binaries build and work fine.

[kcrisman]

* OSX 10.10 support

* SageNB now can do 3d plots without Java, so it is usable again in chrome.

Please test, especially if you are a notebook user! 

For those testing, another thing to test is whether the Mac App binaries build and work fine.

Also, we'll probably need people to volunteer to contribute Mac binaries as apparently now our only buildbot is for Yosemite. 

[Dmitrii Pasechnik]

On 2014-10-30, Volker Braun <vbrau...@gmail.com> wrote:
> ------=_Part_742_1112049983.1414678340265
> Content-Type: text/plain; charset=UTF-8

>
> Notable changes are
>
> * OSX 10.10 support
> * SageNB now can do 3d plots without Java, so it is usable again in chrome.
>
> Please test, especially if you are a notebook user!

building on Ubuntu 12.04 on an i7 Intel (that's my
new Dell laptob, shipped with Ubuntu (!)) runs into trouble at ECM (unknown assembler
commands...), unless one forces the installation of gcc.
The installed gcc is

-v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --enable-plugin --enable-objc-gc
--disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)

and the Sage-produced gcc is

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/dima/software/sage/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../src/configure
--prefix=/home/dima/software/sage/local
--with-local-prefix=/home/dima/software/sage/local
--with-gmp=/home/dima/software/sage/local
--with-mpfr=/home/dima/software/sage/local
--with-mpc=/home/dima/software/sage/local --with-system-zlib
--disable-multilib --disable-nls --enable-languages=c,c++,fortran
--disable-libitm
Thread model: posix
gcc version 4.9.1 (GCC)

[Jeroen Demeyer]

I get doctest failures in sagenb:
http://trac.sagemath.org/ticket/17268

[Gutow, Jonathan H]

Compiled fine on Ubuntu 14.04 i3, although it took a while. The 3-D stuff I've been working on seems to work as expected. Did not run doctests.

Jonathan
On Oct 31, 2014, at 8:07 AM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:


Dr. Jonathan H. Gutow
Chemistry Department gu...@uwosh.edu
UW-Oshkosh Office:920-424-1326
800 Algoma Boulevard FAX:920-424-2042
Oshkosh, WI 54901
http://www.uwosh.edu/facstaff/gutow/

[Volker Braun]

Can you post the log for the failed ecm compile? GCC 4.6 is a bit old in the tooth now, of course...

[kcrisman]

Compiled fine on Ubuntu 14.04 i3, although it took a while.  The 3-D stuff I've been working on seems to work as expected.  Did not run doctests.

Did you notice that when clicking the Java 3D it automatically loads whether or not the live 3D checkbox is checked?  I'm not sure whether this is just me. 

[kcrisman]

Compiled fine on Ubuntu 14.04 i3, although it took a while.  The 3-D stuff I've been working on seems to work as expected.  Did not run doctests.

Did you notice that when clicking the Java 3D it automatically loads whether or not the live 3D checkbox is checked?  I'm not sure whether this is just me. 

Also, just now noticed a couple weird introspection things:

* Evaluate a jsmol and make it live.  

* Now change the code in that input cell to something like plot? and tab

* You should see the jsmol revert to non-live, and sometimes I can't get it to appear at all again (this is not always the case)

Alternately,

* Evaluate a jsmol and make it live.  

* Now change the code in that input cell to something like plot and then tab (no question mark)

* The jsmol reverts to non-live, though you can make it live, and the list of options gets covered up by the jsmol.  The only way to get it back is by tabbing again (but be careful, because if the thing you tabbed is also a function name, Sage interprets the second tab to be a request for documentation).

[Gutow, Jonathan H]

This is the expected behavior until the Jmol team finishes the upstream fix. Javascript and Java will work the same in the next update to the Jmol.spkg.
Jonathan

On Oct 31, 2014, at 9:14 AM, kcrisman <kcri...@gmail.com> wrote:

>
> Compiled fine on Ubuntu 14.04 i3, although it took a while. The 3-D stuff I've been working on seems to work as expected. Did not run doctests.
>
>
> Did you notice that when clicking the Java 3D it automatically loads whether or not the live 3D checkbox is checked? I'm not sure whether this is just me.
>

> --
> You received this message because you are subscribed to the Google Groups "sage-release" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-release...@googlegroups.com.
> To post to this group, send email to sage-r...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-release.
> For more options, visit https://groups.google.com/d/optout.

[Gutow, Jonathan H]

Hmm, I haven't looked at the behavior of tab completion...I will look.

Jonathan

> --
> You received this message because you are subscribed to the Google Groups "sage-release" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-release...@googlegroups.com.
> To post to this group, send email to sage-r...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-release.
> For more options, visit https://groups.google.com/d/optout.

[kcrisman]

 

Did you notice that when clicking the Java 3D it automatically loads whether or not the live 3D checkbox is checked?  I'm not sure whether this is just me. 

Also, just now noticed a couple weird introspection things:

* Evaluate a jsmol and make it live.  

* Now change the code in that input cell to something like plot? and tab

* You should see the jsmol revert to non-live, and sometimes I can't get it to appear at all again (this is not always the case)

Alternately,

* Evaluate a jsmol and make it live.  

* Now change the code in that input cell to something like plot and then tab (no question mark)

* The jsmol reverts to non-live, though you can make it live, and the list of options gets covered up by the jsmol.  The only way to get it back is by tabbing again (but be careful, because if the thing you tabbed is also a function name, Sage interprets the second tab to be a request for documentation).

Aannnd... try

sage: y = var('y')

sage: plot3d(x^2+y^3,(x,-1,1),(y,-1,1),viewer='tachyon')

from the *command line* in an older version and this version.  In Sage 6.2 I get, as expected, a png file popping up, clearly a Tachyon one, while in 6.4.rc0 I get a jmol app (unless I messed up switching branches while testing #16640, but I don't think so).  The display hook changes are what I would target, but I don't really understand that code very well so hopefully someone else can try to diagnose it.

Of the three issues

1. Live Java

2. Weird introspection

3. Tachyon not working from command line

I would only deem 3. a blocker, assuming it was introduced at some point during this series of betas, because people definitely do use tachyon to create super-cool Sage-powered videos.  1. is based on a user intentionally asking for Java, and 2. is annoying but an easy workaround is re-evaluating the cell or just making a new cell above it (though both should be fixed).

[Dmitrii Pasechnik]

On 2014-10-30, Volker Braun <vbrau...@gmail.com> wrote:
> ------=_Part_742_1112049983.1414678340265
> Content-Type: text/plain; charset=UTF-8
>

> Notable changes are
>
> * OSX 10.10 support
> * SageNB now can do 3d plots without Java, so it is usable again in chrome.
>
> Please test, especially if you are a notebook user!

doctest failures in ipython_notebook related to its dependence on
ssl. Should the corresponding (long) tests (9 out of 18) be marked as optional?

[Dmitrii Pasechnik]

On 2014-10-31, Volker Braun <vbrau...@gmail.com> wrote:
> ------=_Part_1806_1992617461.1414763378725
> Content-Type: text/plain; charset=UTF-8

>
> Can you post the log for the failed ecm compile? GCC 4.6 is a bit old in
> the tooth now, of course..

I suppose the relevant parts are
(by the way, I notice it seems to be linking against a static libgpm...)

[...]
Host system:
Linux dima-cs 3.5.0-41-generic #64somerville8-Ubuntu SMP Wed Oct 2
09:57:33 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
****************************************************
C compiler: gcc
C compiler version:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --enable-plugin --enable-objc-gc
--disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)

****************************************************
Adding '-fPIC' to CFLAGS since we don't (also) build a shared library.
Using additional host-specific CFLAGS: -march=native

Settings from SAGE_LOCAL/include/gmp.h:
CC=gcc -std=gnu99
CFLAGS=-m64 -O2 -march=k8 -mtune=k8 -g
Finally using:
CC=gcc
CFLAGS=-march=native -g -O3 -fPIC
CPP=
CPPFLAGS=
LDFLAGS=
ABI=
M4=
(These settings may still get overridden by 'configure' or Makefiles.)

Now configuring GMP-ECM with the following options:
--prefix="/home/dima/software/sage/local"
--libdir="/home/dima/software/sage/local/lib"
--with-gmp="/home/dima/software/sage/local"
You can set ECM_CONFIGURE to pass additional parameters,
e.g. "--enable-shared" to also build a *shared* library,
or "--disable-sse2" if you encounter problems on a Pentium III system.

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for a sed that does not truncate output... /bin/sed
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking dependency style of gcc... (cached) gcc3
checking dependency style of gcc... gcc3
checking whether gcc and cc understand -c and -o together... yes
checking how to print strings... printf
checking for a sed that does not truncate output... (cached) /bin/sed
checking for fgrep... /bin/grep -F
checking for ld used by gcc... ld
checking if the linker (ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments...
3458764513820540925
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-unknown-linux-gnu file names to
x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain
format... func_convert_file_noop
checking for ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (ld -m elf_x86_64) supports shared
libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... no
checking whether to build static libraries... yes
checking for int64_t... yes
checking for uint64_t... yes
checking for long long int... yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking whether time.h and sys/time.h may both be included... yes
checking for size_t... yes
checking for suitable m4... m4
checking how to switch to text section... .text
checking how to export a symbol... .globl
checking what assembly label suffix to use... :
checking if globals are prefixed by underscore... no
checking how to switch to text section... (cached) .text
checking how to export a symbol... (cached) .globl
checking for assembler .type directive...
checking for working alloca.h... yes
checking for alloca... yes
checking for ANSI C header files... (cached) yes
checking math.h usability... yes
checking math.h presence... yes
checking for math.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking malloc.h usability... yes
checking malloc.h presence... yes
checking for malloc.h... yes
checking for strings.h... (cached) yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for unistd.h... (cached) yes
checking io.h usability... no
checking io.h presence... no
checking for io.h... no
checking signal.h usability... yes
checking signal.h presence... yes
checking for signal.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking windows.h usability... no
checking windows.h presence... no
checking for windows.h... no
checking ctype.h usability... yes
checking ctype.h presence... yes
checking for ctype.h... yes
checking for sys/types.h... (cached) yes
checking sys/resource.h usability... yes
checking sys/resource.h presence... yes
checking for sys/resource.h... yes
checking for working strtod... yes
checking for pow in -lm... yes
checking for floor in -lm... yes
checking for sqrt in -lm... yes
checking for fmod in -lm... yes
checking for cos in -lm... yes
checking for cblas_dgemm in -lgslcblas... yes
checking for gsl_blas_dgemm in -lgsl... yes
checking for isascii... yes
checking for memset... yes
checking for strchr... yes
checking for strlen... yes
checking for strncasecmp... yes
checking for strstr... yes
checking for access... yes
checking for unlink... yes
checking for isspace... yes
checking for isdigit... yes
checking for isxdigit... yes
checking for time... yes
checking for ctime... yes
checking for setpriority... yes
checking for nice... yes
checking for gethostname... yes
checking for gettimeofday... yes
checking for getrusage... yes
checking for memmove... yes
checking for signal... yes
checking for fcntl... yes
checking for fileno... yes
checking for malloc_usable_size... yes
checking gmp.h usability... yes
checking gmp.h presence... yes
checking for gmp.h... yes
checking for recent GMP... yes
checking if GMP is MPIR... yes
checking whether we can link against GMP... yes
checking if gmp.h version and libgmp version are the same... (5.0.2/5.0.2) yes
checking for __gmpn_add_nc... no
checking for __gmpn_mod_34lsub1... yes
checking for __gmpn_redc_1... yes
checking for __gmpn_redc_2... yes
checking for __gmpn_mullo_n... no
checking for __gmpn_redc_n... no
checking for __gmpn_preinv_mod_1... yes
checking whether compiler knows __attribute__((hot))... yes
checking for xsltproc... no
checking for valgrind... valgrind -q --error-exitcode=1
creating config.m4
configure: creating ./config.status
config.status: creating Makefile
config.status: creating athlon/Makefile
config.status: creating pentium4/Makefile
config.status: creating x86_64/Makefile
config.status: creating powerpc64/Makefile
config.status: creating build.vc10/Makefile
config.status: creating build.vc10/assembler/Makefile
config.status: creating build.vc10/ecm/Makefile
config.status: creating build.vc10/libecm/Makefile
config.status: creating build.vc10/tune/Makefile
config.status: creating build.vc10/bench_mulredc/Makefile
config.status: creating config.h
config.status: linking ecm-params.h.athlon64 to ecm-params.h
config.status: linking mul_fft-params.h.athlon64 to mul_fft-params.h
config.status: executing depfiles commands
config.status: executing libtool commands
configure: Configuration:
configure: Build for host type x86_64-unknown-linux-gnu
configure: CC=gcc, CFLAGS=-march=native -g -O3 -fPIC
configure: Linking GMP with /home/dima/software/sage/local/lib/libgmp.a
configure: Using asm redc code from directory x86_64
configure: Not using SSE2 instructions in NTT code
configure: Assertions disabled
configure: Shell command execution disabled
configure: OpenMP disabled
configure: Memory debugging disabled

Now building GMP-ECM...
[...]
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I./x86_64
-I/home/dima/software/sage/local/include
-I/home/dima/software/sage/local/include -march=native -g -O3 -fPIC -MT
libecm_la-getprime.lo -MD -MP -MF .deps/libecm_la-getprime.Tpo -c
getprime.c -o libecm_la-getprime.o
/tmp/ccds4jAD.s: Assembler messages:
/tmp/ccds4jAD.s:137: Error: no such instruction: `vfmadd312sd offset(%rip),%xmm0,%xmm3'
/tmp/ccds4jAD.s:713: Error: no such instruction: `vfmadd312sd .LC12(%rip),%xmm0,%xmm2'
make[5]: *** [libecm_la-getprime.lo] Error 1

.

>
> On Friday, October 31, 2014 12:24:47 PM UTC, Dima Pasechnik wrote:
>>

[Volker Braun]

So gcc in Ubuntu 12.04 emits assembler that ubuntu's "as" doesn't understand, yay.

[Volker Braun]

Fix is in http://trac.sagemath.org/ticket/17262

[Volker Braun]

Yes!

[John H Palmieri]

On OSX 10.9,  I'm seeing sporadic failures with the zeromq test suite. If I run "./sage -f -c zeromq", then sometimes it passes, sometimes it fails with

Invalid argument (ip.cpp:136)
/bin/sh: line 1: 71673 Abort trap: 6           ${dir}$tst
FAIL: test_shutdown_stress

although the "Invalid argument" line varies from one failure to another (sometimes it says "(tcp.cpp:50)", for example). I just tried with 6.4.beta3 (where zeromq was not a standard package, I guess, and we had an older version of gcc) and I see a failure there, too:

Assertion failed: (s2), function main, file test_shutdown_stress.cpp, line 64.
/bin/sh: line 1: 93959 Abort trap: 6           ${dir}$tst
FAIL: test_shutdown_stress

--
John

[kcrisman]

Bizarrely, after earlier today having things working fine, now I unaccountably have the old notebook.  I did sage -f sagenb several times (and it unpacked the correct one) but no idea what happened, presumably due to some branch visiting at various times (though I don't recall having downgraded anything for that).  make only rebuilt a few packages.  The easy install path is correct; eventually I had to get rid of the 0.10.8.3 egg in the site-packages!   Baffling.  

In general, how can I figure out what version of any Python site-package I am using, by the way?  Unfortunately, there is no __version__ in this case, and since we usually have multiple versions there after a few upgrades, it can be confusing.

sage: sagenb.__[tab]

sagenb.__builtins__      sagenb.__doc__           sagenb.__hash__          sagenb.__package__       sagenb.__repr__          sagenb.__subclasshook__

sagenb.__class__         sagenb.__file__          sagenb.__init__          sagenb.__path__          sagenb.__setattr__       

sagenb.__delattr__       sagenb.__format__        sagenb.__name__          sagenb.__reduce__        sagenb.__sizeof__        

sagenb.__dict__          sagenb.__getattribute__  sagenb.__new__           sagenb.__reduce_ex__     sagenb.__str__           

sage: import sympy

sage: sympy.__version__

'0.7.4'

[Samuel Lelièvre]

2014-10-30 19:33 GMT+01:00 Volker Braun <vbrau...@gmail.com>:
> You have crap in /usr/local. Homebrew?

Homebrew again. After uninstalling Homebrew, Sage 6.4.rc0 builds fine.

[Volker Braun]

http://trac.sagemath.org/ticket/17268

[Clemens Heuberger]

Am 2014-10-30 um 15:12 schrieb Volker Braun:
> Notable changes are
>
> * OSX 10.10 support
> * SageNB now can do 3d plots without Java, so it is usable again in chrome.
>
> Please test, especially if you are a notebook user!

prior to 6.4.beta6, the following worked:

$ /local/sage/sage-6.3/sage -notebook directory=sage.sagenb
...
Please wait while the Sage Notebook server starts...
notebook(directory=r'''sage.sagenb''')
The notebook files are stored in: sage.sagenb
...

Leaving out "directory=" worked, too.

Now, with 6.4.beta6 or 6.4.rc0, I did not find any equivalent method of calling
the sagenb from the command line with a given directory.

I have tried the following without success:

$ /local/sage/sage-6.4.rc0/sage -notebook directory=sage.sagenb
CRITICAL:root:unknown notebook: directory=sage.sagenb
Error, notebook must be one of default, ipython, sagenb but got
directory=sage.sagenb

$ /local/sage/sage-6.4.rc0/sage -notebook sagenb directory=sage.sagenb
Traceback (most recent call last):
...
File "/local/sage/sage-6.4.rc0/local/lib/python/ast.py", line 79, in _convert
raise ValueError('malformed string')
ValueError: malformed string

$ /local/sage/sage-6.4.rc0/sage -notebook sagenb sage.sagenb
Traceback (most recent call last):
...
ValueError: malformed string

$ /local/sage/sage-6.4.rc0/sage -notebook sagenb --notebook-dir=sage.sagenb
Traceback (most recent call last):
...
ValueError: malformed string

Regards, CH

[Jeroen Demeyer]

On 2014-10-31 21:33, kcrisman wrote:
> In general, how can I figure out what version of any Python site-package
> I am using, by the way?

sage: import sagenb
sage: sagenb
<module 'sagenb' from
'/usr/local/src/sage-config/local/lib/python2.7/site-packages/sagenb-0.11.0-py2.7.egg/sagenb/__init__.pyc'>

[Jeroen Demeyer]

On 2014-10-30 15:12, Volker Braun wrote:
> * SageNB now can do 3d plots without Java, so it is usable again in chrome.

For me, this upgrade breaks 3D graphics to some extent:

When issuing the command cube(viewer="jmol") using

java version "1.6.0_31"
OpenJDK Runtime Environment (IcedTea6 1.13.3) (Gentoo build 1.6.0_31-b31)
OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)

with Firefox ESR 24.8.0 on a x86_64 Gentoo Linux system, I always get a
confusing error message like

/usr/local/src/sage-git/local/lib/python2.7/site-packages/IPython/core/f\
ormatters.py:239: FormatterWarning: Exception in text/plain formatter:
Jmol failed to create file
'/tmp/tmpJEIc27/.jmol_images/sage0-size500.jmol.png', see
'/home/jdemeyer/.sage/temp/tamiyo/2874/tmp_IABUbj.txt' for details
FormatterWarning,
None

The .txt file with details contains

Exception in thread "main" java.lang.UnsupportedClassVersionError:
org/jmol/translation/Jmol/en_GB/Messages_en_GB : Unsupported major.minor
version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:188)
at org.jmol.api.Interface.getInterface(Unknown Source)
at org.jmol.i18n.Resource.getResource(Unknown Source)
at org.jmol.i18n.GT.addBundle(Unknown Source)
at org.jmol.i18n.GT.addBundles(Unknown Source)
at org.jmol.i18n.GT.<init>(Unknown Source)
at org.jmol.i18n.GT.getTextWrapper(Unknown Source)
at org.jmol.i18n.GT._(Unknown Source)
at org.openscience.jmol.app.JmolApp.getOptions(Unknown Source)
at org.openscience.jmol.app.JmolApp.parseCommandLine(Unknown
Source)
at org.openscience.jmol.app.JmolData.main(Unknown Source)

Whether the display of the 3D figure actually works depends on the "Use
java for 3-D" and "Load 3-D Live" settings: it works iff exactly one of
those two is enabled. (but even if it works, I still get the error message)

[Francois Bissey]

That means you need java 1.7 at the minimum. Google is your friend:
http://stackoverflow.com/questions/10382929/unsupported-major-minor-version-51-0

François
> On 1/11/2014, at 22:31, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
>
> Unsupported major.minor version 51.0

[Volker Braun]

Jonathan, do you happen to know if Jmol is actually using Java 1.7 features? If not then it should be compiled with "javac -target 1.6" or something like that to be compatible with older JREs. See

http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#crosscomp-options

[Jeroen Demeyer]

On 2014-11-01 11:04, Francois Bissey wrote:
> That means you need java 1.7 at the minimum.

Is there any chance this could be detected and a better error message
given? Surely, I'm not the only one who would have this problem.

[kcrisman]

prior to 6.4.beta6, the following worked:

$ /local/sage/sage-6.3/sage -notebook directory=sage.sagenb

sage -n option=choice 

should in principle work with all options that work with

sage: notebook(option=choice)

and if they don't that is a bug.

[Clemens Heuberger]

Am 2014-11-02 um 04:13 schrieb kcrisman:
> sage -n option=choice
>
> should in principle work with all options that work with
>
> sage: notebook(option=choice)
>
> and if they don't that is a bug.

It seems that quote signs are now required for strings and were disallowed before:

$ /local/sage/sage-6.3/sage -notebook directory=sage.sagenb
$ /local/sage/sage-6.4.rc0/sage -n sagenb "directory='sage.sagenb'"

both work, however, neither does

$ /local/sage/sage-6.3/sage -n "directory='sage.sagenb'"

Traceback (most recent call last):
...

File "<string>", line 1
notebook(directory=r''''sage.sagenb'''')
^
SyntaxError: EOL while scanning string literal

nor

$ /local/sage/sage-6.4.rc0/sage -n sagenb directory=sage.sagenb

Traceback (most recent call last):
...

ValueError: malformed string

So there are two incompatible changes:

* -n requires "sagenb" or "default" unless it is alone on the command line.
* string handling has been changed.

Regards, CH

[kcrisman]

So there are two incompatible changes:

* -n requires "sagenb" or "default" unless it is alone on the command line.

Yeah, that isn't really cool.   http://trac.sagemath.org/ticket/16996

 

* string handling has been changed.

Does anyone know if this would make a difference for some other command-line options?

[kcrisman]

Jonathan, do you happen to know if Jmol is actually using Java 1.7 features? If not then it should be compiled with "javac -target 1.6" or something like that to be compatible with older JREs. See

http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#crosscomp-options

See also http://jmol.sourceforge.net/faqs/#Application%20system%20requirements which is perhaps old but claims Java 1.4 is sufficient in some manner.

See also http://trac.sagemath.org/ticket/16640#comment:41 

[kcrisman]

I note https://groups.google.com/d/msg/sage-devel/FryWNAidA70/wrgu3Ew0PhMJ but I'm not sure if it's relevant to the command-line parsing question. 

[Gutow, Jonathan H]

Yes, Jmol is using newer java features and for security reasons it is not a good idea to be using older versions of java.

Jonathan

[Gutow, Jonathan H]

There used to be such an error message. I haven't got time until later today to look into this. It is possible that when we moved to using check calls directly from python that we lost the version checking that I had put in the scripts they replaced. Does anybody remember?

Jonathan

> --
> You received this message because you are subscribed to the Google Groups "sage-release" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-release...@googlegroups.com.
> To post to this group, send email to sage-r...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-release.
> For more options, visit https://groups.google.com/d/optout.

[Volker Braun]

On Monday, November 3, 2014 1:34:50 PM UTC, kcrisman wrote:

Yeah, that isn't really cool.   http://trac.sagemath.org/ticket/16996

Closed tickets aren't the right place to discuss this.

I made http://trac.sagemath.org/17280

[Volker Braun]

On Sunday, November 2, 2014 5:10:19 AM UTC, Clemens Heuberger wrote:

$ /local/sage/sage-6.3/sage -n "directory='sage.sagenb'"
Traceback (most recent call last):
...
  File "<string>", line 1
    notebook(directory=r''''sage.sagenb'''')
                                           ^
SyntaxError: EOL while scanning string literal

IMHO that is the expected outcome for an optional command line argument. If you don't want the command line parsing to end (and not treat "directory..." as value) then you should use

sage -n -- directory=sage.sagenb

[Clemens Heuberger]

Am 2014-11-03 um 16:05 schrieb Volker Braun:
> IMHO that is the expected outcome for an optional command line argument. If you
> don't want the command line parsing to end (and not treat "directory..." as
> value) then you should use
>
> sage -n -- directory=sage.sagenb

I'd appreciate if we would have a deprecation warning if a user tries to use the
old behaviour (i.e., adding options immediately after -n, not knowing that there
are "-n default", "-n ipython", "-n sagenb" nowadays?).

Regards, CH

[Volker Braun]

You can't really deprecate that yet make the notebook selectable, either -n takes an option or not. 

On the plus side the error that you'll get is pretty self-explanatory.

$ ./sage -n foo=bar

CRITICAL:root:unknown notebook: foo=bar

Error, notebook must be one of default, ipython, sagenb but got foo=bar

[leif]

Volker Braun wrote:
> You can't really deprecate that yet make the notebook selectable, either
> -n takes an option or not.

Well, if a (potential) argument follows '-n', but doesn't match any of
'ipython', 'sagenb', nor 'default', we should probably default to
'default'... ;-) (Not to mention it contains an equals sign in the case
here, such that it's pretty clear what's meant, or not meant.)

> On the plus side the error that you'll get is pretty self-explanatory.

CRITICAL:root:unknown,

-leif

> $ ./sage -n foo=bar
> CRITICAL:root:unknown notebook: foo=bar
> Error, notebook must be one of default, ipython, sagenb but got foo=bar
>
>
> On Monday, November 3, 2014 5:41:29 PM UTC, Clemens Heuberger wrote:
>
> Am 2014-11-03 um 16:05 schrieb Volker Braun:
> > IMHO that is the expected outcome for an optional command line
> argument. If you
> > don't want the command line parsing to end (and not treat
> "directory..." as
> > value) then you should use
> >
> > sage -n -- directory=sage.sagenb
>
> I'd appreciate if we would have a deprecation warning if a user
> tries to use the
> old behaviour (i.e., adding options immediately after -n, not
> knowing that there
> are "-n default", "-n ipython", "-n sagenb" nowadays?).
>
> Regards, CH

--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail

[Volker Braun]

On Tuesday, November 4, 2014 8:49:10 AM UTC, leif wrote:

Well, if a (potential) argument follows '-n'

Its not a hand-written parser, duh. Also, that is not how command line tools work.

 

> On the plus side the error that you'll get is pretty self-explanatory.
CRITICAL:root:unknown,

Which part of the bog-standard Python logging is hard to understand?

[John Cremona]

It's a long time since I have done a "make ptestlong" and not had
several test failures. I have done "make distclean" first and have
pulled the latest develop branch (commit
8b95db32005c62e289d6698e8233218d5fda0f60) but see this:

sage -t --long src/sage/matrix/matrix_double_dense.pyx # 1 doctest failed
sage -t --long src/sage/tests/french_book/linsolve_doctest.py # 1
doctest failed
sage -t --long src/sage/matrix/matrix_real_double_dense.pyx # 1 doctest failed
sage -t --long src/sage/crypto/mq/sr.py # Timed out

where I think the first three are the usual suspects (for me). The
last one was ok on a retry. The others are

File "src/sage/matrix/matrix_double_dense.pyx", line 87, in
sage.matrix.matrix_double_dense.
Matrix_double_dense
Failed example:
m^(-1)
Expected:
[-1.9999999999999996 0.9999999999999998]
[ 1.4999999999999998 -0.4999999999999999]
Got:
[-2.0 1.0]
[ 1.5 -0.5]

File "src/sage/tests/french_book/linsolve_doctest.py", line 51, in
sage.tests.french_book.li
nsolve_doctest
Failed example:
x = A\b; x # rel tol 1e-15
Expected:
(-0.20000000000000018, 0.9000000000000001)
Got:
(-0.19999999999999987, 0.8999999999999999)
Tolerance exceeded in 1 of 2:
-0.20000000000000018 vs -0.19999999999999987, tolerance 2e-15 > 1e-15

File "src/sage/matrix/matrix_real_double_dense.pyx", line 61, in
sage.matrix.matrix_real_dou
ble_dense.Matrix_real_double_dense
Failed example:
n = m^(-1); n
Expected:
[-1.9999999999999996 0.9999999999999998]
[ 1.4999999999999998 -0.4999999999999999]
Got:
[-2.0 1.0]
[ 1.5 -0.5]

which I am sure have been mentioned before, but I also thought they
had been fixed?

John

[Volker Braun]

At least the ones you mention are in #17278 which will be in rc2

[Jean-Pierre Flori]

Were this specific ones mentonied?
I know some were fixed in #17063, some in #17126, some in #17238 ...
And with all of these merged, everything was fine with 6.4..rc0, but now I get new failing ones with 6.4.rc1 :)

[John Cremona]

On 4 November 2014 13:56, Volker Braun <vbrau...@gmail.com> wrote:
> At least the ones you mention are in #17278 which will be in rc2

Good! looking forward to it.

John

[Volker Braun]

Do you get any failures with #17278?

[Jean-Pierre Flori]

I didn't check but would say so as the failures happen in other files.
Namely in the different translations of:
src/doc/en/tutorial/tour_linalg.rst

[John Cremona]

On 4 November 2014 15:42, Volker Braun <vbrau...@gmail.com> wrote:
> Do you get any failures with #17278?
>

2 pass, 1 still fails:

File "src/sage/tests/french_book/linsolve_doctest.py", line 51, in
sage.tests.french_book.linsolve_doctest
Failed example:
x = A\b; x # rel tol 1e-15
Expected:
(-0.20000000000000018, 0.9000000000000001)
Got:
(-0.19999999999999987, 0.8999999999999999)
Tolerance exceeded in 1 of 2:
-0.20000000000000018 vs -0.19999999999999987, tolerance 2e-15 > 1e-15

John

[Volker Braun]

Since they are machine-dependent numerical noise its not going to get fixed unless you tell us what failed.

[Jean-Pierre Flori]

On Tuesday, November 4, 2014 7:02:00 PM UTC+1, Volker Braun wrote:

Since they are machine-dependent numerical noise its not going to get fixed unless you tell us what failed.

Sure, don't worry, I'll open a ticket for that.
It is #17921.

[Thierry]

Hi,

all those numerical noise appearing suddenly, couldn't that mean that
some numerical algorithm became less stable/accurate somewhere in the
code ?

If it turns out to be the case, we should thank doctests for the
discovery, not asking them to shut up by enlarging the tolerance !

Also, in the case where the error is just "going the other way", we
should not enlarge the tolerence, but instead have an exact expected
result in the doctest. For example, (see #17291):

On Tue, Nov 04, 2014 at 05:15:29PM +0000, John Cremona wrote:
> File "src/sage/tests/french_book/linsolve_doctest.py", line 51, in
> sage.tests.french_book.linsolve_doctest
> Failed example:
> x = A\b; x # rel tol 1e-15
> Expected:
> (-0.20000000000000018, 0.9000000000000001)
> Got:
> (-0.19999999999999987, 0.8999999999999999)
> Tolerance exceeded in 1 of 2:
> -0.20000000000000018 vs -0.19999999999999987, tolerance 2e-15 >
> 1e-15

We should expect (-0.2, 0.9) with the previous tolerance instead of
enlarging the tolerance (therefore weakening the doctest) with an
inexact expected result, since the errors are of the same magnitude but
not the same direction.

The same holds for, for example (see #17278):

On 04/11/2014 14:16, John Cremona wrote:> It's a long time since I have

> File "src/sage/matrix/matrix_double_dense.pyx", line 87, in
> sage.matrix.matrix_double_dense.
> Matrix_double_dense
> Failed example:
> m^(-1)
> Expected:
> [-1.9999999999999996 0.9999999999999998]
> [ 1.4999999999999998 -0.4999999999999999]
> Got:
> [-2.0 1.0]
> [ 1.5 -0.5]

Enlagring the tolerance for catching the correct result instead of
taking this correct result as the centered expectation looks like an odd
fix !

Ciao,
Thierry

[Jean-Pierre Flori]

On Tuesday, November 4, 2014 9:58:54 PM UTC+1, Thierry wrote:

Hi,

all those numerical noise appearing suddenly, couldn't that mean that
some numerical algorithm became less stable/accurate somewhere in the
code ?

I think its the way we treat tolerance which changed, so no real problem hidden here .

Sure putting exact values as the centered ones is the best way to go.

[François Bissey]

It could. But in this case looking at the 1e-15 tolerance I think that
we are just hitting numerical noise because the specification for double
doesn't insure that those last decimals are exact. And even if it
was for a single computation we could be hit by rounding error if there is
a number of computations involved. I think on a number of those the people
who wrote the test were too decimal happy without looking at whether or
not the last ones made any sense in the first place.

The last batch is probably triggered by the ATLAS update to 3.10.2.
In sage-on-gentoo I use openblas and it causes one other doctest to
fail at ~1e-18 level
sage -t --long /usr/share/sage/src/sage/matrix/matrix_double_dense.pyx
**********************************************************************
File "/usr/share/sage/src/sage/matrix/matrix_double_dense.pyx", line 1856, in
sage.matrix.matrix_double_dense.Matrix_double_dense.solve_left
Failed example:
x = A.solve_left(b); x.zero_at(1e-18) # fix noisy zeroes
Expected:
(0.666666666..., 0.0, 0.333333333...)
Got:
(0.6666666666666666, 7.50150692314295e-18, 0.3333333333333332)
**********************************************************************

That test looks if something is 0 up to 1e-18 and I have a result smaller
than 1e-17. Where do you put the bar? And the difference here is in blas
implementation.

At that kind of tolerance, unless you have algorithm that use gmp/mpfr/mpc
and are geared towards high accuracy you see nothing. It is mainly looking
at decimals that are already numerical noise as if they were actually
correct.

Francois

[Volker Braun]

On Tuesday, November 4, 2014 8:58:54 PM UTC, Thierry wrote:

all those numerical noise appearing suddenly, couldn't that mean that
some numerical algorithm became less stable/accurate somewhere in the
code ? 

No, it is because we print more digits now. 

[Jeroen Demeyer]

On 2014-11-04 21:58, Thierry wrote:
> Enlagring the tolerance for catching the correct result instead of
> taking this correct result as the centered expectation looks like an odd
> fix !

On the other hand, don't forget that doctests serve not only as *tests*
but also as *docs*. I think it's good to have some values like
14.9999999999 in the documentation to show users that such results are
normal. If all doctests only show nice values like 15.0, I'm sure
somebody would think that his result of 14.9999999999 is a bug.

In my opinion, doctest output should be the actual output of a Sage run
somewhere and not artificially be adjusted (exceptions are for doctests
which are truly just tests).

[Harald Schilly]

On Tue, Nov 4, 2014 at 10:24 PM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> In my opinion, doctest output should be the actual output of a Sage run
> somewhere and not artificially be adjusted

Well, if there are different outputs for the same input, which one to
pick? IMHO, in this case it's actually better to clearly state what
the actual *expected* output is and add a neat tolerance to cover all
occurring results.

-- H

[Jeroen Demeyer]

On 2014-11-04 22:02, Jean-Pierre Flori wrote:
> I think its the way we treat tolerance which changed

It's true that the way we treat tolerance has changed, see
http://trac.sagemath.org/ticket/16889

But that's not the reason for the failed tests, the reason is
http://trac.sagemath.org/ticket/16858

[Jeroen Demeyer]

On 2014-11-04 22:31, Harald Schilly wrote:
> On Tue, Nov 4, 2014 at 10:24 PM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
>> In my opinion, doctest output should be the actual output of a Sage run
>> somewhere and not artificially be adjusted
>
>
> Well, if there are different outputs for the same input, which one to
> pick?

Any is good.

In practice: whatever you get on the system that you work on.

[kcrisman]

> IMHO that is the expected outcome for an optional command line argument. If you
> don't want the command line parsing to end (and not treat "directory..." as
> value) then you should use
>
> sage -n -- directory=sage.sagenb

I'd appreciate if we would have a deprecation warning if a user tries to use the
old behaviour (i.e., adding options immediately after -n, not knowing that there
are  "-n default", "-n ipython", "-n sagenb" nowadays?).

Just for reference, the current status is at http://trac.sagemath.org/ticket/17280 .  Clemens, this still won't support the syntax you and others are used to...

> Well, if a (potential) argument follows '-n', but doesn't match any of 'ipython', 'sagenb', nor 'default', we should probably default to 'default'... ;-)  (Not to mention it contains an equals sign in the case here, such that it's pretty clear what's meant, or not meant.) 

Yeah, I kind of agree, since even though "it's not a hand-written parser" it still is an API change.

[Volker Braun]

On Wednesday, November 5, 2014 4:23:59 PM UTC, kcrisman wrote:

Yeah, I kind of agree, since even though "it's not a hand-written parser" it still is an API change.

UI change, not API.

I'm against second-guessing what the input might mean. The command line UI rules are IMHO clear and exactly what argparse implements: "-n foo" and "--notebook=foo" ought to be the same.

[Ivan Andrus]

On Nov 5, 2014, at 9:44 AM, Volker Braun <vbrau...@gmail.com> wrote:

On Wednesday, November 5, 2014 4:23:59 PM UTC, kcrisman wrote:

Yeah, I kind of agree, since even though "it's not a hand-written parser" it still is an API change.

UI change, not API.

No.  People write scripts against this, so it’s an API change.  The Mac app is one place.  I don’t think it will be affected by this particular change, but it _is_ still an API.

-Ivan

[Volker Braun]

On Wednesday, November 5, 2014 5:13:04 PM UTC, Ivan Andrus wrote:

No.  People write scripts against this, so it’s an API change.  

No. If you screen scrap the output and run image recognition on the window content then its still a UI, even if you built a crappy API around it. 

[kcrisman]

 

No.  People write scripts against this, so it’s an API change.  

No. If you screen scrap the output and run image recognition on the window content then its still a UI, even if you built a crappy API around it. 

I don't really care if you call it a UI or API; this will be moot to the end user.  It is an interface that worked the same way for a long time and achieved de facto status.  Even if it didn't follow some POSIX thing ("The command line UI rules" of which you speak) the vast majority of Sage users will be unfamiliar with.  The goal of Sage is being a viable alternative to various programs, not infinite compliance with such things, though if we can move that way gently, it makes things easier for (some) developers.

Ivan, if you can test the Mac app with this rc, that would be nice, though I suspect also it might stay okay.

[Volker Braun]

On Wednesday, November 5, 2014 9:28:38 PM UTC, kcrisman wrote:

It is an interface that worked the same way for a long time and achieved de facto status.

Fine, if you don't want a way to start the ipython notebook then I can take out the optional argument. 

[kcrisman]

It is an interface that worked the same way for a long time and achieved de facto status.

Fine, if you don't want a way to start the ipython notebook then I can take out the optional argument. 

Perhaps I will leave it to those who use this feature to comment next.   I assume that means Leif's suggestion would require essentially writing a new parser?

[Clemens Heuberger]

On 2014-11-06 02:41, kcrisman wrote:
>
> It is an interface that worked the same way for a long time and achieved
> de facto status.
>
>
> Fine, if you don't want a way to start the ipython notebook then I can take
> out the optional argument.
>
>
> Perhaps I will leave it to those who use this feature to comment next.

As you somehow ask me as the one who started this discussion to comment again, I
try summarize my opinion on that issue.

I and my co-authors used that feature (-n directory=sage.sagenb) for years now
in order to keep our sage worksheets associated to a paper under the same
version control as the paper itself.

When sage-6.4.beta6 came out, I was not able to quickly find out the problem,
because the problem was twofold (I'd have had to add "default" or "sagenb" and
fix the quotes issue). Since that time, we adapted different strategies, partly
starting the notebook inside sage, partly manually converting our worksheets to
the ipython notebook.

The quotes issue is now fixed in the trac ticket mentioned somewhere in this thread.

On the long run, IMHO,

- having -n with an optional argument is the correct solution,

- requiring separation of the non-options by "--" is also the correct solution,

- I always found these key=value pairs on the command line as something strange.

I currently do not yet have access to a compiled version of 6.4.rc1; therefore,
I do not know

- whether the option --notebook-dir introduced for -n ipython still works or has
been removed due to the change in the default notebook directory. IMHO it
should still be there;

- whether the option --notebook-dir works with sagenb; IMHO it should;

- whether the option --notebook-dir is documented in ./sage -h (or --advanced);
IMHO it should be

- on whether the old behaviour "-n directory=sage.sagenb" is documented
somewhere and whether this documentation has been adapted to the new
situation.

I'd appreciate moving more of the key=value command line arguments to proper
command line options, e.g. --notebook-port=..., usable in all notebooks.

I do not know whether users running into the error message Volker quoted will be
able to react appropriately.

To summarize: I am not happy with the change in the interface without
deprecation of the old behaviour, but if writing a work-around is too
complicated, then let's keep it that way and hope that users using this old
behaviour will either adapt their scripts or move to ipynb.

Kind regards, CH

[Volker Braun]

On Thursday, November 6, 2014 7:12:34 AM UTC, Clemens Heuberger wrote:

- whether the option --notebook-dir introduced for -n ipython still works or has
  been removed due to the change in the default notebook directory. IMHO it
  should still be there;

Its part of the IPython notebook arguments. There are no plans to change it. The default ipython notebook directory has been changed to the current directory. The default directory for sagenb has not been changed. It is not documented in Sage, but documented in the IPython notebook (i.e. sage --notebook=ipython --help)

 

[kcrisman]

> - whether the option --notebook-dir is documented in ./sage -h (or --advanced); 
>   IMHO it should be 

It is not, and that points us to

$ ./sage --notebook --help

usage: sage-notebook [-h] [--log LOG] [--notebook [NOTEBOOK]]

The Sage notebook launcher is used to start the notebook, and allows you to

choose between different implementations. Any further command line options are

passed to the respective notebook.

optional arguments:

  -h, --help            show this help message and exit. Can be combined with

                        "--notebook=[...]" to see notebook-specific options

  --log LOG             one of [DEBUG, INFO, ERROR, WARNING, CRITICAL]

  --notebook [NOTEBOOK], -n [NOTEBOOK], -notebook [NOTEBOOK]

                        The notebook to run [one of: default, ipython,

                        sagenb]. Default is sagenb

which also doesn't help, while that points us to

$ ./sage --notebook=sagenb --help

which unfortunately just gives the notebook? commands but doesn't tell how to use them with the notebook-specific options.

> - on whether the old behaviour "-n directory=sage.sagenb" is documented 
>   somewhere and whether this documentation has been adapted to the new 
>   situation. 

It was documented in the following way, in sage --advanced

  -n, -notebook [...] -- start the Sage notebook (options are the same

                         as for the notebook command in Sage)

So I would say that since I *do* agree that anyone using this option probably is savvy enough to actually read the help, perhaps documenting exactly how the options are to be called in `sage --advanced` and/or `sage --notebook --help`  would be enough to resolve this issue.  (Changing `sage --notebook=sagenb --help` would require more annoyance than worth.)  This should be pretty easy to do in the script itself, and given that we never said exactly how to *call* the options before I think that as long as we clearly document this (not necessarily with zillions of examples, but maybe two) then this would work okay.

One could at the same time add the info about the default directory, incidentally.

I'll put these notes at #17280 as well.

- kcrisman

[kcrisman]

As you somehow ask me as the one who started this discussion to comment again, I
try summarize my opinion on that issue.

 

Thanks.

The quotes issue is now fixed in the trac ticket mentioned somewhere in this thread.

http://trac.sagemath.org/ticket/17280

If you would be so kind as to confirm on that ticket that the fix there does indeed fix it and the code seems right to you?  (Assuming you've tried it out.)

[Clemens Heuberger]

On 2014-11-06 15:59, kcrisman wrote:
>
> http://trac.sagemath.org/ticket/17280
>
> If you would be so kind as to confirm on that ticket that the fix there does
> indeed fix it and the code seems right to you? (Assuming you've tried it out.)

I'll try it out within the next two days (sorry for the delay) and post my
comments on the ticket.

Regards, CH

[kcrisman]

35ae4fd Trac #16706: Update IML to 1.0.4

Turns out something here broke compilation on some Macs.  Here's what I reported at the ticket (can continue conversation here):

On an old Mac (slightly newer than my usual test machine, but still OS X 10.4 PPC) iml bails out with complaining about not having ATLAS 3.0 or greater.  These built Sage 6.4.beta6 fine (other than rpy2) so it must be something about this upgrade that changes it - I assume iml always asked for that, see for instance [https://groups.google.com/forum/#!topic/sage-forum/sHwJyMp7Wmo this nearly 8-year-old discussion]!

Could it possibly be the removal of

{{{

--with-atlas-include="`pwd`" --with-atlas-lib=/usr/lib

}}}

Reading http://web.mit.edu/sage/export/iml-1.0.2/config/atlas-check.m4 certainly seems to indicate so.  Not sure why it would work on newer Macs; in general 

Even though in general we will have to drop easy support for that old of a machine because gcc 4.0.1 won't compile gcc 4.9.x (you'd think it would have made sense for gcc to number it 5.0 when they changed the language they wrote it in!), I do want to make one final binary for Sage 6.4.1 at least, so I would appreciate any assistance.  We don't need a new ticket, I don't think, though I don't know if this would break other people's builds who want to use their own ATLAS to avoid compiling Sage's.

- kcrisman

[Francois Bissey]

It should compile against the vectorize library from apple. Don’t you have
/usr/lib/libclas.dylib on that machine?

Francois

[kcrisman]

It should compile against the vectorize library from apple. Don’t you have
/usr/lib/libclas.dylib on that machine?

I can check this in a little while.  Yes, I know it *should* use that, but for some reason maybe we still have to use the path explicitly - though one of the tickets I looked at implied --with-atlas-include was removed in 1.0.4.

Thanks! Stay tuned.

[Francois Bissey]

Can you send me the config.log that would help finding what went
wrong to some extent.

François

[kcrisman]

On Friday, December 12, 2014 1:38:18 PM UTC-5, François wrote:

Can you send me the config.log that would help finding what went
wrong to some extent.

http://boxen.math.washington.edu/home/kcrisman/config.log

 

François
> On 13/12/2014, at 07:01, kcrisman <kcri...@gmail.com> wrote:
>
>
> It should compile against the vectorize library from apple. Don’t you have
> /usr/lib/libclas.dylib on that machine?
>

No, I do not!  We used something else.

$ ls local/lib/libgslcblas.

libgslcblas.0.dylib  libgslcblas.dylib    

libgslcblas.a        libgslcblas.la    

See e.g. http://trac.sagemath.org/ticket/10509#comment:23 .  I tried a few things to reenable that based on http://git.sagemath.org/sage.git/diff/build/pkgs/iml/spkg-install?id=35ae4fd332022a697c73ce8bca6970fce1545591 but they didn't work.

[kcrisman]

> It should compile against the vectorize library from apple. Don’t you have
> /usr/lib/libclas.dylib on that machine?
>

No, I do not!  We used something else.

$ ls local/lib/libgslcblas.

libgslcblas.0.dylib  libgslcblas.dylib    

libgslcblas.a        libgslcblas.la    

See e.g. http://trac.sagemath.org/ticket/10509#comment:23 .  I tried a few things to reenable that based on http://git.sagemath.org/sage.git/diff/build/pkgs/iml/spkg-install?id=35ae4fd332022a697c73ce8bca6970fce1545591 but they didn't work.

I had to try changing to explicitly say which cblas - probably because this is what that version of Mac was looking for.  Presumably copying the file was not needed but whatever.

EXTRA_BLAS=""

if [ $UNAME = "Darwin" ]; then

    # copy cblas headers from gsl

    cp ../patches/gsl_cblas.h cblas.h

    EXTRA_BLAS="--with-cblas=-lgslcblas"

fi 

and that seemed to do it.  I'll report back if there is anything else needed.

++++++++++++++

By the way, if anyone reads this, on a totally unrelated note, it would be nice to have the git pkg installed as early as possible.  Maybe it has a lot of dependencies?

[Francois Bissey]

You could have created a link from libgslcblas to libcblas. That would have worked too.

François

[P Purkayastha]

I am restarting a sage installation from scratch and realized that the developer guide asks to clone from github, but the github develop is not updated to the latest rc0. Perhaps the dev guide should give examples using git.sagemath.org, instead of github?

On Thursday, October 30, 2014 10:12:20 PM UTC+8, Volker Braun wrote:

Notable changes are 

* OSX 10.10 support

* SageNB now can do 3d plots without Java, so it is usable again in chrome.

Please test, especially if you are a notebook user! 

As usual, pull the "develop" git branch or download the self-contained tarball http://sage.sagedev.org/home/release/sage-6.4.rc0.tar.gz

Mini-changelog:

d990119 Updated Sage version to 6.4.rc0

b2092bb Trac #17020: Update jmol to the latest version

2283698 Trac #16004: Update notebook to utilize pure javascript JSmol for default live 3-D

de7c38e Trac #17242: Uniform random generation  of Composition of a given size

9d8dc84 Trac #15914: Add the option to compute the fox derivative in a specific ring.

3f8b3d0 Trac #17238: Increase Precision in Failing Doctests

ba493df Trac #17169: Upgrade to GCC 4.9.1

94231d3 Trac #17199: doc cleanup in multi_polynomial_ideal

93d3dbf Trac #17244: Add a doctest for closed ticket #8005

522a6f8 Trac #17233: Uniform  random generation  of StandardTableau of a given size

05e978b Trac #17047: Isomorphism of incidence structures

535c980 Trac #16983: Fix finite field modulus handling

35ae4fd Trac #16706: Update IML to 1.0.4

e8696ab Trac #17241: Uniform random generation  of BinaryTree of a given size

cbb76f8 Trac #17216: Poset / LatticePoset: [meet|join]matrix algorithm

2524913 Trac #17179: TIDES interface should convert exact parameters to floating points.

cb14c36 Trac #17204: OSX Yosemite libtool version detection

fb25c13 Trac #10843: Faster listing of number field homsets

77cd34c Trac #16234: Assorted fixes and optimizations in sage-combinat (mostly partitions and tableaux)

5c934c4 Trac #17170: Sagenb graphics displayhook

a46bc25 Trac #16922: find_brouwer_van_rees_with_one_truncated_column

59e5eec Trac #17224: Fix pickling of NC rings with weighted term order

edbd263 Trac #17196: Relax assumptions on bitset operations

a554edb Trac #16719: replace gap.eval with libgap calls in combinat/combinat.py

d6feebb Trac #16313: easy-to-fix mistake in the stein-watkins optional database docs

91adf37 Trac #16493: Sage --dev tests broken for non-interactive shells

1e1cc3b Trac #16278: MPFI's spkg-install overwrites CFLAGS

7ae7117 Trac #17212: OSX zeromq testsuite

93741be Trac #17154: Comparison of WeylGroups

0718d27 Trac #17008: Give affine schemes unique representation (needed for elliptic curves and forking)

94164b6 Trac #17209: allow the use of distinct edgecolor and color for polygons in 2D

9ee40d7 Trac #16470: Add optional distance in BFS

8bdc755 Trac #17157: Improve formula for Bell numbers

4dc3c36 Trac #17203: Make sage -notebook=ipython land by default in pwd

7f934ea Trac #17195: Upgrade Cython to 0.21.1

c7053a5 Trac #15300: Clifford algebras and differential Weyl algebras

633b90e Trac #17202: IPython depends on pyzmq

419ad8e Trac #17186: LatticePoset: faster is_modular

311d9ef Trac #17189: Upon the first pass of the documentation compilation, undefined label warnings should not trigger an exception

ca7cc5e Trac #16396: upgrade Sphinx to 1.2

b5ed445 Trac #16919: mistake in sage/src/bin/sage-bdist, OSX app is always built 32-bit

56543ca Trac #16568: remove desolve_system_strings()

566d834 Trac #17112: Reorganize developer's manual table of contents

56eec8a Trac #9827: Intermittent doctest failure in sage/interfaces/psage.py

67ef668 Trac #17182: random spanning trees using the Aldous-Broder algorithm

f2ad04d Trac #17162: Error in semi-symmetric graph documentation

27a6d50 Trac #17078: Fix documentation in partition.py

810d34a Trac #16999: Fixing documentation typo.

2062d9d Trac #17193: Adding a hash function to weak and strong tableaux

2dbf16b Trac #16920: New V(m,t) vectors

be309e8 Trac #16911: Update sagenb

f68e873 Trac #16559: Brouwer-Van Rees version of Wilson's decomposition

c4e8674 Trac #17181: Poset.__repr__ should mention the linear extension

309f6cd Trac #17140: Remove usage of deprecated scipy.linalg.expm2 and expm3

050af2d Trac #16917: Deprecate cuspform_lseries() and modform_lseries()

a6e111e Trac #17103: Random failure in coercion/index.rst

de46432 Trac #17073: Documentation for Facade Sets

7ea8673 Trac #17168: Fix Cython "except" values in various places

fe042ce Trac #17167: Fix Cython "except" values in matroids

6b5ff95 Trac #17104: IncidenceStructure.relabel() (no arguments)

d9cd1a5 Trac #16233: Exceptions ignored by LeanMatrix operations

9b0995d Trac #17118: Added multiplier computation to affine morphism

22f3e28 Trac #17163: Speed improvement for DiGraph.in_degree

669107e Trac #14019: equality is broken for Posets

0270e9f Trac #17156: Creating a graph from a immutable digraph raises an error

402cfd8 Trac #11945: Throw exception instead of printing error in c_graph.pyx

6cb56e4 Trac #17152: Cython depends on setuptools

2490136 Trac #17126: Floating-point precision issues fail matrix2.py doctests

7c12f2c Trac #17148: Update ATLAS to latest stable 3.10.2

2407e08 Trac #17091: Update to git 2.1.2

4a2b592 Trac #16428: Cleanup/reorganization of FLINT imports

f9f642c Trac #15203: error in LLL method with delta=1

d0f2e7d Trac #10668: Refactor category support for morphisms (Hom is not a functorial construction!)

a4a6579 Trac #16340: Infrastructure for modelling full subcategories

dc64312 Trac #16998: Documentation conflict on is_graded()

bde9a75 Trac #16936: Hecke triangle groups (non-stub implementation)

bb85e22 Trac #17138: LatticePoset: complements() is broken

d82b80c Trac #17095: No documentation for random_element_plancherel()

794df00 Trac #17023: Adding width() function to poset

5e0c8d7 Trac #17119: Disallow pari(None)

599d03e Trac #16933: Remove deprecated code

[Volker Braun]

The develop banch on https://github.com/sagemath/sage is currently at 6.5.beta2 which is where it should be.

[P Purkayastha]

Ah.  Sorry for the noise. I was reading it as 6.5.rc0.