[sage-devel] Re: sage-edu, standard API, etc.

[didier deshommes]

On Fri, Feb 22, 2008 at 5:57 PM, alex clemesha <[EMAIL PROTECTED]> wrote:
> In Knoboo we *decouple* the idea of a kernel, it could be another
> Python (Sage) process, with communication through Pexpect
>
> ... but it also couple be another Python (Sage) process running a very
> minimal XML-RPC server, and all communication occurs through
>  *** HTTP instead of Pexpect ***.

I personally am not too familiar with web development, so it's always
great to hear from someone who has (which is exactly why this
discussion was started). Regarding XML-RPC vs Pexpect:
 - how slow is one compared to the other?  I expect xml-rpc to be
slower, but not so slow to render it unusable.
- I understand xml-rpc working for inter-communication, ie SAGE ->
outside world, but I don't see how it would work for
intra-communication, SAGE -> maxima. Maxima would have to be already
running in the background, right? If that is the case, then every sage
session would have to spawn singular, maxima, maple, etc sessions at
start-up. I don't like that. Is there something I'm not getting here?

didier

--~--~-~--~~~---~--~~
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: exact cover problem

[bard]

Excellent work.

I, too, have thought about DLX a lot. It is well known, being
recommended by Knuth, more than once, in the context of
people who need to solve NP-complete problems.

This is part of the general paradigm of solving NP-complete
problems, where you build up a library of very good
heuristics, exponential-but-not-so-slow algorithms, etc...
and then convert other problems to the ones you can solve,
solve them, and convert back.

The use of SAT-solvers to solve polynomial systems of
equations, which was the backbone of my dissertation, is
exactly this. Solving a polynomial system is NP-hard, and
if the system is over GF(2), reduction to CNF-SAT is relatively
easy (see Bard, Courtois, Jefferson, 2006, on
http://eprint.iacr.org/). You convert, call a SAT-solver (which
might well run for an unbelievably long time) and convert
back.

Is it the same as Mx=[1,1,1,1,...,1]? No. Because suppose
a particular element is ``covered'' twice. In M_2(GF(2)), that
would be 1+1=0 times covered. But we want it to be covered.
The field GF(2) is equivalent to logic when 1 is true and 0 is
false, but the add is XOR and the multiply is AND. There is
also a semiring with add being OR and the multiply is AND.
In this semiring, you can still conceive of matrix multiplication
and squaring. In fact, you can do this to solve "transitive
closure" of a graph, rapidly, by repeatedly squaring a matrix
over this semiring.

I don't know of any matrix inversion method over the semiring.
Since subset-cover is NP-complete, and since Prof Stein just
showed that matrix system solving over the semiring will solve
subset-cover, then we have a nice proof that matrix system
solving over the semiring is NP-complete.

Ok. Now we have DLX is SAGE. This is very good for people
like me who are interested in solving NP-complete problems.
I recommend the following. That we think of all the things
that we can do with a DLX-oracle, just as the SAT-solver
community has spent a lot of time dealing with what you can
do if you have a SAT-oracle on your desk.

First things first... can you reduce subset-cover to CNF-SAT
in a condensed way? Or vice versa? If so, then perhaps DLX
solves CNF-SAT faster than MiniSAT, the current ``good''
SAT-solver. This would be shocking. The reverse would also
be something we should check, but I doubt it. DLX is known
to be very fast.

If the person who implemented the DLX stuff would like a
fast paper, then see if you can solve the modular knapsack
problem with it. Many classes of knapsack cryptosystems are
broken but not the general class... I think many people would
like to see that extended. Modular knapsack is exactly like
the knapsack problem except that the weights and values of
the objects the burglar is stealing are in a cyclic group, not
integers, and one of them should be 0. I am very foggy on this.
---Greg

**
* Gregory V. Bard
* Assistant Professor
* Department of Mathematics
* Fordham University
* Bronx, NY, USA
*
* Office: John Mulcahey Hall, Room 421
* Phone: +1-718-817-3222
* Fax: +1-240-363-0240 (an e-fax)
* E-mail: [EMAIL PROTECTED]
*

















  To  "sage-devel@googlegroups.com"
, "Gregory Bard" <[EMAIL PROTECTED]>
  cc  
  bcc  
  Subject   Re: [sage-devel] Re: exact cover problem
"William Stein" <[EMAIL PROTECTED]>

02/22/2008 12:49 PM PST







































































On Fri, Feb 22, 2008 at 12:04 PM, Jason Grout
<[EMAIL PROTECTED]> wrote:
>
>  [EMAIL PROTECTED] wrote:
>  > I've found a nice implementation of the DLX algorithm, which "quickly"
solves the NP-Complete exact cover problem.  For those who aren't in
Seattle and haven't heard me blathering on and on and on and on about how
awesome DLX is...
>  >
>  > Let M be a binary matrix.  An exact cover is a subset of the rows of
the matrix who sum (exactly) to the vector 1,1,...,1.
>  >

Isn't that exactly the same thing as solving

M*x = [1,...,1],

over GF(2)?   I.e., the cost should be the same as 1
(or maybe 2) reduced echelon forms over GF(2)?
If so, is "your nice implementation of the DLX algorithm"
better than Gregory Bard's existing implementation
of computation of reduced row echelon form of
matrices over GF(2)?

If the number of bits in your rows is 1000 how long does
it take?  On sage.math Gregory Bard's code computes
the rref of a 1000x1000 random matrix over GF(2) in 0.03 seconds:

sage: a = random_matrix(GF(2),1000)
sage: time a.echelonize()
CPU times: user 0.03 s, sys: 0.00 s, total: 0.03 s
Wall time: 0.03

A 4000x4000 takes 1.46 seconds:

sage: a = random_matrix(GF(2),4000)
sage: time a.echelonize()
CPU times: user 1.46 s, sys: 0.00 s, total: 1.46 s
Wall time: 1.46

Here's an example of this relating to your example:

sage: a = matrix(GF(2),4,[1,0,1,0, 1,1,0,0, 1,0,1,1, 0,1,0,1])
sage: b = matrix(GF(2), a.nrows(), [1]*a.nrows())
sage: a.solve_right(b)

[0]
[1]
[1]
[0]

That solve_right uses rref behind the sce

[sage-devel] more on exact cover, DLX, etc...

[bard]

If you want to carry out operations on the semiring afore mentioned,
where adding is OR (not XOR) and multiplying is AND, then you can
use floating point arithmetic.

Let Z be 0, and let P be "non-zero positive". Then ordinary
multiplication and addition have the following chart

ZZ=Z, ZP=Z, PP=P.
Z+Z=Z, Z+P=P, P+P=P.

So long as you don't overflow/wrap around, you are golden.

Of course, you can't invert in this world.

The additive identity is Z, but there does not exist an X
such that P+X=Z, which is needed for a ring.

I'm glad this DLX algorithm is being added to SAGE, now I
don't have to implement it myself, and there are wide classes
of problems to attack.

Here's a challenge:
Given a graph, can you find a small subset of vertexes (not edges,
but vertexes) such that removing them will partition the graph into
two disconnected parts, so that the larger half is at most double
the size of the smaller half.

If not, then do it be removing edges but they have to be weighted,
directed edges, and the removal must be minimal weight.

If you can do this, then let me know, I'd be excited.
---Greg


--~--~-~--~~~---~--~~
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-edu, standard API, etc.

[kcrisman]

I think, though I'm not sure, that mabshoff has perhaps misunderstood
my points, probably because my post was too long, for which I
apologize.  As I said, this post was very much in the conciliatory
spirit of Jason Grout's original one.  In particular, I was
emphatically not addressing any of the issues raised by Ted, most of
which I am entirely ignorant of, and I am sorry that I implied it
because of the reference to "show me the code", which I referred to
more generally than its actual use in the thread.  (I'm not even sure
what problems there are with the notebook, and if someone wants to
leave Sage because of that, it's their business.)  Similarly with
reference to "victim to its own success", in which I only referenced
things from frustrations I've seen aired on the list, and which I may
have overinterpreted; I was not referring to sage-newbie, because it
was clear what happened there.  The references to "brusque" and
"trivial questions" were intended to be hyperbolic.  Ah, electronic
communication - nothing like it :)

In general I tried very hard to use terms like "many" and "likely",
precisely because I know how many different situations there were, and
wanted to make it clear I was generalizing only in a limited fashion,
but still hoping to raise an important issue.  In fact, I agreed with
most of the (nontechnical) things mabshoff said, though the place I
said that may have gotten obscured.  Sage is definitely healthy,
definitely friendly, definitely catches tons of bugs (which I do
explicitly say), and definitely has the potential to involve lots of
education people beyond what it has - precisely because of the
relatively unified nature of mathematics, which is so immensely
salutary.

The reason I refer to different roadblocks and things like where
people are employed is because I want that to succeed, and I have been
very proactive in promoting Sage where I can.  I do not see any viable
open-source competitor, and it is neat to read about where Sage also
beats the proprietary competition.  But my main point remains - and I
would welcome suggestions on sage-edu - that there is a difference in
kind between the research environment and the teaching one.

