Sage 4.3.alpha0 released!

6 views
Skip to first unread message

Mike Hansen

unread,
Nov 22, 2009, 12:53:41 AM11/22/09
to sage-devel, sage-release
Hello all,

Sage 4.3.alpha0 is out! Sage 4.3 now contains much of the new
categories code from the sage-combinat team! It's been in development
for quite awhile, and it's great to finally get it in. There is one
known failure in sage/interfaces/maxima.py caused by #7401. This
issue will be fixed in alpha1 when it comes out.

Source and binary are available at

http://sage.math.washington.edu/home/mhansen/release/4.3/alpha0/sage-4.3.alpha0.tar
http://sage.math.washington.edu/home/mhansen/release/4.3/alpha0/sage-4.3.alpha0-sage.math.washington.edu-x86_64-Linux.tar.gz

The upgrade path is

http://sage.math.washington.edu/home/mhansen/release/4.3/alpha0/sage-4.3.alpha0

Tickets merged in 4.3.alpha0:

#7420: Mike Hansen: Fix uncaught infinite loop in coercion discovery
[Reviewed by Nicolas M. Thiéry, Robert Bradshaw]
#7421: Nicolas M. Thiéry: Weaker precondition for registering a new
coercion. [Reviewed by Robert Bradshaw]
#7460: William Stein: numerical noise on itanium (iras) [Reviewed by
Mike Hansen]
#1163: Karl-Dieter Crisman: make assume behave more consistently and
catch inconsistent assumptions [Reviewed by Jason Grout, Robert Marik]
#3663: Anne Schilling, Brant Jones: add support for affine crystals
[with patch, positive review] [Reviewed by Dan Bump]
#4326: Nicolas M. Thiéry, with help from Anne Schilling, Daniel Bump,
Nicolas Borie, Qiang Wang, Steve Pon: Root systems improvements
[Reviewed by Daniel Bump, Mike Hansen]
#5480: Alex Ghitza: R.quotient_by_principal_ideal() is
self-contradictory [Reviewed by Mike Hansen]
#5482: Alex Ghitza: Quotient ring can be created without generator
names [Reviewed by Mike Hansen]
#5794: Dan Bump: exceptional and reducible type branching rules
[Reviewed by Brant Jones]
#5891: Nicolas M. Thiéry: Categories for the working mathematics
programmer [Reviewed by Robert Bradshaw, Craig Citro, Florent Hivert,
David Kohel, David Roe, Anne Schilling, William Stein, Javier
Vengoroso]
#6136: Nicolas M. Thiéry: (Combinatorial) Free modules: cleanup,
abstraction into categories, and functorial constructions [Reviewed by
Florent Hivert]
#6137: Nicolas M. Thiéry: Symmetric functions: refactoring to use
coercions, categories, unique rep, and Hopf algebra framework
[Reviewed by Jason Bandlow]
#6138: Nicolas M. Thiéry: SymmetricGroupAlgebra: updates w.r.t.
categories and free modules [Reviewed by Florent Hivert]
#6318: Adam Webb: optional doctest failure -- axiom interface --
something doesn't work [Reviewed by Mike Hansen]
#6354: Nicolas M. Thiéry: Advertise and improve sage -fixdoctest
[Reviewed by Mike Hansen]
#6669: Martin Raum: Homomorphisms from matrix groups don't have to
have matrix groups as codomain [Reviewed by Robert Bradshaw]
#6760: Robert Bradshaw: error in quaternion algebra ideal basis
[Reviewed by Alex Ghitza]
#6803: Golam Mortuza Hossain: Implement symbolic Kronecker delta and
also make current signum (sgn) symbolic [Reviewed by Karl-Dieter
Crisman]
#7023: Robert Bradshaw: Upgrade to Cython 0.11.3 [Reviewed by Mike Hansen]
#7036: David Kirkby: rubiks ignores CXX and uses g++ even if CXX is
Sun compiler [Reviewed by Mike Hansen]
#7190: Nathann Cohen: French translation: A Tour of Sage [Reviewed by
Dan Drake, Mike Hansen]
#7208: Florent Hivert: Refactorisation of families [Reviewed by
Nicolas M. Thiéry]
#7352: David Kirkby: Update prereq to version 0.5 [Reviewed by Mike Hansen]
#7395: Florent Hivert: The enumerated set of non negative integers !
[Reviewed by Nicolas M. Thiéry]
#7396: Florent Hivert: Disjoint unions of enumerated sets. [Reviewed
by Nicolas M. Thiéry]
#7397: Florent Hivert: Updated Primes to the category system.
[Reviewed by Nicolas M. Thiéry]
#7401: Robert Marik: Derivative at a point is not translated into
Maxima [Reviewed by Karl-Dieter Crisman]
#7403: Florent Hivert: adds FiniteEnumeratedSet [Reviewed by Nicolas M. Thiéry]
#7443: Florent Hivert: List all categories in the reference manual
[Reviewed by Nicolas M. Thiéry]
#7449: William Stein: Some doc request hangs sage eating all memory.
[Reviewed by Florent Hivert]
#7450: Alex Ghitza: implement is_prime() for ideals [Reviewed by
Martin Albrecht]
#7462: Kwankyu Lee: magma interface -- huge number of doctest failures
[Reviewed by Georg S. Weber]
#7478: Florent Hivert, Nicolas M. Thiéry: TestSuite improvements
[Reviewed by Nicolas M. Thiéry, Florent Hivert]
#7479: Mike Hansen: sage fails to integrate identity [Reviewed by
Karl-Dieter Crisman]
#7371: Alex Ghitza: rename quotient_group() to quotient() in
groups/perm_gps/permgroup.py [Reviewed by Mike Hansen]
#7463: William Stein: document memory management for the magma
interface [Reviewed by Georg Weber]
#7474: Martin Raum: Expose some more functionality of fmz_poly
[Reviewed by Mike Hansen]
#7488: William Stein: plot3d? doesn't document plot_points option
[Reviewed by Mike Hansen]


