[sage-devel] Re: Clarification of Sage and GPL

[root]

> Gee... is "Sage" a trademark?
> 
> Besides, I don't think a trademark is that strong... E.g. "firefox" is
> a trademark of mozilla. Debian doesn't want to be bound by the terms
> of use of said trademark, so the rename the program to "iceweasel".
> All visible occurrences of the name "firefox" are replaced by
> "iceweasel".  However, I can still launch iceweasel by running
> "firefox" from the command line. Is this a trademark violation?
> 
> Now, if "Sage" where a trademark, then "sage-ultralight" would clearly
> be a trademark violation. But say the program is called "fuchsia"
> instead. Fuchsia is a clone of Sage, and it is meant to execute the
> same scripts as Sage itself. Then it's not clear that it would be a
> trademark violation for fuchsia to provide a "sage.py" file for
> compatibility purposes, i.e. just so that "import foo from sage.bar"
> works the same.
> 
> IOW, you cannot create a GUI toolkit named "Qt", but you may be able
> create a GUI toolkit with a different name and provide header files
> using the same filenames as qt (at least wrt trademark... then there
> is arguing about whether interfaces are copyrightable or not...)

Trademark violations occur if the use of the mark causes confusion.
If someone copied Sage (e.g. a fork) and called it fushsia it would
not cause confusion. If starting fushsia was done by typing "sage"
or, when fushsia starts it "announces" itself as "sage" then there
is clearly a claim of "confusion". Thus, to avoid confusion the
fushsia project should change all references to "sage" to read
"fushsia", including the launching script.

The GPL says nothing about trademarks, as far as I'm aware.
It is based on copyright, a whole different area of law.

Tim Daly
 

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] NSF conference

[root]

I've just returned from the NSF conference.

There was a big push for teaching, especially related to CAS. I suggested
a joint effort with the game industry. The idea would be to use a game
like the bridge building game (www.bridgebuilder-game.com) and a CAS.

The idea of the bridge game is to construct a bridge and then apply a
load until it fails.  Students could start building a simple model of
the bridge by attaching matrices to the ends of the beam elements. 
Then they would predict the force to destroy the bridge and
be measured on how close their model is to the actual result. The next
class could add stress or strain or young's modulus or gravity load,
etc.  At the end of 13 weeks, the grades are given by the final
ranking kept by the game program.

The point of the exercise is to develop the skills to construct models
using a CAS.

This seems like a "python-can-do-it" kind of project.
The NSF person at the conference liked the idea a lot.

Tim Daly




--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage and symbolic software design

[root]

This is such an amusing thread. Try re-reading the thread as if everyone
were arguing that "we should improve Maxima because it is open source
and many people can improve upon it". Sure, you'd have to learn lisp
but Guido argues that python is lisp, so is the learning curve so steep?

On average over the lifetime of a project, code costs about $43 per line.
That means that Maxima is worth about $10,750,000 million dollars.
At a really productive rate of 100 lines of debugged code per day
that's 2500 days, or 10 years of work (5days x 50weeks)

If you had 250k lines of python and someone said "lets rewrite it in Java
because " then you would assume the person is misguided. But you
have 250k lines of lisp and now you argue "lets rewrite it in Python
because".

Maxima is old, reliable, solid code that can and does run in Sage.
There are porting issues but the total work required to debug a port
is completely dwarfed by the total work to write and debug a python verion.

If you believe that porting issues are lisp-specific, the transition to
python 3.0, 4.0, 5.0,  might convince you otherwise (eventually).

I don't have a dog in this fight so I don't care either way.
I'm just entertained by all of the "open source is great" arguments that
gets applied to everything but Maxima and lisp.

Tim Daly

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Is Maxima incompatible with Sage licensing

[root]

> But there is certainly still the issue with distribution, i.e. the
> trade press covered the [planned?] deployment of Debian by the
> government of Cuba a couple weeks ago. I wonder who gets into trouble
> for "exporting" Debian in that context - even though there is only a
> minuscule chance that anyone will bring legal actions. Judging the
> past actions of the US government in the context of PGP and Philip R.
> Zimmermann one ought to be a little paranoid about that.

It might be noted that, since Sage is "headquartered" in Washington
(that is, the Lead and the servers are within the U.S. borders) and
may be supported in small parts by NSF grants, Sage is also likely
subject to the same U.S.  Export Law restrictions. Things like elliptic
curves are widely used in crypto work and that is where the "munitions"
act probably gets involved.

I worked on software many years ago that was restricted by the
"munitions list".  It was much easier to enforce since I had to mail a
physical reel of magnetic tape. Regardless of my personal opinion that
such a restriction was very odd, it was still the law. I got signed
letters for each tape distributed since I was the software lead, I was
inside the U.S., and I would be liable.

Tim Daly


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: programming: define a new function

[root]

> > It's on our list too, so it will happen eventually. We definitely
> > still need to improve our algorithms a lot, see e.g.:
> >
> > http://groups.google.com/group/sympy/browse_thread/thread/58916fb31e1ff1ea
> >
> > but a nice thing is that it's in Python, so it's easy to work with.
> >
> > Ondrej
> 
> At some point I probably should get around to joining that group.
> 
> If you have any suggestions for the testing architecture, I'd be happy to hear
> them.
> 
> I've now started using GitHub's issues to do bug/issue tracking for the code.

What's the github name?

Tim Daly

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: programming: define a new function

[root]

> >>> Kudos to SymPy!
> >>>
> >>> I'm wondering why the python integration algorithms implemented there
> >>> aren't in the short term adopted by SAGE.
> >>
> >> They are --- you can use them from sympy inside Sage. It's my goal
> >> that all sympy features are nicely integrated in Sage. I work on this
> >> as time permits.
> >
> > Also, in the pynac-based symbolics that Mike Hansen has been polishing
> > up for full inclusion in Sage (to replace the maxima based symbolics),
> > one can just do
> >
> >   f.integrate(algorithm="sympy")
> >
> > and sage will compute the integral using sympy.   He's already
> > implemented this and I've seen it work well when I tried it out.
> 
> Yes, that way Sage allows to call any of those libraries very easily
> in Sage and at the same time uses just one library by default, that
> currently is the best at integrating, I guess still Maxima.

There is an integration test suite at:
http://axiom-developer.org/axiom-website/CATS
which has the Schaums integral series along with examples.
Each integral result is subtracted from the Schaums answer
and then simplified, hopefully to a constant.

How does Sympy compare?

Tim Daly

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: programming: define a new function

[root]

> > A much shorter example is:
> >
> > integrate(sqrt(x+log(x)),x)
> >
> > to which Axiom replies:
> >
> > integrate: implementation incomplete (constant residues)
> >
> 
> What is f(x) = sqrt(x+log(x)) supposed to be an example of?  Does f
> has an antiderivative that can be expressed in terms of elementary
> functions?  If so, what is it?

Axiom has one of the most complete Risch implementations. Many of
the original authors of the theory worked on the implementation.

Axiom can almost do the Risch integral of the formula you posted. 
It fails with: 
  integrate: implementation incomplete (constant residues)

The failing subexpression sqrt(x+log(x)) falls into the unimplemented
case. Replacing this subexpression by 'a' succeeds.

Most systems do pattern matching and heuristics. Fateman had a server
available that would "integrate" using these techniques.

Tim





--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: programming: define a new function

[root]

> So we have a good start to implement the Risch algorithm in sympy already.

Ondrej, what result do you get for:

 integrate(sqrt(x+log(x)),x)

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: programming: define a new function

[root]