A research mathematician likely has time, resources, and vision for
implementing research-related code *largely on her own* with help from
lists or IRC if determined, and hence will be able to develop the
expertise, and all this falls squarely in her duties.  This isn't
always true, but it is likely, if she is determined.  (Presumably
Jason, as a grad student and postdoc at PhD-granting institutions, is
in this category, and David's expertise is of course long-standing.)

It is also likely that a teaching-focused mathematician has only two
of the three, if he is lucky, and may not get much support from
administration for developing the others, and hence won't be able to,
even if determined.  This isn't always true, but is likely, especially
if he is earnest in devoting attention to the students who would
benefit from Sage in the first place.  (I think my chair is in this
situation, as he's installed Sage on our local server, but has had
difficulty getting octave to play nicely with Sage where he wants it
to.  I have told him to email sage-support more times than I can
count, because there is probably an easy solution, but I think
realistically he just made a choice to not try further as the semester
started.  This is fine - not everyone has to use Sage - but he is also
someone with a lot of experience in mathematical computation and
server administration, so it gives me some pause as to my own ability
to do something significant without guidance.)

I totally hear you on the political aspect of educational grant-
seeking.  Maybe a friend of Sage would have a friend who has been
successful in that arena and could consult or even advocate for Sage?
I see many projects which, while useful, are not just not in the same
league as Sage, but maybe like AA baseball (or Landesliga, for that
matter) compared to the pros, yet which routinely get NSF CCLI grants
and supplements.

Anyway, it's possible that this is really all inherent, which would be
too bad, but sometimes things are like that.  I thought I'd raise it,
though.  If Sage could have even half as many education-focused
developers (which I am sadly not, at least not yet) as it has research
or internals developers, even if they aren't as competent, Sage should
easily be able to surpass the competition in that arena as well.

Thanks as always for a fantastic product, and thanks for the continued
invigorating discussion. (No irony intended!)

- kcrisman
--~--~-~--~~~---~--~~
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-2.10.2

[mabshoff]

On Feb 23, 3:48 am, "William Stein" <[EMAIL PROTECTED]> wrote:
> Hello folks,
>
> Sage 2.10.2 has been released on February 23nd, 2008. It is available at
>
>http://sagemath.org/download.html


Those of you who want to bundle patches against 2.10.2 be warned that
currently the repo at sagemath.org hasn't been updated yet, i.e. the
bundles you will create will have all changes from 2.10.1->2.10.2 in
it. Consequently you will be unable to attach them to any trac ticket
due to its size, i.e. roughly 490 KB!

Cheers,

Michael
--~--~-~--~~~---~--~~
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] some more entries for sagemath.org/pub.html

[Alex Ghitza]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Patrick Ingram, http://arxiv.org/abs/0802.2651";>Multiples of
integral points on elliptic curves (29 pages), 2008.

Nicholas J. Cavenagh, Carlo Hamalainen, Adrian M. Nelson, http://arxiv.org/abs/0712.0233";>On completing three cyclic
transversals to a latin square (13 pages), 2007.

Chris A. Kurth, Ling Long, http://arxiv.org/abs/0710.1835";>Computations with finite index
subgroups of $PSL_2(\mathbb Z)$ using Farey symbols (16 pages), 2007.

David Harvey, http://arxiv.org/abs/0708.3404";>Efficient
computation of p-adic heights (18 pages), 2007.

David Harvey, http://arxiv.org/abs/math/0610973";>Kedlaya's
algorithm in larger characteristic (21 pages), 2006.

John Voight, http://arxiv.org/abs/0802.0194";>Enumeration of
totally real number fields of bounded root discriminant (14 pages),
2008.

David Loeffler, http://arxiv.org/abs/0801.3176";>Explicit
calculations of automorphic forms for definite unitary groups (19
pages), 2008.

Jonathan Sondow, Kyle Schalm, http://arxiv.org/abs/0709.0671";>Which partial sums of the Taylor
series for $e$ are convergents to $e$? (and a link to the primes 2, 5,
13, 37, 463) (13 pages), 2007.






- --
Alexandru Ghitza
Assistant Professor
Department of Mathematics
Colby College
Waterville, ME 04901
http://bayes.colby.edu/~ghitza/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHwDzDdZTaNFFPILgRAiwRAJwMEsSvRhefdgjalS11nyekdvsvnQCfUJ4X
YxBcJDwX8ACy30T8kP5fV+k=
=2BrF
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
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: some more entries for sagemath.org/pub.html

[David Harvey]

On Feb 23, 2008, at 10:33 AM, Alex Ghitza wrote:

> David Harvey, http://arxiv.org/abs/0708.3404";>Efficient
> computation of p-adic heights (18 pages), 2007.

This will appear soon in LMS JCM.

http://www.lms.ac.uk/jcm/

> David Harvey, http://arxiv.org/abs/math/0610973";>Kedlaya's
> algorithm in larger characteristic (21 pages), 2006.

This was published in IMRN:

http://imrn.oxfordjournals.org/cgi/content/abstract/2007/rnm095/rnm095

david


--~--~-~--~~~---~--~~
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-2.10.2

[William Stein]

On Sat, Feb 23, 2008 at 7:21 AM, mabshoff <[EMAIL PROTECTED]> wrote:
>
>
>
>  On Feb 23, 3:48 am, "William Stein" <[EMAIL PROTECTED]> wrote:
>  > Hello folks,
>  >
>  > Sage 2.10.2 has been released on February 23nd, 2008. It is available at
>  >
>  >http://sagemath.org/download.html
>  
>
>  Those of you who want to bundle patches against 2.10.2 be warned that
>  currently the repo at sagemath.org hasn't been updated yet, i.e. the
>  bundles you will create will have all changes from 2.10.1->2.10.2 in
>  it. Consequently you will be unable to attach them to any trac ticket
>  due to its size, i.e. roughly 490 KB!

Don't worry, I just updated the default repo's at sagemath.org.

William

--~--~-~--~~~---~--~~
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-2.10.2

[Hector Villafuerte]

On Sat, Feb 23, 2008 at 10:17 AM, William Stein <[EMAIL PROTECTED]> wrote:
>
>  On Sat, Feb 23, 2008 at 7:21 AM, mabshoff <[EMAIL PROTECTED]> wrote:
>  >
>  >
>  >
>  >  On Feb 23, 3:48 am, "William Stein" <[EMAIL PROTECTED]> wrote:
>  >  > Hello folks,
>  >  >
>  >  > Sage 2.10.2 has been released on February 23nd, 2008. It is available at
>  >  >
>  >  >http://sagemath.org/download.html
>  >  
>  >
>  >  Those of you who want to bundle patches against 2.10.2 be warned that
>  >  currently the repo at sagemath.org hasn't been updated yet, i.e. the
>  >  bundles you will create will have all changes from 2.10.1->2.10.2 in
>  >  it. Consequently you will be unable to attach them to any trac ticket
>  >  due to its size, i.e. roughly 490 KB!
>
>  Don't worry, I just updated the default repo's at sagemath.org.
>
>  William

I just noticed that the binary downloads for sage-2.10.2 haven't been
updated, just the source code is available.
Best,
-- 
 Hector

--~--~-~--~~~---~--~~
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-2.10.2

[mabshoff]

Hi Hector,

> I just noticed that the binary downloads for sage-2.10.2 haven't been
> updated, just the source code is available.
> Best,
> --
>  Hector

it always takes a while (roughly up to a day) for the binaries to be
build, tested and uploaded to the sagemath.org. So they should appear
this evening.

Cheers,

Michael
--~--~-~--~~~---~--~~
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-edu, standard API, etc.

[alex clemesha]

On Sat, Feb 23, 2008 at 12:02 AM, didier deshommes <[EMAIL PROTECTED]>
wrote:

>
> On Fri, Feb 22, 2008 at 5:57 PM, alex clemesha <[EMAIL PROTECTED]> wrote:
> > In Knoboo we *decouple* the idea of a kernel, it could be another
> > Python (Sage) process, with communication through Pexpect
> >
> > ... but it also couple be another Python (Sage) process running a very
> > minimal XML-RPC server, and all communication occurs through
> >  *** HTTP instead of Pexpect ***.
>
> I personally am not too familiar with web development, so it's always
> great to hear from someone who has (which is exactly why this
> discussion was started). Regarding XML-RPC vs Pexpect:
>  - how slow is one compared to the other?  I expect xml-rpc to be
> slower, but not so slow to render it unusable.


I would say that it is even faster than how the current Sage notebook
does its process of compiling scripts to be passed back and forth with
Pexpect.

But in reality, both methods of communication, in most cases,
are sub-second and constant, so this is mostly a complete non-issue.


> - I understand xml-rpc working for inter-communication, ie SAGE ->
> outside world, but I don't see how it would work for
> intra-communication, SAGE -> maxima. Maxima would have to be already
> running in the background, right? If that is the case, then every sage
> session would have to spawn singular, maxima, maple, etc sessions at
> start-up. I don't like that. Is there something I'm not getting here?


Sage intra-communication would stay exactly the same.  The way that
works (pseudo-tty) won't be changing any time soon (ever?).
It's fundamental to how Sage encapsulates all it's external programs.

Behind the scenes, when you use a function that requires,
for example, singular or maxima to be used, then that new process
would start only when you call that function, not at startup,
which is already a working, built in part of Sage.

The method of using some light-weight RPC server,
(could be Python's built in XML-RPC server, could be a DSage instance, etc)
to act as the running namespace for a notebook is almost identical
to how the Sage notebook uses it's separate processes for each notebook,
it's just that communication to the *outside world* is done with
standard RPC methods instead of with a psuedo-tty (Pexpect).  This is the
key point.

By using standard RPC methods,
(which by the way is the bread and butter of most web services, regardless
of programming language)
to communicate with the running Sage process,
you can then support some API which others can use too.

-Alex









>
> didier
>
> >
>

--~--~-~--~~~---~--~~
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] harmonizing derivatives of symbolic expressions and polynomials

[Carl Witty]

Currently, symbolic expressions have 3 identical "derivative"
methods: .derivative(), .diff(), and .differentiate() (that is, they
are aliases of each other).  These have a powerful argument list;
foo.diff(x, 3, y, z, 2) differentiates three times with respect to x,
then once with respect to y, then twice with respect to z.  (And if
foo contains only one variable, then foo.diff() differentiates with
respect to that variable.)

Polynomials (both univariate and multivariate) have a .diff() method,
which takes a required variable argument; univariate polynomials also
have a .derivative() method, which does not take an argument.

There are also global functions diff(), differentiate(), and
derivative(), which are basically wrappers for the .derivative()
method: diff(foo, ...) is equivalient to foo.derivative(...).

1) Do we really need three names for this concept?  Could we get rid
of one or two?  If so, can we just remove it, or do we need some sort
of deprecation procedure?

2) I plan to make the polynomial methods match the symbolic expression
methods.  (This should be backward-compatible.)  Any objections?

Carl

--~--~-~--~~~---~--~~
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: harmonizing derivatives of symbolic expressions and polynomials