Other tickets closed in the 4.3 release cycle:

#2783: notebook -- ocassional "crap" in output like this print "\x01r\x01e580"
#3464: notebook server error on sage.math (port detection problem)
#3802: notebook -- run server locally and logout then go to local
server again and get KeyError in server log and internal server error
#6517: FriCAS X.Y.Z
#7142: We must check if the version of 'tar' found is gnu tar
#7143: We must check if the version of 'make' found is gnu 'make'
#7181: We must ensure we have GNU make, not HP-UX or Solaris 'make'
#7182: HP-UX failure of gfan-0.3.p4 but easier to ensure we have GNU make.
#7203: prereq-0.4 does not exit if CC is not gcc, but CXX is g++
#7284: create an optional gmp spkg
#7384: SageNB -- Fix Sphinxify doctests
#3772: Gnuplot.py uses IPython/Python 2.6 keyword with
#7187: update optional package Gnuplot.py to 1.8
#7156: prereq-0.4 has a minor portability issue.
#6533: sage >= 4.1.rc1 doesn't build on cleo (ia64-Linux-rhel5)
#436: http to https redirect for secure notebook
#3463: notebook -- create a resource folder and move AnonymousToplevel to it
#3778: part 1 of new configuration system
#3535: notebook -- A "getting started" worksheet for new users
#3753: notebook -- change the default for nb.save('...')
#6765: Linear Programming in Tutorial's Tour !
#1916: notebook -- implement a way to turn off word wrap globally in
the notebook

--Mike

ma...@mendelu.cz

unread,
Nov 22, 2009, 3:16:28 AM11/22/09
to sage-devel
Thanks Mike
I wonder how tickets with positive review are merged into Sage. The
following two have positive review and were not included. Is something
wrong with the patches? Or should the tickets simply wait for
inclusion?

http://trac.sagemath.org/sage_trac/ticket/7325
http://trac.sagemath.org/sage_trac/ticket/6479

Many thanks
Robert

On 22 lis, 06:53, Mike Hansen <mhan...@gmail.com> wrote:
> Hello all,
>
> Sage 4.3.alpha0 is out!   Sage 4.3 now contains much of the new
> categories code from the sage-combinat team!  It's been in development
> for quite awhile, and it's great to finally get it in.  There is one
> known failure in sage/interfaces/maxima.py caused by #7401.  This
> issue will be fixed in alpha1 when it comes out.
>
> Source and binary are available at
>
> http://sage.math.washington.edu/home/mhansen/release/4.3/alpha0/sage-...http://sage.math.washington.edu/home/mhansen/release/4.3/alpha0/sage-...
>
> The upgrade path is
>
> http://sage.math.washington.edu/home/mhansen/release/4.3/alpha0/sage-...

Nathann Cohen

unread,
Nov 22, 2009, 4:13:41 AM11/22/09
to sage-devel
Hello !! :-)