> > Wikipedia also has a few interesting remarks, e.g., that the Risch
> > algorithm isn't an algorithm, because it depends on being able to
> > check equality of general elementary functions, which is evidently an
> > open problem in general (so in practice you just fake it by evaluating
> > numerically at lots of points to decide if something is probably equal
> > to something else).   It's also evidently not implemented anywhere,
> > e.g., a nice example on the Wikipedia page, is that if you let
> >
> > f = (x^2 + 2*x + 1 +
> > (3*x+1)*sqrt(x+log(x)))/(x*sqrt(x+log(x))*(x+sqrt(x+log(x
> >
> > then it has the antiderivative
> >
> > g = 2*(sqrt(x+log(x)) + log(x+sqrt(x+log(x
> >
> > since
> >
> > sage: h = g.derivative() - f
> > sage: h.full_simplify()
> > 0
> >
> > However, Sage, Maple, and Mathematica, all simply give "integral(f)"
> > back when asked to integrate f.  (I just checked this with the latest
> > versions.)
> 
> Curiously though, SymPy knows this particular integral.
> 
> >>> from sympy import *
> >>> x=Symbol('x')
> >>> f=(x**2+2*x+1+(3*x+1)*sqrt(x+log(x)))/(x*sqrt(x+log(x))*(x+sqrt(x+log(x
> >>> integrate(f,x)
> 2*log(x + (x + log(x))**(1/2)) + 2*(x + log(x))**(1/2)
> 
> Fredrik

A much shorter example is:

integrate(sqrt(x+log(x)),x)

to which Axiom replies:

integrate: implementation incomplete (constant residues)

For further information, Bronstein deals with constant residues
(written after his Axiom work) in his book [1] after page 147.

Tim Daly

[1] Bronstein, Manuel "Symbolic Integration I", Second Edition
Springer ISBN 3-540-21493-3

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: programming: define a new function

[root]

> > Wikipedia also has a few interesting remarks, e.g., that the Risch
> > algorithm isn't an algorithm, because it depends on being able to
> > check equality of general elementary functions, which is evidently an
> > open problem in general (so in practice you just fake it by evaluating
> > numerically at lots of points to decide if something is probably equal
> > to something else).   It's also evidently not implemented anywhere,
> > e.g., a nice example on the Wikipedia page, is that if you let
> >
> > f = (x^2 + 2*x + 1 +
> > (3*x+1)*sqrt(x+log(x)))/(x*sqrt(x+log(x))*(x+sqrt(x+log(x
> >
> > then it has the antiderivative
> >
> > g = 2*(sqrt(x+log(x)) + log(x+sqrt(x+log(x
> >
> > since
> >
> > sage: h = g.derivative() - f
> > sage: h.full_simplify()
> > 0
> >
> > However, Sage, Maple, and Mathematica, all simply give "integral(f)"
> > back when asked to integrate f.  (I just checked this with the latest
> > versions.)
> 
> Curiously though, SymPy knows this particular integral.
> 
> >>> from sympy import *
> >>> x=Symbol('x')
> >>> f=(x**2+2*x+1+(3*x+1)*sqrt(x+log(x)))/(x*sqrt(x+log(x))*(x+sqrt(x+log(x
> >>> integrate(f,x)
> 2*log(x + (x + log(x))**(1/2)) + 2*(x + log(x))**(1/2)
> 
> Fredrik

A much shorter example is:

integrate(sqrt(x+log(x)),x)

to which Axiom replies:

integrate: implementation incomplete (constant residues)

Tim Daly

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Dr. Kovacic died April 1

[root]

A loss for the CAS community, from William Sit:

Dear Friends of Jerry Kovacic:

It is with great sadness that I am passing on the news that
Jerry Kovacic died of brain cancer at around 2:30 pm on
April 1, 2009. He was 67.

Jerry is well known for his eponymous algorithm for solving
linear second order differential equations, which was
implemented in Scratchpad (Axiom). His early work in the
late 1960's on the inverse problem for differential Galois
theory paved the way for a complete solution of this
difficult problem. He has been a visiting scholar at the
Department of Mathematics at The City College of The City
University New York since his retirement from a software
company, and he has made significant contributions to a
modernized treatment of differential algebraic geometry. For
the last few years, Jerry was an organizer for the Kolchin
Seminar in Differential Algebra, and until a month ago,
despite his fight with brain cancer, he continued to attend
the Kolchin
Seminar at the Graduate Center, CUNY, and participated in
discussions. 

We will miss him dearly.

Sadly,


William 
- -- 
William Sit, Professor Emeritus
Department of Mathematics..Email: wy...@sci.ccny.cuny.edu
City College of New YorkTel: 212-650-5179
New York, NY 10031, USA.Fax: 212-862-0004
Home page: ...http://scisun.sci.ccny.cuny.edu/~wyscc/


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Python and Lisp

[root]

> About two years ago we made the painful transition from using Darcs to
> Mercurial for our revision control system. This was difficult, but had
> to be done because it was hard to get Darcs to run everywhere, and
> there were weird corner cases where Darcs would hang.  Mercurial isn't
> optimal but it gets the job done.
> 
> Frankly, I think we have similar problems using Python at the core of
> Sage.   I've been thinking very hard about how to deal with this for
> nearly a year now, and have come to the conclusion that we should make
> a switch from using Python at the core of Sage to Lisp.  The
> transition won't be easy, but it will be well worth the effort, since
> in the time frame I have in mind (30 years, say) I see Lisp really
> taking off, and despite its faults, anyone who has used Lisp a lot
> knows that Lisp is clearly a far better language than Python in
> several critical ways.The strategy for switching will go something
> like this:
> 
>   1. Forking:  We fork clisp.   We have been using clisp for several
> years now in Sage, so we're very familiar with their build system.
> However, they don't make regular releases, and their foreign function
> interface is severely lacking, as is their Solaris support.  So we're
> forking, and will call the fork LispX.  I've talked with Robert
> Bradshaw about creating a new language called CylispX, which will be
> similar to Cython but for LispX, and I'm confident we can pull this
> off.
> 
>   2. Porting:  We have an intense sequence if "Lisp days", both
> workshops and 1-day long IRC events, where we go line-by-line through
> the Sage library and rewrite everything in Lisp.   As we go, we'll
> make sure that the rewritten code is always at least as fast as the
> original code (this shouldn't be a problem, because of LispX's
> extremely good profiling and dynamic optimization features).   I hope
> everyone here is willing to pitch in significant time to this effort.
> If you're not, I would really like to know what your concerns are.
> 
>   3. Polish: I estimate step 2 will take about 3 years, given the
> amount of time it took to write the original Sage library, and also
> the level of familiarity of most Sage developers with Lisp.  Also, we
> will likely run into subtle snags with SageLisp's interface for
> calling C functions.   But with everybody's hard work, we'll get
> through this.
> 
>   4. Sage-4.0: On April 1, 2012, we'll release Sage-4.0, which will be
> the complete Lisp-rewritten version of Sage.  We will then get to work
> on porting all of the nasty C/C++/Fortran dependencies in Sage to
> Lisp.  We'll likely start with GMP/MPIR (we may have to fork, though I
> *hope* Bill Hart will be on board), then moving onto mpfr, mpfi,
> FLINT, PARI, etc.  I estimate that with lots of hard work by everybody
> reading this email, we can accomplish this in at most 4 years.  This
> will be a great contribution to mankind.
> 
>   5. Finally, on April 1, 2016, we'll release Sage-5.0, the fully
> Lisp-ified Sage.  We will then get back to porting Sage to Windows,
> Solaris, and implementing new functionality for combinatorics, linear
> algebra, number theory, algebraic geometry, optimization, etc.
> 
> If anybody isn't 100% convinced that this change isn't -- in the long
> run (30 years) -- well worth our effort, please respond.
> 
>   -- Best Regards,
>   William Stein
> 

On the whole, and after great consideration, I feel that you must be
suffering from delusions caused by Mercur(ial) poisoning. 

While I admire your vision of the long term I think that you underestimate
the "snobol" lesson, which is that accretion and agglomeration are the
proper way to create a design that encompasses all minds, rather than
the stilted, uniform design that represents a straight-jacket for the
imagination. As evidenced by Sage's rapid growth, similar to the rapid
acceleration of a snowball, Sage is clearly on the right path.

Far be it from me to challenge your attraction to the curvaceous
(some say "rubinesque", (although "bloated" has been applied by those
who awake (buried as they are) within the inner depths of parentheses))
but I caution you about following your eye rather than your intellect.
  Besides, a space is clearly a lighter weight character, despite the
minor inconvenience of distinguishing a left-space " " from a 
 right-space " ". No doubt the notebook colors them properly.
  Equally balanced as a favoring syntactic argument, in which I
   nest the pile of my missive and plea for right thinking,
python is shown to be a language capable of swallowing all, like
 its reptile cousin.

Surely mathematics requires interpretation, which is respectable for
its deliberate air, rather than crass compilation. If everything were
reduced to turing-computablity, who can say when it will end?

Mathematics is known to have inconsistent notations, which the current
Sage design admirably captures. Consistency is the hobgoblin of small
minds \ci

[sage-devel] Re: [sage-combinat-devel] Cardinality of a set...

[root]

>> I like s.cardinality() since that's what I've used often already all
>> over in Sage.
>> Do
>> 
>> sage: search_src('cardinality')
>> 
>
>Arglll !!! I had this idea and issued an
>
>tomahawk-*ge-combinat/sage $ grep def\ cardinality\( **/*.py* | wc
> 11  35 533
>
>which was a pretty low number. For the record:
>  tomahawk-*ge-combinat/sage $ grep def\ cardinality\( **/*.py*
>  rings/integer_mod_ring.py:def cardinality(self):
>  rings/ring.pyx:def cardinality(self):
>  schemes/elliptic_curves/ell_finite_field.py:def cardinality(self, 
> algorithm='heuristic', extension_degree=1):
>  sets/primes.py:def cardinality(self):
>  sets/set.py:def cardinality(self):
>  sets/set.py:def cardinality(self):
>  sets/set.py:def cardinality(self):
>  sets/set.py:def cardinality(self):
>  sets/set.py:def cardinality(self):
>  sets/set.py:def cardinality(self):
>  structure/parent.pyx:def cardinality(self):
>
>Is there a standard policy about aliases like card/cardinality ?
>
>I'm personally against them because they tends to make the code more
>confusing. But I'd like to know if there si a general answer.

Axiom provides a general answer. Axiom is structured into 3 different
things, Categories, Domains, and Packages.

By analogy to, say, dressmaking
  Categories are components, like patterns, colors, styles, buttons, etc
  Domains are concrete things like a particular dress
  Packages are tools that work on dresses, like sewing machines, irons, etc

Thus, to construct a particular domain (dress) you choose
   categories yellow, floweredPattern, 3Button, EmpireWaist, LauraAshleyStyle
 
When you define a domain you mention the categories it inherits.
The names of functions NOT locally defined in the new domain get
inherited from the categories.

Thus, the categories impose a naming convention that everybody uses.
Function names such as "cardinality" get inherited everywhere.

The suggestion is that Sage consider an Axiom Category-like organization
that normalizes the names through inheritance. Of course, this requires
a huge re-think of the organization of Sage. It would also require "cover"
functions for external packages to map the names to the category names.

Tim Daly

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: dump lisp and maxima from sage?

[root]

>>Could you please elaborate (in technical terms) what is wrong in
>>principle with our Risch algorithm implementation, apart that it needs
>>fixing for integrals that it cannot yet do? Or is the approach we took
>>with sympy not the right one to get the symbolic integration done.
>>
>>If Sage developers are willing to write calculus things in Python (or
>>Cython) I am definitely interested, if it'd be possible to use it as a
>>standalone package (e.g. without the rest of Sage, currently 1GB after
>>unpacking on my system).
>>
>>To put my question in other words, what exactly should be done to
>>implement the symbolic integration in Sage? I want to have symbolic
>>integration in Python and so far what I (and mainly Mateusz, Kirill
>>and other sympy developers) tried is in sympy. So if our approach is
>>wrong, I am interested in critical opinions.
>
>Ondrej,
>
>As an objective measure of sympy, what results do you get for the
>Schaums test suite:
>
>http://axiom-developer.org/axiom-website/CATS

Ondrej, Tim,

Beyond the integration routines, Maxima provides other facilities
that may not be available in the rest of Sage. I'm not sure about
the Ordinary Differential Equations abilities without Maxima. I've
uploaded the CATS test suite for ODEs to:

http://axiom-developer.org/axiom-website/CATS

so they can also be tested. It would be great to see the same
test suite in many different systems. Note that Maple is exceptionally
good at ODEs. If Sage has a goal of replacing Maple it might be good
to see how well it does on these suites.



It would be useful to collect other sets of test suites which exercise
functions that are only available from Maxima. As I develop them I will
make them available for your amusement.

Tim Daly


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: dump lisp and maxima from sage?

[root]

>Could you please elaborate (in technical terms) what is wrong in
>principle with our Risch algorithm implementation, apart that it needs
>fixing for integrals that it cannot yet do? Or is the approach we took
>with sympy not the right one to get the symbolic integration done.
>
>If Sage developers are willing to write calculus things in Python (or
>Cython) I am definitely interested, if it'd be possible to use it as a
>standalone package (e.g. without the rest of Sage, currently 1GB after
>unpacking on my system).
>
>To put my question in other words, what exactly should be done to
>implement the symbolic integration in Sage? I want to have symbolic
>integration in Python and so far what I (and mainly Mateusz, Kirill
>and other sympy developers) tried is in sympy. So if our approach is
>wrong, I am interested in critical opinions.

Ondrej,

As an objective measure of sympy, what results do you get for the
Schaums test suite:

http://axiom-developer.org/axiom-website/CATS

Tim Daly


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: dump lisp and maxima from sage?

[root]

>> I think there might be a bit of overconfidence in assuming that any
>> one of the "top 10 Sage developers" is going to reproduce even a
>> fraction of that complexity in the near term.
>
>That's not what is being discussed.  The question is about the
>technical feasibility of removing lisp/maxima from the core of Sage.

...[snip]...

>The rest of your email is interesting but off topic, where I hope the
>topic of this thread will stay: "technical feasibility of removing
>lisp/maxima from the core of sage (they will instead be optional)".

A strawman argument? Surely you can simply remove Maxima by  simply
removing it. If you don't wish to discuss the complexity of replacing
the removed functionality then I don't see that this thread has any
content at all. Simply remove Maxima and be done with it.

I'd have thought that implicit in removing Maxima would be an effort
to replace the lost functionality. That implies an evaluation of the
complexity of the problem, which I was trying to give based on facts. 

I've clearly misunderstood. Sorry for the off topic post.

Tim Daly

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: dump lisp and maxima from sage?

[root]

>I don't mean to suggest this could be trivially done by anybody right
>now.  I'm talking about feasibility in the sense of several very hard
>weeks work by one of the top 10 Sage developers.
>
>...
>
>1. Consider "lines of code". How many correct LOC/day does a top 10
>Sage developer write? On average. A guess.
>2. How many LOC are there in Maxima's code for integration? (easy to
>count)
>3. How many LOC are there in the code that Maxima's integration code
>USES? (not so easy to count -- includes
>pieces of many of the source files like simplification, solve,
>rational manipulation...  there is a chart about this, and
>you can also get dependency information from tools that are available
>in some lisp compilers. )
>4. How many LOC in LISP per LOC in whatever language you choose? 1,
>10, 1/10?
>
>Of course you might actually have to learn how to do this task by
>reading some pretty dense material; PhD dissertations by Bronstein,
>Trager, Davenport, Rothstein, Rioboo, Cherry, ... so that might take,
>oh, a few hours by one of the top 10 Sage developers ?

Integration in Axiom (and Fricas, which Sage now includes) uses a fair
amount of the algebra.  To get an idea of the complexity of the
problem take a look at the algebra graph for Axiom at:

http://axiom-developer.org/axiom-website/documentation.html#buildorder

under the Axiom build order link. Each node in the graph is a file of
algebra code (e.g. a python class kind of object) written in a very
high level algebra language (Spad). Edges represent only immediate
dependence from the prior level but each node actually has an
average of about 20 dependencies links so the graph should more likely
have 22000 edges. Maxima has a similar complexity.

I think there might be a bit of overconfidence in assuming that any 
one of the "top 10 Sage developers" is going to reproduce even a
fraction of that complexity in the near term. Axiom represents
approximately 300 man-years of research and development. Maxima
has a similar history.

My experience in both Lisp and Python indicates that the code size in
Python is likely to be a factor of 10 larger than the lisp/spad
implementation.  And my experience with Lisp compiled vs Lisp
bytecoded (as Python is) indicates that a Python implementation will
likely be a factor of 10 slower. Moving to Cython will likely regain
the speed at the cost of explicit knowledge of the internal
representation, making the system more fragile and less agile. Note
that we're ignoring the fact that the Maxima code has so many more
years of testing and field use than new python code would see.




What puzzles me is the cognitive dissonance between the Sage goals
of "not re-inventing the wheel" and "working to connect existing
systems" and the apparent rejection of the largest bodies of CAS
work in systems like lisp/Maxima. The code needed to cleverly 
connect Maxima to Sage is SO many orders-of-magnitude easier than
the code needed to reproduce Maxima functionality that I'm at a
complete loss to explain the rejection.

So the question I have is: Why not devote some of the top 10 Sage
developers to figure out a clever, more generic, more well-designed
API between Sage and Maxima? Even better would be a way to inline
Lisp code in Python and then you can execute Maxima code directly.

Since Sage doesn't use Axiom I really don't care what the outcome is.

Tim Daly




--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: dump lisp and maxima from sage?

[root]

>The possibility to dump lisp and maxima entirely from Sage keeps
>popping into my head.

If you only wish to eliminate Maxima then Fricas would suffice.
If you wish to dump lisp then this implies dumping the Fricas 
package also since it is lisp based. 

Tim Daly


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.2.2.alpha0 released!

[root]

>What about an option to the upgrade script, e.g.
>
>sage -upgrade [-b branch]
>
>which would upgrade specified branch inplace if specified?

I don't want to start a religious war but this is trivial in 
a git repository. There was some talk a while back about changing
to git.

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Cosine Integral and Sine Integral?

[root]

Tim,

Actually what I'm hoping for is a merged document that can be used by
anyone to see the results from various systems compared. This is similar
in spirit to the rosetta document I helped author:

except that I would like to see such information for standard math
test suites. I'm not sufficiently clueful about Sage to generate
the information first-hand.

So this is independent of how you release your results.  I'm willing
to do all the work. I'm basically asking for permission to reformat
your results into the CATS documents.

Tim Daly

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Cosine Integral and Sine Integral?

[root]

Tim,

When you publish your test suite I'd like to be able to merge
the Sage version of the integrations back into the CATS version
of the schaums tests. Do you think this will be possible?

Tim Daly

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Computer Algebra Test Suite (CATS)

[root]

Tim,

Were you just interested in integration or do you intend to work on a
full test suite? If you're interested in building a larger test suite
I'd be happy to work with you (or others) on areas that interest both
Axiom and Sage. Indeed, this might be a good way for students and
mathematicians who don't program to contribute to Sage.

As you know, the CATS idea is that we establish a common test suite
among the various systems so that we can leverage the test effort
from any one system for the benefit of all. Testing is important and
in very short supply.

Ideally we would have independently created and verified mathematics
(like the standard integration tables, ODEs, polynomial factorization)
organized in some rational way.  Then we show that every system using
the suite gets equivalent answers. For areas where Axiom implements
the mathematics I'm willing to do the heavy lifting of getting the
original mathematics into an initial, machine readable form. And I'm
willing to run the test suite through Axiom to create an initial set
of results.

When Sage decides to develop various facilities (like integration)
in native form these test suites would be very valuable. The test
suites would also be useful as user documentation for Sage.

Axiom already has over 600 input files used to test various parts
of the system. Comparing these results with other subsystems of
Sage would provide a valuable cross-check.

Tim Daly

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage patch licenses

[root]

>...[snip]...
>...   Van Lindberg points
>out implicit licenses are not legally binding and presents a legal
>horror story of one guy "contributing" code he do not own to an OS
>sourceforge project, only to be bankrupted by lawsuits and SF
>being required to remove his code.
>...[snip]...
>

I'm working my way through the same book. I'm afraid there is no
defense against any lawsuit brought against an open source project.
The cost to defend against a lawsuit implies that the any unfunded
open source project immediately loses. It is a classic case of 
justice being blind (to financial imbalance).

Of course, most lawyers will tell you that you only embark on a lawsuit
in order to gain money. "On principle" lawsuits, that is, not for
financial gain but to prove a point, assume that you're willing to 
risk a huge loss against a balance of "I was right". If you have that
much money to burn then the lawyer's fee will be quite a bit higher. :-)

The person bringing the lawsuit has to have "standing", or legal
interest. So that is either (A) the contributor of the patch or 
(B) the original owner of the code.

Somehow it seems unlikely that a person contributing a patch (case A)
would bring, or could win, a lawsuit if they posted the patch to the
open source project mailing list. (Never say never, however.)

If the original owner of the code complained (case B) then I would
think that an open source project would abide by the "notice and
takedown" provision of the DMCA. Given this provision, I'm certain
that any open source project would "do the right thing", back out the
patch, and rewrite it. Thus, I think the DMCA would cover this case.
The "notice and takedown" provision would seem to provide a safe harbor.

Standard industry practice on half a million open source projects
does not include an "I have signed over my copyright on this particular
patch" button. A general copyright judgement making the current practice
illegal would wipe out the free software movement overnight (except for
the FSF work, but they have paid lawyers).

Also note that Sage is not covered by the "safe harbor" provisions
of the copyright law. The safe harbor provisions allow the use of
copyrighted material for educational, research, and scientific use.
But the stated goal of the Sage project is to compete with the
commercial software and does not qualify.

Tim Daly (not a lawyer)


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Categories for the working programmer

[root]

>Don't worry: I am bound to be productive into translating code from
>MuPAD to Sage :-) And the MuPAD's category hierarchy is quite similar
>(since inspired from) Axiom's.

Do you have information about MuPad's categories?

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: [Axiom-developer] Re: [sage-devel] Categories for the working programmer

[root]

Mike,

>On Sun, Nov 9, 2008 at 1:21 PM, root <[EMAIL PROTECTED]> wrote:
>> There are at least two possible paths toward a category hierarchy in Sage,
>> adopting Axiom's version or designing a new one.
>>
>> The key advantage of adopting the Axiom category hierarchy is the Sage
>> system could reuse a lot of the algorithms in Axiom. The Spad language
>> used in Axiom is similar in style and spirit to the Sage python language.
>> If the same categories were available it should be possible to use the
>> algorithms in Axiom's domains as written.
>>
>> The temptation to re-design is very seductive but not very productive.
>
>What is the relationship between "categories" in Axiom and the
>mathematical notion of a category?

That's a pretty deep question that's been under debate for a while
on the Axiom mailing list. See:
<http://lists.gnu.org/archive/html/axiom-developer/>

My capsule response would be that it is a computational approximation
to the mathematical idea. Axiom's implementation was not trying to 
develop category theory in full generality. However, because many of
the ideas underlie the implementation, Axiom has a very strong 
"scaffold" that arranges and supports its category hierarchy.

I've found that there is a gap between traditional mathematics and
computational mathematics. Implementing the exact mathematics makes
a system extremely difficult to use. Implementing the computational
approximation makes mathematical reasoning awkward and approximate.
(Trivially, consider "Real Numbers")

I do not believe that the proper theory exists to bridge the gap.
I feel that such a theory will be the fundamental theory of
computational mathematics. And, no, I have no idea what that might be.



The point I was making is related to Nicolas's suggestion of redesigning
the category hierarchy to handle additive vs multiplicative forms in a
different way. While that may be a good idea it would have the side-effect
of changing the implementation of the algorithms. I make no claim that
Axiom's choices are better than any other possible choices, merely that
the pragmatics of the choice make life easier.

If Sage had an Axiom-style category hierarchy then the Axiom (Spad language)
algorithms for things like integration could be rewritten into python
with a local-minimum of effort. Spad uses indentation in the same way
that python does. However, this would not be "trivial" since python
does not support lisp-like macros, Sage does not seem to have a compiler,
python does not support the data==program abstraction, etc.


Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Categories for the working programmer

[root]

There are at least two possible paths toward a category hierarchy in Sage,
adopting Axiom's version or designing a new one.

The key advantage of adopting the Axiom category hierarchy is the Sage
system could reuse a lot of the algorithms in Axiom. The Spad language
used in Axiom is similar in style and spirit to the Sage python language.
If the same categories were available it should be possible to use the
algorithms in Axiom's domains as written.

The temptation to re-design is very seductive but not very productive.


For those who don't understand Axiom's category/domain/package structure
I'll give the following very weak analogy:

You might find it useful to understand that Axiom has the algebra
divided into 3 kinds of things, Categories, Domains, and Packages.

By analogy to clothing,
   Categories would be the patterns, fabrics, buttons, styles and
   other things that are not specific. Mathematically these are things
   like OrderedSet which specify functions like >, <=, etc.

   Domains are instances of choices, like a particular dress, which
   is chosen from a selection of categories by inheritance, so that
   a particular domain (dress) has a certain fabric, pattern, style, etc.
   Mathematically these are domains like Integer which model the 
   integer number system.

   Packages are tools for dressmaking, such as sewing machines,
   button-hole makers, ironing boards, etc.

In general, you work in domains which are particular instances of
mathematics with certain functions and properties inherited from
the categories. Every object created lives in some domain.


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Categories for the working programmer

[root]

Nicolas,

The category hierarchy in Axiom is being documented in more detail.

The latest, nearly complete, version is at:

Note that the PDF is hyperlinked.

A (currently partial) diagram of the hierarchy can be found at:


Further documentation is at: 


Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: documentation licenses [was: yet another talk on Sage]

[root]

To quote U.S. copyright law, section 107:

  Notwithstanding the provisions of sections 106 and 106A, the fair use
  of a copyrighted work, including such use by reproduction in copies or
  phonorecords, or by any other means specified by that section, for
  purposes such as criticism, comment, news reporting, teaching
  (including multiple copies for classroom use), scholarship, or
  research, is not an infringement of copyright. In determining whether
  the use made of a work in any particular case is a fair use the
  factors to be considered shall include:
  
1. the purpose and character of the use, including whether such use
   is of a commercial nature or is for nonprofit educational purposes;
2. the nature of the copyrighted work;
3. the amount and substantiality of the portion used in relation to
   the copyrighted work as a whole; and
4. the effect of the use upon the potential market for or value of
   the copyrighted work.
  
  The fact that a work is unpublished shall not itself bar a finding of
  fair use if such finding is made upon consideration of all of the
  above factors.
  
Tim Daly

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Fwd: New Journal

[root]

John,

>As the outgoing editor-in-chief of the LMS-JCM (London Mathematical
>Society Journal of Computation and Mathematics) (for the next 5 days,
>when Derek Holt takes over), and also an editor of the Journal of
>Algebra's Section on Computational Algebra, I feel obliged to ask
>exactly what the new journal(s) will provide which existing ones do
>not.  The JCM is all-electronic.  See here
>(http://www.lms.ac.uk/jcm/editorial.html) for its aims and scope,
>which explicitly include source code and tables and the like, which
>traditional journals do not have space for.
>
>I am definitely not saying that there's no room for anything new in
>this area, but I am interested to know what the LMS JCM is not doing
>which it could be.  Of course, it may just be that none of the j-sag
>board have heard of it, and if that is the case then I should
>certainly know that!

Dr. Traverso and I have been thinking along different lines in
terms of freely available electronic publications. Your site is
academically interesting but misses the point. Of course you might
not care about the goals we've been trying to achieve so the rest
of this note might not apply. 

Doyen was the initial idea. See 
(The Doyen CD for Sage by Alfredo Portes has this eventual goal.)

The basic idea is that I attend a conference where a paper is 
presented. During the lecture I can visit the URL, drag and drop
the paper being presented onto my system (Axiom, Sage, ...) and
immediately have a running version. Thus, if the author was
presenting efficiency claims, I could populate the tables for my
own machine during the lecture. Or I could execute the examples
and my own tests during the talk. In any case, I'd end up with
a useful tool which is immediately accessible rather than having
to re-understand (poorly), re-implement (badly), the years of
work that the author did.


The terms and conditions do not allow me to include the material
into Axiom or Sage. For Axiom's goals in particular this is not
useful.

Axiom is becoming a literate program (ref: Knuth, See:


As a literate program it is necessary to be able to rework the
source material into a form that can further the user's ability
to understand. So the terms and conditions have to allow us to,
at bare minimum, redistribute the material, which the LMS Term
and Conditions do not. (ref: )

Two key, long-term goals of Axiom are to make the whole system
available for research and available for teaching. In sum, these
require that the research be kept with the code and that the code
be intertwined with the associated research. As a matter of style
the eventual result will look quite different from your "publication"
style but the style is vitally important to the user's ability
to read the result in some literate fashion.

Furthermore, the distribution in PDF ("compiled form") without the
TeX ("source form") makes these papers only marginally useful for
further work (akin to "binary-only" algebra for Sage). The closed
source nature of the site reproduces the paper-based world. That 
misses the whole point of electronic copies.

If you read the terms and conditions for the LMS journal it is
clear that they keep the material from being useful in practice.

As intellectual "bricks" the license allows me to contemplate
the pretty shapes and random sizes of these bricks but I cannot
join and reshape them into a useful larger structure. LMS is
basically an "art gallery", not a supply house. That makes it
pretty, but not very useful as a source of further work.

Perhaps you might consider asking the authors for permission
to re-distribute in "attribution-only" form, the source form
of their documents. Think of it as a GPLv2 request that Sage
makes for their authors. Axiom is Modified BSD and we strongly
encourage people to re-use the material in any way they might
find useful.

It is the age of electronics. We want to use work in computational
mathematics NOW, not next year. We can't afford large amounts of
time to re-implement and re-debug every single new algorithm or
enhancement. Authors who make this easy will be "most quoted" in
running systems and those who don't will not. Sage gives the
possibility of thousands of users overnight. 

Besides, it is clearly a useful "citation" if your code is already
running on the tenure committee's laptops :-)

Tim Daly
Axiom








--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Fwd: New Journal

[root]

>> Hi.  Dan Grayson sent Greg and me a message letting us know about this
>> discussion and I thought it might be helpful for if I joined the
>> discussion as one of the managing editors.
>
>
>
>> I'm delighted that the journal has generated so much discussion.
>
>Yes, I think that forces between the different efforts in this area (I
>am aware of M2, Sage and also something in that direction by Daly and
>Traverso around Axiom)  should coordinate/merge since having three
>competing journals might not be best situation. This obviously depends
>on agreeing on a bunch of things like the license of the content and
>so on and since none of the journals has actually gone beyond the
>planning stage and put out an issue it remains to be seen what is
>happening.
>
>One thing that I see as a tiny problem is that right now it is the
>"Journal of Software for Algebra and Geometry" while at least of JSage
>(the Sage one to make it 100% clear) there was at least the
>possibility to go "beyond" algebra and geometry. Since we have not
>done anything in that direction the journal is vaporware for now, so
>the whole point might me moot.

Dr. Traverso (Univ. Pisa) and I have had many discussions about a
"live" or "literate" journal. The key concept is that the publication
should include the actual source code necessary to reproduce the
results in a particular version of a target system (e.g. Sage 3.1).

There are many fine points to discuss and debate but I think it is
vital to keep the research results with the actual implementation.
The current journal/conference/thesis mechanisms do not do that,
almost certainly because of their paper-based legacy.

If "reference" versions of the CAS programs were available then
these could be used to reproduce the results. Perhaps a CAS reference
site would be appropriate.

I'm not much concerned about the focus on Algebra and Geometry since
an idea has to start somewhere and an over-general attempt might fail.
I am hopeful that this journal can demonstrate the key concepts.
I'm willing to volunteer time and energy to make it happen.

Tim Daly
Axiom

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: reopening Sage - Blender discussion

[root]

>> >I've been playing around with learning blender, with the idea of
>> >animating some 4-D projection/rotations of polytopes into 3D.  But all
>> >I really want is a nice compressed animation/movie format, and it
>> >seems like there should be a lighter-weight way to do that.  If I come
>> >up with anything worth sharing I will submit it.
>>
>> There are 3 french professors who have done an amazing job at
>> 4D polytope projections. See:
>>
>> 
>
>That's a great movie - and since it was made in my lab I have some info
>relevant to the discussion. They use povray to generate all the images,
>and the animation is done within povray (you can set loops and such) ;
>povray as such doesn't have too many primitives, so most of the fancy
>knots and such are actually strings of spheres, and the path is
>precomputed. The main advantage of povray is that it looks gorgeous ... 
>The main disadvantage is that it takes ages to compute (well, in the 
>order of a few minutes per frame).
>
>So, to return to Sage : it should be quite doable to have one plot3d
>format be povray source-code, to be compiled separately (or which gets
>compiled in the background). That's not at all real-time, so I'm not
>sure it fits the original purpose, but it certainly can produce a movie 
>(in .avi or whatever format) in the end.

It would seem that ray tracing should be a fully parallel task.
I don't know if povray does this but given the upcoming multicore
machines this kind of technology might be closer to real time
than before. Do you know if povray can use multicore?

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: reopening Sage - Blender discussion

[root]

>I've been playing around with learning blender, with the idea of
>animating some 4-D projection/rotations of polytopes into 3D.  But all
>I really want is a nice compressed animation/movie format, and it
>seems like there should be a lighter-weight way to do that.  If I come
>up with anything worth sharing I will submit it.

There are 3 french professors who have done an amazing job at 
4D polytope projections. See:



Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Symbolic differential equation solving deserves better syntax

[root]

>FriCAS / Axiom is supposed to be very good at linear differential
>equations and differential equations of the form y'=f(x, y) - the code
>is by Manuel Bronstein.  It seems to be rather weak for others, it
>cannot solve the equation above for example.  I must admit, however,
>that I do not know much about it.  Furthermore, it does not attempt to
>solve for the function, as the first example shows (sorry about the
>ASCII-art, do you prefer LaTeX on the list?)

The Axiom project has created a test suite based on the Kamke
(E. Kamke "Differential Equations, Methods of Solutions and
Solutions" Leipzig (1956)) which, I believe, is the same test
suite used by Maple.

Portions of the test suite, including answers where Axiom can produce them,
is available at

(also kamke1, kamke2, kamke3, kamke4, kamke5, kamke6, and kamke7)

Maple clearly dominates this area and has, by far, the best
implementation of an ODE solver. Like all of the math projects,
they dominate because they have the best person for the job.

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Things I miss from Maple in Sage

[root]

>If someone proposes an implementation I can try and shoot it down or  
>improve it.  But I don't know sage well enough to know whether there  
>is an obvious way to do it all.  My guess is that this is a natural  
>task for Lisp and the wrong task for Python.

Having worked in both python and lisp I can say that this is
certainly a weak point in python (programs are not data) and
a strong point in lisp (programs are data). Thus, it is a
natural task for lisp and the wrong task for python.

More to the point when someone considers an implementation
I might mention that Richard Fateman, one of your favorite 
contributors to this project, created MockMMA. I don't know
the details but I believe Wolfram had an opinion about the
look-and-feel issue. You might consider asking someone who has
already been down this path before you get too far along.

Way back in history Apple sued Microsoft for copying the Apple
look-and-feel. Apple lost. Thus it is unlikely that Wolfram can
legally stop you from doing something like MockMMA. But it might
cost you several million dollars to be "right" about that.

There are clauses in the copyright law that allow copies to be
made for "research" and "education" but since Sage has clearly
stated that it intends to go after Wolfram's commercial market
I'm not sure these are a safe harbor.

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Things I miss from Maple in Sage

[root]

>MATHEMATICA:
>Timing[a = Expand[(x^Sin[x] +y^Cos[y] - z^(x+y))^100];]
> {0.180212, Null}
>
>SAGE:
>sage: time a = expand((x^sin(x) + y^cos(y) - z^(x+y))^100)
>CPU times: user 0.15 s, sys: 0.00 s, total: 0.15 s
>

Does this include the time to format and print the output?

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.1.final is out

[root]

>I tried the "sage -upgrade" way but I did not realise it would compile
>everything from scratch and how long it would take. Actually, I still
>don't know how long it will take, since it has been compiling for more
>than an hour now and is still going. I am upgrading from 3.0.5 on a
>MacBook Pro 2.4 GHz with Mac OSX 10.4.11.
>
>Can you give an estimate of how long it could take, so that I can
>decide whether to wait or just abort and reinstall from the binaries,
>so that I can keep working?

On my iBook G4 on OSX 10.4 it takes 417m real, 289 user, 76 sys
It is an old and slow machine but I do not know how to check the
processor speed on a Mac.

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: why sage is useful for me

[root]

> > Well, there is a vast people using Windows out there either by choice
> > or because they don't know about alternatives.
>
> True, but I suspect the first year students under discussion should be
> aware of other systems such as Linux. They would have the choice to
> use Linux if they wanted. I can't believe it would be hard to find a
> Linux box in a university now if you wanted to use one. Even easier to
> install it on their own PC.

Just as a data point: While I was at City College in New York I
started a project called Doyen to make a Live CD as a computer 
algebra platform. I advertised in the computer science department
for 2 students with a knowledge of Linux for a paid position.
Ten students showed up for interviews, all of them were computer
science majors and most of them were seniors. Eight of the ten
had not heard of Linux.

This was 4 years ago. Things might have changed. Your school may vary.

Tim



--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: [Axiom-developer] Re: [sage-devel] Re: Identification with ldap.

[root]

>> Do you want your code to live?
>
>That's a very interesting question. When I was much younger, I used to
>think I did. But when you realize that an awful lot of code isn't meant
>to "live" -- it's meant to solve an immediate problem, and then be
>discarded -- then you don't care whether it lives or not.
>
>Axiom was clearly designed to live, rather than solve an immediate
>problem. But how much code is out there that was designed with a 30-year
>horizon? 

More to the point, how much code is in Sage that is designed for the
30 year horizon? Will a matrix inversion still give the right answer
30 years from now? If so, how many dozens of times will it have to
be reimplemented because nobody can understand the current code?
Which of the 16 kinds of matrix inversions are used and how do they
differ in terms of input domains, performance, robustness, etc?
Should I use the Maxima inversion or the Sympy inversion or the
Lapack inversion or implement a new one? 

The front ends will likely change. Axiom's hyperdoc help system is
being reimplemented using a firefox front end. The build system is
about to be moved from using 'make' to using 'asdf'. The file system
layout is disappearing, replaced by latex literate books. 

Sage's notebook is certain to be replaced.

Even so, if we want the next generation of developers to contribute
effectively it seems important to write down what they need to know so
they don't give up in frustration. That's a serious loss. We need a
computational mathematician to be able to contribute effectively
without becoming frustrated. We also need to capture the special
knowledge that lies behind the contributed code since there will be
very few experts worldwide in a given research area. Would you 
recognize and be able to fix a bug in a feynman quantum computation?

William has stated that he doesn't care about this issue since he
wants a system NOW that he can use to do his number theory research.

But it is fundamentally about the quality of the system. The 4Ms
don't care because they pay people to learn the code.

Google and Microsoft, having invested real dollars into the
effort, ought to try for a higher standard and a longer horizon.
I really wish they would hire a team with a mandate to make this
code literate.

Tim



--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: units, was: Suggestion components to add onto SAGE

[root]

>I have looked around to see what Maple and Mathematica have in
>the way of units, but from what I have seen, there is nothing very
>exciting. Which is OK --- something boring which just works right
>would be very useful.

Frink is the standard for unit conversion.


I cannot find any mention of a license.
It seems to be implemented in Java.

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Identification with ldap.

[root]

> [EMAIL PROTECTED] writes:
>
> Yes, yes, it is easy to criticize and whats really needed is energy
> and effort... well I hope to try some more... but the structure of the
> files makes it very difficult to follow. When one only has a limited
> amount of time to contribute it is really depressing spending 9/10 ths
> of it just trying to figure out what calls what. Ideally it would be
> nice to make a small patch as you suggest but I don't see how. Every
> tweak I make breaks something else. Perhaps if I knew how it was all
> connected a small patch would be possible. I don't, and trial and
> error is very inefficient.

The Mythical Man-Month (Fred Brooks, a MUST read book) has an interesting
example of a dinosaur stuck in a tarpit. The dinosaur can lift any foot
but cannot escape the tarpit. Really large systems, like Axiom and Sage,
have massive, dinosaur-sized tarpits of code.

Developers of these systems have the belief that it is sufficient to write
code that the machine understands. After all, any part of the system can
be understood by anyone with sufficient effort (see... we can lift any
foot you point at...). And every piece of code is perfectly clear
despite having many levels of inherited behavior and unstated background
mathematical theory.

The problem is that tarpit gets larger and deeper with every passing
day and with every additional piece of code added. As the current
developers move on and new people join, they have no way to understand
the prior work except to try to read each file and "integrate".

The best solution I've found it Knuth's Literate Programming (Axiom
uses noweb). The fundamental idea is to write for people while
writing the code so the machine can follow along. This adds about
two to three times as much work for the original developer but
saves the time for everyone else in the future.

And, yes, I know that nobody has the time. But if you don't take
the time now, the next person can only guess, probaby incorrectly, 
or give up and rewrite it.

Do you want your code to live?

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: how to handle assumptions

[root]

Robert,

>> 
>> view the pdf file for "Schaums 14.120-14.124" (schaum5.input.pdf)
>> See the result on page 3 of the pdf.
>>
>> The first integral result returned by Axiom is a list of answers.
>
>Hmm. I don't see any indication of the domain in which each
>result is applicable. Did I miss something?
>
>It appears that the ascii art display shows something different
>from the TeX display. Maybe they're equivalent, I can't tell.

Axiom does not use an assume facility. It computes all the answers
and returns a list if there is more than one.

The format of the file is one section per integral.

Within the section you see the Schaums input and expected answer in latex.
e.g. 

 \[ \int{sin(x)}dx \]
 \[ -cos(x) \]

This is followed by an Axiom integrate command for the integral given.
(assigned to the aa variable)
e.g. 

 aa := integrate(sin(x),x)

The "ascii art" output (the things after the --R lines) are the Axiom output.
(Note: The -- is an Axiom comment. These are regression test files.) e.g. 

  -cos(x)

Following the integration call is an Axiom input of the answer given by
Schaums. (Assigned to the bb variable)
e.g 
  bb := -cos(x)

Next we difference the Axiom answer from the Schaums answer. 

 cc := aa - bb

They should only differ by a constant (hopefully zero). If they are
not immediately found to differ by a constant there are a series of
simplification steps applied to try to prove that the answers are
equivalent.


The final step in each section draws one of several possible
conclusions. See the comment on the last step in each section.

   Axiom and Schaums agree means that we got a zero difference.

   Axiom and Schaums differ by a constant of integration.

   Axiom cannot do the integration ... which implies that there is no
   closed form of the integral over the elementary functions. This
   is a consequence of the Risch algorithm. If Axiom returns the
   integral unevaluated then it is a proof that no closed form exists.

   Axiom cannot simplify the result which means that we do not know if
   Axiom and Schaums are equivalent. The most likely reason that the
   simplification fails is that Axiom and Schaums are using different
   branch cuts for trig functions. 


Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: how to handle assumptions

[root]

>>> Also part of the problem is that the assume system in Maxima
>>> is not very strong, and it has bugs. We could use some help on
>>> that too.
>>
>> What are your ideas to handle assumptions correctly?
>>
>> E.g. from your slides you prefer the formula and all the symbols to be
>> just symbols without any assumptions attached to them, plus there
>> should be some global (?) assumptions (those need to be made robust)
>> and the functions consult them? I like this approach.
>>
>> Maxima has years of experience in this, so I am interested in what you think.
>
>If you answer could you summarize what Maple/Mathematica do (if you care),
>and if so why you think whatever you propose is better than them.
>
>In fact, if any Maple or Mathematica users out there want to explain
>(probably for the nth time) how Maple or Mathematica deals with these
>assumption and multiple-possible-integral problems, and whether or not
>they like the choices made by those systems, please speak up!
>
>(Derive, Mupad, Axiom people too...)

Visit:

view the pdf file for "Schaums 14.120-14.124" (schaum5.input.pdf)
See the result on page 3 of the pdf.

The first integral result returned by Axiom is a list of answers.

Tim Daly


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: test suites, was: presentation about Maxima at Sage developer days

[root]

>> Are there any other major test suite collections available?
>
>At present Maxima includes a copy of Michael Wester's test suite
>which was the basis for his published review of computer algebra
>systems from about 10 years ago. We haven't done anything with it
>but I asked for and received permission from him to release it under
>terms of GPL and it is now in Maxima CVS.

Yes, I did a set of tests for Michael years ago for the review.
The Axiom version of those tests are in our test suite also.

I'm looking for test suites against "standard" sources (like Schaums,
Zwillinger, Kamke, etc) as well as other large collections of tests
(e.g. Bondarenko). Ideally ALL computer algebra systems should
test against the same published standard sets, a project I call "CATS"
(Computer Algebra Test Suite).

It only makes sense to have a fully vetted version of tests that
people can use against all the systems. These tests should have the
agreed-upon "correct" answers along with commentary about ranges,
branch cuts, etc. Ideally these CATS documents would also present the
algorithms in both mathematical terms and as software implementations.
(I would support Sage's calc rewrites IF they were doing it to present
the algorithms in some literate form for people to reference and
learn. Sadly competition, not science, seems to be the driving
motivation.)

If we can collect such test sets and show that each system generates
equivalent answers (a difficult problem given the zero equivalence
issue), then people can feel SOME confidence that 
  (a) they are getting reasonable answers
  (b) the systems are plug-equivalent

This IS supposed to be computational mathematics and the answers
are testable.

In fact, I believe that NIST should fund such an effort to support
both the quality of computational mathematics and the educational
aspects of showing the "best of breed" computational algorithms.

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] MAC OSX 10.4 port

[root]

I cleared up space on my server.
The binary MAC OSX 10.4 port is at:

http://daly.axiom-developer.org/sage-3.0.3-osx10.4-ppc-PowerMacintosh-Darwin.dmg

Please let me know when you have a copy so I can erase it 
and reclaim the space.

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: presentation about Maxima at Sage developer days

[root]

> Sage has a huge test suite that gets run with every release,

Is there an obvious way to collect all of these tests?
I'd like to run them in Axiom

Tim



--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: presentation about Maxima at Sage developer days

[root]

>> Since the stated goal of Sage is to be a viable alternative to
>> the 4Ms it makes sense to develop a "measure" of how close the
>> goal is approached.
>[specifc test suites]
>> This is where Sage gets to prove it really is a 4Ms alternative.
>
>The goal of Sage is to be an alternative to the 4M's in the sense that
>it is a viable alternative for *real people* to do what they need to do on
>a day to day basis for their research, teaching, and education.  This is
>best measured by *listening* to real people describe how they
>use math software, and specifically what they they really find
>lacking in Sage.Pursuing a grand program involving large test
>suites is of course very valuable, but it is a much different than
>the main goal of the Sage project, and it somewhat ignores the
>dynamic nature of real people and their needs.
>
>The mission of the Sage project -- to provide a viable free open
>source alternative for every real people to Magma, Maple,
>Mathematica, and Matlab -- is not going to change until it
>is accomplished.

I believe you sidestepped the question. My point is that Sage
makes the claim that it will be a viable alternative to the 4Ms.
In computational mathematics that is a testable claim. So test it.

Or is your claim that *real people* do not care that Sage provides
correct and tested answers to ODEs, integration, limits, etc? Clearly
the 4Ms have shown what they can do. Maple's Kamke test suite answers
give me great confidence that
  (a) Maple can handle my ODE needs, 
  (b) they give correct answers,
  (c) they have a much wider range than Axiom and
  (d) Axiom gets the right answers for the subset it accepts.
I now know that Axiom needs more extensive ODE algorithms.
If you do ODE work I'd highly recommend Maple over Axiom, at least
until Axiom can prove it is competitiive in ODEs.

It is not a lot of effort. The Kamke test suite took a couple weeks
to test. The Bonderenko suite took about 2 months. The Schaum test
suite took about 2 months (but I had to develop it from scratch).
These are summer tasks for students. They are all in Axiom syntax
but some bright spot could write an Axiom-to-Sage translator and
have the tests running quickly.

I would offer to do it for Sage but I'm busy building a new test
suite for graphics based on the CRC Standard for Curves and Surfaces.
You're welcome to use the test suite when it is complete.

The results would go far toward convincing *real people* who care
about the quality of their computational mathematics software (e.g. me)
that Sage "meets or exceeds" the 4Ms in fundamental areas.

Without some sort of objective measurement (which we ought to expect
from computational mathematicians) the "viable alternative" claim
is just marketing hype. Since I'm confident that Sage is capable of
"meets or exceeds" I think it would benefit the community to test it.

Tim
An occasional "real people", although I have my complex moments.

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: presentation about Maxima at Sage developer days

[root]

As to the point of "community goals" I have a proposal to make.

Since the stated goal of Sage is to be a viable alternative to
the 4Ms it makes sense to develop a "measure" of how close the
goal is approached.





Maple has a Kamke ordinary differential equation test set.
Maple can do almost all of the ODEs in that set.
How well does Sage do, where is Sage weak, and what needs to be 
developed in order to be a Maple alternative?

Bonderenko has a 4000 integral test suite used against Maple and MMA.
How well does Sage do, where is Sage weak, and what needs to be 
developed in order to be an MMA alternative?

Axiom has a 619 integral Schaums test suite.
How well does Sage do, where is Sage weak, and what needs to be 
developed in order to be a Axiom alternative?

Are there any other major test suite collections available?
Is there one for limits? For finite fields? For linear algebra?
If not, can people be sponsored to collect them?





Perhaps Sage could host a test suite site that shows the results
of running the test suite against the competition. Something like:

   Schaums' test suite (619 indefinite integrals)
   Axiom: 419 passed, 
  137 no closed form exists.
   60 cannot simplify
2 Schaums typos found
1 Axiom bug found
   MMA:
   Maple:
   Sage:

   Kamke test suite 
   Bonderenko test suite
etc.

Students could be hired to perform the test suite collection and
computation. There can be no question of python-vs-C, ad-hominem,
free-vs-paid, or any other argument.




This is where Sage gets to prove it really is a 4Ms alternative.

Tim




--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: presentation about Maxima at Sage developer days

[root]

>I think that's really the core issue in this whole thread -- some people
>are really disturbed by code get thrown away...  Well deal with it.

Lets try to avoid ad hominem.  Bernard's point is not one of ego. Nor
is mine.  Almost all the code I've written in the last 37 years is
gone and I'm thankful for that :-)

In fact, *I* didn't write any of the integration code.
I am not capable of writing Davenport-Trager-Bronstein (DTB) code.

The core issue is, very few people *are* DTB-capable worldwide.
And if you are anywhere near DTB-capable, it would make more sense
to build on top of existing robust, well tested, and high quality
code towers.







>It's much more important to make decisions that are best for the
>overall quality of a project and "the community goals" than to
>stroke your ego by keeping your own code alive forever.

Code *quality* is the key issue. When I see an expert like Paul
Zimmermann involved in the gmp-Sage work, I know from experience
that Paul writes quality code and gmp is well tested. It has been
around a long time and has been widely used. I can make the same
quality argument about Axiom's DTB integration code. Both are
"best of breed".

Bernard's point is that it is much less effort to interface
than it is to rewrite from scratch. "The community" benefits
more from an interface than a rewrite.

But your time is your own.

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: presentation about Maxima at Sage developer days

[root]

>Actually I would really like to know why Sage developers prefer to
>restart from scratch. I do really believe that they are
>underestimating the required work. I have read somewhere that Gary is
>an undergraduate. I have nothing against undergraduates, we were all
>undegraduates at one time, but assigning this kind of task to *one*
>undergraduate is in my opinion a clear sign of an underestimation of
>the work/knowledge required to build serious calculus capabilites.

I have to second Bernard's comment here. The integration code in Axiom
was written by Davenport, Trager, and Bronstein, all of whom invented
the code as their PhD thesis work. I worked with all three people on
the Axiom project. Axiom represents an estimated 300 man-years of work
over a 23 year period, with funding at an estimated total of $42 million
(back when the dollar was worth something). All three people spent years
working on the project.

The belief that it might be "better" to rewrite this code from scratch
seriously underestimates the time, knowledge, and effort required to
achieve high quality, well tested, trustworthy code.

The code size, time requirements, porting effort and complexity of
making a working interface to systems like Giac, Maxima, or Axiom
is MUCH less than rewriting algebra code from scratch.

I do admit that interfaces lacks the same "street cred" as new algebra
code but Sage would end up with a much higher quality final product.

Tim



--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage-3.0.3

[root]

>> I finished the MAC OSX 10.4 build of sage-3.0.3 and am ready to build
>> the binary but I cannot remember the command. I thought it was
>> make dist but the makefile doesn't contain such a stanza.
>>
>
>./sage -bdist 3.0.3-osx10.4-ppc
>
>and you find the result in dist/

I tried to upload the dmg but blew out the disk space on my server.
Is there an upload site on sagemath?

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Lisp code development

[root]

I know there are several people who feel that Lisp code is hard
to develop. I can highly recommend a series of short videos that
show the development of a reddit clone in common lisp.


He shows quite a few interesting features, including writing unit
tests that drive the browser and check web pages and the use of
macros to simplify lisp code.

It is a rather painless introduction to modern day lisp development.

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage-3.0.3

[root]

I finished the MAC OSX 10.4 build of sage-3.0.3 and am ready to build
the binary but I cannot remember the command. I thought it was 
make dist but the makefile doesn't contain such a stanza.

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: hg clone and symlinks...

[root]

>I don't exactly understand these distributed control systems very
>well, so hopefully this isn't an obvious question. Right now as I'm
>working on symbolics I commonly have files from multiple branches open
>(symbolics-stable/backup, symbolics-current, calculus-old).  I also
>have to frequently have to toggle between them (to test backwards
>compatibility).  

Doing a branch

 git-branch calculus-old

generates a 40 bit key which points to a history tree node. That is
all the disk space required.

 git-checkout calculus-old

"magically" transforms the files so they conform to the "calculus-old"
sources and you can work in that tree. 

 git-checkout master

will bring you back to the trunk, "magically" transforming the files again.

Note that since git uses hashcodes to track changes it will not duplicate
files. Two files with the same hash code occupy one file. One side effect
is that a distro might actually be smaller when moved into git if it
had copies of files in subdirectories.

Thus the branch only needs to keep the changes as it shares the
unchanged files by pointing at the same sources. So a branch only costs
you the disk space and time to maintain the changes.






>It seems like switching to branching would require
>having three full sage installs at the cost of a huge amount of space
>if I want to be able to switch between them quickly and edit multiple
>versions of the same file, which seems like a massive negative side
>effect.  Do I understand this right?

So, in answer to your question, no it does not require much disk space.
I have 20+ branches locally and there is almost no disk space overhead
and changing between the branches happens in about the time it takes
to type the command.

Tim


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] git advantage

[root]

One unmentioned feature of a git-based Sage archive is the ability
to pull a guaranteed-correct tree from history. This is not possible
using CVS or SVN. I am not sure about bzr or hg.

Suppose you work on Sage-3.0.2 and it has an spkg, say SymPy at 3.3.
Suppose both Sage-3.0.2 and SymPy are held in different git repos
somewhere on the net (e.g Sage in sagemath.org, sympy in sympy.org)

Now suppose the world moves on to Sage-3.1 and SymPy goes to 4.0

You can set up Sage so that if a user does a git-pull on Sage-3.0.2
the "make" procedure can git-pull the correct tree (3.3) from sympy.
Since the git repo tree nodes are all uniquely labelled by a 40 bit
hash code you can be certain you got exactly the right sympy build.

The advantage is that you would no longer have to have any spkg
code that contained sympy. And if I don't use sympy I don't need
to download it.

Note that, in general, I very much like the fact that I only do 
one tarball download, type "make" and it "just works". But the
latest DCVS tools support functionality that was not possible
using CVS/SVN.

Tim



--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: hg clone and symlinks...

[root]

>In terms of using patches as a transport, its just a transport. I think
>it would be cleaner to import the branch as a branch and have final
>merges into mainline branches controlled using current practice.
>Patches in trac are, IMHO, clumsy although in practice it probably
>doesn't matter much.
>
>I'd also say that the patch approach is more appropriate to SVN style
>controls than DCVS controls.

I'm not sure about bzr or hg but I suspect they support the same
mechanisms as git.

In a DCVS (I use git), the appropriate way to transport changes is
with pull/push. I use github as a host for Axiom.  After the first
clone all else is push/pull. If I like the change I commit, otherwise
I reset. Since git uses a crypto-style hashcode I'm guaranteed that I
have the correct source tree which matches the host.

A git-push or git-pull is blindingly fast even for large changes so
managing a large repository (Axiom is about 1/5 the size of Sage) is
much more efficient. Given the same changes applied to a git repo and
the sourceforge SVN repo I can do the whole git-commit/git-push in the
time it takes for the svn commit to print another progress period.

Branching in git requires 40 bytes whereas cloning can require
100meg. The disk saving and time saving is significant.

For journal purpose I publish the diff-Naur (git-diff) form to the
mailing lists but the rest of the work occurs "within the system".
I do use the diff-Naur patches against the SVN and CVS copies of
Axiom (sourceforge and savannah) despite the fact that git can update
those repo styles. Old habits die hard.

DCVS is a completely different way of looking at software development.
It took a while before I "got it" and started using the branch/push/pull
tools properly. Once you understand the ideas it really does change the
way you work. I have 20ish branches locally and they take up a minimal
amount of space, especially compared to 20 clones.

Again, I'm not sure about bzr and hg but I suspect they are equivalent
in design. It would be much more lightweight in bandwidth, space, and
time if Sage were hosted in a DCVS where users could just do a pull.
The real struggle is unlearning the CVS/SVN master site mindset.

Tim


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: coercing of log(2)*1.0

[root]

>I'm not sure how allowing partial coercions would help the situation.  
>The problems are (1) given a and b in different rings, how to quickly  
>find a' and b' so that a' + b' makes sense and dispatch to that  
>operation and (2) whether or not sqrt(2) should start out as a SR  
>object, or something more specific the same way integers and  
>rationals do, and then coerced down to SR if need be.

Axiom does this in two different ways, depending on whether the
code is interpreted or compiled. 

Interpreted code does the lookup dynamically and looks at the domains.
Domains (types) can export a coerce operation that will coerce things
from other types into the current type, e.g.

  Polynomial(Integer) exports two coerce operations:
coerce : Symbol -> Polynomial(Integer)
coerce : Integer -> Polynomial(Integer)

and the interpreter can automatically use these to lift the input
types to the Polynomial type. Searching for and using these coerce
operations take time in the interpreter. Thus,

  1 + x

finds 9 plus operations that do not apply and one that can apply which
allows the interpreter to automatically coerce 
  1 -> Polynomial(Integer)
  x -> Polynomial(Integer)

and Polynomial(Integer) has a plus operation
  +(POLY(INT),POLY(INT)) -> POLY(INT)

so the result gets automatically coerced to Polynomial(Integer).


The other way occurs during compiles. The compiler requires you
to specify the types explicitly so it can lay down fast code.
At runtime, compiled code does a hardcoded index into the vector
that implements the Domain type to invoke the proper function.

Of course, Sage uses Python so compiling for speed isn't possible.

So allowing classes to export coerce operations that can be 
automatically applied by the interpreter is effective, if not
the most efficient method. Classes are the only place that can
encapsulate the "special case knowledge" necessary to do the
coercions. If the coercions are all buried in some external,
general purpose coercion routine with special case knowledge then,
by design, this routine needs to know everything about everything.
This makes it impossible to add new classes that "just work".

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: coercing of sqrt(2)

[root]

>Maple does
>
> > 1/(1+I);
>   1/2 - 1/2 I

Axiom does

 1/(1+%i)

   1
 --
 1 + %i

which is of type Fraction Complex Integer, that is a fraction 
whose numerator and denominator are of type Complex(Integer).

You can ask Axiom to place the result in a different type:

 1/(1+%i)::Complex Fraction Integer

  1   1
  - - - %i
  2   2

and the type is Complex Fraction Integer, that is a Complex 
number whose real and imaginary components are Fraction(Integer).

The "simple form" depends on what is canonical for the type.

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Trying to extend Integer

[root]

>sage: class foo:
>...   def __init__(self, a):
>...   self.b = a
>sage: f = foo(10)
>sage: f.b
>10
>sage: f.__init__(20)
>sage: f.b
>20
>
>Well Sage hasn't exploded already because of this, so
>I guess we'll just have to live with it.

Excellent. Now we can inflate integers to match the dollar inflation!

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Survey of User Interfaces for Computer Algebra Systems.

[root]

You might find some of the ideas in this paper of interest:

Norbert Kajler and Neil Soiffer "A Survey of User Interfaces for
Computer Algebra Systems" Journal of Symbolic Computation 1998
Vol 25 pp127-159

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage on Scientific Linux?

[root]

Troy,

I recommend you talk to William Stein. He's the project lead.
I follow both Scientific Linux and Sage but am not a contributor to either.
But I think that FNAL and other labs would be the ideal target
audience for a Sage system.

Tim
>> Colleagues,
>> 
>> There is a cross-fertilization that might be very useful for both
>> the Scientific Linux world and the Sage world.
>> 
>> For those who don't know, Scientific Linux is a linux distribution
>> that is a "common platform" for scientific users. It was recently
>> described as:
>> 
>> Sage is an open source effort to create a free and open alternative
>> to Mathematica, Maple, Magma, and Matlab.
>> 
>> It seems to me that the development of a standardized open source
>> platform for science and scientific computation have quite common
>> goals. Indeed, it could be argued quite strongly that this kind of
>> a platform effort is a strong target for NSF, INRIA, or other major
>> government funding.
>> 
>> I can answer some trivial questions about both projects but I am
>> not a "contact person" for either project.
>> 
>> Tim Daly
>> Axiom
>
>Hi Tim,
>That does look like an interesting program.  It's possible that many 
>scientists would be interested in it.
>Has someone already packaged it in an rpm that you know of?
>Troy Dawson
>__
>Troy Dawson  [EMAIL PROTECTED]  (630)840-6468
>Fermilab  ComputingDivision/CSS  CSI Group
>__

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Sage on Scientific Linux?

[root]

Colleagues,

There is a cross-fertilization that might be very useful for both
the Scientific Linux world and the Sage world.

For those who don't know, Scientific Linux is a linux distribution
that is a "common platform" for scientific users. It was recently
described as:

Sage is an open source effort to create a free and open alternative
to Mathematica, Maple, Magma, and Matlab.

It seems to me that the development of a standardized open source
platform for science and scientific computation have quite common
goals. Indeed, it could be argued quite strongly that this kind of
a platform effort is a strong target for NSF, INRIA, or other major
government funding.

I can answer some trivial questions about both projects but I am
not a "contact person" for either project. 

Tim Daly
Axiom



--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Function images, visual mathematics

[root]

This is interesting. Visual mathematics of functions.
http://nylander.wordpress.com

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: ISSAC abstract

[root]

>>> I can try to build a Sage binary on Fedora 3 if you wish
>>> but I'm not optimistic. I know that my Fedora 5 could not
>>> build Sage because the compiler was too old.
>>
>>The compiler wasn't too old, it was *borken*, i.e. "internal compiler
>>error". IIRC it was some gcc 4.1.0 and as well all know a ".0" release
>>is just an extended beta test. FC5's rpm repo offers some gcc 4.1.1
>>that will likely build Sage just fine.
>>
>>> Fedora 3 likely has the same issue.
>>
>>Nope, it ships gcc 3.4.3 which is C99 compliant. I didn't use it
>>recently, but it is quite reliable and any issue with Sage and gcc 3.4
>>will likely be fixed quickly.
>
>Ok. I'll try a fedora 3 build.

Sage failed to build in fedora 3

The log is at


Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: ISSAC abstract

[root]

>> I can try to build a Sage binary on Fedora 3 if you wish
>> but I'm not optimistic. I know that my Fedora 5 could not
>> build Sage because the compiler was too old.
>
>The compiler wasn't too old, it was *borken*, i.e. "internal compiler
>error". IIRC it was some gcc 4.1.0 and as well all know a ".0" release
>is just an extended beta test. FC5's rpm repo offers some gcc 4.1.1
>that will likely build Sage just fine.
>
>> Fedora 3 likely has the same issue.
>
>Nope, it ships gcc 3.4.3 which is C99 compliant. I didn't use it
>recently, but it is quite reliable and any issue with Sage and gcc 3.4
>will likely be fixed quickly.

Ok. I'll try a fedora 3 build.


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: ISSAC abstract

[root]

Alfredo,

I can try to build a Sage binary on Fedora 3 if you wish
but I'm not optimistic. I know that my Fedora 5 could not
build Sage because the compiler was too old. Fedora 3
likely has the same issue.

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: ISSAC abstract

[root]

>Though I've never been to ISSAC (someone who has been, correct me if  
>I'm wrong), I get the impression that many of the people there would  
>have little C programs and scripts that they use/develop for  
>research. If this is the case then I think it would be worthwhile  
>expanding on the interfaces portion about how Sage can easily  
>interact with C and command line programs, do non-trivial text  
>processing, and put it all together in one cohesive mathematical  
>environment.

I've been to a fair number of the ISSAC conferences going back into
the late 80s. I'd characterize the attendees as the group of people
who have developed computational mathematics algorithms. The whole
proceedings from 2007 is algorithms of one sort or other. Most of
these people have developed a CAS or used a CAS as their primary
platform, although by looking at the 2007 papers it is not clear where
some of the work was done, but some are quite specific, as in:

  Jeffery-Hamel Flow with Maple

Paul Zimmermann had a paper that used C++ and GMP.
Jacob Smith, Gaby Dos Reis and Jaakko Jarvi used Axiom.

In general, I don't see reference to the systems or the source
code that was used to do the research. As you might guess, I find
this flaw to be pretty fundamental. If most of the work were done
in Sage, perhaps the "standards of publication" might change.

Tim Daly


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: ISSAC abstract

[root]

>  You might consider designating a particular snapshot (say, 3.0)
>  that you plan to package and build onto CDs. If they use Alfredo
>  Portes's Doyen Live CD then people can just boot up their laptops
>  and have Sage running live immediately.
 
In fact, If you used the Live CD to give your talk it would make
rather more of an impression on the audience.

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: ISSAC abstract

[root]

In the past I have had 2 "distributions" that I gave away at ISSAC.

The first was my Rosetta collection (about 100 open source systems
collected onto CDs). Some of these I eventually put on the ISSAC CD
itself (I constructed the CD for 2 years). It was distributed by ACM.

The second was an Axiom distribution. Axiom was also on the ISSAC CD.

I made enough CDs so that everyone had one distributed with their
information packets and I had a pile of 50 CDs that sat on the 
registration desk.

You might consider designating a particular snapshot (say, 3.0)
that you plan to package and build onto CDs. If they use Alfredo
Portes's Doyen Live CD then people can just boot up their laptops
and have Sage running live immediately. 

Distributing Sage with the registration materials would mean
that everyone could try it during or after your talk.

In fact, if you find out who is going to make the ISSAC CDs
this year you might be able to get the whole CD actually BE a 
Sage distribution. I don't know who might be doing it this
year but Emil Volcheck would certainly know who to ask.

Tim Daly


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: fast vs viable (offline post)

[root]

>My point was that information on branch cuts should either A) be
>publicly available or B) preferably available as an export option.
>Mathematica and Maple both do A.  Perhaps B is the better answer for
>open systems.  In any event I stand by my point that this is only an
>issue because people have a tendency to ignore branch cuts; it is not
>actually a flaw inherent in aggregating many systems, and there are no
>technical reasons it couldn't be handled better.

Consider what you propose as mechanisms for "handled better".

Systems are unlikely to allow you to dynamically change the chosen
branch cuts ((B) above) since the assumption is "built in" to code,
such as the integration routines and the simplification routines.

Neither the authors of "System A" nor the authors of "System B"
would consider a bug report valid since they are both internally
consistent (one hopes), and thus not in error. But the subtle
mistake made by the user (under an incorrect assumption) is very
hard to track down. If Sage allows composing calls from System A
with calls from System B, this is sure to be an issue. The OpenMath
 project has been working on these kinds
of standards.




One hope is for the end user of the system to be able to look
up such information when needed. For most systems I have no idea
where to look for this. This requires good documentation but I'd
be the last to suggest this :-)

Another hope is to use a set of external test cases (the Computer
Algebra Test Suite (CATS) idea) that consists of well chosen problem
sets; in this case, problem sets that reveal the branch cuts. Each
system would show that they got "the canonical answer" (e.g. that they
agree with Schaum's Mathematical Handbook). In that way we could be
sure that the systems were "plug replaceable" at the user level. Thus,
a Mathematica or Maple user could be sure that Sage gave the same
results for trigonometric branch cuts. (To practice what I preach
I've been checking Axiom against published results from many
different sources. See the mailing list and src/input files.)

I feel that both the documentation and CATS approaches are both
important and necessary. Clearly these fall into (A) above.

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: fast vs viable (offline post)

[root]

>I do believe that computational mathematics needs to become a more
>rigorous subject. In fact, I'd like to see a piece of code written by
>Tim upholding the standards he is advocating, where someone has "taken
>the time", because I would like to compare it to my own code and get
>some ideas.
>
>However, I think that a vast number of mathematical papers are written
>to a vastly lower standard than a lot of code. Much of what is
>written, you really do need a fields medal to understand it and papers
>are absolutely full of errors, omissions, handwaving, unchecked
>assertions, statements which have come from the mouths of other people
>but never formally proved, etc, etc.
>
>Just this morning I read a note in which an important new result was
>mentioned. There was no indication of who the result was due to, what
>year they published it, or any other clues. I eventually tracked down
>another paper which mentioned it. But that paper also did not mention
>the authors of the original result. I eventually established that it
>was one or more of the authors of the very paper I was reading! They
>couldn't even reference their own work properly. Not only that, it
>appears to be an unpublished result, and may have been "proved" using
>a computer. I did however manage to find out which month they
>discovered their result, but this didn't help me recover the proof.
>
>On the up side, I also read a paper which was somewhat comprehensible,
>where all the terms were defined, references were given for omitted
>proofs (and they weren't in obscure papers in Russian) and the paper
>was really doing something interesting which was not written down in a
>textbook somewhere. I have to say though, that kind of paper is about
>as rare as the code you are referring to.

The "canonical example" which is in-plan to write is based on the
paper in src/doc/primesp.spad.pamphlet

I obtained permission from the authors to use this paper in Axiom as
the basis for a canonical example. It is not yet complete and fully
integrated into Axiom so I don't talk about it much but it is 
"in process".

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: fast vs viable (offline post)

[root]

>>   - It suffers from the "OpenMath" communication issue (e.g. if you
>>take an Axiom expression, export it to maple, compute with it,
>>and re-import it to Axiom you have violated a lot of type
>>assumptions in Axiom, possibly violated branch cut assumptions
>>(e.g. acosh), done invalid simplifications, and any number of
>>violent mathematical mistakes)
>
>If merely by exporting the data and re-importing it you have violated
>assumptions, then Axiom is broken and needs a better exporting system.

Well, that's something of the issue, actually. 

Suppose we're looking at an inverse function that uses branch cuts.
System A uses "cut 1", say $-\pi < x < \pi$
System B uses "cut 2", say $0 < x < 2\pi$

Suppose you take a result from System A:

  x=A.getResult()

simplify it with System B

  y=B.simplify()

and hand it back to System A

  A.compute(y)

Trigonometric simplification formulas depend on the branch cuts.
Thus, the simplification performed in B, while perfectly valid under
the branch cut assumptions in System B, may not be valid under the
branch cut assumptions in System A.

You get a final answer (assuming a LONG chain of using a lot of
available systems in Sage). Is the answer correct?

Do all of the subsystems in Sage that use transcendental functions
use the same choice of branch cuts in all their routines? Frankly,
I'm not sure how to begin to answer the question because (a) most
(all?) of the systems do NOT document their branch cut assumptions
and (b) I'd likely not be able to follow the logic of so many 
systems through their simplifier.

Is this important? Only if you want a correct answer.

Tim





--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: fast vs viable (offline post)

[root]

>But you still haven't told me: where is all this time going to come  
>from? I can't magically make more time appear. I have other things to  
>do. It's a damn shame.



and, for the record, I vote for MaryAnn. :-)

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Slightly OT: SCC 2008 & Braid Groups

[root]

Michael,

>On the other hand: I couldn't find the python bindings, neither in the
>sf tarball nor the sf svn/cvs repo. Any pointers? I couldn't find any
>reference to python in any file:

I found a copy of it. See 


This will unpack into "gap_front_end" (Magnus can talk to GAP)

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Slightly OT: SCC 2008 & Braid Groups

[root]

I WANT Sage to live. I want it to succeed. I want it to be the
lingua-franca of the business so that we can all post our results
"in Sage" at conferences. I want to be able to "drag and drop"
your publication onto my system and have your code "just work",
your documentation "just connect". I want to be able to not only
use what you write, but to understand it so I can use it effectively.
I want MMA and Maple users to "write for Sage" instead.

My problem is that I don't see the fundamental difference between
Sage and any other system that I've touched in the past. And I don't
want this whole generation of mathematicians to "do it all over again"
without some fundamental gain. I may be wrong that the literate 
documentation is the key. And I admit I'm a knuth-boy fanatic about it.
My question is, what can you suggest that will make it live when others
have not?

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Slightly OT: SCC 2008 & Braid Groups

[root]

>On the other hand: I couldn't find the python bindings, neither in the
>sf tarball nor the sf svn/cvs repo. Any pointers? I couldn't find any
>reference to python in any file:

The python bindings were created using SWIG. I'll see if I have a copy
(I no longer work at CCNY). Gilbert probably has them. I've copied him.



> A couple other things I noticed:

Umm, yeah. The makefiles are, shall we say, "extremely elegant".
I didn't write them. I'd be happy to have any patches you suggest
that might fit your requirements. Be aware that the Makefiles are
self-modifying during build.



>while there is some documentation the format is not in something
>that seems easily extractable.

The documentation is designed to be used by the front-end system.
We won't mention that the code and algorithms need documentation :-)

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Slightly OT: SCC 2008 & Braid Groups

[root]

Jason, Please send me a diff-Naur patch of your changes. --Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] fast vs viable (offline post)

[root]

David,

>> But we've already had this discussion and it is clear that I'm
>> completely out-in-the-weeds, talking-nonsense, and obviously have
>> no idea how REAL-open-source-projects are done. So lets just leave
>> it where it left off before, which is that I've simply dropped the
>> attempt to give the benefit of experience.
>
>Hi Tim,
>
>I've been vaguely following your posts to this list over the last few  
>weeks. I don't think you're talking nonsense, but I don't completely  
>understand what point you are trying to make. You seem to be making  
>the following argument, correct me if I'm wrong. You claim that the  
>documentation of the implementations of algorithms in Sage is not  
>good enough, in the sense that someone looking at the Sage codebase  
>in a few years won't be able to understand what is going on. You  
>conclude that Sage will die. The implication is that the way to fix  
>things is for us to improve the documentation of these  
>implementations (perhaps via literate programming or whatever), so  
>that Sage will be more likely to succeed.
>
>But isn't the core problem simply one of limited resources? We all  
>have limited time (fields-medallists and non-fields-medallists  
>alike), and so there is some tradeoff between getting something to  
>work as quickly as possible (and hence is useful NOW) and making a  
>beautiful product which meets higher standard of scholarship (and  
>hence is more useful LATER). I can't see any way around this  
>tradeoff. The only thing I can see that will stop a project like Sage  
>from dying is to keep building a steady inflow of users and  
>contributors, so that the knowledge you refer to remains as alive as  
>possible.
>
>david

I've been associated with some open source projects, and in particular,
with Axiom, Magnus, and Doyen. And I've been programming for 35 years.

Once a week I hear the "I don't have enough time" argument.

This argument is fine for most of the things I do, e.g. the things
I get paid to do because, frankly, almost nothing I've ever done will
be worth anything 10 years from now.

Computational Mathematics is different in this respect. The answer
to integrate(sin(x),x) will be the same 30 years from now. However,
the expert who wrote the code will not. (Manual Bronstein is dead).
Who will maintain this code if it requires a PhD in Infinite Group
Theory just to understand WHY it works and a computer science degree
to understand what the PROGRAM is doing?

The real tradeoff question is "Are you doing science?" or just 
"playing around with ideas". Because, if you're doing science then
you're doing it for the community. Which means that there is a 
standard of scholarship that is expected. 

When I read a proof of a new theorem I expect to see references
to prior results, complete proofs of lemmas, complete documentation
of assumptions, and a full explanation of the whys-and-wherefores.
It takes about 5-10 pages to reach this standard of publication
for most mathematics. And THAT TAKES TIME.

So ask yourself the following question:
  What is the "standard of publication" for COMPUTATIONAL mathematics?

What *I* expect to see is an explanation of the mathematics, possibly
with proofs (if new). I expect an explanation of how and why the CODE
implements the mathematics. I expect complexity bounds. I expect an
explanation of optimizations that are not obvious but are critical.
This may take 10-100 pages to reach this standard of publication for
computational mathematics. and THAT TAKES TIME.

If you haven't given me that level of documentation then you haven't
given me anything but your lab notebook. You've published nothing but
your scribblings to yourself with no assurance that (a) it is mathematically
sound, (b) it is correct, and (c) the who/what/where basis for your
work is anything but your own self-mutterings.

Do we build a science on this?



A few centuries ago a mathematician could claim anything by
handwaving, and "prove it" by solving the questions posed to him.

In the last century the standard of proof has risen in mathematics
from handwaving, thru simple explanations, and eventually onto more
rigourous proofs.

Computational mathematics, the collision of math and computers, 
is still at the handwaving stage. 




Sage is dancing around like it has discovered something new and
wonderful. But I've been in this business now since the late 80s and
Sage has done absolutely NOTHING that has not already been done
before. Maple used a highly popular language (C) as its basis for a
user interface, MMA used Lisp-like notation initially.  Magnus
collected experts and was funded by NSF. Axiom was funded by NSF and
IBM. Axiom used to be "free and open source" when I was at IBM. If you
asked I'd send you a tape of the source code.  Magnus has always been
free as Gilbert thought it was important.  William Stein is a new
incarnation of Gilbert Baumslag, 20 years later, thinking he's
discovered something that nobody ever noticed be

[sage-devel] Re: Slightly OT: SCC 2008 & Braid Groups

[root]

>Wasn't Magnus Tim Daly's main example of a project in trouble
>development and usage-wise?  From this thread:
>http://groups.google.com/group/sage-devel/browse_thread/thread/c65e235f83cb2cd1/93b5dc531e50bb1c?lnk=gst&q=magnus#93b5dc531e50bb1c
>
>Tim wrote:
>"the only person
>who can properly maintain, modify, and extend the code will no
>longer be available and the code will be frozen in time. My
>Magnus infinite group theory project has this problem.
>New people coming onto the project cannot find the literature
>that corresponds to the actual code because it does not exist.
>Most published results are 5 page conference papers that just
>hint at the non-core, but vitally important, details if they
>mention them at all. This problem has 2 parts, both of which
>stem from the lack of focus on the new discipline of computational
>mathematics. Part 1 is that journals and conferences only want
>short papers, which are adequate for math, not the complete
>implementation. Part 2 is that there is no place to describe the
>actual code-level optimizations that make the implementation
>practical and fast. "

Magnus is a stalled project. It was a free, NSF-funded, top-of-line,
best-of-breed project that brought together Fields-medal level people.
The algorithms in Magnus are world-class and written by experts. They
work, and work well. And they are GPLed, free, and open sourced. Magnus
has a truly innovative, zero-learning-curve, notebook-like front-end.
It runs algorithms in parallel, with user-controlled time proportions.
It has context-sensitive menus and help systems. It has a problem-graph
that organizes the results of experiments and allows you to pursue
mulitiple-independent lines of research on the same "notebook".
Sage is nowhere near the level of sophistication Magnus displays today.
Did I mention that it is free? 

Magnus has been used (thru python) in an embedded demonstration of
cryptographic security using infinite groups to protect user logins.
It has been shown to allow logins on systems all the way down to a
handheld zaurus.  (Infinite groups are MUCH harder to break than other
schemes and Gilbert can show why these are hard (in a cryptographic
sense). Small keys, yet solid locks.)

Historically, Magnus was where Sage is now.



The quote above is in the context of literate programming, or lack
thereof.  Magnus is documented at the same level as other open source
projects (e.g. Sage). The code is all there, freely available, and
written in a widely used, VERY popular language (C++). It can be used
from Python. Yet Magnus and its algorithms now suffer from the same
fate that I predict L-functions in Sage, and Sage itself, will suffer 5
years from now. William will have his system, will have published his
research (the classic 5 page papers), and will have retired to Alaska.
That is,
  >New people coming onto the project cannot find the literature
  >that corresponds to the actual code because it does not exist.

But we've already had this discussion and it is clear that I'm
completely out-in-the-weeds, talking-nonsense, and obviously have
no idea how REAL-open-source-projects are done. So lets just leave
it where it left off before, which is that I've simply dropped the
attempt to give the benefit of experience.

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Slightly OT: SCC 2008 & Braid Groups

[root]

>>
>>  I don't know if that is of any interest but someone around here might care
>>  about the fact that Sage was probably the most mentioned (and cited)
>>  mathematics software at the "First Conference for Symbolic Computation and
>>  Cryptography" (SCC 2008) in Beijing.
>>
>>  Specifically, these authors/papers mentioned Sage:
>>
>>  * Tobias Eibach and Gunnar Völkel: Optimising Gröbner Bases on Bivium (used
>>  Sage to implement attack)
>>  * Burçin Eröcal: SCrypt: Using Symbolic Computation to Bridge the Gap 
>> Between
>>  Algebra and Cryptography (module for Sage)
>>  * Ralf-Philipp Weinmann and Johannes Buchmann: Distributed Memory 
>> Computation
>>  of Row-Reduced Echelon Forms over Finite Fields (benchmarked against Sage)
>>  * Yours truly and Carlos Cid: Algebraic Techniques in Differential
>>  Cryptanalysis (used Sage to implement attack)
>>
>>   (... yes, I know that 3 out of 4 are Sage developers, but still ...)
>>
>>  Another thing:Two talks dealt with Braid group cryptography, namely:
>>
>>  * Robert Gilman, Alex D. Miasnikov, Alexei G. Myasnikov and Alexander 
>> Ushakov:
>>  New Developments in Commutator Key Exchange
>>  * Alex D. Myasnikov and Alexander Ushakov: Cryptanalysis of the
>>  Anshel-Anshel-Goldfeld-Lemieux Key Agreement Protocol
>>
>>  The group developed a C++ library CRAG:
>>
>>  """
>>  The Cryptography And Groups (CRAG) Library provides an environment to test
>>  cryptographic protocols constructed from non-commutative groups, for example
>>  the braid group. The Library is written in C++ and provides an interface and
>>  routines for computations. There are implementations of basic algebraic
>>  objects like words, maps and subgroups. We plan to continually expand the
>>  list of group-theoretic algorithms implemented in the library. In addition
>>  the Library will contain classes and routines implementing non-classical
>>  heuristic approaches and tools to perform statistical and exploratory
>>  analysis of algebraic data. Together with the C++ source code CRAG contains
>>  interface to Python scripting language.
>>  """
>>
>>   http://www.acc.stevens.edu/downloads.php
>>
>>  I don't know much about group theory but still I figured someone might find 
>> it
>>  interesting and is able to evaluate if it could be a good addition to Sage.
>
>This is very interesting. I just have some general remarks. Alexi Myasnikov
>(a good friend of mine knows him well and that is what he calls him - Alexi, 
>not
>Alex. as on the website) is an extremely talented group theorist. I heard that
>there was some discussion of him getting a Fields medal years ago when
>he announced
>his solution of the Tarski problem. That is his level. If he is behind
>this library
>then I think that it at least has the stamp of authority. BTW, both Alexi and
>Gilbert Baumslag were behind MAGNUS, an infinite group theory package. I had
>a few (off-list, I think) emails with William Stein and Gilbert
>Baumslag, and I met
>with Gilbert face-to-face a month or so ago about MAGNUS and SAGE. The
>problem is that MAGNUS is designed in a way which makes its GUI front-end
>difficult to separate from its group-computational engine at the back-end. As a
>bit of background, Gilbert Baumslag is also a superstar in the field
>of combinatorial
>group theory and has just recently moved from the math dept at CUNY to the CS
>dept. This graphic design was probably Gilbert's idea and very much in
>line with some
>other (computer science) projects he has worked on. Anyway,
>MAGNUS->SAGE just didn't
>work out. I think the design of CRAG is different and may be easier to 
>integrate
>into SAGE. I do see that they have a free group and finitely presented group
>(C++) class, which is good. These are also in GAP though. What GAP
>does not have is
>"Definition of equations over finitely presented group", nor does it
>have any of the
>crypto stuff.
>
>So, I vote +1 to include it at least as an optional package. Making it
>a standard part of SAGE
>should IMHO wait until a solid FreeGroup and FinitelyPresentedGroup
>(Python) class
>are created for SAGE. If I had more time I would do this myself.
>
>Thanks again Martin for pointing this out.

(disclaimer: I'm the person who set up the Magnus sourceforge site
and I worked for Gilbert Baumslag at City College)

I know that there is an existing Python wrapper around Magnus.

I know that Magnus has a large number of C++ routines for group
theory that exist nowhere else.

I know that Magnus can be used without the frontend (we used it
as a password mechanism for logging into linux using groups theory).

I know that Magnus is designed to run procedures in parallel.
(not algorithms since they may not terminate; in general, 
there are very few algorithms for this kind of work)
Using the procedures in parallel enable you to try various
approaches until one succeeds and then poison the others.

I know that Magnus is GPL.

I know that there are a large number of people who have collaborated
with

[sage-devel] Re: Initial support for posets

[root]

>Sage just uses the mainstream language Python; we are
>not in the language design business.  It's an interesting
>exercise to think through how each of the ideas you generously
>explained above is expressed using Python.

This is a general purpose python idea, actually. If there was
a python function that looked at the namespace available for
each .py file then it could decide that there are two lattice
functions. This could issue an "import lattice from poset"
to disambiguate the lattice question automatically. (I have no
idea how you might look at a .py file and get its namespace).

This is not a new issue because Sage already has several different
polynomials available to it at any given time. The user has to
specify which one to call by naming the spkg tool explicitly.
Thus the various spkgs split the namespace at the moment. 

As more functionality migrates from the external packages into
"Sage-native python" this issue will grow worse. Which package
gets to own the name "differentiate"? Axiom shows 25 different
functions of that name, e.g. polynomials vs power series. 

Suppose the user wants to use the "same name" in the "same sentence"
(e.g. differentiate(poly)*differentiate(powerseries)). How is
this resolved? Does the user have to do special imports? How
will the user know that there are 50 differentiates from 7
different spkgs (25 from Axiom alone) and 6 from python packages?

It is an explicit design decision of the user interface to decide
whether there is an automatic resolution or a user-specified
resolution. It would be worthwhile to have a discussion of this
design decision before it gets "encoded by default" as a result
of the lattice discussion. 

I don't think that Axiom's solution can work for Sage because
Axiom is a strongly typed language. But it does highlight at
least one other point in the space of design decisions.

Names matter.

Tim





--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Initial support for posets

[root]

Axiom's "solution" to the lattice problem is to use an interpreter
for user interaction. Instead of just talking to a top level lisp
command prompt, you interact with the interpreter.

The interpreter looks at the arguments and classifies them by type.
It looks for "modemaps" that define the functions (e.g. all lattice
functions) and finds a minimum type matching modemap. The process
is repeated "working outward" for the final expression type.

Thus Axiom has some 1 functions with approximately 3000 names
in the name space. The user can explicitly override this process
in various ways.

You might say lattice(args)$Posets to explictly override the
interpreter (although it will fail if the argument types don't
match).

Given the limits of naming conventions by various fields of math,
the interpreter provides a way to overload names in useful and
naturals ways. Thus a single function (say, map) can have multiple
well defined meanings (there are 80 map functions in Axiom).

In compiled code (Spad), you must specify exactly which function
of which domain you intend to call. If you're ambiguous about it,
the compiler gives you a suitably ambiguous error message.

Perhaps someone might give some thought to a Sage-interpreter
that helps in name resolution rather than having 80 people 
try to define which "map" is the "correct" map.

Tim Daly



--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage OSX 10.4.4 dmg

[root]

My Mac box is generally idle except when I'm doing the every-other-month
Axiom release. If you need images I can build them for OSX 10.4

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage OSX 10.4.4 dmg

[root]

Have you copied the image?
Can I remove it?

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: [fricas-devel] Re: [sage-devel] Re: FriCAS/Open-Axiom and SAGE

[root]

Yes, both books are part of the documentation that ships with Axiom.

The Jenks book (ISBN 0-387-97855-0) is in src/doc/book.pamphlet
(the latex sources). It is also available as a pdf file at 


The Daly book (ISBN 1-411-66597-X) is in src/doc/bookvol1.pamphlet
(the latex sources). It is also available as a pdf file at 




Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: [fricas-devel] Re: [sage-devel] Re: FriCAS/Open-Axiom and SAGE

[root]

Gary,

Also of interest, the algebra hierarchy diagram and data hierarchy
diagrams within Axiom (the endpapers from the Axiom book) are online at:



Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: [fricas-devel] Re: [sage-devel] Re: FriCAS/Open-Axiom and SAGE

[root]

Gary,

If you're interested in exploring Axiom's type system 
the best source of material available is the Jenk's book.
It would be useful if Sage's type hierarchy was close to
the one Axiom uses, making it possible to share algorithms.
If you'll mail me a postal address (offline), 
I'll send you a copy of the book.

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0 released

[root]

I have a MAC OX X 10.4.4 build in process.
Its on a PowerPC (G4)
I'll make it available when it completes.

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0 notebook fails to display

[root]

sage -b solved it. thanks --Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Project

[root]

>I feel that I have done more than a reasonable amount of work here. Do
>you agree or disagree?

Have you done a reasonable amount of work? That's for you to judge
since you're the person with the need.

But lets see what seems to be going on with Clisp.

Sam's reply to you seems to be that you need a certain combination of
operating systems and compilers and libraries to generate a supported
build. (This is very similar to the reply to my Sage bug report,
essentially "fix your compiler".)  So the expected response would be
for you to reinstall Solaris to the "correct" version with the
"correct" libraries and the bug goes away. Asking a user to "fix
their system" is not a valid response but that seems to be the essence
of the replies.




Ask yourself why you might get this kind of response.

Sam (and Camm) may have time constraints. I know that Camm does the
work in his free time. I know Camm is working on a massive rewrite
(probably NOT in public).  I don't know what Sam does for a living but
I suspect his work is also a free time activity. Axiom is also free
time support. Dormant bug reports are not an indication of inactivity.
Sage may have a few bug reports that are a few months old. Clisp is
free software. You have the source code, you have the need, post a
patch.

Sam (and Camm) may have hardware/operating system constraints.
Possibly the boxen that they use are borrowed and they cannot
reproduce your exact environment. I have 9 physical machines here with
32 virtual boxen and I still cannot reproduce all of the
combinations. I don't have access to a Sparc, for instance.

Sourceforge took down their compile farm and HP doesn't have a large
set in their farm. Axiom runs in many more places than I publish but
there are outstanding build issues so I won't claim it "runs" anywhere
but on a published subset of combinations. You do the same thing
(e.g. no redhat9 gcc x.x.x). I did ask Google, Microsoft, and
Sourceforge to put up compile farms but nothing happened. If we
all used a "standard compile farm" this problem might be minimized.
For now, though, the odds are good that Sam does not have your 
Solaris machine configuration and cannot reproduce your bug.



We are both in the same business; you package Sage to run everywhere
and I package Axiom to run everywhere. As soon as you touch anything
at all, something breaks. When GCL breaks, I post a patch and locally
apply the patch until it is accepted upstream (if at all). If Clisp
fails for you then fix it, post a patch, locally apply the patch
until it gets applied upstream, and move on.




It is not a question of "reasonable amount of work".
It is a question of expectations.

What, exactly, do you expect? Instant, top-of-the-pile bug fixes on
all of YOUR hardware/software combinations? This is free and open
source software. The only thing you can expect is to get the source
code so you can fix it and post a patch. Everything else is not in the
contract. That's why people pay for software.  Franz would be willing
to fix your issues immediately. I'm not sure your check to Sam has
cleared yet. If you don't want to build patches then send Sam a
contract. I'm sure he'd be happy to get paid. Sage will have this same
problem in the future as various package maintainers move on or you
can no longer reach your Sparc.

What if your expectations are not fulfilled? Well, that generally
leads to anger and frustration, both natural reactions. But it seems
that you have used "hasty generalization" to conclude that Lisp is
dead.  And from there to conclude that Lisp should be removed from
everywhere.  That's a shame because Maxima contains an astonishing
amount of well debugged algorithms by recognized experts in the field.

And characterizing Lisps like SBCL (fork of CMUCL, child of the CMU
Spice Lisp research project) as "polishing a turd", implies that
Scott Fahlman wasted his time studying dynamic language optimization
in compilers. Python has yet to even think about these issues, most
of which have already been solved by Scott. Everywhere else in Sage
I see people struggle over milliseconds. Then I see Maxima built on
Clisp (an interpreter) rather than SBCL, a optimizing compiler.


Ultimately the point of my post was that, despite not seeing immediate
results, it is STILL worthwhile to post bug reports. At minimum, other
people can google them and find that they also have the problem. 


As for your original question, if your bug reports contain a patch
THEN you've done a reasonable amount of work, at least by my
definition of "reasonable". Your definition might differ.

Tim


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Project

[root]

>.
>  If the lisp community were alive and well
>their tools would be alive and well. That is clearly not the case of
>gcl and clisp certainly has some serious issues to deal with with
>newer gcc releases as well as compilers not gcc.
>

I'm also on the clisp mailing list and I don't recall seeing any
sage-related bug reports there either.

>Can gcl be improved? Certainly. But I am not holding my breath.
>
>.

I know you don't care about lisp and that's fine. And I know you've
encountered problems with lisp builds. And we both know that when
someone encounters problems with open source tools it is expected
behavior to post bug reports (as I did with Sage this morning).

Please post specific bug reports. We all know that's the only real
way anything will get done to solve the problems. The clisp maintainers
are very responsive to mailing list bug reports.

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0 is out

[root]

Sage 3.0 build failed. See:


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Project

[root]

>> Having spent a fair portion of my life porting software, I understand
>> the frustrations you feel. And having spent the bulk of my life using
>> Lisp I "get" the get-rid-of-lisp pushback. But a lot of astonishingly
>> good computer algebra exists in lisp (we won't discuss the reasons).
>> Reproducing Axiom's "million-things-of-code" in Python would be no
>> small task, especially since some of the experts are dead.
>
>Well, many things are available in non-lisp CASes and many of them are
>in Sage, so it isn't that Sage without Axiom isn't viable [not that
>you implied that]. If a sufficient number of people want Lisp to
>remain a significant player in the CAS world [and computer science in
>general] it will be so. We are not forcing you to use Python or Sage.
>This is all about what tool gets the job done for you and in your case
>it is Axiom ;)

Well, Sage doesn't actually use Axiom. William has no long term focus
except to compete with the 4Ms. Sage doesn't use GCL. And the project
is strongly motivated to elide lisp. Except for my involvement in the
Sage program committee for the Nancy conference, I don't see that I
can be of much help. Sorry for the noise.

Tim



--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Project

[root]

>> I think you'd feel the same frustrations with Python if you compiled
>> Python from scratch for every platform. You ship "sources" but assume
>> that the python language exists and is compatible, which is not likely
>> to be the case when 3.0 arrives. If you can assume the python  
>> language,
>> why can't you assume the lisp language? If you can't assume the lisp
>> language, why can you assume the python language?
>
>We do compile python from scratch on every platform. It's part of the  
>Sage distribution.

+1 for you, -1 for me. 

t

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Project

[root]

>For example, is the fact that GCL doesn't build for us anywhere, something
>that you think we'll get passed by just trying harder?  Or is it going
>to be really really hard.



All versions are built with GCL. I do not have access to a Sparc
although GCL has run there in the past. I no longer have access
to my Zaurus although GCL has run there in the past. I do have
access to an OLPC-XO. I release Axiom every two months so I'm
likely to get it working in the next release cycle.

GCL runs on windows although I have not spent any time on a 
windows port. Waldek has, so he might have an opinion. Given
what I know about GCL internals I have every reason to believe
that it would compile using MS or Borland compilers (modulo a
few #ifdefs to pay homage to C). I don't have access to a native
C compiler for windows.

GCL is just a (big) C program and like every other C program I've
ever used, it is easily ported. But
the actual fact of the matter is that it does run everywhere I've
ever tried to make it run. All it requires is the right set of
./configure switches. My collection above includes, I86-32, 
I86-64, and PowerPC.




> The GCL-devel mailing list has on average about 5-6 messages a month
> during the last couple of months, except for a bunch of messages in
> January about people trying to build GCL from cvs.

You claim that you pass problem reports upstream but I don't see many
Sage postings to the GCL mailing list. Camm, the GCL maintainer, has
always been very responsive and effective in his replies. But, like
you, he needs good, clear, effective bug reports.




I think you'd feel the same frustrations with Python if you compiled
Python from scratch for every platform. You ship "sources" but assume
that the python language exists and is compatible, which is not likely
to be the case when 3.0 arrives. If you can assume the python language,
why can't you assume the lisp language? If you can't assume the lisp
language, why can you assume the python language? 


Having spent a fair portion of my life porting software, I understand
the frustrations you feel. And having spent the bulk of my life using
Lisp I "get" the get-rid-of-lisp pushback. But a lot of astonishingly
good computer algebra exists in lisp (we won't discuss the reasons).
Reproducing Axiom's "million-things-of-code" in Python would be no
small task, especially since some of the experts are dead.

Tim


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Project

[root]

>> In any case, it is certainly possible to use lisp as a library
>> element rather than using pexpect. I'm not sure why ECLS is special
>> in this context since I've never used it.
>
>I am not aware of any other lisp interpreter that you can easily embed
>in a C library. Can you point me to one?

GCL is just a C program. Use memory mapped I/O to map your input string
as a "file" and your output area as another file. See 
<http://www.ecst.csuchio.edu/~beej/guide/ipc/mmap.html>

Give GCL the memory map file handles for I/O. Call read. (See
<http://cvs.savannah.gnu.org/viewvc/gcl/o/read.d?root=gcl&view=markup>)

Fetch the output from the mmapped memory output "file" region. 

Zero parsing overhead using filelength to delimit the output.



The "problem" with this approach is that (a) it isn't generic like
pexpect and (b) it requires programming (although this is posix).
You could probably hack it up in Cython.

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Project

[root]

>> I have no idea why you think ECLS is a silver bullet.
>
>I forgot one important argument here: With ecls you can embed the lisp
>interpreter into an external library, hence we would be able to use
>Maxima as a library instead of using the inefficient pexpect
>interface. I am not sure how much work this would be, but if I were a
>Maxima coder I would certainly look into that possibility since it
>opens a whole lot of possibilities for Maxima IMHO - totally
>independent of Maxima's role in Sage.

I looked at pexpect. It appears to be a process controller of sorts
that interprets and parses console I/O.

Axiom has its own version called sman (superman). You don't normally
type directly at the axiom command prompt but are talking to sman
which mediates the console i/o. Sman manages a set of processes
(the AXIOMsys interpreter, the graphics, hyperdoc, etc) but makes
it appear that you are talking to axiom. You could talk directly
to the AXIOMsys system prompt or directly to AXIOMsys thru a network
port (which is how the Axiom Firefox works). But sman doesn't actually
parse anything at all. It is just a very small C program which forks
processes and sets up ptys and thus has nearly zero overhead.

I'm not sure what Maxima does. But I'd bet that almost all of the
overhead you're seeing isn't Maxima but pexpect delay. Somebody
is probably playing parsing games to get prompt and end-of-input
processing and that has got to cost a lot. Why not just reach into
the lisp and do it directly? Why use a console connection at all?
Using pexpect has got to be the worst of all possible ways to talk
to Maxima.

In any case, it is certainly possible to use lisp as a library
element rather than using pexpect. I'm not sure why ECLS is special
in this context since I've never used it.

Tim



--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: notebook features discussion

[root]

>>  For about 2/3 the things I personally want to output word wrap is
>>  better, and for the other half, word wrap is worse.
>
>
>The above sentence is mathematically inconsistent because I had "half" at the
>beginning of the sentence, changed it to 2/3, but didn't change the
>other half to 1/3.

Only if you assume the sets are disjoint but knowing users, that may
not be a good assumption.

Tim

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: One Laptop Per Child Is very interested in Sage

[root]

>>  Is there anybody at UW that is interested in meeting with some OLPC
>>  people?  (I'm cc'ing this to sage-devel, because people there are generally
>>  interested in OLPC.)
>
>I'm not in Seattle, so I can't meet with the OLPC people,
>but a very enthusiastic +1 on this effort.  Sounds awesome.
>
>-Alex
>
>
>>
>>
>>  -- Forwarded message --
>>  From: Seth Woodworth <[EMAIL PROTECTED]>
>>  Date: Thu, Apr 17, 2008 at 3:40 PM
>>  Subject: One Laptop Per Child Is very interested in Sage
>>  To: [EMAIL PROTECTED]
>>
>>
>>  Hello,
>>
>>  I'm an intern at OLPC and I'm throwing an event at UW this weekend.
>>  While the event is specifically about healthcare, there will be
>>  several people there that are strongly involved in OLPC.  For some
>>  time SAGE has been kicked around as a back end for a graphic
>>  calculator application on the XO laptop, and there are many developers
>>  that would love to pick your brain on the subject.
>>
>>  Since there will be several OLPC people at the UW this weekend, I was
>>  wondering if you would be interested in meeting up with us and
>>  discussing SAGE.  This invitation of course applies to any of the
>>  other SAGE team members as well.
>>
>>  The XO laptop is a great piece of machinery.
>>
>  Seth Woodworth, HealthJam Organizer.


I'm actively working with Luanne Burns on a version of her PhD thesis

called MEADOW: An integrated system for intelligent tutoring of subtraction
concepts and procedures.

Basically what happens is that the student does subtraction homework
problems and this software monitors the students actions (using a
combination neural net and rule based programming). If the student
makes a mistake the system analyzes the mistake and explains the mistake 
(using pictures, scripts, audio, etc) to the student. Thus it acts as
a constant tutor to the student in a home setting.

Thus it is perfect for "at home" tutoring. We think that the 3rd world
students will not have timely access to tutors and the parents may not
have the necessary expertise to handle arithmetic.

This is "math" in some sense but quite far away on the spectrum from
doing Sage on an XO :-). It is probably best to have any further
discussions off the Sage lists.

Tim Daly
Axiom



--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Output Form versus Internal Structure

[root]

Robert,

I briefly looked over your coercion model.

_repr_ This is the easiest way to define how your object prints
   It should take a string representing your object
   I takes one argument, do_latex


I might comment that Axiom uses an output domain that exports functions
for constructing the print representation of its objects. This design
has made it possible for an object to print itself in various ways.

Over time Axiom has implemented many different output forms, such as
script (an IBM internal scripting language), algebra (the default 2D
ascii output), LaTeX, FORTRAN, and most recently MathML, used in the
new Firefox front end.

You might consider a design that allows the end user the option of
specifying the desired output form as decoupled from the object
structure.

Tim Daly
Axiom

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: multivariate factoring - use maxima ?

[root]

>Michael Abshoff made that comment.  He's motivated by wanting
>to port Sage to a wide range of architectures and keep everything
>maintainable, since he works incredibly hard on that.   He suffers
>a huge amount trying to deal with build issues on various platforms
>such as solaris, Linux PPC, etc.  I'm sure you understand well
>how hard building complicated math software is on a range of platforms!

I understand. I have ported Axiom from Maclisp/VMLisp on mainframes to
workstations to PCs under a dozen lisps and a dozen opsys versions,
including Dos so I understand his pain. In fact, I think that porting
Sage is going to absorb a very large portion of your available time
and energy.  The port to the next version of Python should be fun.
Trust me, you're underpaying Michael :-)

Tim Daly
Axiom


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---