[Alex Ghitza]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I was going to point to trac tickets and comments by David Harvey, but
he beat me to the punch :)

Since I agree with what he already said, I'll just address one point:

Carl Witty wrote:
| 1) Do we really need three names for this concept?  Could we get rid
| of one or two?  If so, can we just remove it, or do we need some sort
| of deprecation procedure?

I vote in favor of keeping only one method name.  I prefer derivative()
over the other two, but I won't be too devastated if it's not the one
picked.


Best,
Alex


- --
Alexandru Ghitza
Assistant Professor
Department of Mathematics
Colby College
Waterville, ME 04901
http://bayes.colby.edu/~ghitza/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHwGLgdZTaNFFPILgRAjPgAKCA2It/swAG6+D38z1sqEGNlDfyRwCgm0MD
M/9BnqqJswvpKMiTWVCedP8=
=Chq+
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
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: harmonizing derivatives of symbolic expressions and polynomials

[David Harvey]

On Feb 23, 2008, at 1:03 PM, Carl Witty wrote:

> Currently, symbolic expressions have 3 identical "derivative"
> methods: .derivative(), .diff(), and .differentiate() (that is, they
> are aliases of each other).  These have a powerful argument list;
> foo.diff(x, 3, y, z, 2) differentiates three times with respect to x,
> then once with respect to y, then twice with respect to z.  (And if
> foo contains only one variable, then foo.diff() differentiates with
> respect to that variable.)
>
> Polynomials (both univariate and multivariate) have a .diff() method,
> which takes a required variable argument; univariate polynomials also
> have a .derivative() method, which does not take an argument.
>
> There are also global functions diff(), differentiate(), and
> derivative(), which are basically wrappers for the .derivative()
> method: diff(foo, ...) is equivalient to foo.derivative(...).
>
> 1) Do we really need three names for this concept?  Could we get rid
> of one or two?  If so, can we just remove it, or do we need some sort
> of deprecation procedure?
>
> 2) I plan to make the polynomial methods match the symbolic expression
> methods.  (This should be backward-compatible.)  Any objections?

Carl, I'm glad you've brought this up now, I was planning to take  
this on myself in the next few days. I strongly agree everything  
should be harmonised.

Here are several related tickets:

http://trac.sagemath.org/sage_trac/ticket/756
http://trac.sagemath.org/sage_trac/ticket/753
http://trac.sagemath.org/sage_trac/ticket/1578

david


--~--~-~--~~~---~--~~
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-2.10.2

[Hector Villafuerte]

On Sat, Feb 23, 2008 at 11:26 AM, mabshoff <[EMAIL PROTECTED]> wrote:
...
>  it always takes a while (roughly up to a day) for the binaries to be
>  build, tested and uploaded to the sagemath.org. So they should appear
>  this evening.
>
>  Cheers,
>
>  Michael

I see. Thanks for letting me know, Michael!
-- 
 Hector

--~--~-~--~~~---~--~~
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-edu, standard API, etc.

[William Stein]

On Sat, Feb 23, 2008 at 9:39 AM, alex clemesha <[EMAIL PROTECTED]> wrote:
>
>
>
> On Sat, Feb 23, 2008 at 12:02 AM, didier deshommes <[EMAIL PROTECTED]>
> wrote:
> >
> >
> > On Fri, Feb 22, 2008 at 5:57 PM, alex clemesha <[EMAIL PROTECTED]> wrote:
> > > In Knoboo we *decouple* the idea of a kernel, it could be another
> > > Python (Sage) process, with communication through Pexpect
> > >
> > > ... but it also couple be another Python (Sage) process running a very
> > > minimal XML-RPC server, and all communication occurs through
> > >  *** HTTP instead of Pexpect ***.
> >
> > I personally am not too familiar with web development, so it's always
> > great to hear from someone who has (which is exactly why this
> > discussion was started). Regarding XML-RPC vs Pexpect:
> >  - how slow is one compared to the other?  I expect xml-rpc to be
> > slower, but not so slow to render it unusable.
>
> I would say that it is even faster than how the current Sage notebook
> does its process of compiling scripts to be passed back and forth with
> Pexpect.
>
> But in reality, both methods of communication, in most cases,
> are sub-second and constant, so this is mostly a complete non-issue.

I'm actually pretty curious about how pexpect and XMLRPC both
done locally compare speedwise.  I've done some simple benchmarks
below.  The short answer is that pexpect is between several hundred
to several thousand times faster than XMLRPC, depending on the
platform.

Here's a good pexpect benchmark to do in sage-2.10.2:

sage: gp('2+2')
4
sage: timeit("gp.eval('2+2')")
625 loops, best of 3: 136 µs per loop

This benchmarks adding 2 and 2 over the pexpect interface
to pari and getting back the result.  It takes 136 microseconds
to do that on my OS X 10.5 intel 2.6Ghz computer.  On sage.math
it's about 500 times faster, only 303 nanoseconds:

sage: timeit(gp.eval('2+2'))
625 loops, best of 3: 303 ns per loop

Pexpect may have a reputation for being "dog slow", but on small
transactions it's actually surprisingly fast.  Seriously.  It's only bad
when the input is large.


Now let's try xmlrpc (with Yi's help).  Copy in the setup from
   http://docs.python.org/lib/simple-xmlrpc-servers.html
then time adding two integers (we put an r after them below
so that they are *Python* integers, which avoid preparsing):

On my 2.6Ghz Intel OS X computer:

sage: timeit('s.add(2r,3r)')
25 loops, best of 3: 43.7 ms per loop

On sage.math:
sage: timeit('s.add(2r,3r)')
625 loops, best of 3: 1.38 ms per loop

So let's compare:

On OS X 2.6Ghz machine pexpect is 321 times faster
than XMLRPC:
sage: 43.7 / (136 * 10^(-3))
321.323529411765

On sage.math pexpect is 4554 times faster than XMLRPC:
sage: 1.38 / (303 * 10^(-6))
4554.45544554455

Obviously there may be tricks for speeding up XMLRPC (and
for speeding up pexpect), and I would really love for an expert
in XMLRPC to retry the above benchmarks but with their tricks.
However, XMLRPC is using the TCP/IP networking stack, and
probably will have to use encryption if we're to do this seriously,
whereas pexpect is just all happening in RAM (vis unix named
pipes), so it's maybe not surprising that pexpect would
have a big advantage speedwise.

>
>
> >
> > - I understand xml-rpc working for inter-communication, ie SAGE ->
> > outside world, but I don't see how it would work for
> > intra-communication, SAGE -> maxima. Maxima would have to be already
> > running in the background, right? If that is the case, then every sage
> > session would have to spawn singular, maxima, maple, etc sessions at
> > start-up. I don't like that. Is there something I'm not getting here?
>
> Sage intra-communication would stay exactly the same.  The way that
> works (pseudo-tty) won't be changing any time soon (ever?).

It may change for MS Windows; I don't know.  Windows doesn't suppose
pseudo-tty's so well (?), so we may have to come up with a new approach
there, since now we're serious about fully porting Sage to Windows.

>  It's fundamental to how Sage encapsulates all it's external programs.
>
> Behind the scenes, when you use a function that requires,
> for example, singular or maxima to be used, then that new process
> would start only when you call that function, not at startup,
>  which is already a working, built in part of Sage.

Yep.

> The method of using some light-weight RPC server,
> (could be Python's built in XML-RPC server, could be a DSage instance, etc)
> to act as the running namespace for a notebook is almost identical
>  to how the Sage notebook uses it's separate processes for each notebook,
> it's just that communication to the *outside world* is done with
> standard RPC methods instead of with a psuedo-tty (Pexpect).  This is the
> key point.

Very clear explanation.  And yes, I think XML-RPC is a good
external API for Python to talk to other programs.  And it's already
done -- we don't have to write anything -- it's been done for years.
And it's completely "industry standard".

> By using standard RPC

[sage-devel] more numerical noise?

[John Cremona]

A fresh 64-bit install of 2.10.2 have this (and only this) error with
"make check":

sage -t  
devel/sage-main/sage/rings/number_field/totallyreal.py**
File "totallyreal.py", line 410:
sage: sage.rings.number_field.totallyreal.__selberg_zograf_bound(8,7)
Expected:
15.851871776151311
Got:
15.851871776151313
**
1 items had failures:
   1 of   1 in __main__.example_5
***Test Failed*** 1 failures.
For whitespace errors, see the file .doctest_totallyreal.py
 [1.7 s]
exit code: 256

--
The following tests failed:


sage -t  devel/sage-main/sage/rings/number_field/totallyreal.py


I could not find a ticket for this but was surprised that it was not
caught by someone before.

John

-- 
John Cremona

--~--~-~--~~~---~--~~
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: more numerical noise?

[William Stein]

On Sat, Feb 23, 2008 at 10:55 AM, John Cremona <[EMAIL PROTECTED]> wrote:
>
>  A fresh 64-bit install of 2.10.2 have this (and only this) error with
>  "make check":
>
>  sage -t  
> devel/sage-main/sage/rings/number_field/totallyreal.py**
>  File "totallyreal.py", line 410:
> sage: sage.rings.number_field.totallyreal.__selberg_zograf_bound(8,7)
>  Expected:
> 15.851871776151311
>  Got:
> 15.851871776151313
>  **
>  1 items had failures:
>1 of   1 in __main__.example_5
>  ***Test Failed*** 1 failures.
>  For whitespace errors, see the file .doctest_totallyreal.py
>  [1.7 s]
>  exit code: 256
>
>  --
>  The following tests failed:
>
>
> sage -t  devel/sage-main/sage/rings/number_field/totallyreal.py
>
>
>  I could not find a ticket for this but was surprised that it was not
>  caught by someone before.

I have at least 9 test machines, including 3 64-bit linux machines,
and the above error doesn't happen on any of them.   In fact
"All tests pass" on all of my machines.  So it's probably fairly
architecture specific?  What *exactly* are you using?  OS, hardware,
etc.?

 -- William

--~--~-~--~~~---~--~~
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: exact cover problem

[Carlo Hamalainen]

On Fri, Feb 22, 2008 at 8:55 PM,  <[EMAIL PROTECTED]> wrote:
>  Arguments for including Ajanki's code:
> 1) It's the only Python implementation of DLX I've seen.
> 2) I emailed the author, who happily added the "or later" bit after the 
> GPL2
> 3) With my Sage Matrix -> DLXMatrix code (plus docstrings to everything I 
> added), the file dlx.py is only 8kB!
> 4) It will resolve tickets #1311 and #1313