The same happened to this one :
http://trac.sagemath.org/sage_trac/ticket/6813

I first thought because it was not just a patch, but added a new file
somewhere, though it now seems to be a wrong hypothesis :-)

Nathann

John H Palmieri

unread,
Nov 22, 2009, 11:41:46 AM11/22/09
to sage-devel
My guess is that the first priority was to merge all of the new
category stuff and get 4.3.alpha0 out the door. Maybe now the release
manager can deal with more patches?

John

John Cremona

unread,
Nov 22, 2009, 12:05:12 PM11/22/09
to sage-...@googlegroups.com
I built 4.3.alpha0 fine on two linux machines (32 and 64 bit) but on
both I get one failure:

The following tests failed:
sage -t "devel/sage/sage/interfaces/maxima.py"

Details below.

John

sage -t "devel/sage/sage/interfaces/maxima.py"
**********************************************************************
File "/home/john/sage-4.3.alpha0/devel/sage/sage/interfaces/maxima.py",
line 2172:
sage: latex(maxima(derivative(ceil(x*y*d), d,x,x,y)))
Exception raised:
Traceback (most recent call last):
File "/home/john/sage-4.3.alpha0/local/bin/ncadoctest.py", line
1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/home/john/sage-4.3.alpha0/local/bin/sagedoctest.py", line
38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example,
filename, compileflags)
File "/home/john/sage-4.3.alpha0/local/bin/ncadoctest.py", line
1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_68[4]>", line 1, in <module>
latex(maxima(derivative(ceil(x*y*d), d,x,x,y)))###line 2172:
sage: latex(maxima(derivative(ceil(x*y*d), d,x,x,y)))
File "/home/john/sage-4.3.alpha0/local/lib/python/site-packages/sage/interfaces/expect.py",
line 1033, in __call__
return self._coerce_from_special_method(x)
File "/home/john/sage-4.3.alpha0/local/lib/python/site-packages/sage/interfaces/expect.py",
line 1057, in _coerce_from_special_method
return (x.__getattribute__(s))(self)
File "expression.pyx", line 429, in
sage.symbolic.expression.Expression._maxima_
(sage/symbolic/expression.cpp:3324)
File "sage_object.pyx", line 364, in
sage.structure.sage_object.SageObject._interface_
(sage/structure/sage_object.c:3327)
File "sage_object.pyx", line 453, in
sage.structure.sage_object.SageObject._maxima_init_
(sage/structure/sage_object.c:5036)
File "expression.pyx", line 452, in
sage.symbolic.expression.Expression._interface_init_
(sage/symbolic/expression.cpp:3414)
File "/home/john/sage-4.3.alpha0/local/lib/python/site-packages/sage/symbolic/expression_conversions.py",
line 214, in __call__
return self.arithmetic(ex, operator)
File "/home/john/sage-4.3.alpha0/local/lib/python/site-packages/sage/symbolic/expression_conversions.py",
line 553, in arithmetic
args = ["(%s)"%self(op) for op in ex.operands()]
File "/home/john/sage-4.3.alpha0/local/lib/python/site-packages/sage/symbolic/expression_conversions.py",
line 214, in __call__
return self.arithmetic(ex, operator)
File "/home/john/sage-4.3.alpha0/local/lib/python/site-packages/sage/symbolic/expression_conversions.py",
line 553, in arithmetic
args = ["(%s)"%self(op) for op in ex.operands()]
File "/home/john/sage-4.3.alpha0/local/lib/python/site-packages/sage/symbolic/expression_conversions.py",
line 218, in __call__
return self.derivative(ex, operator)
File "/home/john/sage-4.3.alpha0/local/lib/python/site-packages/sage/symbolic/expression_conversions.py",
line 541, in derivative
raise NotImplementedError, "cannot convert expression to Maxima"
NotImplementedError: cannot convert expression to Maxima
**********************************************************************


2009/11/22 John H Palmieri <jhpalm...@gmail.com>:
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel-...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org

ma...@mendelu.cz

unread,
Nov 22, 2009, 12:52:56 PM11/22/09
to sage-devel


On 22 lis, 18:05, John Cremona <john.crem...@gmail.com> wrote:
> I built 4.3.alpha0 fine on two linux machines (32 and 64 bit) but on
> both I get one failure:
>
> The following tests failed:
>         sage -t  "devel/sage/sage/interfaces/maxima.py"
>
> Details below.
>