This afternoon I wrote some code to get completions of partial latin
squares using Ajanki's DLX code (this is basically the same as solving
a Sudoku puzzle, minus a few constraints because latin squares don't
have the 3x3 blocks).

I discovered that the main function, dosearch(), uses recursion, and
Python's recursion limit is reached quite easily (e.g. finding a
completion of a 16x16 partial latin square blows up). Knuth's original
implementation in C avoided recursion by using an array to simulate a
stack, and looping uses goto statements, and so it can be run on quite
large problem instances. As a side benefit there is no function call
overhead in the main part of the algorithm.

I have been using my own implementation of DLX in C++ for a while now
and I've found it very useful, so I'm all for the algorithm getting
into Sage. I can see a few ways forward:

(1) Rewrite Ajanki's code to avoid the recursion limit. The problem
here is that Python doesn't have 'goto'. Can the recursion limit be
dealt with in some other way?

(2) Write a wrapper for an implementation in C++. I'm happy to make my
code GPL and I'm also happy to write a wrapper once I get my head
around cython/pyrex.

(3) Write the algorithm from scratch in Cython. Does Cython have goto?

Cheers,

-- 
Carlo Hamalainen
http://carlo-hamalainen.net

--~--~-~--~~~---~--~~
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: more numerical noise?

[mabshoff]

On Feb 23, 8:03 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> On Sat, Feb 23, 2008 at 10:55 AM, John Cremona <[EMAIL PROTECTED]> wrote:
>
> >  A fresh 64-bit install of 2.10.2 have this (and only this) error with
> >  "make check":
>
> >  sage -t  
> > devel/sage-main/sage/rings/number_field/totallyreal.py**
> >  File "totallyreal.py", line 410:
> > sage: sage.rings.number_field.totallyreal.__selberg_zograf_bound(8,7)
> >  Expected:
> > 15.851871776151311
> >  Got:
> > 15.851871776151313
> >  **
> >  1 items had failures:
> >1 of   1 in __main__.example_5
> >  ***Test Failed*** 1 failures.
> >  For whitespace errors, see the file .doctest_totallyreal.py
> >  [1.7 s]
> >  exit code: 256
>
> >  --
> >  The following tests failed:
>
> > sage -t  devel/sage-main/sage/rings/number_field/totallyreal.py
>
> >  I could not find a ticket for this but was surprised that it was not
> >  caught by someone before.
>
> I have at least 9 test machines, including 3 64-bit linux machines,
> and the above error doesn't happen on any of them.   In fact
> "All tests pass" on all of my machines.  So it's probably fairly
> architecture specific?  What *exactly* are you using?  OS, hardware,
> etc.?

A different compiler can make all the difference, even on the same
hardware. So this is a legitimate issue and ought to be fixed. John,
please open a ticket and I am sure  you can post the trivial patch.

>  -- William

Cheers,

Michael
--~--~-~--~~~---~--~~
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: more numerical noise?

[William Stein]

On Sat, Feb 23, 2008 at 11:07 AM, mabshoff <[EMAIL PROTECTED]> wrote:
>
>
>
>  On Feb 23, 8:03 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
>
>
> > On Sat, Feb 23, 2008 at 10:55 AM, John Cremona <[EMAIL PROTECTED]> wrote:
>  >
>  > >  A fresh 64-bit install of 2.10.2 have this (and only this) error with
>  > >  "make check":
>  >
>  > >  sage -t  
> devel/sage-main/sage/rings/number_field/totallyreal.py**
>  > >  File "totallyreal.py", line 410:
>  > > sage: sage.rings.number_field.totallyreal.__selberg_zograf_bound(8,7)
>  > >  Expected:
>  > > 15.851871776151311
>  > >  Got:
>  > > 15.851871776151313
>  > >  **
>  > >  1 items had failures:
>  > >1 of   1 in __main__.example_5
>  > >  ***Test Failed*** 1 failures.
>  > >  For whitespace errors, see the file .doctest_totallyreal.py
>  > >  [1.7 s]
>  > >  exit code: 256
>  >
>  > >  --
>  > >  The following tests failed:
>  >
>  > > sage -t  devel/sage-main/sage/rings/number_field/totallyreal.py
>  >
>  > >  I could not find a ticket for this but was surprised that it was not
>  > >  caught by someone before.
>  >
>  > I have at least 9 test machines, including 3 64-bit linux machines,
>  > and the above error doesn't happen on any of them.   In fact
>  > "All tests pass" on all of my machines.  So it's probably fairly
>  > architecture specific?  What *exactly* are you using?  OS, hardware,
>  > etc.?
>
>  A different compiler can make all the difference, even on the same
>  hardware. So this is a legitimate issue and ought to be fixed. John,
>  please open a ticket and I am sure  you can post the trivial patch.

I'm sorry -- I definitely *do* think it is a legitimate issue that ought
to be fixed.  I'm just really curious about what is different.

John -- I definitely didn't mean to dismiss your issue as not legitimate,
and greatly appreciate that your posted about it!!

 -- William

--~--~-~--~~~---~--~~
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: harmonizing derivatives of symbolic expressions and polynomials

[David Harvey]

okay I made a list of all diff() and derivative() and  
differentiate() functions that we should probably be caring about for  
this issue. The list does not include aliases.


functions/elementary.py
 class ElementaryFunction_class(CommutativeRingElement):
 def differentiate(self,verbose=None):

interfaces/maxima.py
 class MaximaElement(ExpectElement):
 def diff(self, var='x', n=1):

calculus/calculus.py
 class SymbolicExpression(RingElement):
 def derivative(self, *args):

 class Symbolic_object(SymbolicExpression):
 #def derivative(self, *args):

calculus/functional.py
 def derivative(f, *args, **kwds):

functions/piecewise.py
 class PiecewisePolynomial:
 def derivative(self):

rings/polynomial/polynomial_modn_dense_ntl.pyx
 cdef class Polynomial_dense_mod_n(Polynomial):
 def diff(self, variable, have_ring=False):

rings/polynomial/multi_polynomial_libsingular.pyx
 cdef class MPolynomial_libsingular 
(sage.rings.polynomial.multi_polynomial.MPolynomial):
 def diff(self, MPolynomial_libsingular variable,  
have_ring=True):

rings/polynomial/polynomial_singular_interface.py
 class Polynomial_singular_repr:
 def diff(self, variable, have_ring=False):

misc/functional.py
 def derivative(x):

rings/laurent_series_ring_element.pyx
 cdef class LaurentSeries(AlgebraElement):
 def derivative(self):

rings/polynomial/polynomial_element.pyx
 cdef class Polynomial(CommutativeAlgebraElement):
 def derivative(self):

rings/polynomial/polynomial_element_generic.py
 class Polynomial_generic_sparse(Polynomial):
 def derivative(self):

rings/polynomial/polynomial_modn_dense_ntl.pyx
 cdef class Polynomial_dense_mod_n(Polynomial):
 def derivative(self):
 cdef class Polynomial_dense_modn_ntl_zz(Polynomial_dense_mod_n):
 def derivative(self):

rings/power_series_poly.pyx
 cdef class PowerSeries_poly(PowerSeries):
 def derivative(self):

rings/power_series_ring_element.pyx
 cdef class PowerSeries(AlgebraElement):
 def derivative(self):

rings/sparse_poly.pyx
 cdef class Polynomial:
 def derivative(self):



There's also stuff in the following files which we probably shouldn't  
worry about:

libs/ntl/ntl_GF2X.pyx
libs/ntl/ntl_lzz_pX.pyx
libs/ntl/ntl_ZZ_pEX.pyx
libs/ntl/ntl_ZZ_pX.pyx
libs/ntl/ntl_ZZX.pyx
schemes/elliptic_curves/monsky_washnitzer.py
lfunctions/dokchitser.py

david


--~--~-~--~~~---~--~~
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-2.10.2

[mhampton]

I am having trouble as described in trac # 2003; I had the same
problem with 2.10.1 but I don't have a serious reason to use the
latest sage on my laptop, so I just waited and hoped it would get
fixed for 2.10.2.

I tried changing my path to something pretty minimal but I am still
having this problem.  Any suggestions?

-M. Hampton

On Feb 23, 9:21 am, mabshoff <[EMAIL PROTECTED]> wrote:
> On Feb 23, 3:48 am, "William Stein" <[EMAIL PROTECTED]> wrote:> Hello folks,
>
> > Sage 2.10.2 has been released on February 23nd, 2008. It is available at
>
> >http://sagemath.org/download.html
>
> 
>
> Those of you who want to bundle patches against 2.10.2 be warned that
> currently the repo at sagemath.org hasn't been updated yet, i.e. the
> bundles you will create will have all changes from 2.10.1->2.10.2 in
> it. Consequently you will be unable to attach them to any trac ticket
> due to its size, i.e. roughly 490 KB!
>
> Cheers,
>
> Michael
--~--~-~--~~~---~--~~
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] first stab at #1422 (add bibtex function to get citation for Sage components)

[Alex Ghitza]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi folks,