This has been explained in the first message which started this
thread.

Robert

John Cremona

unread,
Nov 22, 2009, 1:05:43 PM11/22/09
to sage-...@googlegroups.com
2009/11/22 ma...@mendelu.cz <ma...@mendelu.cz>:
Sorry -- I had missed that.

John

> Robert

Jaap Spies

unread,
Nov 22, 2009, 4:38:52 PM11/22/09
to sage-...@googlegroups.com
Mike Hansen wrote:
> Hello all,
>
> Sage 4.3.alpha0 is out! Sage 4.3 now contains much of the new
> categories code from the sage-combinat team! It's been in development
> for quite awhile, and it's great to finally get it in. There is one
> known failure in sage/interfaces/maxima.py caused by #7401. This
> issue will be fixed in alpha1 when it comes out.
>
> Source and binary are available at
>
> http://sage.math.washington.edu/home/mhansen/release/4.3/alpha0/sage-4.3.alpha0.tar
> http://sage.math.washington.edu/home/mhansen/release/4.3/alpha0/sage-4.3.alpha0-sage.math.washington.edu-x86_64-Linux.tar.gz
>
> The upgrade path is
>
> http://sage.math.washington.edu/home/mhansen/release/4.3/alpha0/sage-4.3.alpha0
>

Upgrading from 4.2.1 on Fedora 11, 32 bit I had the known issue with interfaces/maxima.py


Jaap

ma...@mendelu.cz

unread,
Nov 22, 2009, 4:52:28 PM11/22/09
to sage-devel
On 22 lis, 22:38, Jaap Spies <j.sp...@hccnet.nl> wrote:
> Upgrading from 4.2.1 on Fedora 11, 32 bit I had the known issue with interfaces/maxima.py

This was my patch. I am very sorry for this and do not understand, why
all tests passed on my computer when I tested this patch. Now I have
the same issue.

Robert

Dan Drake

unread,
Nov 22, 2009, 8:38:10 PM11/22/09
to sage-...@googlegroups.com
On Ubuntu 9.04 amd64, all tests for 4.3.alpha0 pass except the maxima test. On
Ubuntu 9.10 amd64, all tests pass except the maxima test and cell.py:

$ ./sage -t devel/sage/sage/server/notebook/cell.py
sage -t "devel/sage/sage/server/notebook/cell.py"
**********************************************************************
File "/var/tmp/sage-4.3.alpha0/devel/sage/sage/server/notebook/cell.py", line 1601:
sage: C.introspect_html()
Expected:
'<div class="docstring">...<span class="math">foobar</span>...</div>'
Got:
'.84495 -1.39908 0.170874\nv -1.84495 -1.79882 -0.226049\nv -1.84495 -2.19855 -0.5'
**********************************************************************
1 items had failures:
1 of 13 in __main__.example_71
***Test Failed*** 1 failures.
For whitespace errors, see the file /home/drake/.sage//tmp/.doctest_cell.py
[11.7 s]
exit code: 1024

----------------------------------------------------------------------
The following tests failed:


sage -t "devel/sage/sage/server/notebook/cell.py"
Total time for all tests: 11.7 seconds


Dan

--
--- Dan Drake
----- http://mathsci.kaist.ac.kr/~drake
-------

signature.asc

David M. Monarres

unread,
Nov 24, 2009, 2:46:52 AM11/24/09
to sage-...@googlegroups.com
OSX 10.6.2 on Intel with Xcode 3.21:

----------------------------------------------------------------------
The following tests failed:


sage -t "devel/sage/doc/en/a_tour_of_sage/index.rst"
sage -t "devel/sage/doc/en/bordeaux_2008/introduction.rst"
sage -t "devel/sage/doc/en/constructions/interface_issues.rst"
sage -t "devel/sage/doc/en/constructions/plotting.rst"
sage -t "devel/sage/doc/en/numerical_sage/scipy.rst"
sage -t "devel/sage/doc/en/tutorial/tour_algebra.rst"
sage -t "devel/sage/doc/en/tutorial/tour_functions.rst"
sage -t "devel/sage/doc/en/tutorial/tour_plotting.rst"
sage -t "devel/sage/doc/fr/a_tour_of_sage/index.rst"
sage -t "devel/sage/doc/fr/tutorial/tour_algebra.rst"
sage -t "devel/sage/doc/fr/tutorial/tour_plotting.rst"
sage -t "devel/sage/sage/calculus/calculus.py"
sage -t "devel/sage/sage/calculus/desolvers.py"
sage -t "devel/sage/sage/calculus/functional.py"
sage -t "devel/sage/sage/calculus/tests.py"
sage -t "devel/sage/sage/calculus/wester.py"
sage -t "devel/sage/sage/categories/category.py"
sage -t "devel/sage/sage/categories/examples/finite_semigroups.py"
sage -t "devel/sage/sage/categories/examples/finite_weyl_groups.py"
sage -t "devel/sage/sage/categories/finite_coxeter_groups.py"
sage -t "devel/sage/sage/categories/primer.py"
sage -t "devel/sage/sage/coding/code_bounds.py"
sage -t "devel/sage/sage/combinat/crystals/crystals.py"
sage -t "devel/sage/sage/combinat/crystals/letters.py"
sage -t "devel/sage/sage/combinat/posets/hasse_diagram.py"
sage -t "devel/sage/sage/combinat/posets/posets.py"
sage -t "devel/sage/sage/combinat/words/paths.py"
sage -t "devel/sage/sage/combinat/words/suffix_trees.py"
sage -t "devel/sage/sage/combinat/words/word.py"
sage -t "devel/sage/sage/combinat/yang_baxter_graph.py"
sage -t "devel/sage/sage/finance/time_series.pyx"
sage -t "devel/sage/sage/functions/hyperbolic.py"
sage -t "devel/sage/sage/functions/other.py"
sage -t "devel/sage/sage/functions/piecewise.py"
sage -t "devel/sage/sage/functions/prime_pi.pyx"
sage -t "devel/sage/sage/functions/special.py"
sage -t "devel/sage/sage/functions/transcendental.py"
sage -t "devel/sage/sage/functions/trig.py"
sage -t "devel/sage/sage/geometry/lattice_polytope.py"
sage -t "devel/sage/sage/graphs/bipartite_graph.py"
sage -t "devel/sage/sage/graphs/cliquer.pyx"
sage -t "devel/sage/sage/graphs/graph.py"
sage -t "devel/sage/sage/graphs/graph_bundle.py"
sage -t "devel/sage/sage/graphs/graph_plot.py"
sage -t "devel/sage/sage/groups/group.pyx"
sage -t "devel/sage/sage/groups/perm_gps/cubegroup.py"
sage -t "devel/sage/sage/gsl/dwt.pyx"
sage -t "devel/sage/sage/gsl/fft.pyx"
sage -t "devel/sage/sage/gsl/interpolation.pyx"
sage -t "devel/sage/sage/gsl/ode.pyx"
sage -t "devel/sage/sage/gsl/probability_distribution.pyx"
sage -t "devel/sage/sage/interfaces/maxima.py"
sage -t "devel/sage/sage/matrix/matrix2.pyx"
sage -t "devel/sage/sage/matrix/matrix_symbolic_dense.pyx"
sage -t "devel/sage/sage/modular/overconvergent/genus0.py"
sage -t "devel/sage/sage/modules/free_module_element.pyx"
sage -t "devel/sage/sage/numerical/optimize.py"
sage -t "devel/sage/sage/plot/animate.py"
sage -t "devel/sage/sage/plot/arrow.py"
sage -t "devel/sage/sage/plot/bar_chart.py"
sage -t "devel/sage/sage/plot/bezier_path.py"
sage -t "devel/sage/sage/plot/circle.py"
sage -t "devel/sage/sage/plot/colors.py"
sage -t "devel/sage/sage/plot/complex_plot.pyx"
sage -t "devel/sage/sage/plot/contour_plot.py"
sage -t "devel/sage/sage/plot/density_plot.py"
sage -t "devel/sage/sage/plot/disk.py"
sage -t "devel/sage/sage/plot/line.py"
sage -t "devel/sage/sage/plot/matrix_plot.py"
sage -t "devel/sage/sage/plot/plot.py"
sage -t "devel/sage/sage/plot/plot_field.py"
sage -t "devel/sage/sage/plot/point.py"
sage -t "devel/sage/sage/plot/polygon.py"
sage -t "devel/sage/sage/plot/primitive.py"
sage -t "devel/sage/sage/plot/scatter_plot.py"
sage -t "devel/sage/sage/plot/step.py"
sage -t "devel/sage/sage/plot/text.py"
sage -t "devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py"
sage -t "devel/sage/sage/rings/polynomial/pbori.pyx"
sage -t "devel/sage/sage/rings/polynomial/polynomial_element.pyx"
sage -t "devel/sage/sage/schemes/elliptic_curves/ell_generic.py"
sage -t "devel/sage/sage/schemes/elliptic_curves/ell_point.py"
sage -t "devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py"
sage -t "devel/sage/sage/schemes/plane_curves/affine_curve.py"
sage -t "devel/sage/sage/schemes/plane_curves/projective_curve.py"
sage -t "devel/sage/sage/server/notebook/cell.py"
sage -t "devel/sage/sage/structure/sage_object.pyx"
sage -t "devel/sage/sage/symbolic/constants.py"
sage -t "devel/sage/sage/symbolic/expression.pyx"
sage -t "devel/sage/sage/symbolic/function.pyx"
sage -t "devel/sage/sage/tests/book_stein_ent.py"