I made a first attempt at a bibtex() function for citing Sage
components.  It returns a string containing either the citation
information in bibtex database format (i.e. what you would put in a .bib
file) or in bibliography format (i.e. what you would put directly in a
.tex file if you didn't want to bother with bibtex).

Before I go on and put in the info for the various components, I'd
appreciate it if people could take a look at it and comment on

1. whether it does what you want it to do
2. whether the code looks ok
3. miscellaneous

(as an example of 3., I'd like to hear suggestions on the best way to
get the volatile information like the version number from sage instead
of hard-coding it in bibtex.py).

I'm attaching the patch (made against sage-2.10.2) to this email.

Best,
Alex

- --
Alexandru Ghitza
Assistant Professor
Department of Mathematics
Colby College
Waterville, ME 04901
http://bayes.colby.edu/~ghitza/



-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHwHjndZTaNFFPILgRAhRvAJ9XGG1achIql69hSWTDyFngDmzD2wCgqVj5
J4xkukNDFoVkpL9ZtlGU5iA=
=7dS/
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

# HG changeset patch
# User Alexandru Ghitza <[EMAIL PROTECTED]>
# Date 1203795825 18000
# Node ID c837c13f9ef1f893c4d0430475b2931612a3d9b5
# Parent  59538ebc8f3bc9e36d8e847c5c15a8cad5a90791
generate bibtex code for citing the sage components

diff -r 59538ebc8f3b -r c837c13f9ef1 sage/misc/all.py
--- a/sage/misc/all.py  Fri Feb 22 18:45:11 2008 -0800
+++ b/sage/misc/all.py  Sat Feb 23 14:43:45 2008 -0500
@@ -139,6 +139,8 @@ from functional import (additive_order,
 
 
 from latex import latex, view, pretty_print, pretty_print_default, jsmath
+
+from bibtex import bibtex
  
 # disabled -- nobody uses mathml
 #from mathml ml
diff -r 59538ebc8f3b -r c837c13f9ef1 sage/misc/bibtex.py
--- /dev/null   Thu Jan 01 00:00:00 1970 +
+++ b/sage/misc/bibtex.py   Sat Feb 23 14:43:45 2008 -0500
@@ -0,0 +1,207 @@
+"""
+BibTeX support for producing citations for Sage components
+
+"""
+
+#*
+#
+#   SAGE: System for Algebra and Geometry Experimentation
+#
+#   Copyright (C) 2008 Alexandru Ghitza <[EMAIL PROTECTED]>
+#   Copyright (C) 2008 William Stein <[EMAIL PROTECTED]>
+#
+#  Distributed under the terms of the GNU General Public License (GPL)
+#
+#This code is distributed in the hope that it will be useful,
+#but WITHOUT ANY WARRANTY; without even the implied warranty of
+#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+#General Public License for more details.
+#
+#  The full text of the GPL is available at:
+#
+#  http://www.gnu.org/licenses/
+#*
+
+
+key_dict = {
+'pari': 'PARI2',
+'sage': 'Sage',
+'singular': 'GPS07',
+'_test': 'Test',
+}
+
+title_dict = {
+'pari': 'PARI/GP',
+'sage': '{S}age {M}athematics {S}oftware',
+'singular': 'Singular. A Computer Algebra System for Polynomial 
Computations',
+'_test': 'Just a Test, Nothing More',
+}
+
+version_dict = {
+'pari': '2.3.3',
+'sage': '2.10.2',
+'singular': '3.0.4.1',
+'_test': '99.1.alpha',
+}
+
+author_dict = {
+'sage': 'William Stein',
+'singular': r'G.-M. Greuel and G. Pfister and H. Sch\"onemann',
+'_test': 'John Doe',
+}
+
+author_compiled_dict = {
+'sage': 'Stein, William',
+'singular': r'G.-M.~Greuel, G.~Pfister, and H.~Sch\"onemann',
+'_test': 'Doe, John',
+}
+
+organization_dict = {
+'pari': 'The PARI~Group',
+'sage': 'The Sage~Group',
+'singular': 'Centre for Computer Algebra',
+'_test': 'ACME Test Group',
+}
+
+url_dict = {
+'pari': 'http://pari.math.u-bordeaux.fr/',
+'sage': 'http://www.sagemath.org',
+'singular': 'http://www.singular.uni-kl.de',
+}
+
+note_dict = {
+'pari': 'Available from',
+'_test': 'Available nowhere',
+}
+
+address_dict = {
+'pari': 'Bordeaux',
+'singular': 'University of Kaiserslautern',
+}
+
+year_dict = {
+'pari': '2007',
+'sage': '2008',
+'singular': '2007',
+'_test': '2008',
+}
+
+
+def bibtex(component = 'sage', compiled = False):
+"""
+Return the citation information for the desired component of Sage.
+
+If the flag "compiled" is False (default), the citation is
+returned formatted as a BibTeX database entry, for inclusion
+in a .bib file.  If the flag "co

[sage-devel] Re: more numerical noise?

[John Cremona]

I did not interpret the response as dismissive!  The OS and compiler
details are posted on trac 2279.  (64-bit Suse, gcc 4.1.2).

John

On 23/02/2008, mabshoff <[EMAIL PROTECTED]> wrote:
>
>
>
>  On Feb 23, 8:03 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
>
> > On Sat, Feb 23, 2008 at 10:55 AM, John Cremona <[EMAIL PROTECTED]> wrote:
>  >
>  > >  A fresh 64-bit install of 2.10.2 have this (and only this) error with
>  > >  "make check":
>  >
>  > >  sage -t  
> devel/sage-main/sage/rings/number_field/totallyreal.py**
>  > >  File "totallyreal.py", line 410:
>  > > sage: sage.rings.number_field.totallyreal.__selberg_zograf_bound(8,7)
>  > >  Expected:
>  > > 15.851871776151311
>  > >  Got:
>  > > 15.851871776151313
>  > >  **
>  > >  1 items had failures:
>  > >1 of   1 in __main__.example_5
>  > >  ***Test Failed*** 1 failures.
>  > >  For whitespace errors, see the file .doctest_totallyreal.py
>  > >  [1.7 s]
>  > >  exit code: 256
>  >
>  > >  --
>  > >  The following tests failed:
>  >
>  > > sage -t  devel/sage-main/sage/rings/number_field/totallyreal.py
>  >
>  > >  I could not find a ticket for this but was surprised that it was not
>  > >  caught by someone before.
>  >
>  > I have at least 9 test machines, including 3 64-bit linux machines,
>  > and the above error doesn't happen on any of them.   In fact
>  > "All tests pass" on all of my machines.  So it's probably fairly
>  > architecture specific?  What *exactly* are you using?  OS, hardware,
>  > etc.?
>
>
> A different compiler can make all the difference, even on the same
>  hardware. So this is a legitimate issue and ought to be fixed. John,
>  please open a ticket and I am sure  you can post the trivial patch.
>
>  >  -- William
>
>  Cheers,
>
>  Michael
>
> >
>


-- 
John Cremona

--~--~-~--~~~---~--~~
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: exact cover problem

[boothby]

On Sat, 23 Feb 2008, Carlo Hamalainen wrote:

>
> On Fri, Feb 22, 2008 at 8:55 PM,  <[EMAIL PROTECTED]> wrote:
>>  Arguments for including Ajanki's code:
>> 1) It's the only Python implementation of DLX I've seen.
>> 2) I emailed the author, who happily added the "or later" bit after the 
>> GPL2
>> 3) With my Sage Matrix -> DLXMatrix code (plus docstrings to everything 
>> I added), the file dlx.py is only 8kB!
>> 4) It will resolve tickets #1311 and #1313
>
> This afternoon I wrote some code to get completions of partial latin
> squares using Ajanki's DLX code (this is basically the same as solving
> a Sudoku puzzle, minus a few constraints because latin squares don't
> have the 3x3 blocks).
>
> I discovered that the main function, dosearch(), uses recursion, and
> Python's recursion limit is reached quite easily (e.g. finding a
> completion of a 16x16 partial latin square blows up). Knuth's original
> implementation in C avoided recursion by using an array to simulate a
> stack, and looping uses goto statements, and so it can be run on quite
> large problem instances. As a side benefit there is no function call
> overhead in the main part of the algorithm.
>
> I have been using my own implementation of DLX in C++ for a while now
> and I've found it very useful, so I'm all for the algorithm getting
> into Sage. I can see a few ways forward:
>
> (1) Rewrite Ajanki's code to avoid the recursion limit. The problem
> here is that Python doesn't have 'goto'. Can the recursion limit be
> dealt with in some other way?

Yes, I've devoted some thought to this -- we can remove the recursion by using 
a stack.  This shouldn't be too hard.  But why do you want a "goto"?  That's 
like duct-taping your car door shut when the latch works fine.

> (2) Write a wrapper for an implementation in C++. I'm happy to make my
> code GPL and I'm also happy to write a wrapper once I get my head
> around cython/pyrex.

Sweet.  I wanted Ajanki's code because it worked out of the box.  I modified it 
a little so it'd yield solutions rather than using a callback function.  Faster 
is better.

> (3) Write the algorithm from scratch in Cython. Does Cython have goto?

I'm sitting across from Robert Bradshaw.  He said "Gotos are ugly. Well, gotos 
are ugly unless you're writing a compiler, and then you need them".  So no, no 
gotos in Cython.

DLX should be absolutely trivial to implement using a stack instead of 
recursion.  That should give a huge boost, and there will be no need for gotos.


--~--~-~--~~~---~--~~
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] gp script error message not caught cleanly

[John Cremona]

The following code is fine if 10^17 is replaced by (say) 10^16, so the
underlying cause is probably due to being close to pari's limitations.
 But the error message is rather unacceptable!  Here gp is yielding an
error message (see end)

[EMAIL PROTECTED]
--
| SAGE Version 2.10.2, Release Date: 2008-02-22  |
| Type notebook() for the GUI, and license() for information.|
--

sage: p=next_prime(10^17); p
13
sage: E=EllipticCurve(GF(p),[123,324])
sage: P=E(53989543867592054, 16386953280180785)
sage: P.order()
---
 Traceback (most recent call last)

/home/jec/sage-2.10.2/ in ()

/home/jec/sage-2.10.2/local/lib/python2.5/site-packages/sage/schemes/elliptic_curves/ell_point.py
in order(self, disable_warning)
633 lb,ub=ell_generic.Hasse_bounds(q)
634 if K.is_prime_field():
--> 635 e = E._gp()
636 N = rings.Integer(e.ellzppointorder(list(self.xy(
637 else:

/home/jec/sage-2.10.2/local/lib/python2.5/site-packages/sage/schemes/elliptic_curves/ell_finite_field.py
in _gp(self)
126 if not F.is_prime_field():
127 raise NotImplementedError
--> 128 self.__gp = gp_cremona.ellinit(self.a_invariants(),
F.characteristic())
129 return self.__gp
130

/home/jec/sage-2.10.2/local/lib/python2.5/site-packages/sage/schemes/elliptic_curves/gp_cremona.py
in ellinit(e, p)
 74 """
 75 init()
---> 76 return gp("e=ellzpinit(%s,%s);"%(e,p))
 77
 78

/home/jec/sage-2.10.2/local/lib/python2.5/site-packages/sage/interfaces/expect.py
in __call__(self, x)
736 return x
737 if isinstance(x, basestring):
--> 738 return cls(self, x)
739 try:
740 return self._coerce_from_special_method(x)

/home/jec/sage-2.10.2/local/lib/python2.5/site-packages/sage/interfaces/expect.py
in __init__(self, parent, value, is_name)
   1005 except (TypeError, KeyboardInterrupt,
RuntimeError, ValueError), x:
   1006 self._session_number = -1
-> 1007 raise TypeError, x
   1008 self._session_number = parent._session_number
   1009

: Error executing code in GP/PARI:
CODE:
sage[1]=e=ellzpinit([0, 0, 0, 123, 324],13);;
GP/PARI ERROR:
  ***   error opening input file: /home/jec/.sage//tem
  ^


I think gp is showing an error message like this:

  *** vector: the PARI stack overflows !
  current stack size: 1000 (9.537 Mbytes)
  [hint] you can increase GP stack with allocatemem()


I will be writing around this anyway since the new code now in 2.10.2
for elliptic curves over finite fields means that we will no longer
need to use my old gp scripts for any of this (ellzpinit() is not part
of standard gp, but is part of the external scripts included in Sage).

I guess this should be another trac ticket?

John

-- 
John Cremona

--~--~-~--~~~---~--~~
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: exact cover problem

[William Stein]

On Sat, Feb 23, 2008 at 12:46 PM,  <[EMAIL PROTECTED]> wrote:
>
>
>
>
>  On Sat, 23 Feb 2008, Carlo Hamalainen wrote:
>
>  >
>  > On Fri, Feb 22, 2008 at 8:55 PM,  <[EMAIL PROTECTED]> wrote:
>  >>  Arguments for including Ajanki's code:
>  >> 1) It's the only Python implementation of DLX I've seen.
>  >> 2) I emailed the author, who happily added the "or later" bit after 
> the GPL2
>  >> 3) With my Sage Matrix -> DLXMatrix code (plus docstrings to 
> everything I added), the file dlx.py is only 8kB!
>  >> 4) It will resolve tickets #1311 and #1313
>  >
>  > This afternoon I wrote some code to get completions of partial latin
>  > squares using Ajanki's DLX code (this is basically the same as solving
>  > a Sudoku puzzle, minus a few constraints because latin squares don't
>  > have the 3x3 blocks).
>  >
>  > I discovered that the main function, dosearch(), uses recursion, and
>  > Python's recursion limit is reached quite easily (e.g. finding a
>  > completion of a 16x16 partial latin square blows up). Knuth's original
>  > implementation in C avoided recursion by using an array to simulate a
>  > stack, and looping uses goto statements, and so it can be run on quite
>  > large problem instances. As a side benefit there is no function call
>  > overhead in the main part of the algorithm.
>  >
>  > I have been using my own implementation of DLX in C++ for a while now
>  > and I've found it very useful, so I'm all for the algorithm getting
>  > into Sage. I can see a few ways forward:
>  >
>  > (1) Rewrite Ajanki's code to avoid the recursion limit. The problem
>  > here is that Python doesn't have 'goto'. Can the recursion limit be
>  > dealt with in some other way?
>
>  Yes, I've devoted some thought to this -- we can remove the recursion
> by using a stack.  This shouldn't be too hard.  But why do you want a "goto"?
> That's like duct-taping your car door shut when the latch works fine.

Here's an example of using an  "evil trick" Tom just suggested
to me to make a goto directly in Cython.  NEVER REALLY
DO THIS!  This is for your amusement only.


cdef extern from "stdio.h":
void goto "goto out; //"()
void receive "out: //"()

print "1"
goto()
print "2"
receive()
print "3"



This outputs:

1
3

--~--~-~--~~~---~--~~
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: more numerical noise?

[Simon King]

Dear Sage team,

totallyreal.py failed for me as well.

I was building from scratch. My "coordinates":

> uname -a
Linux mpc739 2.6.18.8-0.3-default #1 SMP Tue Apr 17 08:42:35 UTC 2007
x86_64 x86_64 x86_64 GNU/Linux

> cat /etc/issue

Welcome to openSUSE 10.2 (X86-64) - Kernel \r (\l).

> gcc -v
Es werden eingebaute Spezifikationen verwendet.
Ziel: x86_64-unknown-linux-gnu
Konfiguriert mit: ../gcc-4.2.1/configure
Thread-Modell: posix
gcc-Version 4.2.1

> cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 15
model   : 55
model name  : AMD Athlon(tm) 64 Processor 3700+
stepping: 2
cpu MHz : 1000.000
cache size  : 1024 KB
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext
fxsr_opt lm 3dnowext 3dnow up pni lahf_lm
bogomips: 2011.52
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp

Cheers
   Simon

--~--~-~--~~~---~--~~
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: some more entries for sagemath.org/pub.html

[David Roe]

A friend of mine also pointed out the following, which uses Sage to compare
runtimes for different algorithms:
Dan Boneh, Craig Gentry, Michael Hamburg. http://crypto.stanford.edu/~dabo/pubs.html";>Space-efficient identity based
encryption without pairings (37 pages), Proceedings FOCS 2007.
David


On Sat, Feb 23, 2008 at 10:33 AM, Alex Ghitza <[EMAIL PROTECTED]> wrote:

>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> Patrick Ingram, http://arxiv.org/abs/0802.2651";>Multiples of
> integral points on elliptic curves (29 pages), 2008.
>
> Nicholas J. Cavenagh, Carlo Hamalainen, Adrian M. Nelson,  href="http://arxiv.org/abs/0712.0233";>On completing three cyclic
> transversals to a latin square (13 pages), 2007.
>
> Chris A. Kurth, Ling Long,  href="http://arxiv.org/abs/0710.1835";>Computations with finite index
> subgroups of $PSL_2(\mathbb Z)$ using Farey symbols (16 pages), 2007.
>
> David Harvey, http://arxiv.org/abs/0708.3404";>Efficient
> computation of p-adic heights (18 pages), 2007.
>
> David Harvey, http://arxiv.org/abs/math/0610973";>Kedlaya's
> algorithm in larger characteristic (21 pages), 2006.
>
> John Voight, http://arxiv.org/abs/0802.0194";>Enumeration of
> totally real number fields of bounded root discriminant (14 pages),
> 2008.
>
> David Loeffler, http://arxiv.org/abs/0801.3176";>Explicit
> calculations of automorphic forms for definite unitary groups (19
> pages), 2008.
>
> Jonathan Sondow, Kyle Schalm,  href="http://arxiv.org/abs/0709.0671";>Which partial sums of the Taylor
> series for $e$ are convergents to $e$? (and a link to the primes 2, 5,
> 13, 37, 463) (13 pages), 2007.
>
>
>
>
>
>
> - --
> Alexandru Ghitza
> Assistant Professor
> Department of Mathematics
> Colby College
> Waterville, ME 04901
> http://bayes.colby.edu/~ghitza/ 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHwDzDdZTaNFFPILgRAiwRAJwMEsSvRhefdgjalS11nyekdvsvnQCfUJ4X
> YxBcJDwX8ACy30T8kP5fV+k=
> =2BrF
> -END PGP SIGNATURE-
>
> >
>

--~--~-~--~~~---~--~~
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: more numerical noise?

[John Cremona]

That's the same Suse version as mine:

[EMAIL PROTECTED] /etc/issue

Welcome to openSUSE 10.2 (X86-64) - Kernel \r (\l).

Each of the 4 processors is like this:

processor   : 3
vendor_id   : AuthenticAMD
cpu family  : 15
model   : 65
model name  : Dual-Core AMD Opteron(tm) Processor 2220
stepping: 3
cpu MHz : 2800.164
cache size  : 1024 KB
physical id : 1
siblings: 2
core id : 1
cpu cores   : 2
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm
cr8_legacy
bogomips: 5600.66
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc



On 23/02/2008, Simon King <[EMAIL PROTECTED]> wrote:
>
>  Dear Sage team,
>
>  totallyreal.py failed for me as well.
>
>  I was building from scratch. My "coordinates":
>
>  > uname -a
>  Linux mpc739 2.6.18.8-0.3-default #1 SMP Tue Apr 17 08:42:35 UTC 2007
>  x86_64 x86_64 x86_64 GNU/Linux
>
>  > cat /etc/issue
>
>  Welcome to openSUSE 10.2 (X86-64) - Kernel \r (\l).
>
>  > gcc -v
>  Es werden eingebaute Spezifikationen verwendet.
>  Ziel: x86_64-unknown-linux-gnu
>  Konfiguriert mit: ../gcc-4.2.1/configure
>  Thread-Modell: posix
>  gcc-Version 4.2.1
>
>  > cat /proc/cpuinfo
>  processor   : 0
>  vendor_id   : AuthenticAMD
>  cpu family  : 15
>  model   : 55
>  model name  : AMD Athlon(tm) 64 Processor 3700+
>  stepping: 2
>  cpu MHz : 1000.000
>  cache size  : 1024 KB
>  fpu : yes
>  fpu_exception   : yes
>  cpuid level : 1
>  wp  : yes
>  flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
>  mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext
>  fxsr_opt lm 3dnowext 3dnow up pni lahf_lm
>  bogomips: 2011.52
>  TLB size: 1024 4K pages
>  clflush size: 64
>  cache_alignment : 64
>  address sizes   : 40 bits physical, 48 bits virtual
>  power management: ts fid vid ttp
>
>  Cheers
>
>Simon
>
>
>  >
>


-- 
John Cremona

--~--~-~--~~~---~--~~
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: some more entries for sagemath.org/pub.html