This was a fresh source build with SAGE64=yes.

Full log

http://dl.dropbox.com/u/1768136/test.log




--
David Monarres
dmmon...@gmail.com

"Which is worse: ignorance or apathy? Who knows? Who cares?"

Pablo De Napoli

unread,
Nov 25, 2009, 10:28:15 AM11/25/09
to sage-...@googlegroups.com
It would be really nice if we can include the new weapper for the lcalc
library.

http://trac.sagemath.org/sage_trac/ticket/5396

[marked ad "with patch, neeeds review"]

Pablo

Dr. David Kirkby

unread,
Nov 25, 2009, 11:24:41 AM11/25/09
to sage-...@googlegroups.com
Pablo De Napoli wrote:
> It would be really nice if we can include the new weapper for the lcalc
> library.
>
> http://trac.sagemath.org/sage_trac/ticket/5396
>
> [marked ad "with patch, neeeds review"]
>
> Pablo

I have been less than impressed with lcalc itself. Of all the packages I have
met in Sage, it seems to have presented with more than its fair share of problems.

* At one point there was a non-portable option to suppress warnings from the
assembler. I fixed that, so it would actually build on Solaris with gcc, with
either the Sun or GNU assembler.

http://trac.sagemath.org/sage_trac/ticket/6609

* I note it used the -no-deprecated (or similar option) to hide the fact the
code is deprecated.

* It will not build on Solaris with the Sun compiler
http://trac.sagemath.org/sage_trac/ticket/7065

* It will not build on HP-UX with gcc
http://trac.sagemath.org/sage_trac/ticket/7178

* If you run 'lint' on the sources, one find numerous variables that are
declared but never used.

IMHO, lcalc needs a major overhall.

I always find it worrying when the source is deprecated, efforts are made to
suppress warnings, it is not portable, variables are unused ...It always makes
me wonder what other issues might exist, which I do not know about.


Dave


William Stein

unread,
Nov 25, 2009, 11:33:43 AM11/25/09
to sage-devel, Michael Rubinstein
On Wed, Nov 25, 2009 at 8:24 AM, Dr. David Kirkby
<david....@onetel.net> wrote:
> Pablo De Napoli wrote:
>> It would be really nice if we can include the new weapper for the lcalc
>> library.
>>
>> http://trac.sagemath.org/sage_trac/ticket/5396
>>
>> [marked ad "with patch, neeeds review"]
>>
>> Pablo
>
> I have been less than impressed with lcalc itself. Of all the packages I have

For balance, I have to comment that I'm more than impressed by what
lcalc itself actually *does*. It's by far the world's best program at
computing zeros of L-functions (such as the Riemann Zeta function),
far surpassing anything available in any other general purpose (or
otherwise) math software, as far as I know.

It would indeed be very nice to have much more functionality from
Lcalc exposed in Sage, so I'm glad for 5396 getting finished, finally!
Of course, I'm also glad David pointed out the various quality
issues, and hope they can get addressed too. Mike -- maybe you can
hire an undergrad CS major using our grant to knock them out? They
don't require any real knowledge of math.

-- William