[John Cremona]

What a coincidence.  One of the algorithms discussed by that paper is
by Cocks;  and I heard Cocks give a lecture about it last Monday (he
just received an honorary degree from the University of Bristol where
I am visiting, as those of you who were at SD6 know).  And both the
paper and Cocks in his lecture refer to a paper and algorithm of mine
which I had no idea before 5 days ago had any such application!
Unfortunately this algorithm (for finding rational points on diagonal
conics) is not in Sage (well, it is in eclib but has no wrapper
currently).

John

On 23/02/2008, David Roe <[EMAIL PROTECTED]> wrote:
> A friend of mine also pointed out the following, which uses Sage to compare
> runtimes for different algorithms:
> Dan Boneh, Craig Gentry, Michael Hamburg.  href="http://crypto.stanford.edu/~dabo/pubs.html";>Space-efficient
> identity based encryption without pairings (37 pages), Proceedings FOCS
> 2007.
>  David
>
>
>
> On Sat, Feb 23, 2008 at 10:33 AM, Alex Ghitza <[EMAIL PROTECTED]> wrote:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> >
> > Patrick Ingram, http://arxiv.org/abs/0802.2651";>Multiples of
> > integral points on elliptic curves (29 pages), 2008.
> >
> > Nicholas J. Cavenagh, Carlo Hamalainen, Adrian M. Nelson,  > href="http://arxiv.org/abs/0712.0233";>On completing three cyclic
> > transversals to a latin square (13 pages), 2007.
> >
> > Chris A. Kurth, Ling Long,  > href="http://arxiv.org/abs/0710.1835";>Computations with finite index
> > subgroups of $PSL_2(\mathbb Z)$ using Farey symbols (16 pages), 2007.
> >
> > David Harvey, http://arxiv.org/abs/0708.3404";>Efficient
> > computation of p-adic heights (18 pages), 2007.
> >
> > David Harvey,  href="http://arxiv.org/abs/math/0610973";>Kedlaya's
> > algorithm in larger characteristic (21 pages), 2006.
> >
> > John Voight, http://arxiv.org/abs/0802.0194";>Enumeration of
> > totally real number fields of bounded root discriminant (14 pages),
> > 2008.
> >
> > David Loeffler, http://arxiv.org/abs/0801.3176";>Explicit
> > calculations of automorphic forms for definite unitary groups (19
> > pages), 2008.
> >
> > Jonathan Sondow, Kyle Schalm,  > href="http://arxiv.org/abs/0709.0671";>Which partial sums of the Taylor
> > series for $e$ are convergents to $e$? (and a link to the primes 2, 5,
> > 13, 37, 463) (13 pages), 2007.
> >
> >
> >
> >
> >
> >
> > - --
> > Alexandru Ghitza
> > Assistant Professor
> > Department of Mathematics
> > Colby College
> > Waterville, ME 04901
> > http://bayes.colby.edu/~ghitza/
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v2.0.7 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> >
> iD8DBQFHwDzDdZTaNFFPILgRAiwRAJwMEsSvRhefdgjalS11nyekdvsvnQCfUJ4X
> > YxBcJDwX8ACy30T8kP5fV+k=
> > =2BrF
> > -END PGP SIGNATURE-
> >
> >
> >
>
>
>  >
>


-- 
John Cremona

--~--~-~--~~~---~--~~
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: more numerical noise?

[William Stein]

On Sat, Feb 23, 2008 at 3:16 PM, John Cremona <[EMAIL PROTECTED]> wrote:
>
>  That's the same Suse version as mine:

And coincidentally I don't test building Sage under SUSE.
I did for a long time, but then ran into a bug in their compilers,
and couldn't figure out how to install new compilers since SUSE
uses rpms, etc., and it's just not friendly like Debian-based
systems are.  (Even though I used Redhat for 6 years, I still
find apt-get way easier.)   I'll try again.

>
>  [EMAIL PROTECTED] /etc/issue
>
>
>  Welcome to openSUSE 10.2 (X86-64) - Kernel \r (\l).
>
>  Each of the 4 processors is like this:
>
>
>  processor   : 3
>  vendor_id   : AuthenticAMD
>  cpu family  : 15
>  model   : 65
>  model name  : Dual-Core AMD Opteron(tm) Processor 2220
>  stepping: 3
>  cpu MHz : 2800.164
>  cache size  : 1024 KB
>  physical id : 1
>  siblings: 2
>  core id : 1
>  cpu cores   : 2
>
> fpu : yes
>  fpu_exception   : yes
>  cpuid level : 1
>  wp  : yes
>  flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
>  mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
>  fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm
>  cr8_legacy
>  bogomips: 5600.66
>
> TLB size: 1024 4K pages
>  clflush size: 64
>  cache_alignment : 64
>  address sizes   : 40 bits physical, 48 bits virtual
>  power management: ts fid vid ttp tm stc
>
>
>
>
>
>  On 23/02/2008, Simon King <[EMAIL PROTECTED]> wrote:
>  >
>  >  Dear Sage team,
>  >
>  >  totallyreal.py failed for me as well.
>  >
>  >  I was building from scratch. My "coordinates":
>  >
>  >  > uname -a
>  >  Linux mpc739 2.6.18.8-0.3-default #1 SMP Tue Apr 17 08:42:35 UTC 2007
>  >  x86_64 x86_64 x86_64 GNU/Linux
>  >
>  >  > cat /etc/issue
>  >
>  >  Welcome to openSUSE 10.2 (X86-64) - Kernel \r (\l).
>  >
>  >  > gcc -v
>  >  Es werden eingebaute Spezifikationen verwendet.
>  >  Ziel: x86_64-unknown-linux-gnu
>  >  Konfiguriert mit: ../gcc-4.2.1/configure
>  >  Thread-Modell: posix
>  >  gcc-Version 4.2.1
>  >
>  >  > cat /proc/cpuinfo
>  >  processor   : 0
>  >  vendor_id   : AuthenticAMD
>  >  cpu family  : 15
>  >  model   : 55
>  >  model name  : AMD Athlon(tm) 64 Processor 3700+
>  >  stepping: 2
>  >  cpu MHz : 1000.000
>  >  cache size  : 1024 KB
>  >  fpu : yes
>  >  fpu_exception   : yes
>  >  cpuid level : 1
>  >  wp  : yes
>  >  flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
>  >  mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext
>  >  fxsr_opt lm 3dnowext 3dnow up pni lahf_lm
>  >  bogomips: 2011.52
>  >  TLB size: 1024 4K pages
>  >  clflush size: 64
>  >  cache_alignment : 64
>  >  address sizes   : 40 bits physical, 48 bits virtual
>  >  power management: ts fid vid ttp
>  >
>  >  Cheers
>  >
>  >Simon
>  >
>  >
>  >  >
>  >
>
>
>  --
>  John Cremona
>
>
>
>  >
>



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

--~--~-~--~~~---~--~~
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] Inequality solver

[SBP]

Hi everyone:

I've made a little function for solving inequalities, it hasn't been
extensively tested but it works at least for solving both of Wester's
problems on inequalities and some my girlfriend had a few days ago.

Hope you find it useful.

Cheers.

--
Sirio Bolaños.
UNAM, México

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

#!/usr/bin/env python

#function parameters are the inequality to solve and left and right endpoints tuple of the interval in which to search for a solution (consequence of the plot-dependant algorithm for finding all roots)

def isolve(ineq,(rleft,rright)):
zeros = []
roots = []
solution = []
#perhaps eps should also be a parameter?
eps = 0.1

try:
op = ineq.__getitem__(1)
lm = ineq.__getitem__(0)
rm = ineq.__getitem__(2)
except:
raise ValueError, "trying to solve expression without operator"
if op == operator.eq:
raise ValueError, "trying to solve equation, please use solve() instead"

f = lm - rm
p = plot(f,(rleft,rright),plot_points=1000)

for i in range(len(p[0])-1):
if (p[0][i][1] > 0 and p[0][i+1][1] < 0) or (p[0][i][1] < 0 and p[0][i+1][1] > 0):
 zeros.append((p[0][i],p[0][i+1]))
 
if len(zeros) is not 0:
for i in range(len(zeros)):
root = f.find_root(zeros[i][0][0],zeros[i][1][0])
#quick fix to find_root providing inexact roots if integers
if abs(floor(root)-root) < eps:
root = floor(root)
elif abs(ceil(root)-root) < eps:
root = ceil(root)
roots.append(root)
else:
raise ValueError, "inequality has no solution"
#FIXME provide a way of specifying if RIF is open or closed interval depending on operator (<,<=,>,>=)
if len(roots) > 1:
if bool(op(f(roots[0]-eps),0)) is True:
solution.append(RIF((-infinity,roots[0])))
for i in range(len(roots)-1):
if bool(op(f(roots[i]+eps),0)) is True:
solution.append(RIF((roots[i],roots[i+1])))
if bool(op(f(roots[-1]+eps),0)) is True:
solution.append(RIF((roots[-1],infinity)))
else:
if bool(op(f(roots[0]+eps),0)) is True:
solution.append(RIF((roots[0],infinity)))
else:
solution.append(RIF((-infinity,roots[0])))
return solution

[sage-devel] Inequality Solver

[SBP]

Hi again,

I've just added some description so it show when typing isolve?

Cheers.


Sirio Bolaños.
UNAM, México.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

#!/usr/bin/env python
# -*- coding: utf-8 -*-

#function parameters are the inequality to solve and left and right endpoints tuple of the interval in which to search for a solution (consequence of the plot-dependant algorithm for finding all roots)

def isolve(ineq,(rleft,rright)):
"""
Inequality solver

sage can solve inequalities and express the result as the intervals of solution

sage: isolve(abs(x^2-2)<2,(-10,10))
'[[-2. .. 2.]]'

AUTHORS:
-- Sirio Bolanos: initial version

EXAMPLES:
sage: isolve((x-1)*(x-2)*(x-3)*(x-4)*(x-5)<0,(-10,10))
'[[-infinity .. 1.], [2. .. 3.], [4. .. 5.]]'
sage: isolve(abs(x-2)+abs(2*x^3-1)>abs(2*x+7),(-10,10))
'[[-infinity .. -0.87961487981223052], [1.7837690610319452 .. +infinity]]'
"""
zeros = []
roots = []
solution = []
#perhaps eps should also be a parameter?
eps = 0.1