> met in Sage, it seems to have presented with more than its fair share of problems.
>
> * At one point there was a non-portable option to suppress warnings from the
> assembler. I fixed that, so it would actually build on Solaris with gcc, with
> either the Sun or GNU assembler.
>
> http://trac.sagemath.org/sage_trac/ticket/6609
>
> * I note it used the -no-deprecated (or similar option) to hide the fact the
> code is deprecated.
>
> * It will not build on Solaris with the Sun compiler
> http://trac.sagemath.org/sage_trac/ticket/7065
>
> * It will not build on HP-UX with gcc
> http://trac.sagemath.org/sage_trac/ticket/7178
>
> * If you run 'lint' on the sources, one find numerous variables that are
> declared but never used.
>
> IMHO, lcalc needs a major overhall.
>
> I always find it worrying when the source is deprecated, efforts are made to
> suppress warnings, it is not portable, variables are unused ...It always makes
> me wonder what other issues might exist, which I do not know about.
>
>
> Dave
>
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel-...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org



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

Michael Rubinstein

unread,
Nov 25, 2009, 1:07:15 PM11/25/09
to William Stein, sage-devel

Thanks for the update.

I've spent the past few weeks making major improvements to lcalc.
I plan to release this updated version in a few weeks.

1) I got rid of the deprecated header files and the unused variables
so it compiles much cleaner.

2) I got lcalc to compile and run with Bailey's double double and quad double,
and also with mpfr (using a newer c++ wrapper for that),
so it now works in arbitrary precision. This took some effort to make sure
all the routines work in higher precision and to deal with some quirks
of each package.

3) I wrote my own cos and sin which is 4 times faster than my machine's (at least
on my core2 laptop) and more than twice as fast Bailey's. It uses table a
lookup table of Taylor series. I spent two days hacking it as much as I could.
This makes some key routines 2-3 times faster.

4) I now handle values of s anywhere in the complex plane (rather than a half
plane). I had previously avoided slight complications due to trivial zeros cancelling
out poles of the gamma factors in Lambda(s) (completed L-function).

5) I improved the derivatives option substantially using formulas for central
differences that give much better precision and allow for higher derivatives
numerically.

6) I am in the process of finishing to wire in Hiary's band limited interpolation
routine for the Riemann zeta function when many values are needed.
At height 10^12 it runs 15 times faster than the straight forward summation of the
Riemann Siegel formula, and at height 10^16 it runs a few hundred times faster.

7) I cleaned up and reorganized the makefile and am adding a 'make test'
option that will check whether routines are running to the expected precision.

8) I fixed a couple of bugs that were affecting precision slightly.

9) There is a subtle bug that appears when looking for zeros of L-functions-
sometimes (very rarely) a zero is duplicated and another zero is skipped.
I'll be fixing that up in a little while.

10) Now that openmp is available on gcc with most machines I am going
to make use of that (as a compile option) in some of the key routines.

11) Many other small improvements are planned for later this year:
application of the fft and band limited interpolation to make
zero finding much faster (by a few orders of magnitude- more
improvement the further one goes).

About the guy who asked about number fields- I might try to get this
to work in my code using pari's routines (not immediately), but having him
try it in sage with Rishi's wrapper would also be a good idea.

Best,
Mike

Craig Citro

unread,
Nov 25, 2009, 1:12:20 PM11/25/09
to sage-...@googlegroups.com
Hi David,

First, I want to thank you for all the work you've been doing to get
Sage to play nicely on Sun and HP-UX recently. I think that's really
helpful, and in particular, I think some of the comments you make
below are definitely things that will help Mike (or anyone else) make
lcalc better.

That said, I think you're often extremely rude in the way you phrase
things, either on purpose or by accident. For instance:

> I have been less than impressed with lcalc itself.
>

Really? Have you used it to compute any zeros of L-functions? Have you
found that it's slow at computing values of L(s,f) for certain modular
forms? Are you unhappy with Mike's code involving the approximate
functional equation? Or are you just unhappy that it's failing to
build on your particular OS/hardware configuration? Mike doesn't seem
to keep a list of "supported platforms" on the lcalc webpage anywhere;
maybe he's part of the vast majority of people who don't use a Solaris
machine as one of his development platforms.

In short, I think "builds on a variety of hard-to-find Unix systems"
is a metric that's much less important than "performs some interesting
mathematical computation correctly."

I'd say that maybe this was a one-off thing, but you've had strong
negative comments for most of the packages you've looked at -- I
remember PolyBoRi in specific, but I know there were others. I'm *not*
saying you shouldn't report these bugs -- I think it's extremely
helpful that you're taking the time to test all the components of Sage
on other Unixes. I'm just asking that you be a little more polite when
you report them. For instance, you could have started this email by
saying "I've run into a few problems trying to build lcalc on this
hardware configuration." Remember, the people writing these pieces of
software aren't hardened software developers or system administrators
-- they're mathematicians who happen to enjoy writing software. Seeing
their name show up in an angry sage-devel or sage-support email isn't
going to bring us into their good graces.