try:
op = ineq.__getitem__(1)
lm = ineq.__getitem__(0)
rm = ineq.__getitem__(2)
except:
raise ValueError, "trying to solve expression without operator"
if op == operator.eq:
raise ValueError, "trying to solve equation, please use solve() instead"

f = lm - rm
p = plot(f,(rleft,rright),plot_points=1000)

for i in range(len(p[0])-1):
if (p[0][i][1] > 0 and p[0][i+1][1] < 0) or (p[0][i][1] < 0 and p[0][i+1][1] > 0):
 zeros.append((p[0][i],p[0][i+1]))
 
if len(zeros) is not 0:
for i in range(len(zeros)):
root = f.find_root(zeros[i][0][0],zeros[i][1][0])
#quick fix to find_root providing inexact roots if integers
if abs(floor(root)-root) < eps:
root = floor(root)
elif abs(ceil(root)-root) < eps:
root = ceil(root)
roots.append(root)
else:
raise ValueError, "inequality has no solution"
#FIXME provide a way of specifying if RIF is open or closed interval depending on operator (<,<=,>,>=)
if len(roots) > 1:
if bool(op(f(roots[0]-eps),0)) is True:
solution.append(RIF((-infinity,roots[0])))
for i in range(len(roots)-1):
if bool(op(f(roots[i]+eps),0)) is True:
solution.append(RIF((roots[i],roots[i+1])))
if bool(op(f(roots[-1]+eps),0)) is True:
solution.append(RIF((roots[-1],infinity)))
else:
if bool(op(f(roots[0]+eps),0)) is True:
solution.append(RIF((roots[0],infinity)))
else:
solution.append(RIF((-infinity,roots[0])))
return solution

[sage-devel] Inequality solver

[SBP]

Hi all,

just a minor fix in the description.

Cheers!


-
Sirio Bolaños.
UNAM, México.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

#!/usr/bin/env python
# -*- coding: utf-8 -*-

#function parameters are the inequality to solve and left and right endpoints tuple of the interval in which to search for a solution (consequence of the plot-dependant algorithm for finding all roots)

def isolve(ineq,(rleft,rright)):
"""
Inequality solver

sage can solve inequalities and express the result as the intervals of solution

syntax is: isolve(inequality,(left endpoint of interval in which to search for solutions,right endpoint))

sage: isolve(abs(x^2-2)<2,(-10,10))
'[[-2. .. 2.]]'

AUTHORS:
-- Sirio Bolanos: initial version

EXAMPLES:
sage: isolve((x-1)*(x-2)*(x-3)*(x-4)*(x-5)<0,(-10,10))
'[[-infinity .. 1.], [2. .. 3.], [4. .. 5.]]'
sage: isolve(abs(x-2)+abs(2*x^3-1)>abs(2*x+7),(-10,10))
'[[-infinity .. -0.87961487981223052], [1.7837690610319452 .. +infinity]]'
"""
zeros = []
roots = []
solution = []
#perhaps eps should also be a parameter?
eps = 0.1

try:
op = ineq.__getitem__(1)
lm = ineq.__getitem__(0)
rm = ineq.__getitem__(2)
except:
raise ValueError, "trying to solve expression without operator"
if op == operator.eq:
raise ValueError, "trying to solve equation, please use solve() instead"

f = lm - rm
p = plot(f,(rleft,rright),plot_points=1000)

for i in range(len(p[0])-1):
if (p[0][i][1] > 0 and p[0][i+1][1] < 0) or (p[0][i][1] < 0 and p[0][i+1][1] > 0):
 zeros.append((p[0][i],p[0][i+1]))
 
if len(zeros) is not 0:
for i in range(len(zeros)):
root = f.find_root(zeros[i][0][0],zeros[i][1][0])
#quick fix to find_root providing inexact roots if integers
if abs(floor(root)-root) < eps:
root = floor(root)
elif abs(ceil(root)-root) < eps:
root = ceil(root)
roots.append(root)
else:
raise ValueError, "inequality has no solution"
#FIXME provide a way of specifying if RIF is open or closed interval depending on operator (<,<=,>,>=)
if len(roots) > 1:
if bool(op(f(roots[0]-eps),0)) is True:
solution.append(RIF((-infinity,roots[0])))
for i in range(len(roots)-1):
if bool(op(f(roots[i]+eps),0)) is True:
solution.append(RIF((roots[i],roots[i+1])))
if bool(op(f(roots[-1]+eps),0)) is True:
solution.append(RIF((roots[-1],infinity)))
else:
if bool(op(f(roots[0]+eps),0)) is True:
solution.append(RIF((roots[0],infinity)))
else:
solution.append(RIF((-infinity,roots[0])))
return solution

[sage-devel] Re: sage-edu, standard API, etc.

[alex clemesha]

On Sat, Feb 23, 2008 at 10:24 AM, William Stein <[EMAIL PROTECTED]> wrote:

>
> On Sat, Feb 23, 2008 at 9:39 AM, alex clemesha <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > On Sat, Feb 23, 2008 at 12:02 AM, didier deshommes <[EMAIL PROTECTED]>
> > wrote:
> > >
> > >
> > > On Fri, Feb 22, 2008 at 5:57 PM, alex clemesha <[EMAIL PROTECTED]>
> wrote:
> > > > In Knoboo we *decouple* the idea of a kernel, it could be another
> > > > Python (Sage) process, with communication through Pexpect
> > > >
> > > > ... but it also couple be another Python (Sage) process running a
> very
> > > > minimal XML-RPC server, and all communication occurs through
> > > >  *** HTTP instead of Pexpect ***.
> > >
> > > I personally am not too familiar with web development, so it's always
> > > great to hear from someone who has (which is exactly why this
> > > discussion was started). Regarding XML-RPC vs Pexpect:
> > >  - how slow is one compared to the other?  I expect xml-rpc to be
> > > slower, but not so slow to render it unusable.
> >
> > I would say that it is even faster than how the current Sage notebook
> > does its process of compiling scripts to be passed back and forth with
> > Pexpect.
> >
> > But in reality, both methods of communication, in most cases,
> > are sub-second and constant, so this is mostly a complete non-issue.
>
> I'm actually pretty curious about how pexpect and XMLRPC both
> done locally compare speedwise.  I've done some simple benchmarks
> below.  The short answer is that pexpect is between several hundred
> to several thousand times faster than XMLRPC, depending on the
> platform.
>
> Here's a good pexpect benchmark to do in sage-2.10.2:
>
> sage: gp('2+2')
> 4
> sage: timeit("gp.eval('2+2')")
> 625 loops, best of 3: 136 µs per loop
>
> This benchmarks adding 2 and 2 over the pexpect interface
> to pari and getting back the result.  It takes 136 microseconds
> to do that on my OS X 10.5 intel 2.6Ghz computer.  On sage.math
> it's about 500 times faster, only 303 nanoseconds:
>
> sage: timeit(gp.eval('2+2'))
> 625 loops, best of 3: 303 ns per loop
>
> Pexpect may have a reputation for being "dog slow", but on small
> transactions it's actually surprisingly fast.  Seriously.  It's only bad
> when the input is large.
>
>
> Now let's try xmlrpc (with Yi's help).  Copy in the setup from
>   http://docs.python.org/lib/simple-xmlrpc-servers.html
> then time adding two integers (we put an r after them below
> so that they are *Python* integers, which avoid preparsing):
>
> On my 2.6Ghz Intel OS X computer:
>
> sage: timeit('s.add(2r,3r)')
> 25 loops, best of 3: 43.7 ms per loop
>
> On sage.math:
> sage: timeit('s.add(2r,3r)')
> 625 loops, best of 3: 1.38 ms per loop
>
> So let's compare:
>
> On OS X 2.6Ghz machine pexpect is 321 times faster
> than XMLRPC:
> sage: 43.7 / (136 * 10^(-3))
> 321.323529411765
>
> On sage.math pexpect is 4554 times faster than XMLRPC:
> sage: 1.38 / (303 * 10^(-6))
> 4554.45544554455
>
> Obviously there may be tricks for speeding up XMLRPC (and
> for speeding up pexpect), and I would really love for an expert
> in XMLRPC to retry the above benchmarks but with their tricks.
> However, XMLRPC is using the TCP/IP networking stack, and
> probably will have to use encryption if we're to do this seriously,
> whereas pexpect is just all happening in RAM (vis unix named
> pipes), so it's maybe not surprising that pexpect would
> have a big advantage speedwise.
>

First off, thanks for doing those benchmarks,
they are pretty interesting to see!

I want to stress that I think that this API discussion
should really *not* have anything to do with speed,
and this is precisely because of the use case of the API:

Users evalute cells one at a time, not 625 times in 1 second ;)

The above is not meant to be precise in any way,
just to kind of express the issue we are dealing with here.
If both methods allow a cell's code to be transfered in
sub-second time, let's aim for functionality, not speed.



>
> >
> >
> > >
> > > - I understand xml-rpc working for inter-communication, ie SAGE ->
> > > outside world, but I don't see how it would work for
> > > intra-communication, SAGE -> maxima. Maxima would have to be already
> > > running in the background, right? If that is the case, then every sage
> > > session would have to spawn singular, maxima, maple, etc sessions at
> > > start-up. I don't like that. Is there something I'm not getting here?
> >
> > Sage intra-communication would stay exactly the same.  The way that
> > works (pseudo-tty) won't be changing any time soon (ever?).
>
> It may change for MS Windows; I don't know.  Windows doesn't suppose
> pseudo-tty's so well (?), so we may have to come up with a new approach
> there, since now we're serious about fully porting Sage to Windows.
>
> >  It's fundamental to how Sage encapsulates all it's external programs.
> >
> > Behind the scenes, when you use a function that requires,
> > for example, singular or maxima to be used, then that new proc