-cc

Dr. David Kirkby

unread,
Nov 25, 2009, 3:24:23 PM11/25/09
to sage-...@googlegroups.com
Craig Citro wrote:
> Hi David,
>
> First, I want to thank you for all the work you've been doing to get
> Sage to play nicely on Sun and HP-UX recently. I think that's really
> helpful, and in particular, I think some of the comments you make
> below are definitely things that will help Mike (or anyone else) make
> lcalc better.

Thank you.


> That said, I think you're often extremely rude in the way you phrase
> things, either on purpose or by accident. For instance:
>
>> I have been less than impressed with lcalc itself.
>>
>
> Really? Have you used it to compute any zeros of L-functions? Have you
> found that it's slow at computing values of L(s,f) for certain modular
> forms? Are you unhappy with Mike's code involving the approximate
> functional equation? Or are you just unhappy that it's failing to
> build on your particular OS/hardware configuration? Mike doesn't seem
> to keep a list of "supported platforms" on the lcalc webpage anywhere;
> maybe he's part of the vast majority of people who don't use a Solaris
> machine as one of his development platforms.

I apologise if it came across that way. It was not my intension. I guess I
sometimes let my frustration get the better of me.

> In short, I think "builds on a variety of hard-to-find Unix systems"
> is a metric that's much less important than "performs some interesting
> mathematical computation correctly."

There is evidence to show a positive correlation between bugs and compiler
warnings. I can not say this

http://www.springerlink.com/content/317x276846767585/

is the best scientific paper I have ever read, but it shows a statistically
significant positive correlation between compiler warnings and the number of
changes to a file. Papers it reference show a correlation between bugs and
changes to a file.

(One of the main weaknesses of the paper is that the reasons for the changes are
not known. A file could be changed a lot, simply as new functionality is added.)
However, often files get changed a lot, when they have problems, which keep
needing to be addressed.

Some real bugs I have found in Sage are the result of testing on multiple
platforms. I know a bug which only showed up on AIX in

http://atlc.sourceforge.net/

was in fact a real bug that could have appeared on any platform. A colleague of
mine found out a bug which could have given incorrect results on his linux box,
but just never showed up until he tested on Solaris.

I personally feel it is inappropriate to cover up warning messages from a
compiler or assembler by using options to do this, or by redirecting the outputs
of the compilation process to /dev/null.

Perhaps my judgment is wrong, but I personally have greater than average
confidence in a program like mpfr, where

* It is clear the developers take time to test it on multiple platforms
* It does not generate many compiler warnings
* It has an extensive test suite.

But once again, I appologise for any unintended rudeness.

dave


Alex Ghitza

unread,
Nov 25, 2009, 3:29:16 PM11/25/09
to sage-...@googlegroups.com, William Stein

All of this sounds AWESOME! Looking forward to the new version.


Best,
Alex
Alex Ghitza -- Lecturer in Mathematics -- The University of Melbourne
-- Australia -- http://www.ms.unimelb.edu.au/~aghitza/

Dr. David Kirkby

unread,
Nov 25, 2009, 3:48:10 PM11/25/09
to sage-...@googlegroups.com
Michael Rubinstein wrote:
> Thanks for the update.
>
> I've spent the past few weeks making major improvements to lcalc.
> I plan to release this updated version in a few weeks.
>
> 1) I got rid of the deprecated header files and the unused variables
> so it compiles much cleaner.

Excellent

> 3) I wrote my own cos and sin which is 4 times faster than my machine's (at least
> on my core2 laptop) and more than twice as fast Bailey's. It uses table a
> lookup table of Taylor series. I spent two days hacking it as much as I could.
> This makes some key routines 2-3 times faster.

I would suggest this is something that can be a configurable parameter, or
perhaps tested at compile time. These sorts of things are often dramatically
better on one machine than another.

I remember many years ago, needing lots of sines and cosines, but I did not need
huge accuracy - every 0.1 degrees or so was good enough. It was much faster to
generate a look up table, store that in RAM, rather than use the floating point
processor to compute them each time.

On other systems, it was faster to compute them using sin() and cos() rather
than look them up in a table.

I've never used any sophisticated techniques like you are using, but I would not
be surprised if a simple library call was not faster on one platform or processor.

Dave
Reply all
Reply to author
Forward
0 new messages