[sage-devel] Re: SymbolicEquation type error

[Ted Kosan]

Carl wrote:

> Is there any chance that you've assigned a value to x earlier in your
> session, so that x is no longer a symbolic variable?

The code was executed in the first cell of the first worksheet that I
created after launching Sage 2.9 for the first time.

After closing the worksheet, reopening it, and rerunning the code, the
problem disappeared and I have been unable to recreate it.
Interesting...

Ted

--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: factoring benchmarks

[Joel B. Mohler]

On Wednesday 19 December 2007 23:42, Bill Hart wrote:
> Here is a graph that uses slightly bigger coefficients, up to 1
> bits.
>
> http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/factor2.pn
>g
>
> I don't see the speed increase you mentioned for large coefficients,
> but this might be due to some special properties of the polynomials
> you are factoring, or perhaps due to the particular architecture you
> have. Prime field arithmetic is probably quite architecture dependent,
> so that may contribute, I'm not sure.

Yeah, in the end, I don't think I believe the speed increase for large 
coefficients either.  I think what I did observe was probably a result of 
accidents with semi-random polynomials.

Here's a snippet from my patched branch:
Loading SAGE library. Current Mercurial branch is: uni-factoring
sage: R.=ZZ[]
sage: f=x^2-1
sage: timeit f._factor_ntl()   NTL wins
1 loops, best of 3: 159 µs per loop
sage: timeit f._factor_pari()
1000 loops, best of 3: 794 µs per loop
sage: f=R.random_element(6)
sage: timeit f._factor_ntl()# NTL wins
1000 loops, best of 3: 316 µs per loop
sage: timeit f._factor_pari()
1000 loops, best of 3: 533 µs per loop

I'm not seeing this NTL win on your chart.  I'm wondering if this might be 
because of data-conversion costs to pari.  Of course, that data conversion is 
a cost of the sage implementation so when making the cutoff choices for sage 
we need to include the conversion costs.

--
Joel

--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] elliptic curve issues

[John Cremona]

Topic 1: isomorphisms between Weierstrass models

For Robert B as author of weierstrass_morphism.py:  It's not a bug but
I would recommend that you test for equality of j-invariants before
doing the harder work (which you do by extracting 12th roots of the
ratio of the discriminants).  Similarly in

elliptic_curves/ell_generic.py

in the function is_isomorphic().   Also, I am yet to be convinced that
the code in weierstrass_morphism.py is correct, but I will reserve
judgement until I have a counterexample.
It certainly is *not* correct in char. 2 & 3 since you divide by 2 and 3!

I have always done this using the ratio of c4 and/or c6 invariants,
which is fine except in characteristics 2 and 3 anyway, and also
simpler (since unless j=0 or j=1728 you only need to test for
something being a square, not need for 12'th roots).  That code can
already be found in simon's ellQ.gp (the new version incorporating
some improvements I suggested to him).  But it does not deal with char
2 & 3, which I'll sit down and work through one day, and then submit
an improved version of weierstrass_morphism.py.

Topic 2: package names.

I am a little embarrassed that there is precisely one package (spkg)
whose name is a person's name (especially when it apparently results
in bug reports of the form "cremona causes fatal crash").  It has
never occurred to me to invent a name for my programs collectively
though.  Anyway, given this, having types in Sage such as
mwrank_EllipticCurve seems odd now that the mwrank package has been
superceded, and logically they should probably be called
cremona_EllipticCurve -- at least until I decide that may package
should be renamed foobar at which point they'll have to be
foobar_EllipticCurve.

Topic 3: trac #1058: the mwrank interface barfs on bad input

The issue here is whether to extend mwrank_EllipticCurve to allow
curves with rational (as opposed to integral) coefficients.  I have
been thinking about this.  I do not want to rewrite my elliptic curve
code from scratch, but some things would be relatively easy:
* allowing the mwrank binary to accept 5-tuples of rationals to define a curve
* allowing the two_descent class (which computes rank and the MW
group) to accept rationals
 -- in each case, the generating points returned would be correctly
mapped back to the input not-necessarily-integral model.

But it would be a lot harder to extend this to all the other
functionality, to the extent that a Sage user could construct an
mwrank_EllipticCurve which was not integral.  Since I guess hardly any
Sage users actually construct mwrank_EllipticCurves anyway, would that
be a problem?

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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] lisp.run, server crash

[mhampton]

What is lisp.run?  I was doing a pretty simple calculation, which
ended up taking a long time (12+ hours, I was expecting maybe 30
minutes tops), and I noticed that lisp.run seemed to be doing all the
work.  After poking around, my best guess is that it was somehow being
called by the abs() function through pari or maxima (I had a loop that
was doing about 180,000 calls to abs()).

I also managed to crash my sage server to some extent, so I can't
immediately supply better diagnostics - interrupting the calculation
didn't work, so I tried quitting/restarting the worksheet, and now I
can't access the server at all.  When I get in to my office I can
check this out in more detail.  By running 'tops' remotely it looks
like my other worksheet processes are still hanging around but I am
not sure.

Thanks,

Marshall Hampton
--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: lisp.run, server crash

[Ismail Dönmez]

Thursday 20 December 2007 16:08:16 tarihinde mhampton şunları yazmıştı:
> What is lisp.run?

As far as I know thats from clisp.

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.

--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: lisp.run, server crash

[William Stein]

On Dec 20, 2007 7:08 AM, mhampton <[EMAIL PROTECTED]> wrote:
>
> What is lisp.run?  I was doing a pretty simple calculation, which

lisp.run is the name of the clisp interpreter, which maxima uses.
So in your calculation, you were evidentily doing a big maxima
calculation.

> ended up taking a long time (12+ hours, I was expecting maybe 30
> minutes tops), and I noticed that lisp.run seemed to be doing all the
> work.  After poking around, my best guess is that it was somehow being
> called by the abs() function through pari or maxima (I had a loop that
> was doing about 180,000 calls to abs()).

Yep.

> I also managed to crash my sage server to some extent, so I can't
> immediately supply better diagnostics - interrupting the calculation

Wow.  It should be very very difficult to crash the sage server, since
it is very much a separate process from anything that does any
computing, and the linking between the two processes is only
via a pseudo-tty, so it's very hard to crash the server -- in fact I know
of no systematic way to do so.

> didn't work, so I tried quitting/restarting the worksheet, and now I
> can't access the server at all.  When I get in to my office I can
> check this out in more detail.  By running 'tops' remotely it looks
> like my other worksheet processes are still hanging around but I am
> not sure.

It's likely.

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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: elliptic curve issues

[William Stein]

On Dec 20, 2007 4:21 AM, John Cremona <[EMAIL PROTECTED]> wrote:
> Topic 2: package names.
>
> I am a little embarrassed that there is precisely one package (spkg)
> whose name is a person's name (especially when it apparently results
> in bug reports of the form "cremona causes fatal crash").  It has
> never occurred to me to invent a name for my programs collectively
> though.

* How about "eclib", for "elliptic curve library"?
Googling for that suggests it would be a good choice of name.

* "ecl" is not a good choice, since it is already taken by a programming
language and a lisp implementation


>
> Topic 3: trac #1058: the mwrank interface barfs on bad input
>
> The issue here is whether to extend mwrank_EllipticCurve to allow
> curves with rational (as opposed to integral) coefficients.  I have
> been thinking about this.  I do not want to rewrite my elliptic curve
> code from scratch, but some things would be relatively easy:
> * allowing the mwrank binary to accept 5-tuples of rationals to define a curve
> * allowing the two_descent class (which computes rank and the MW
> group) to accept rationals
>  -- in each case, the generating points returned would be correctly
> mapped back to the input not-necessarily-integral model.
>
> But it would be a lot harder to extend this to all the other
> functionality, to the extent that a Sage user could construct an
> mwrank_EllipticCurve which was not integral.  Since I guess hardly any
> Sage users actually construct mwrank_EllipticCurves anyway, would that
> be a problem?

I think making mwrank_EllipticCurve give an error on non-integral
input is fine, since nobody should use mwrank .   Transforming a
curve to integral form first should be done in Sage.

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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: lisp.run, server crash

[mhampton]

OK, I will give the server logs here in case they are of interest.  I
am still not sure what went wrong.  I will have to find a quicker way
to do my calculation - perhaps cast things to floats, and use python's
math.abs().

As a preamble to the server logs: it looked like I was dropped into a
python session, so I entered "exit()".  Then I pressed CTRL-C several
times and got back to a sage prompt, and from there restarted the
notebook, which seems fine, none of the worksheets are active.  Here
is server output:

2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] End Of File
(EOF) in read_nonblocking(). Empty string style platform.
2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252]

2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] version: 2.0
($Revision: 1.151 $)
2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] command: /
Volumes/D/sage-2.8.4.1/sage
2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] args: ['/
Volumes/D/sage-2.8.4.1/sage', '-python', '-u']
2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] patterns:
2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] >>>
2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] buffer (last
100 chars):
2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] before (last
100 chars):
2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] after: 
2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] match: None
2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] match_index:
None
2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] exitstatus:
None
2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] flag_eof: 1
2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] pid: 9636
2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] child_fd: 15
2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] timeout: 30
2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] delimiter:

2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] logfile: None
2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] maxread: 1
2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252]
searchwindowsize: None
2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252]
delaybeforesend: 0
Python 2.5.1 (r251:54863, Sep 21 2007, 09:05:53)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> exit()
2007/12/20 10:45 -0500 [HTTPChannel,11974,71.221.40.252] Exception
rendering:
2007/12/20 10:45 -0500 [HTTPChannel,11974,71.221.40.252] Unhandled
Error
Traceback (most recent call last):
  File "/Volumes/D/sage-2.8.4.1/local/lib/python2.5/site-
packages/twisted/internet/defer.py", line 182, in addCallbacks
self._runCallbacks()
  File "/Volumes/D/sage-2.8.4.1/local/lib/python2.5/site-
packages/twisted/internet/defer.py", line 317, in _runCallbacks
self.result = callback(self.result, *args, **kw)
  File "/Volumes/D/sage-2.8.4.1/local/lib/python2.5/site-
packages/twisted/internet/defer.py", line 281, in _continue
self.unpause()
  File "/Volumes/D/sage-2.8.4.1/local/lib/python2.5/site-
packages/twisted/internet/defer.py", line 277, in unpause
self._runCallbacks()
---  ---
  File "/Volumes/D/sage-2.8.4.1/local/lib/python2.5/site-
packages/twisted/internet/defer.py", line 317, in _runCallbacks
self.result = callback(self.result, *args, **kw)
  File "/Volumes/D/sage-2.8.4.1/local/lib/python2.5/site-
packages/twisted/web2/server.py", line 268, in 
d.addCallback(lambda res, req: res.renderHTTP(req), self)
  File "/Volumes/D/sage-2.8.4.1/local/lib/python2.5/site-
packages/twisted/web2/resource.py", line 85, in renderHTTP
return method(request)
  File "/Volumes/D/sage-2.8.4.1/local/lib/python2.5/site-
packages/twisted/web2/resource.py", line 202, in http_GET
return super(Resource, self).http_GET(request)
  File "/Volumes/D/sage-2.8.4.1/local/lib/python2.5/site-
packages/twisted/web2/resource.py", line 128, in http_GET
return self.render(request)
  File "/Volumes/D/sage-2.8.4.1/local/lib/python2.5/site-
packages/sage/server/notebook/twist.py", line 1061, in render
self.worksheet.restart_sage()
  File "/Volumes/D/sage-2.8.4.1/local/lib/python2.5/site-
packages/sage/server/notebook/worksheet.py", line 1351, in
restart_sage
ulimit = self.notebook().get_ulimit())
  File "/Volumes/D/sage-2.8.4.1/local/lib/python2.5/site-
packages/sage/server/notebook/worksheet.py", line 79, in
initialized_sage
S._start(block_during_init=False)
  File "/Volumes/D/sage-2.8.4.1/local/lib/python2.5/site-
packages/sage/interfaces/expect.py", line 463, in _start
raise RuntimeError, "Unable to start %s"%self.__name
exceptions.RuntimeError: Unable to start sage

^C^C2007/12/20 10:46 -0500 [-] (Notebook 

[sage-devel] Re: factoring benchmarks

[Bill Hart]

Hi Joel,

Yes, it occurred to me this morning that conversion costs might be
getting in the way.

Does SAGE use the GP interpreter or the Pari library to do this
computation? If it is using the Pari library, and the data conversion
isn't quadratic time, then I don't think this should be a problem.

The other thing is, you are factoring a single random polynomial,
which may be irreducible. Factoring generic polynomials may be much
faster, since one only needs to know it is irreducible and then one
need not do any factoring. I will prepare a graph comparing the time
to factor generic polynomials, though I don't in general think that is
such a great benchmark, unless one specifically wants to tune for that
situation (which could be a nice idea if one had a certain flag that
could be set to indicate that one expected the polynomials being
factored to be vaguely generic).

Bill.

On 20 Dec, 10:10, "Joel B. Mohler" <[EMAIL PROTECTED]> wrote:
> On Wednesday 19 December 2007 23:42, Bill Hart wrote:
>
> > Here is a graph that uses slightly bigger coefficients, up to 1
> > bits.
>
> >http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/fact...
> >g
>
> > I don't see the speed increase you mentioned for large coefficients,
> > but this might be due to some special properties of the polynomials
> > you are factoring, or perhaps due to the particular architecture you
> > have. Prime field arithmetic is probably quite architecture dependent,
> > so that may contribute, I'm not sure.
>
> Yeah, in the end, I don't think I believe the speed increase for large
> coefficients either.  I think what I did observe was probably a result of
> accidents with semi-random polynomials.
>
> Here's a snippet from my patched branch:
> Loading SAGE library. Current Mercurial branch is: uni-factoring
> sage: R.=ZZ[]
> sage: f=x^2-1
> sage: timeit f._factor_ntl()   NTL wins
> 1 loops, best of 3: 159 µs per loop
> sage: timeit f._factor_pari()
> 1000 loops, best of 3: 794 µs per loop
> sage: f=R.random_element(6)
> sage: timeit f._factor_ntl()# NTL wins
> 1000 loops, best of 3: 316 µs per loop
> sage: timeit f._factor_pari()
> 1000 loops, best of 3: 533 µs per loop
>
> I'm not seeing this NTL win on your chart.  I'm wondering if this might be
> because of data-conversion costs to pari.  Of course, that data conversion is
> a cost of the sage implementation so when making the cutoff choices for sage
> we need to include the conversion costs.
>
> --
> Joel
--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: factoring benchmarks

[Joel B. Mohler]

On Thursday 20 December 2007 10:56, Bill Hart wrote:
> Does SAGE use the GP interpreter or the Pari library to do this
> computation? If it is using the Pari library, and the data conversion
> isn't quadratic time, then I don't think this should be a problem.

The library and I think the conversion is done correctly.  It's a bit of 
convoluted path in the sage code to get in this specific case though so there 
might be other silly issues.

> The other thing is, you are factoring a single random polynomial,
> which may be irreducible. Factoring generic polynomials may be much
> faster, since one only needs to know it is irreducible and then one
> need not do any factoring. I will prepare a graph comparing the time
> to factor generic polynomials, though I don't in general think that is
> such a great benchmark, unless one specifically wants to tune for that
> situation (which could be a nice idea if one had a certain flag that
> could be set to indicate that one expected the polynomials being
> factored to be vaguely generic).

My observation is that random polynomials are almost always irreducible.  This 
fact seems in startling contrast to the case for integers!  For instance:
sage: R.=ZZ[]
sage: R.random_element(6,-2^23,2^23).factor()
# virtually always 1 factor
I've actually been doing tests of 3 different cases (not all of which made it 
to the mailing list).
1) product of a bunch of small factors
2) product of 2 medium factors
3) random (irreducible by comments above)

NTL seems to gain a bit relative to pari when there are non-trivial factors, 
but it doesn't seem too significant.  It's main influence in my cutoff points 
has been to let NTL factor small polys out to degree 30 rather than degree 
10.  But both are so competitive for degree 10-20 that it's not that big of a 
deal.

--
Joel

--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: lisp.run, server crash

[William Stein]

On Dec 20, 2007 8:55 AM, mhampton <[EMAIL PROTECTED]> wrote:
>
> OK, I will give the server logs here in case they are of interest.  I
> am still not sure what went wrong.  I will have to find a quicker way
> to do my calculation - perhaps cast things to floats, and use python's
> math.abs().

If you can reproduce this it would be very valuable.

The public notebooks run for weeks without ever crashing, but
clearly you did crash the notebook server below somehow.

 -- William

> As a preamble to the server logs: it looked like I was dropped into a
> python session, so I entered "exit()".  Then I pressed CTRL-C several
> times and got back to a sage prompt, and from there restarted the
> notebook, which seems fine, none of the worksheets are active.  Here
> is server output:
>
> 2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] End Of File
> (EOF) in read_nonblocking(). Empty string style platform.
> 2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252]
> 
> 2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] version: 2.0
> ($Revision: 1.151 $)
> 2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] command: /
> Volumes/D/sage-2.8.4.1/sage
> 2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] args: ['/
> Volumes/D/sage-2.8.4.1/sage', '-python', '-u']
> 2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] patterns:
> 2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] >>>
> 2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] buffer (last
> 100 chars):
> 2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] before (last
> 100 chars):
> 2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] after:  'pexpect.EOF'>
> 2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] match: None
> 2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] match_index:
> None
> 2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] exitstatus:
> None
> 2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] flag_eof: 1
> 2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] pid: 9636
> 2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] child_fd: 15
> 2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] timeout: 30
> 2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] delimiter:
> 
> 2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] logfile: None
> 2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252] maxread: 1
> 2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252]
> searchwindowsize: None
> 2007/12/20 08:51 -0500 [HTTPChannel,11974,71.221.40.252]
> delaybeforesend: 0
> Python 2.5.1 (r251:54863, Sep 21 2007, 09:05:53)
> [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>>
> >>> exit()
> 2007/12/20 10:45 -0500 [HTTPChannel,11974,71.221.40.252] Exception
> rendering:
> 2007/12/20 10:45 -0500 [HTTPChannel,11974,71.221.40.252] Unhandled
> Error
> Traceback (most recent call last):
>   File "/Volumes/D/sage-2.8.4.1/local/lib/python2.5/site-
> packages/twisted/internet/defer.py", line 182, in addCallbacks
> self._runCallbacks()
>   File "/Volumes/D/sage-2.8.4.1/local/lib/python2.5/site-
> packages/twisted/internet/defer.py", line 317, in _runCallbacks
> self.result = callback(self.result, *args, **kw)
>   File "/Volumes/D/sage-2.8.4.1/local/lib/python2.5/site-
> packages/twisted/internet/defer.py", line 281, in _continue
> self.unpause()
>   File "/Volumes/D/sage-2.8.4.1/local/lib/python2.5/site-
> packages/twisted/internet/defer.py", line 277, in unpause
> self._runCallbacks()
> ---  ---
>   File "/Volumes/D/sage-2.8.4.1/local/lib/python2.5/site-
> packages/twisted/internet/defer.py", line 317, in _runCallbacks
> self.result = callback(self.result, *args, **kw)
>   File "/Volumes/D/sage-2.8.4.1/local/lib/python2.5/site-
> packages/twisted/web2/server.py", line 268, in 
> d.addCallback(lambda res, req: res.renderHTTP(req), self)
>   File "/Volumes/D/sage-2.8.4.1/local/lib/python2.5/site-
> packages/twisted/web2/resource.py", line 85, in renderHTTP
> return method(request)
>   File "/Volumes/D/sage-2.8.4.1/local/lib/python2.5/site-
> packages/twisted/web2/resource.py", line 202, in http_GET
> return super(Resource, self).http_GET(request)
>   File "/Volumes/D/sage-2.8.4.1/local/lib/python2.5/site-
> packages/twisted/web2/resource.py", line 128, in http_GET
> return self.render(request)
>   File "/Volumes/D/sage-2.8.4.1/local/lib/python2.5/site-
> packages/sage/server/notebook/twist.py", line 1061, in render
> self.worksheet.restart_sage()
>   File "/Volumes/D/sage-2.8.4.1/local/lib/python2.5/site-
> packages/sage/server/notebook/worksheet.py", line 1351, in
> restart_sage
> ulimit = self.notebook().get_ulimit())
>   File "/Volumes/D

[sage-devel] Re: factoring benchmarks

[Bill Hart]

On 20 Dec, 16:22, "Joel B. Mohler" <[EMAIL PROTECTED]> wrote:
> On Thursday 20 December 2007 10:56, Bill Hart wrote:
>
> > Does SAGE use the GP interpreter or the Pari library to do this
> > computation? If it is using the Pari library, and the data conversion
> > isn't quadratic time, then I don't think this should be a problem.
>
> The library and I think the conversion is done correctly.  It's a bit of
> convoluted path in the sage code to get in this specific case though so there
> might be other silly issues.
>
> > The other thing is, you are factoring a single random polynomial,
> > which may be irreducible. Factoring generic polynomials may be much
> > faster, since one only needs to know it is irreducible and then one
> > need not do any factoring. I will prepare a graph comparing the time
> > to factor generic polynomials, though I don't in general think that is
> > such a great benchmark, unless one specifically wants to tune for that
> > situation (which could be a nice idea if one had a certain flag that
> > could be set to indicate that one expected the polynomials being
> > factored to be vaguely generic).
>
> My observation is that random polynomials are almost always irreducible.  This
> fact seems in startling contrast to the case for integers!  

Yes I believe this.

> For instance:
> sage: R.=ZZ[]
> sage: R.random_element(6,-2^23,2^23).factor()
> # virtually always 1 factor
> I've actually been doing tests of 3 different cases (not all of which made it
> to the mailing list).
> 1) product of a bunch of small factors
> 2) product of 2 medium factors
> 3) random (irreducible by comments above)
>
> NTL seems to gain a bit relative to pari when there are non-trivial factors,
> but it doesn't seem too significant.

That doesn't surprise me. NTL probably tries to find these.

>  It's main influence in my cutoff points
> has been to let NTL factor small polys out to degree 30 rather than degree
> 10.  But both are so competitive for degree 10-20 that it's not that big of a
> deal.

That's interesting. Pari has certainly yielded some surprises
recently.

The generic poly profile is currently running. I'll post the graph
when it is done, So far Pari at least, doesn't look much faster than
it was before.

Bill.
--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] blog post about sage: "today, there is a wide range of high-quality open source apps, and the list keeps on growing. Here's the latest, and it's a biggie:"

[William Stein]

Hi Sage-Devel,

From

http://opendotdotdot.blogspot.com/2007/12/sage-does-maths-of-free-software.html

"One of the persistent myths about free software is that successes
like Linux are one-offs, and that the open source methodology can't be
applied easily to tackle complex software challenges. In the early
days of free software, the relative paucity of end-user apps was
trotted out as proof of this idea - The GIMP stood in splendid
isolation back then.

Things have change, though; today, there is a wide range of
high-quality open source apps, and the list keeps on growing. Here's
there latest, and it's a biggie: 

http://opendotdotdot.blogspot.com/2007/12/sage-does-maths-of-free-software.html
"

 -- 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: elliptic curve issues

[John Cremona]

eclib is ok (though I was tempted to make if jeclib ;)) though it does
not capture the new modular symbol functionality, it is snappier than
(say) meclib.  Of course we should have started to think about this
back at SD6.

On 20/12/2007, William Stein <[EMAIL PROTECTED]> wrote:
>
> On Dec 20, 2007 4:21 AM, John Cremona <[EMAIL PROTECTED]> wrote:
> > Topic 2: package names.
> >
> > I am a little embarrassed that there is precisely one package (spkg)
> > whose name is a person's name (especially when it apparently results
> > in bug reports of the form "cremona causes fatal crash").  It has
> > never occurred to me to invent a name for my programs collectively
> > though.
>
> * How about "eclib", for "elliptic curve library"?
> Googling for that suggests it would be a good choice of name.
>
> * "ecl" is not a good choice, since it is already taken by a programming
> language and a lisp implementation
>
>
> >
> > Topic 3: trac #1058: the mwrank interface barfs on bad input
> >
> > The issue here is whether to extend mwrank_EllipticCurve to allow
> > curves with rational (as opposed to integral) coefficients.  I have
> > been thinking about this.  I do not want to rewrite my elliptic curve
> > code from scratch, but some things would be relatively easy:
> > * allowing the mwrank binary to accept 5-tuples of rationals to define a 
> > curve
> > * allowing the two_descent class (which computes rank and the MW
> > group) to accept rationals
> >  -- in each case, the generating points returned would be correctly
> > mapped back to the input not-necessarily-integral model.
> >
> > But it would be a lot harder to extend this to all the other
> > functionality, to the extent that a Sage user could construct an
> > mwrank_EllipticCurve which was not integral.  Since I guess hardly any
> > Sage users actually construct mwrank_EllipticCurves anyway, would that
> > be a problem?
>
> I think making mwrank_EllipticCurve give an error on non-integral
> input is fine, since nobody should use mwrank .   Transforming a
> curve to integral form first should be done in Sage.
>

OK, so I will add the functionality to allow rational input both for
command-line mwrank and for the two_descent class which Sage's rank
function calls.  Watch this space.

John

> William
>
> >
>


-- 
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] traffic to sagemath.org

[William Stein]

Hi Sage Developers,

With help from Martin Albrecht, I've been tracking the traffic to
sagemath.org here:

http://sagemath.org/traffic.html

Probably the most interesting graph is this one:

http://www.alexa.com/data/details/traffic_details/sagemath.org?site0=sagemath.org&site1=www.maplesoft.com&site2=www.wolfram.com

it compares Sagemath.org to Maplesoft.com up until Dec 17. Before the
UW press release (inspired by Trophees du Libre ), sagemath.org
traffic was insignificant when compared to Maple.   On Dec 3 when the
press release went out until Dec 11, there was a huge spike in
traffic, so that sagemath.org went from being a speck to over twice
the amount of traffic as Maple gets.  NOTE -- this increase in traffic
started two days before the slashdotting.  On Dec 5 during the
slashdotting, the number of downloads of sage itself went up a huge
amount (thousands per day).  This hump died down after about a week on
December 11.  However, the steady state for sagemath.org during the
last week has been similar to and sometimes slightly hire than
maplesoft.com.   This suggests that the number of Sage users has gone
up by quite a bit, and that a nontrivial fraction of the people who
tried Sage a week ago are now Sage users.   Traffic to sagemath.org
has gone from "0"  as measured by "Alexa" to comparable to Maple.

Perhaps soon

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

can be closed and replaced by a ticket to have 100,000 users?


(and yes, I posted a version of the above email to
http://sagemath.blogspot.com/)


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


-- 
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: elliptic curve issues

[William Stein]

On Dec 20, 2007 9:55 AM, John Cremona <[EMAIL PROTECTED]> wrote:
>
> eclib is ok (though I was tempted to make if jeclib ;))

If you make it eclib you increase the chances of getting
outside contributions a little maybe.  Also, I personally
hope that your code gets picked up and improved a lot
by other people in addition to you.  Imagine if instead
of starting from scratch the Magma or PARI developers had
spent all their effort improving your C++ libraries, and making
the results freely available and usable from their systems?
Then eclib would now have 3-descent, 4-descent, S-integral points,
etc.   Just packaging your code in a way that encourages contributions
could lead to just that sort of thing happening in the years to come.
Also, packaging it with Sage means that basically anybody can
trivially build all your code from source, and hence start working
on it (without having to worry about build issues).

> though it does
> not capture the new modular symbol functionality, it is snappier than
> (say) meclib.  Of course we should have started to think about this
> back at SD6.

Your modular symbols functionality is all geared toward and motivated by
elliptic curves, so I think it's an OK name.

 William

>
>
> On 20/12/2007, William Stein <[EMAIL PROTECTED]> wrote:
> >
> > On Dec 20, 2007 4:21 AM, John Cremona <[EMAIL PROTECTED]> wrote:
> > > Topic 2: package names.
> > >
> > > I am a little embarrassed that there is precisely one package (spkg)
> > > whose name is a person's name (especially when it apparently results
> > > in bug reports of the form "cremona causes fatal crash").  It has
> > > never occurred to me to invent a name for my programs collectively
> > > though.
> >
> > * How about "eclib", for "elliptic curve library"?
> > Googling for that suggests it would be a good choice of name.
> >
> > * "ecl" is not a good choice, since it is already taken by a programming
> > language and a lisp implementation
> >
> >
> > >
> > > Topic 3: trac #1058: the mwrank interface barfs on bad input
> > >
> > > The issue here is whether to extend mwrank_EllipticCurve to allow
> > > curves with rational (as opposed to integral) coefficients.  I have
> > > been thinking about this.  I do not want to rewrite my elliptic curve
> > > code from scratch, but some things would be relatively easy:
> > > * allowing the mwrank binary to accept 5-tuples of rationals to define a 
> > > curve
> > > * allowing the two_descent class (which computes rank and the MW
> > > group) to accept rationals
> > >  -- in each case, the generating points returned would be correctly
> > > mapped back to the input not-necessarily-integral model.
> > >
> > > But it would be a lot harder to extend this to all the other
> > > functionality, to the extent that a Sage user could construct an
> > > mwrank_EllipticCurve which was not integral.  Since I guess hardly any
> > > Sage users actually construct mwrank_EllipticCurves anyway, would that
> > > be a problem?
> >
> > I think making mwrank_EllipticCurve give an error on non-integral
> > input is fine, since nobody should use mwrank .   Transforming a
> > curve to integral form first should be done in Sage.
> >
>
> OK, so I will add the functionality to allow rational input both for
> command-line mwrank and for the two_descent class which Sage's rank
> function calls.  Watch this space.
>
> John
>
> > William
>
> >
> > >
> >
>
>
> --
> 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: elliptic curve issues

[John Cremona]

OK, I'm convinced.  So the next version I submit of cremona*.spkg will
in fact be called eclib-.spkg.

I hope the release managers will cooperate!

Incidentally, cremona-20071116 can be removed from the list of
optional packages currently available as it's an older version of what
is now a non-optional package!

John

On 20/12/2007, William Stein <[EMAIL PROTECTED]> wrote:
>
> On Dec 20, 2007 9:55 AM, John Cremona <[EMAIL PROTECTED]> wrote:
> >
> > eclib is ok (though I was tempted to make if jeclib ;))
>
> If you make it eclib you increase the chances of getting
> outside contributions a little maybe.  Also, I personally
> hope that your code gets picked up and improved a lot
> by other people in addition to you.  Imagine if instead
> of starting from scratch the Magma or PARI developers had
> spent all their effort improving your C++ libraries, and making
> the results freely available and usable from their systems?
> Then eclib would now have 3-descent, 4-descent, S-integral points,
> etc.   Just packaging your code in a way that encourages contributions
> could lead to just that sort of thing happening in the years to come.
> Also, packaging it with Sage means that basically anybody can
> trivially build all your code from source, and hence start working
> on it (without having to worry about build issues).
>
> > though it does
> > not capture the new modular symbol functionality, it is snappier than
> > (say) meclib.  Of course we should have started to think about this
> > back at SD6.
>
> Your modular symbols functionality is all geared toward and motivated by
> elliptic curves, so I think it's an OK name.
>
>  William
>
> >
> >
> > On 20/12/2007, William Stein <[EMAIL PROTECTED]> wrote:
> > >
> > > On Dec 20, 2007 4:21 AM, John Cremona <[EMAIL PROTECTED]> wrote:
> > > > Topic 2: package names.
> > > >
> > > > I am a little embarrassed that there is precisely one package (spkg)
> > > > whose name is a person's name (especially when it apparently results
> > > > in bug reports of the form "cremona causes fatal crash").  It has
> > > > never occurred to me to invent a name for my programs collectively
> > > > though.
> > >
> > > * How about "eclib", for "elliptic curve library"?
> > > Googling for that suggests it would be a good choice of name.
> > >
> > > * "ecl" is not a good choice, since it is already taken by a programming
> > > language and a lisp implementation
> > >
> > >
> > > >
> > > > Topic 3: trac #1058: the mwrank interface barfs on bad input
> > > >
> > > > The issue here is whether to extend mwrank_EllipticCurve to allow
> > > > curves with rational (as opposed to integral) coefficients.  I have
> > > > been thinking about this.  I do not want to rewrite my elliptic curve
> > > > code from scratch, but some things would be relatively easy:
> > > > * allowing the mwrank binary to accept 5-tuples of rationals to define 
> > > > a curve
> > > > * allowing the two_descent class (which computes rank and the MW
> > > > group) to accept rationals
> > > >  -- in each case, the generating points returned would be correctly
> > > > mapped back to the input not-necessarily-integral model.
> > > >
> > > > But it would be a lot harder to extend this to all the other
> > > > functionality, to the extent that a Sage user could construct an
> > > > mwrank_EllipticCurve which was not integral.  Since I guess hardly any
> > > > Sage users actually construct mwrank_EllipticCurves anyway, would that
> > > > be a problem?
> > >
> > > I think making mwrank_EllipticCurve give an error on non-integral
> > > input is fine, since nobody should use mwrank .   Transforming a
> > > curve to integral form first should be done in Sage.
> > >
> >
> > OK, so I will add the functionality to allow rational input both for
> > command-line mwrank and for the two_descent class which Sage's rank
> > function calls.  Watch this space.
> >
> > John
> >
> > > William
> >
> > >
> > > >
> > >
> >
> >
> > --
> > John Cremona
> >
> > >
> >
>
>
>
> --
> William Stein
> Associate Professor of Mathematics
> University of Washington
> http://wstein.org
>
> >
>


-- 
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Fwd: Symbolic Computation and Cryptography 2008

[Martin Albrecht]

Hi there,

I am not sure if forwarding this e-mail is considered spaming the list but I 
figured some of the Sage developers would like to be aware of this if they 
aren't already.

Sorry, if I am wrong,
Martin

==


SCC 2008
 First International Conference on Symbolic Computation and Cryptography
  http://www.cc4cm.org/scc2008
Beijing, China, April 28-30, 2008

  FIRST CALL FOR PAPERS


SCC 2008 is the first of a new series of conferences where research and
development in symbolic computation and cryptography may be presented
and discussed. It is organized in response to the growing interest in
applying and developing methods, techniques, and software tools of symbolic
computation for cryptography. The use of lattice reduction algorithms in 
cryptology and the application of Groebner bases in the context of algebraic 
attacks are typical examples of explored applications.

SCC 2008 aims at providing an interactive forum for interested
researchers to exchange ideas and views, to present research results and 
progress, and to learn and discuss recent developments and emerging problems 
on

- the design, modeling, and analysis of cryptographic systems and protocols
  for which symbolic computation may be used or needed, and
- the design, implementation, and analysis of algorithms and software tools
  of symbolic computation that may have potential applications in   
  cryptography.

TOPICS

Specific topics for SCC 2008 include, but are not limited to:

- Multivariate cryptography, braid group cryptography, noncommutative
  cryptography, and quantum cryptography
- Code-based, factorization-based, and lattice-based cryptography
- Algebraic attacks for block ciphers, stream ciphers, and hash functions
- Design and analysis of algebraic, elliptic, and embedded cryptographic
  systems and protocols
- Groebner basis techniques in cryptology, algebraic number theory, and
  coding theory
- Triangular sets and new techniques for solving algebraic systems over
  finite fields
- Algorithms and software for symbolic computation in cryptography

INVITED SPEAKERS

Bruno Buchberger (Johannes Kepler Universitaet Linz, Austria)
Arjen K. Lenstra (Ecole Polytechnique Federale de Lausanne, Switzerland)
 (to be confirmed)
Adi Shamir (Weizmann Institute of Science, Israel)
Xiaoyun Wang (Tsinghua University and Shandong University, China)

SUBMISSION

Potential participants of SCC 2008 are invited to submit extended
abstracts of 3-5 pages or full papers describing their work to be
presented at the conference. The submitted extended abstracts and
full papers will be reviewed by members of the program committee (PC)
for soundness and relevance to the conference. Submission of original
research papers is encouraged, while published material and work in
progress will also be considered for presentation at the conference.
Extended abstracts and full papers should be prepared using LaTeX with
the style file available on the SCC 2008 webpage and according to the
instructions given therein. Submissions must be done electronically
via EasyChair at http://www.easychair.org/conferences/?conf=scc2008 or
sent in PDF or PS format as e-mail attachments to scc2008 @ cc4cm.org.

Accepted extended abstracts and full papers will be printed in the
proceedings of SCC 2008 for distribution at the conference.

PUBLICATION

Authors of the extended abstracts and full papers accepted for
presentation at the conference will be invited to submit their full
and/or revised papers for publication in special issues of
Mathematics in Computer Science (MCS - http://www.cc4cm.org/mcs) by
Birkhauser/Springer after the meeting. The submitted papers will be
formally reviewed by PC members and external referees according to
the standard refereeing procedure of MCS.

IMPORTANT DATES

Deadline for extended abstract submission:  February 17, 2008
Notification of acceptance or rejection:March 16, 2008
Conference taking place:April 28-30, 2008
Deadline for full paper submission: June 30, 2008

GENERAL CHAIR

Zhiming Zheng (China)

PROGRAM COMMITTEE

Anne Canteaut (France)   Jintai Ding (USA)
Jean-Charles Faugere, Co-chair (France)  Joachim von zur Gathen
(Germany)
Pierrick Gaudry (France) Jaime Gutierrez (Spain)
Hoon Hong (USA)  Antoine Joux (France)
Martin Kreuzer (Germany) Dongdai Lin (China)
Zhuojun Liu (China)  Alexander May (Germany)
Ludovic Perret (France)  Igor Shparlinski (Australia)
Rainer Steinwandt (USA)  Boaz Tsaban (Israel)
Dongming Wang, Co-chair (China/France)

LOCAL ARRANGEMENTS

Shangzhi Li, Chair (China)  Jinxi Ma (China)  Chenqi Mou (China)


-- 
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_www: http://www.informatik.un

[sage-devel] plotting vectors

[Jason Grout]

Hi all,

I'm teaching linear algebra next semester and plan to use Sage.  In 
trying the "obvious" way to plot a vector:

sage: v=vector([1,2])
sage: v.plot().show()

I get what looks like a step function of the coordinates.  Instead, I 
have to do:

sage: v=vector([1,2])
sage: arrow((0,0),v).show()

which doesn't seem quite so natural to an undergraduate linear algebra 
student.  First, is there an easier way to plot a vector (yes, I know I 
don't have to define v above and could just give the coordinates to 
arrow, but usually I'll be doing something with v as a vector)?  Is it 
reasonable to redefine v.plot() to return the arrow for a vector with 3 
or fewer dimensions, or is there some bigger reason to have things the 
way they are now?

Thanks,

Jason


--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] build failures on Ubuntu and RHEL

[noo]

Hi,
First two attempts to build sage failed.
One on Ubuntu 7.10 with a gcc (4.1.3) internal error.
Other on RHEL4 due to malformed config.h in spkg/build/ntl-5.4.1.p9/
src/src/.
Details below FYI.
Best wishes in this effort.

_
(1) Ubuntu 7.10
Intel Pentium M Processor 1.86GHz
$ uname -a
Linux compname 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007
i686 GNU/Linux

$ g++ --version
g++ (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
Copyright (C) 2006 Free Software Foundation, Inc.

>From install.log:

g++ -DPACKAGE_NAME=\"liblinboxwrap\" -DPACKAGE_TARNAME=\"liblinboxwrap
\" -DPACKAGE_VERSION=\"0.0.1\" "-DPACKAGE_STRING=\"liblinboxwrap
0.0.1\"" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"liblinboxwrap\" -
DVERSION=\"0.0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -
DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -
DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -
DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -
DHAVE_BLAS=1 -I. -g -I/home/lastname/downloads/sage-2.9/local/include/
linbox -I/home/lastname/downloads/sage-2.9/local/include -g -fPIC -I/
home/lastname/downloads/sage-2.9/local/include -I/home/lastname/
downloads/sage-2.9/local/include/linbox -L/home/lastname/downloads/
sage-2.9/local/lib -MT linbox_wrap.lo -MD -MP -MF .deps/
linbox_wrap.Tpo -c src/linbox_wrap.cpp  -fPIC -DPIC -o .libs/
linbox_wrap.o
g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions, see
.

make[2]: *** [linbox_wrap.lo] Error 1
make[2]: Leaving directory `/data/home/lastname/downloads/sage-2.9/
spkg/build/linbox-20070915.p3/linbox_wrap'
Error installing linboxwrap
_
(2) RedHat Enterprise Linux 4
$ uname -a
Linux compname 2.6.9-67.EL #1 Wed Nov 7 13:41:13 EST 2007 i686 i686
i386 GNU/Linux
$ cat /proc/cpuinfo
model name  : Intel(R) Pentium(R) 4 CPU 2.93GHz

$ g++ --version
g++ (GCC) 4.2.1

$ perl -v
This is perl, v5.8.5 built for i386-linux-thread-multi

NTL/config.h has lines that say just "#if".
>From install.log, many errors like this:

In file included from GetTime5.c:1:
../include/NTL/config.h:57:5: error: #if with no expression
../include/NTL/config.h:88:5: error: #if with no expression
[similar lines]
../include/NTL/config.h:306:7: error: #if with no expression
some thing is wrong...
make[3]: *** [setup2] Error 1
make[3]: Leaving directory `/orange1/lastname/downloads/sage-2.9/spkg/
build/ntl-5.4.1.p9/src/src'
make[2]: *** [lib] Error 2
make[2]: Leaving directory `/orange1/lastname/downloads/sage-2.9/spkg/
build/ntl-5.4.1.p9/src/src'
Error creating ntl shared library.

real0m40.531s
user0m30.030s
sys 0m1.977s
sage: An error occurred while installing ntl-5.4.1.p9

--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: factoring benchmarks

[Bill Hart]

Here is the graph for generic polynomials:

http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/factor-gen.png

At about 1000 bits and length 6, NTL does seem to get ahead again.

Bill.
--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: build failures on Ubuntu and RHEL

[William Stein]

On Dec 20, 2007 10:44 AM, noo <[EMAIL PROTECTED]> wrote:
>
> Hi,
> First two attempts to build sage failed.
> One on Ubuntu 7.10 with a gcc (4.1.3) internal error.
> Other on RHEL4 due to malformed config.h in spkg/build/ntl-5.4.1.p9/
> src/src/.
> Details below FYI.
> Best wishes in this effort.
>
> _
> (1) Ubuntu 7.10
> Intel Pentium M Processor 1.86GHz
> $ uname -a
> Linux compname 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007
> i686 GNU/Linux
>
> $ g++ --version
> g++ (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
> Copyright (C) 2006 Free Software Foundation, Inc.
>
> From install.log:
>
> g++ -DPACKAGE_NAME=\"liblinboxwrap\" -DPACKAGE_TARNAME=\"liblinboxwrap
> \" -DPACKAGE_VERSION=\"0.0.1\" "-DPACKAGE_STRING=\"liblinboxwrap
> 0.0.1\"" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"liblinboxwrap\" -
> DVERSION=\"0.0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -
> DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -
> DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -
> DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -
> DHAVE_BLAS=1 -I. -g -I/home/lastname/downloads/sage-2.9/local/include/
> linbox -I/home/lastname/downloads/sage-2.9/local/include -g -fPIC -I/
> home/lastname/downloads/sage-2.9/local/include -I/home/lastname/
> downloads/sage-2.9/local/include/linbox -L/home/lastname/downloads/
> sage-2.9/local/lib -MT linbox_wrap.lo -MD -MP -MF .deps/
> linbox_wrap.Tpo -c src/linbox_wrap.cpp  -fPIC -DPIC -o .libs/
> linbox_wrap.o
> g++: Internal error: Killed (program cc1plus)


That makes it a GCC bug.  You should upgrade or downgrade
your version of GCC.  Currently you are using "g++ (GCC) 4.1.3
20070929 (prerelease)", i.e. a prerelease version of GCC, i.e., one
that is
very *likely* to have bugs.

I regularly build sage on ubuntu 7.10 using GCC-4.1.2.

> Please submit a full bug report.
> See http://gcc.gnu.org/bugs.html> for instructions.
> For Debian GNU/Linux specific bug reporting instructions, see
> .
>
> make[2]: *** [linbox_wrap.lo] Error 1
> make[2]: Leaving directory `/data/home/lastname/downloads/sage-2.9/
> spkg/build/linbox-20070915.p3/linbox_wrap'
> Error installing linboxwrap
>

_
> (2) RedHat Enterprise Linux 4
> $ uname -a
> Linux compname 2.6.9-67.EL #1 Wed Nov 7 13:41:13 EST 2007 i686 i686
> i386 GNU/Linux
> $ cat /proc/cpuinfo
> model name  : Intel(R) Pentium(R) 4 CPU 2.93GHz
>
> $ g++ --version
> g++ (GCC) 4.2.1
>
> $ perl -v
> This is perl, v5.8.5 built for i386-linux-thread-multi
>
> NTL/config.h has lines that say just "#if".

This looks like something going wrong with the ntl auto-tuning code.
I regularly build sage on RHEL 4 also, I think using GCC-4.2.1,
so I don't know what is going wrong here.  We can easily
make a version of the ntl spkg that doesn't do tuning for you
as a test.   Anyway, please post a link to the install.log for that
RHEL build.

> From install.log, many errors like this:
>
> In file included from GetTime5.c:1:
> ../include/NTL/config.h:57:5: error: #if with no expression
> ../include/NTL/config.h:88:5: error: #if with no expression
> [similar lines]
> ../include/NTL/config.h:306:7: error: #if with no expression
> some thing is wrong...
> make[3]: *** [setup2] Error 1
> make[3]: Leaving directory `/orange1/lastname/downloads/sage-2.9/spkg/
> build/ntl-5.4.1.p9/src/src'
> make[2]: *** [lib] Error 2
> make[2]: Leaving directory `/orange1/lastname/downloads/sage-2.9/spkg/
> build/ntl-5.4.1.p9/src/src'
> Error creating ntl shared library.
>
> real0m40.531s
> user0m30.030s
> sys 0m1.977s
> sage: An error occurred while installing ntl-5.4.1.p9
>
> >
>



-- 
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: build failures on Ubuntu and RHEL

[Ismail Dönmez]

Thursday 20 December 2007 20:11:04 tarihinde William Stein şunları yazmıştı:
> On Dec 20, 2007 10:44 AM, noo <[EMAIL PROTECTED]> wrote:
> > Hi,
> > First two attempts to build sage failed.
> > One on Ubuntu 7.10 with a gcc (4.1.3) internal error.
> > Other on RHEL4 due to malformed config.h in spkg/build/ntl-5.4.1.p9/
> > src/src/.
> > Details below FYI.
> > Best wishes in this effort.
> >
> > _
> > (1) Ubuntu 7.10
> > Intel Pentium M Processor 1.86GHz
> > $ uname -a
> > Linux compname 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007
> > i686 GNU/Linux
> >
> > $ g++ --version
> > g++ (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
> > Copyright (C) 2006 Free Software Foundation, Inc.
> >
> > From install.log:
> >
> > g++ -DPACKAGE_NAME=\"liblinboxwrap\" -DPACKAGE_TARNAME=\"liblinboxwrap
> > \" -DPACKAGE_VERSION=\"0.0.1\" "-DPACKAGE_STRING=\"liblinboxwrap
> > 0.0.1\"" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"liblinboxwrap\" -
> > DVERSION=\"0.0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -
> > DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -
> > DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -
> > DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -
> > DHAVE_BLAS=1 -I. -g -I/home/lastname/downloads/sage-2.9/local/include/
> > linbox -I/home/lastname/downloads/sage-2.9/local/include -g -fPIC -I/
> > home/lastname/downloads/sage-2.9/local/include -I/home/lastname/
> > downloads/sage-2.9/local/include/linbox -L/home/lastname/downloads/
> > sage-2.9/local/lib -MT linbox_wrap.lo -MD -MP -MF .deps/
> > linbox_wrap.Tpo -c src/linbox_wrap.cpp  -fPIC -DPIC -o .libs/
> > linbox_wrap.o
> > g++: Internal error: Killed (program cc1plus)
>
> That makes it a GCC bug.  You should upgrade or downgrade
> your version of GCC.  Currently you are using "g++ (GCC) 4.1.3
> 20070929 (prerelease)", i.e. a prerelease version of GCC, i.e., one
> that is
> very *likely* to have bugs.
>
> I regularly build sage on ubuntu 7.10 using GCC-4.1.2.

FWIW linbox builds fine with gcc 4.3 snapshot.

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.

--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: elliptic curve issues

[William Stein]

On Dec 20, 2007 10:18 AM, John Cremona <[EMAIL PROTECTED]> wrote:
>
> OK, I'm convinced.  So the next version I submit of cremona*.spkg will
> in fact be called eclib-.spkg.
>
> I hope the release managers will cooperate!

They will.

> Incidentally, cremona-20071116 can be removed from the list of
> optional packages currently available as it's an older version of what
> is now a non-optional package!
>
> John

OK, done.

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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: elliptic curve issues

[Robert Bradshaw]

On Dec 20, 2007, at 3:21 AM, John Cremona wrote:

> Topic 1: isomorphisms between Weierstrass models
>
> For Robert B as author of weierstrass_morphism.py:  It's not a bug but
> I would recommend that you test for equality of j-invariants before
> doing the harder work (which you do by extracting 12th roots of the
> ratio of the discriminants).  Similarly in
>
> elliptic_curves/ell_generic.py
>
> in the function is_isomorphic().

Good point.

> Also, I am yet to be convinced that
> the code in weierstrass_morphism.py is correct, but I will reserve
> judgement until I have a counterexample.
> It certainly is *not* correct in char. 2 & 3 since you divide by 2  
> and 3!

I think I put a note in there about characteristic 2 and 3, but if  
not there should be one. Other than that, if I've made a mistake I'll  
be happy to be proven wrong, but I'm pretty confident.

> I have always done this using the ratio of c4 and/or c6 invariants,
> which is fine except in characteristics 2 and 3 anyway, and also
> simpler (since unless j=0 or j=1728 you only need to test for
> something being a square, not need for 12'th roots).  That code can
> already be found in simon's ellQ.gp (the new version incorporating
> some improvements I suggested to him).  But it does not deal with char
> 2 & 3, which I'll sit down and work through one day, and then submit
> an improved version of weierstrass_morphism.py.

OK, I'll take a look at that.

- Robert

--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: plotting vectors

[William Stein]

On Dec 19, 2007 12:24 PM, Jason Grout <[EMAIL PROTECTED]> wrote:
> I'm teaching linear algebra next semester and plan to use Sage.  In
> trying the "obvious" way to plot a vector:
>
> sage: v=vector([1,2])
> sage: v.plot().show()
>
> I get what looks like a step function of the coordinates.

Yes, that's what it is.  This is very useful, e.g., when using
vectors of data, computing Fourier transforms of them, etc.
And it works in arbitrary dimensions.

>  Instead, I
> have to do:
>
> sage: v=vector([1,2])
> sage: arrow((0,0),v).show()
>
> which doesn't seem quite so natural to an undergraduate linear algebra
> student.  First, is there an easier way to plot a vector (yes, I know I
> don't have to define v above and could just give the coordinates to
> arrow, but usually I'll be doing something with v as a vector)?  Is it
> reasonable to redefine v.plot() to return the arrow for a vector with 3
> or fewer dimensions, or is there some bigger reason to have things the
> way they are now?

I think that would be bad, because it's potentially confusing and
unsystematic.  However, the following -- which you will like --
would be acceptable to me:

   Redefine v.plot() so for dimensions <= 3 it does what you describe above,
i.e., draws an arrow, but for dimensions >= 4 it gives an error message.
Then add an option to plot called "step", which if set to True restores
the current behavior.

In fact, this was my intention all along, and somehow I screwed up.
The current plot signature for vectors is:

def plot(self, xmin=0, xmax=1, eps=None, res=None,
 connect=True, step=False, **kwds):

Notice that step=False is already there!

Anyway, this is now
   http://trac.sagemath.org/sage_trac/ticket/1575


-- 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: factoring benchmarks

[Bill Hart]

I've redone both graphs since the generic NTL profiling code in FLINT
was assuming that a length n polynomial had n+1 coefficients (my
student had done this due to some confusion about the way coefficients
were counted).

The graph for polynomials with two large factors (at least):

http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/factor.png

and the graph for generic polynomials:

http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/factor-gen.png

Hopefully these are correct now.

Bill.

On 20 Dec, 17:49, Bill Hart <[EMAIL PROTECTED]> wrote:
> Here is the graph for generic polynomials:
>
> http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/fact...
>
> At about 1000 bits and length 6, NTL does seem to get ahead again.
>
> Bill.
--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: build failures on Ubuntu and RHEL

[noo]

http://copper.math.buffalo.edu/sage2.9_install.log

On Dec 20, 1:11 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> On Dec 20, 2007 10:44 AM, noo <[EMAIL PROTECTED]> wrote:
>
 ...
>
> This looks like something going wrong with the ntl auto-tuning code.
> I regularly build sage on RHEL 4 also, I think using GCC-4.2.1,
> so I don't know what is going wrong here.  We can easily
> make a version of the ntl spkg that doesn't do tuning for you
> as a test.   Anyway, please post a link to the install.log for that
> RHEL build.
>
>
>
> > From install.log, many errors like this:
>
> > In file included from GetTime5.c:1:
> > ../include/NTL/config.h:57:5: error: #if with no expression
> > ../include/NTL/config.h:88:5: error: #if with no expression
> > [similar lines]
> > ../include/NTL/config.h:306:7: error: #if with no expression
> > some thing is wrong...
> > make[3]: *** [setup2] Error 1
> > make[3]: Leaving directory `/orange1/lastname/downloads/sage-2.9/spkg/
> > build/ntl-5.4.1.p9/src/src'
> > make[2]: *** [lib] Error 2
> > make[2]: Leaving directory `/orange1/lastname/downloads/sage-2.9/spkg/
> > build/ntl-5.4.1.p9/src/src'
> > Error creating ntl shared library.
>
> > real0m40.531s
> > user0m30.030s
> > sys 0m1.977s
> > sage: An error occurred while installing ntl-5.4.1.p9
>
> --
> William Stein
> Associate Professor of Mathematics
> University of Washingtonhttp://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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: ticket 1441 -- latex(x_1,x1)

[Jason Grout]

Robert Bradshaw wrote:
> On Dec 19, 2007, at 4:07 AM, Joel B. Mohler wrote:
> 
>> On Tuesday 18 December 2007 22:54, Jason Grout wrote:
>>> How would you propose getting an output like the second command?  I
>>> guess one possibility is that:
>>>
>>> sage: latex(var('variable123')) # where 123 could be any number
>>> variable_{123}
>>>
>>> but
>>>
>>> sage: latex(var('variable_n'))
>>> variable_{n}
>> Jason, I'm not sure from your post if you are aware of this, but  
>> this is
>> exactly the way it currently is coded for exactly the reasons you  
>> mention.
>> This was my design goal when I rewrote some latex'ing code a month  
>> ago.
>>
>> x1 -> x_1
>> x_1 -> x_1
>> x_n -> x_n
>> xn -> \text{xn}
>> alpha1 -> \alpha_1
>>
>> etc.  (I omitted '{','}' for clutter reduction.)
>>
>> So, I would summarize Robert and Jason's discussion as agreeing  
>> that the bug
>> is invalid?
> 
> Yes.

If this bug is marked invalid, I think we ought to have huge warning 
signs somewhere.  I think the bug has a good point about the current 
behavior being confusing to a new user.  I do like the convenience the 
current approach affords.

Jason


--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: elliptic curve issues

[John Cremona]

I believe that it's fine in characteristics not 2 or 3.  But once you
have checked equality of j-invariants (which is of course easy and
should be done first) and you have a candidate u, then computing r,s,t
appropriately will give a transform which is *guaranteed* to be
correct.

My question to you is:  suppose that u^12 has more than one 12th root
in K.  You pick one of them, call it u,  and try to construct r,s,t,
and you check that the transform then works.  But what if one 12th
root works and another doesn't?   If you try the one which does not
work first then you'll miss the isomorphism and give an incorrect
negative answer.  So it's up to you to prove to me that this does not
happen (or change the code).

John

On 20/12/2007, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
>
> On Dec 20, 2007, at 3:21 AM, John Cremona wrote:
>
> > Topic 1: isomorphisms between Weierstrass models
> >
> > For Robert B as author of weierstrass_morphism.py:  It's not a bug but
> > I would recommend that you test for equality of j-invariants before
> > doing the harder work (which you do by extracting 12th roots of the
> > ratio of the discriminants).  Similarly in
> >
> > elliptic_curves/ell_generic.py
> >
> > in the function is_isomorphic().
>
> Good point.
>
> > Also, I am yet to be convinced that
> > the code in weierstrass_morphism.py is correct, but I will reserve
> > judgement until I have a counterexample.
> > It certainly is *not* correct in char. 2 & 3 since you divide by 2
> > and 3!
>
> I think I put a note in there about characteristic 2 and 3, but if
> not there should be one. Other than that, if I've made a mistake I'll
> be happy to be proven wrong, but I'm pretty confident.
>
> > I have always done this using the ratio of c4 and/or c6 invariants,
> > which is fine except in characteristics 2 and 3 anyway, and also
> > simpler (since unless j=0 or j=1728 you only need to test for
> > something being a square, not need for 12'th roots).  That code can
> > already be found in simon's ellQ.gp (the new version incorporating
> > some improvements I suggested to him).  But it does not deal with char
> > 2 & 3, which I'll sit down and work through one day, and then submit
> > an improved version of weierstrass_morphism.py.
>
> OK, I'll take a look at that.
>
> - Robert
>
> >
>


-- 
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: ticket 1441 -- latex(x_1,x1)

[William Stein]

On Dec 20, 2007 12:23 PM, Jason Grout <[EMAIL PROTECTED]> wrote:
>
> >> So, I would summarize Robert and Jason's discussion as agreeing
> >> that the bug
> >> is invalid?
> >
> > Yes.
>
> If this bug is marked invalid, I think we ought to have huge warning
> signs somewhere.  I think the bug has a good point about the current
> behavior being confusing to a new user.  I do like the convenience the
> current approach affords.

This bug is now marked invalid.  Where would the huge warning sign
be?  Perhaps in the output of
   sage: latex?

In fact, latex? doesn't print *anything* right now at all, so somebody
writing some documentation and docstrings there would be good!

We really need to have a "doc day".

 -- 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: plotting vectors

[John Cremona]

I have never been a fan of the "arrow" view of vectors, as (to my
mind) it causes a lot of confusion when the students move on to "real"
multidimensional linear algebra.  What I would expect to see if I
asked for a plot of the (real) vector (2,1) would be a big fat dot at
the appropriate position in the plane.

Aren't arrow-type vectors another type of object altogether?  Since
they have a start and an end point, where you are taking the start
point to be the origin?  Personally I think those should be given
another name altogether!

John

On 20/12/2007, William Stein <[EMAIL PROTECTED]> wrote:
>
> On Dec 19, 2007 12:24 PM, Jason Grout <[EMAIL PROTECTED]> wrote:
> > I'm teaching linear algebra next semester and plan to use Sage.  In
> > trying the "obvious" way to plot a vector:
> >
> > sage: v=vector([1,2])
> > sage: v.plot().show()
> >
> > I get what looks like a step function of the coordinates.
>
> Yes, that's what it is.  This is very useful, e.g., when using
> vectors of data, computing Fourier transforms of them, etc.
> And it works in arbitrary dimensions.
>
> >  Instead, I
> > have to do:
> >
> > sage: v=vector([1,2])
> > sage: arrow((0,0),v).show()
> >
> > which doesn't seem quite so natural to an undergraduate linear algebra
> > student.  First, is there an easier way to plot a vector (yes, I know I
> > don't have to define v above and could just give the coordinates to
> > arrow, but usually I'll be doing something with v as a vector)?  Is it
> > reasonable to redefine v.plot() to return the arrow for a vector with 3
> > or fewer dimensions, or is there some bigger reason to have things the
> > way they are now?
>
> I think that would be bad, because it's potentially confusing and
> unsystematic.  However, the following -- which you will like --
> would be acceptable to me:
>
>Redefine v.plot() so for dimensions <= 3 it does what you describe above,
> i.e., draws an arrow, but for dimensions >= 4 it gives an error message.
> Then add an option to plot called "step", which if set to True restores
> the current behavior.
>
> In fact, this was my intention all along, and somehow I screwed up.
> The current plot signature for vectors is:
>
> def plot(self, xmin=0, xmax=1, eps=None, res=None,
>  connect=True, step=False, **kwds):
>
> Notice that step=False is already there!
>
> Anyway, this is now
>http://trac.sagemath.org/sage_trac/ticket/1575
>
>
> -- William
>
> >
>


-- 
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: plotting vectors

[William Stein]

On Dec 20, 2007 1:03 PM, John Cremona <[EMAIL PROTECTED]> wrote:
>
> I have never been a fan of the "arrow" view of vectors, as (to my
> mind) it causes a lot of confusion when the students move on to "real"
> multidimensional linear algebra.  What I would expect to see if I
> asked for a plot of the (real) vector (2,1) would be a big fat dot at
> the appropriate position in the plane.
>
> Aren't arrow-type vectors another type of object altogether?  Since
> they have a start and an end point, where you are taking the start
> point to be the origin?  Personally I think those should be given
> another name altogether!
>

Are you confusing the notion of n-tuple and vector?   The definition of
"vector" in pretty much any dictionary is "a quantity having a direction
and magnitude".  Thus it definitely makes sense to plot a vector by giving
an arrow.

 -- Willam

--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: factoring benchmarks

[Bill Hart]

For comparison, here is our favourite non-free closed source package
vs Pari and NTL for factoring with two large factors:

Magma vs Pari:

http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/magpari-factor.png

Magma vs NTL:

http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/magNTL-factor.png

Something that may not be fair here is that Magma factors the content,
so I have divided the polynomials used by their content before
factoring them. But I didn't include the time taken to divide by the
content in the timing. Given that computing the content should be
almost instant generically, I don't see this as much of a problem
though.

Bill.

On 20 Dec, 18:46, Bill Hart <[EMAIL PROTECTED]> wrote:
> I've redone both graphs since the generic NTL profiling code in FLINT
> was assuming that a length n polynomial had n+1 coefficients (my
> student had done this due to some confusion about the way coefficients
> were counted).
>
> The graph for polynomials with two large factors (at least):
>
> http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/fact...
>
> and the graph for generic polynomials:
>
> http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/fact...
>
> Hopefully these are correct now.
>
> Bill.
>
> On 20 Dec, 17:49, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> > Here is the graph for generic polynomials:
>
> >http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/fact...
>
> > At about 1000 bits and length 6, NTL does seem to get ahead again.
>
> > Bill.
--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: "solving" equations that are always true

[William Stein]

On Dec 19, 2007 11:48 AM, Carl Witty <[EMAIL PROTECTED]> wrote:
>
> On Dec 18, 10:49 pm, "[EMAIL PROTECTED]"
> <[EMAIL PROTECTED]> wrote:
> > Is this working as intended?
> >
> > The first statement should return the same as the second, and the
> > third statemnt is ok.
> >
> > sage: solve([3==3, 1.00*x^3 == 0], x)
> > []
> > sage: solve([1.00*x^3 == 0], x)
> > [x == 0]
> > sage: solve([1==3, 1.00*x^3 == 0], x)
> > []
>
> In my opinion, this is a bug.  Thanks for reporting this; it is now
> tracked at http://sagetrac.org/sage_trac/ticket/1569

I think I've fixed this and posted a patch at
   http://sagetrac.org/sage_trac/ticket/1569

Refereeing is, of course, appreciated.

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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: factoring benchmarks

[William Stein]

On Dec 20, 2007 1:13 PM, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> For comparison, here is our favourite non-free closed source package
> vs Pari and NTL for factoring with two large factors:
>
> Magma vs Pari:
>
> http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/magpari-factor.png
>
> Magma vs NTL:
>
> http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/magNTL-factor.png
>
> Something that may not be fair here is that Magma factors the content,
> so I have divided the polynomials used by their content before
> factoring them. But I didn't include the time taken to divide by the
> content in the timing. Given that computing the content should be
> almost instant generically, I don't see this as much of a problem
> though.

Conclusion: Magma completely totally devastates both PARI and NTL,
except for some
small cases?  That's what the plots seem to say.

I now really wonder how Maple and Mathematica do in comparison.

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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: factoring benchmarks

[Bill Hart]

And here we go for generic polynomials:

Magma vs Pari:

http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/magpari-factor-gen.png

Magma vs NTL:

http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/magNTL-factor-gen.png

Bill.

On 20 Dec, 20:13, Bill Hart <[EMAIL PROTECTED]> wrote:
> For comparison, here is our favourite non-free closed source package
> vs Pari and NTL for factoring with two large factors:
>
> Magma vs Pari:
>
> http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/magp...
>
> Magma vs NTL:
>
> http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/magN...
>
> Something that may not be fair here is that Magma factors the content,
> so I have divided the polynomials used by their content before
> factoring them. But I didn't include the time taken to divide by the
> content in the timing. Given that computing the content should be
> almost instant generically, I don't see this as much of a problem
> though.
>
> Bill.
>
> On 20 Dec, 18:46, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> > I've redone both graphs since the generic NTL profiling code in FLINT
> > was assuming that a length n polynomial had n+1 coefficients (my
> > student had done this due to some confusion about the way coefficients
> > were counted).
>
> > The graph for polynomials with two large factors (at least):
>
> >http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/fact...
>
> > and the graph for generic polynomials:
>
> >http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/fact...
>
> > Hopefully these are correct now.
>
> > Bill.
>
> > On 20 Dec, 17:49, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> > > Here is the graph for generic polynomials:
>
> > >http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/fact...
>
> > > At about 1000 bits and length 6, NTL does seem to get ahead again.
>
> > > Bill.
--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: example of a Mathematica program from my lecture

[Ondrej Certik]

On Dec 20, 2007 9:39 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
> Hi,
>
> today I was attending a Lie group lecture and the teacher Karel Houfek
> wrote the attached program in Mathematica
> to calculate some Lie groups generators etc. So my first question was
> if I can make it public
> and with his permission I am sending it here.
>
> I think Sage should be able to do it as well, only it has to be
> rewritten in Python. I think William was
> asking me what kind of stuff people do in Mathematica. So this kind of stuff.
>
> However, the biggest problem is the 2GB space for the windows wmware
> image. (Yes, all people I know that
> use Mathematica, use it from windows). Two of my friends told me Sage
> is just too big for them and I agree.
> If Michael and others succeed in a native Windows port, needing just
> couple hundreds MB, then Sage
> will be a killer app.
>
> Mainly because of bringing a matlab/mathematica like Python IDE to all
> those people at universities.
> Sage is really doing a fantastic job to the whole Python community. So
> I hope it will be accepted under
> the umbrella of PSF for the google summer of code.

If not as a standalone mentor organisation. You should definitely try
it again William.

Ondrej

--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage vs Octave

[Ondrej Certik]

> >  (a) eternal peace and prosperity for mankind
> >  (b) infinite personal power and wealth
> >  (c) having the people responsible for designing Fortran run time
> > libraries and linker modes/modules beamed into space
> >
> > I would choose (c) without having to think about it.
>
> I don't know if you guys have yet a little weekly summary of sage
> happenings.  If you do, it would be nice to have a QOTW (Quote of the
> Week) feature, and if you implement it, I heartily vote  for this one
> to be nominated as Sage QOTW :)

Mabshoff have some other cool remarks too. :)

Ondrej

--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: build failures on Ubuntu and RHEL

[mabshoff]

On Dec 20, 7:14 pm, Ismail Dönmez <[EMAIL PROTECTED]> wrote:
> Thursday 20 December 2007 20:11:04 tarihinde William Stein şunları yazmıştı:
>
>
>
> > On Dec 20, 2007 10:44 AM, noo <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > > First two attempts to build sage failed.
> > > One on Ubuntu 7.10 with a gcc (4.1.3) internal error.
> > > Other on RHEL4 due to malformed config.h in spkg/build/ntl-5.4.1.p9/
> > > src/src/.
> > > Details below FYI.
> > > Best wishes in this effort.
>
> > > _
> > > (1) Ubuntu 7.10
> > > Intel Pentium M Processor 1.86GHz
> > > $ uname -a
> > > Linux compname 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007
> > > i686 GNU/Linux
>
> > > $ g++ --version
> > > g++ (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
> > > Copyright (C) 2006 Free Software Foundation, Inc.
>
> > > From install.log:
>
> > > g++ -DPACKAGE_NAME=\"liblinboxwrap\" -DPACKAGE_TARNAME=\"liblinboxwrap
> > > \" -DPACKAGE_VERSION=\"0.0.1\" "-DPACKAGE_STRING=\"liblinboxwrap
> > > 0.0.1\"" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"liblinboxwrap\" -
> > > DVERSION=\"0.0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -
> > > DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -
> > > DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -
> > > DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -
> > > DHAVE_BLAS=1 -I. -g -I/home/lastname/downloads/sage-2.9/local/include/
> > > linbox -I/home/lastname/downloads/sage-2.9/local/include -g -fPIC -I/
> > > home/lastname/downloads/sage-2.9/local/include -I/home/lastname/
> > > downloads/sage-2.9/local/include/linbox -L/home/lastname/downloads/
> > > sage-2.9/local/lib -MT linbox_wrap.lo -MD -MP -MF .deps/
> > > linbox_wrap.Tpo -c src/linbox_wrap.cpp  -fPIC -DPIC -o .libs/
> > > linbox_wrap.o
> > > g++: Internal error: Killed (program cc1plus)
>
> > That makes it a GCC bug.  You should upgrade or downgrade
> > your version of GCC.  Currently you are using "g++ (GCC) 4.1.3
> > 20070929 (prerelease)", i.e. a prerelease version of GCC, i.e., one
> > that is
> > very *likely* to have bugs.
>
> > I regularly build sage on ubuntu 7.10 using GCC-4.1.2.
>
> FWIW linbox builds fine with gcc 4.3 snapshot.
>

But I don't think out linbox.spkg does yet because I haven't merged
the fix yet. There are also a bunch of other spkgs that do not build
"out of the box" yet, but I do have fixes for all of them and they
will probably all make it into 2.9.x over the next two weeks.

Cheers,

Michael

> Regards,
> ismail
>
> --
> Never learn by your mistakes, if you do you may never dare to try again.
--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: factoring benchmarks

[Bill Hart]

I fixed the four magma graphs above so that they take into account the
time to compute and divide by the content, since Pari and NTL
certainly do that.

The result is just about the same. Magma is significantly faster for
longer polynomials, usually a factor of about 2.5, though it varies a
bit.

Bill.

On 20 Dec, 20:28, Bill Hart <[EMAIL PROTECTED]> wrote:
> And here we go for generic polynomials:
>
> Magma vs Pari:
>
> http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/magp...
>
> Magma vs NTL:
>
> http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/magN...
>
> Bill.
>
> On 20 Dec, 20:13, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> > For comparison, here is our favourite non-free closed source package
> > vs Pari and NTL for factoring with two large factors:
>
> > Magma vs Pari:
>
> >http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/magp...
>
> > Magma vs NTL:
>
> >http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/magN...
>
> > Something that may not be fair here is that Magma factors the content,
> > so I have divided the polynomials used by their content before
> > factoring them. But I didn't include the time taken to divide by the
> > content in the timing. Given that computing the content should be
> > almost instant generically, I don't see this as much of a problem
> > though.
>
> > Bill.
>
> > On 20 Dec, 18:46, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> > > I've redone both graphs since the generic NTL profiling code in FLINT
> > > was assuming that a length n polynomial had n+1 coefficients (my
> > > student had done this due to some confusion about the way coefficients
> > > were counted).
>
> > > The graph for polynomials with two large factors (at least):
>
> > >http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/fact...
>
> > > and the graph for generic polynomials:
>
> > >http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/fact...
>
> > > Hopefully these are correct now.
>
> > > Bill.
>
> > > On 20 Dec, 17:49, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> > > > Here is the graph for generic polynomials:
>
> > > >http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/fact...
>
> > > > At about 1000 bits and length 6, NTL does seem to get ahead again.
>
> > > > Bill.
--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: example of a Mathematica program from my lecture

[William Stein]

On Dec 20, 2007 1:39 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
> However, the biggest problem is the 2GB space for the windows wmware
> image. (Yes, all people I know that
> use Mathematica, use it from windows). Two of my friends told me Sage
> is just too big for them and I agree.
> If Michael and others succeed in a native Windows port, needing just
> couple hundreds MB, then Sage
> will be a killer app.

Vmware is not the reason the install is so big.  It could be made much smaller
if anybody besides me were interesting putting some serious work into it.
I think the result would be comparable to anything one could do with
a native port.   In fact, it could easily be _bigger_.   The sage-vmware image
is 2GB now because:

   (1) I use Ubuntu linux instead of something like DSL (Damn Small Linux)

   (2) The base installation disk is not a compressed file system, but
it could be.
If it were, Sage and all the OS stuff would automatically be decompressed on
the fly -- thus the result could easily be smaller than a native
windows install.

   (3) I do not think it is my place to put a lot of time into the
sage-vmware virtual
machine, and nobody has yet volunteered to make it their project.

I used to make a much smaller sage-vmware image, and it even included a GUI;
but of course using DSL is less plush than using Ubuntu, and _surprisingly_ few
people complain about the size of the sage-vmware image.

I want to emphasize again very strongly that very little effort has
gone into the
sage-vmware image -- it's just enough to get the job done and nothing more.

Creating and maintaining a native windows port is vastly more difficult
than making the sage-vmware machine small.

That said I'm all for a native windows port!  I just think we need to do it for
the right reasons, and also hope somebody will put some work into improving
running Sage under windows via virtualization.

 -- William

>
> Mainly because of bringing a matlab/mathematica like Python IDE to all
> those people at universities.
> Sage is really doing a fantastic job to the whole Python community. So
> I hope it will be accepted under
> the umbrella of PSF for the google summer of code.
>
> Ondrej
>
> >
>



-- 
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: [sage-newbie] Re: How do I use R from Sage 2.9?

[William Stein]

On Dec 20, 2007 3:04 PM, Simon Beaumont <[EMAIL PROTECTED]> wrote:
>
> Is there some secret handshake I should use or did I ask a difficult
> question?

Give us money :-)  Just kidding!

A lot of Sage developers -- like me -- are on vacation for the
holidays right now.

> On Dec 18, 10:26 pm, Simon Beaumont <[EMAIL PROTECTED]> wrote:
> > Just installed 2.9 - how do I use the newly integrated R from sage?
> > documentation seems to be behind on this ;-)

Yep, there's no documentation at all included with Sage on how to use
R from Sage
or even that R is included in Sage.

To use R in a way that integrates nicely with Sage,  check out this webpage:

http://rpy.sourceforge.net/

Here is a notebook session that illustrates doing some things with
the R <--> Sage interface:

{{{id=16|
from rpy import *
r.t_test(range(10))
///
{'null.value': {'mean': 0.0}, 'data.name': '0:9', 'method': 'One
Sample t-test', 'p.value': 0.0011200178871001592, 'statistic': {'t':
4.7000967108038418}, 'estimate': {'mean of x': 4.5}, 'conf.int':
[2.3341494103318317, 6.6658505896681683], 'parameter': {'df': 9.0},
'alternative': 'two.sided'}
}}}

{{{id=17|
from rpy import *
v = [1,2,5, 10]
v = [int(z) for z in v]  # rpy doesn't play well with Sage types yet!!!
r.t_test(v)
///
{'null.value': {'mean': 0.0}, 'data.name': 'c(1L, 2L, 5L, 10L)',
'method': 'One Sample t-test', 'p.value': 0.11231741583919484,
'statistic': {'t': 2.2269224668742709}, 'estimate': {'mean of x':
4.5}, 'conf.int': [-1.930851808629775, 10.930851808629777],
'parameter': {'df': 3.0}, 'alternative': 'two.sided'}
}}}

{{{id=18|
from rpy import *
v = [random.random() for _ in range(10^4)]
r.mean(v)
///
0.50381458009226054
}}}

{{{id=19|
r.median(v)
///
0.50252807909097674
}}}

{{{id=21|
r.sd(v)
///
0.2889341870587569
}}}

{{{id=22|

}}}


This last may or may not work for you.  For me it popped up a window
with a plot in it.

{{{id=15|
from rpy import *
degrees = 4
grid = r.seq(0, 10, length=100)
values = [r.dchisq(x, degrees) for x in grid]
r.par(ann=0)
r.plot(grid, values, type='lines')
///
Warning message:
In plot.xy(xy, type, ...) :
  plot type 'lines' will be truncated to first character
}}}


We haven't quite stabilized how we will do plotting with R and the Sage notebook
yet.

Here's another big example:


{{{id=14|
%python

faithful_dat = get_remote_file('http://rpy.sourceforge.net/faithful.dat')
from rpy import *

faithful_data = {"eruption_duration":[],
 "waiting_time":[]}

f = open(faithful_dat,'r')

for row in f.readlines()[1:]: # skip the column header line
splitrow = row[:-1].split(" ")
faithful_data["eruption_duration"].append(float(splitrow[0]))
faithful_data["waiting_time"].append(int(splitrow[1]))

f.close()

ed = faithful_data["eruption_duration"]
edsummary = r.summary(ed)
print "Summary of Old Faithful eruption duration data"
for k in edsummary.keys():
print k + ": %.3f" % edsummary[k]
print
print "Stem-and-leaf plot of Old Faithful eruption duration data"
print r.stem(ed)

r.png('faithful_histogram.png',width=733,height=550)
r.hist(ed,r.seq(1.6, 5.2, 0.2), prob=1,col="lightgreen",
   main="Old Faithful eruptions",xlab="Eruption duration (seconds)")
r.lines(r.density(ed,bw=0.1),col="orange")
r.rug(ed)
r.dev_off()

long_ed = filter(lambda x: x > 3, ed)
r.library('ctest')
print "Shapiro-Wilks normality test of Old Faithful eruptions longer
than 3 seconds"
sw = r.shapiro_test(long_ed)
print "W = %.4f" % sw['statistic']['W']
print "p-value = %.5f" % sw['p.value']

print
print "One-sample Kolmogorov-Smirnov test of Old Faithful eruptions
longer than 3 seconds"
ks = r.ks_test(long_ed,"pnorm", mean=r.mean(long_ed), sd=r.sqrt(r.var(long_ed)))
print "D = %.4f" % ks['statistic']['D']
print "p-value = %.4f" % ks['p.value']
print "Alternative hypothesis: %s" % ks['alternative']
print
///
Attempting to load remote file: http://rpy.sourceforge.net/faithful.dat
Loading: [print "\x01r\x01e49"
.]
Summary of Old Faithful eruption duration data
Min.: 1.600
1st Qu.: 2.163
3rd Qu.: 4.454
Median: 4.000
Max.: 5.100
Mean: 3.488

Stem-and-leaf plot of Old Faithful eruption duration data

  The decimal point is 1 digit(s) to the left of the |

  16 | 07035588
  18 | 2223335522335777888
  20 | 2223378800035778
  22 | 0002335578023578
  24 | 00228
  26 | 23
  28 | 080
  30 | 7
  32 | 2337
  34 | 250077
  36 | 823577
  38 | 235582225577
  40 | 003357780022338
  42 | 0333778800238
  44 | 033555778235777
  46 | 23335770023578
  48 | 0022335800333
  50 | 0370

None
Warning message:
package 'ctest' has been merged into 'stats'
Shapiro-Wilks normality test of Old Faithful eruptions longer than 3 seconds
W = 0.9793
p-value = 0.01052

One-sample Kolmogorov-Smirnov test of Old Faithful eruptions longer
than 3 seconds
Warning message:
In function (x, y, ..., alternative = c("two.sided", "less", "greater"),  :
  cannot compute correct p-val

[sage-devel] Re: traffic to sagemath.org

[David Joyner]

Does Spain in the number 2 position of
"Sagemath.org users come from these countries:"
mean that Spain downloads more copies of SAGE than
any other country but the US? Or i it just webpage
accesses?


On Dec 20, 2007 12:06 PM, William Stein <[EMAIL PROTECTED]> wrote:
>
> Hi Sage Developers,
>
> With help from Martin Albrecht, I've been tracking the traffic to
> sagemath.org here:
>
> http://sagemath.org/traffic.html
>
> Probably the most interesting graph is this one:
>
> http://www.alexa.com/data/details/traffic_details/sagemath.org?site0=sagemath.org&site1=www.maplesoft.com&site2=www.wolfram.com
>
> it compares Sagemath.org to Maplesoft.com up until Dec 17. Before the
> UW press release (inspired by Trophees du Libre ), sagemath.org
> traffic was insignificant when compared to Maple.   On Dec 3 when the
> press release went out until Dec 11, there was a huge spike in
> traffic, so that sagemath.org went from being a speck to over twice
> the amount of traffic as Maple gets.  NOTE -- this increase in traffic
> started two days before the slashdotting.  On Dec 5 during the
> slashdotting, the number of downloads of sage itself went up a huge
> amount (thousands per day).  This hump died down after about a week on
> December 11.  However, the steady state for sagemath.org during the
> last week has been similar to and sometimes slightly hire than
> maplesoft.com.   This suggests that the number of Sage users has gone
> up by quite a bit, and that a nontrivial fraction of the people who
> tried Sage a week ago are now Sage users.   Traffic to sagemath.org
> has gone from "0"  as measured by "Alexa" to comparable to Maple.
>
> Perhaps soon
>
> http://trac.sagemath.org/sage_trac/ticket/1000
>
> can be closed and replaced by a ticket to have 100,000 users?
>
>
> (and yes, I posted a version of the above email to
> http://sagemath.blogspot.com/)
>
>
> --
> William Stein
> Associate Professor of Mathematics
> University of Washington
> http://wstein.org
>
>
> --
> 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: traffic to sagemath.org

[William Stein]

On Dec 20, 2007 3:58 PM, David Joyner <[EMAIL PROTECTED]> wrote:
>
> Does Spain in the number 2 position of
> "Sagemath.org users come from these countries:"
> mean that Spain downloads more copies of SAGE than
> any other country but the US? Or i it just webpage
> accesses?

It is webpage access -- e.g., looking at the docs on sagemath.org, etc.
It is very interesting that Spain is number two overall...

The 1-week average for Sage for the "Percent of global Internet users
who visit this site"
is 0.00067315%.  This is up 3,400% from 3 months ago.  The corresponding numbers
for Maple are:  0.001145% and they are up 35% from 3 months ago.
That's not so bad,
since

sage:  0.001145 /  0.00067315
1.70095818168313

For woflram.com, they are: 0.0165% which is up 45% from 3 months ago.
For matlab, they are: 0.0193%, which is up 47%.

Such figures don't seem to exist for Magma, Maxima, etc., since they don't have
their own domain names.

 -- William

>
>
>
> On Dec 20, 2007 12:06 PM, William Stein <[EMAIL PROTECTED]> wrote:
> >
> > Hi Sage Developers,
> >
> > With help from Martin Albrecht, I've been tracking the traffic to
> > sagemath.org here:
> >
> > http://sagemath.org/traffic.html
> >
> > Probably the most interesting graph is this one:
> >
> > http://www.alexa.com/data/details/traffic_details/sagemath.org?site0=sagemath.org&site1=www.maplesoft.com&site2=www.wolfram.com
> >
> > it compares Sagemath.org to Maplesoft.com up until Dec 17. Before the
> > UW press release (inspired by Trophees du Libre ), sagemath.org
> > traffic was insignificant when compared to Maple.   On Dec 3 when the
> > press release went out until Dec 11, there was a huge spike in
> > traffic, so that sagemath.org went from being a speck to over twice
> > the amount of traffic as Maple gets.  NOTE -- this increase in traffic
> > started two days before the slashdotting.  On Dec 5 during the
> > slashdotting, the number of downloads of sage itself went up a huge
> > amount (thousands per day).  This hump died down after about a week on
> > December 11.  However, the steady state for sagemath.org during the
> > last week has been similar to and sometimes slightly hire than
> > maplesoft.com.   This suggests that the number of Sage users has gone
> > up by quite a bit, and that a nontrivial fraction of the people who
> > tried Sage a week ago are now Sage users.   Traffic to sagemath.org
> > has gone from "0"  as measured by "Alexa" to comparable to Maple.
> >
> > Perhaps soon
> >
> > http://trac.sagemath.org/sage_trac/ticket/1000
> >
> > can be closed and replaced by a ticket to have 100,000 users?
> >
> >
> > (and yes, I posted a version of the above email to
> > http://sagemath.blogspot.com/)
> >
> >
> > --
> > William Stein
> > Associate Professor of Mathematics
> > University of Washington
> > http://wstein.org
> >
> >
> > --
> > William Stein
> > Associate Professor of Mathematics
> > University of Washington
> > http://wstein.org
> >
> > >
> >
>
> >
>



-- 
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: factoring benchmarks

[Bill Hart]

Taking a look at the actual data from the timings I did, the time
taken to factor varies much more in Magma than in NTL. Here are the
Magma timings for length 341 polynomials:

341 1   1.020e+06   1.723e+06
341 2   9.600e+05   3.090e+06
341 3   1.937e+06   3.177e+06
341 4   8.900e+05   2.973e+06
341 5   2.200e+06   3.203e+06
341 6   1.120e+06   2.352e+06
341 7   9.200e+05   3.170e+06
341 8   1.075e+06   2.507e+06
341 10  1.167e+06   3.463e+06
341 12  1.383e+06   2.433e+06
341 15  2.177e+06   3.175e+06
341 18  1.173e+06   2.480e+06
341 22  9.500e+05   2.583e+06
341 26  1.233e+06   3.257e+06

Here are the times for NTL:

341 1   3.444e+06   3.740e+06
341 2   3.124e+06   3.634e+06
341 3   3.122e+06   3.707e+06
341 4   3.397e+06   4.052e+06
341 5   3.563e+06   3.797e+06
341 6   3.348e+06   4.000e+06
341 7   3.130e+06   3.895e+06
341 8   3.367e+06   3.684e+06
341 10  3.611e+06   4.001e+06
341 12  3.232e+06   3.776e+06
341 15  3.536e+06   3.978e+06
341 18  3.192e+06   3.744e+06
341 22  3.409e+06   3.833e+06
341 26  3.418e+06   3.787e+06

As you can see, the NTL timings differ between the best and worst
times by about 10-15%, however the Magma timings differ from each
other by a factor of up to 2 or 3.

I believe this is because of small factors being removed at various
stages due to some heuristics developed by Allan Steel as mentioned in
the Magma documentation. If you look at the maximum times taken in
each case, NTL is not that far behind NTL.

Bill.

On 20 Dec, 21:26, Bill Hart <[EMAIL PROTECTED]> wrote:
> I fixed the four magma graphs above so that they take into account the
> time to compute and divide by the content, since Pari and NTL
> certainly do that.
>
> The result is just about the same. Magma is significantly faster for
> longer polynomials, usually a factor of about 2.5, though it varies a
> bit.
>
> Bill.
>
> On 20 Dec, 20:28, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> > And here we go for generic polynomials:
>
> > Magma vs Pari:
>
> >http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/magp...
>
> > Magma vs NTL:
>
> >http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/magN...
>
> > Bill.
>
> > On 20 Dec, 20:13, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> > > For comparison, here is our favourite non-free closed source package
> > > vs Pari and NTL for factoring with two large factors:
>
> > > Magma vs Pari:
>
> > >http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/magp...
>
> > > Magma vs NTL:
>
> > >http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/magN...
>
> > > Something that may not be fair here is that Magma factors the content,
> > > so I have divided the polynomials used by their content before
> > > factoring them. But I didn't include the time taken to divide by the
> > > content in the timing. Given that computing the content should be
> > > almost instant generically, I don't see this as much of a problem
> > > though.
>
> > > Bill.
>
> > > On 20 Dec, 18:46, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> > > > I've redone both graphs since the generic NTL profiling code in FLINT
> > > > was assuming that a length n polynomial had n+1 coefficients (my
> > > > student had done this due to some confusion about the way coefficients
> > > > were counted).
>
> > > > The graph for polynomials with two large factors (at least):
>
> > > >http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/fact...
>
> > > > and the graph for generic polynomials:
>
> > > >http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/fact...
>
> > > > Hopefully these are correct now.
>
> > > > Bill.
>
> > > > On 20 Dec, 17:49, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> > > > > Here is the graph for generic polynomials:
>
> > > > >http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/fact...
>
> > > > > At about 1000 bits and length 6, NTL does seem to get ahead again.
>
> > > > > Bill.
--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] #1426: new trac view: tickets ***reported by*** given user

[David Harvey]

Hi paul,

is this what you wanted?

http://sagetrac.org/sage_trac/report/9

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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Notebook listing usernames

[Robert Miller]

As pointed out by Michael Abshoff, it seems like an information leak
to list all the usernames on a notebook when you fail to use a valid
one to log in. Thoughts?
--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: #1426: new trac view: tickets ***reported by*** given user

[Robert Miller]

David,

Did you mean to attach something to that ticket?


-- Robert M

On Dec 20, 8:07 pm, David Harvey <[EMAIL PROTECTED]> wrote:
> Hi paul,
>
> is this what you wanted?
>
> http://sagetrac.org/sage_trac/report/9
>
> 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: #1426: new trac view: tickets ***reported by*** given user

[David Harvey]

On Dec 20, 2007, at 8:47 PM, Robert Miller wrote:

> David,
>
> Did you mean to attach something to that ticket?

no... sorry I put "[with patch]" but I really meant "[solution  
has been implemented]" but no-one ever writes that and I didn't want  
to feel left out :-(

The point is that there is a new "report" which allows you to easily  
see all the tickets you have reported, which is what paul apparently  
was asking for.

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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: #1426: new trac view: tickets ***reported by*** given user

[Yi Qiang]

I believe it is supposed to be a custom view that shows tickets you've
reported, although it's not working for me.

On Dec 20, 2007 5:47 PM, Robert Miller <[EMAIL PROTECTED]> wrote:
>
> David,
>
> Did you mean to attach something to that ticket?
>
>
> -- Robert M
>
>
> On Dec 20, 8:07 pm, David Harvey <[EMAIL PROTECTED]> wrote:
> > Hi paul,
> >
> > is this what you wanted?
> >
> > http://sagetrac.org/sage_trac/report/9
> >
> > 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: #1426: new trac view: tickets ***reported by*** given user

[David Harvey]

On Dec 20, 2007, at 8:52 PM, Yi Qiang wrote:

> I believe it is supposed to be a custom view that shows tickets you've
> reported, although it's not working for me.

Are you logged in?

(I don't suppose you're seeing tickets reported by ME? (i.e. by  
dmharvey?) Did I mess up?)

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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: #1426: new trac view: tickets ***reported by*** given user

[mabshoff]

On Dec 21, 2:56 am, David Harvey <[EMAIL PROTECTED]> wrote:
> On Dec 20, 2007, at 8:52 PM, Yi Qiang wrote:
>
> > I believe it is supposed to be a custom view that shows tickets you've
> > reported, although it's not working for me.
>
> Are you logged in?
>
> (I don't suppose you're seeing tickets reported by ME? (i.e. by
> dmharvey?) Did I mess up?)
>

It works for me, i.e. not you ;)

> david

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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Sage 2.9.1.alpha2

[Robert Miller]

Sage 2.9.1 alpha2 is out, available at:

http://sage.math.washington.edu/home/rlmill/sage-2.9.1.alpha2.tar

Closed tickets:
alpha2:
#1064 - Robert Miller - permutation __call__ type check
#1175 - Michael Abshoff - circular link in sage/local/lib/python2.5
#1233 - Michael Abshoff, John Cremona - mwrank wrapper causes crashes
and error on non-minimal curves
#1240 - Michael Abshoff - wrong unix rights of some files
#1424 - William Stein - threaded map function, as requested by Peter
Doyle
#1459 - Mike Hansen - make notebook ? behavior like command line
behavior
#1546 - Michael Abshoff - Update FLINT.spkg to 1.03 release
#1556 - Yi Qiang - make usernames legible on bad login name to
notebook
#1562 - Robert Bradshaw - inverse trig
#1563 - Robert Miller - ./sage -r main
#1569 - William Stein - solve() fails if one list element is True
#1572 - Michael Abshoff - memleak in graph_fast.pyx
#1573 - Michael Abshoff - Mismatched free() / delete / delete [] in
wrap.cc

alpha1:
#1139 - Mike Hansen - nintegral raises helpful error if precision is
too high
#1318 & #1319 - Robert Miller - eigenspaces/charpoly of a graph
#1363 - Carl Witty - sqrt for complex intervals
#1380 - Martin Albrecht - R.=QQ[]; x.subs(x=1/y); now works
#1421 - Paul Zimmerman, Craig Citro - finer control in ECM interface
#1432 - William Stein - plotting examples
#1540 - Michael Abshoff - remove linux elf binaries during lapack
build
#1542 & #1543 - Craig Citro - R/rpy build issues fixed
#1548 - Michael Abshoff - numerical noise in doctests in calculus.py
#1551 - Robert Miller - is_subgraph
#1555 - bill.p, William Stein - typos in documentation



--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: Notebook listing usernames

[William Stein]

On Dec 20, 2007 6:24 PM, Robert Miller <[EMAIL PROTECTED]> wrote:
>
> As pointed out by Michael Abshoff, it seems like an information leak
> to list all the usernames on a notebook when you fail to use a valid
> one to log in. Thoughts?

This exact question comes up about every other week.   Are you talking
about a public notebook like sagenb.org or sagenb.com?  If so, then
note that *anybody* can make a new account, and once they login
with that account, it is trivial for them -- in several different ways -- to get
a list of all user names.  If you're talking about a server that you personally
run but with no user accounts, then there is just one name, i.e., "admin".
In both cases, security by obscuring the existing usernames is no security
at all.

So maybe you are talking about semi-private servers that have a fixed list
of accounts and users, like a normal UNIX system say, where potential
users cannot sign up for a new account -- only an admin can create accounts.
In this case getting a list of users would be a security issue.  But
you probably
don't mean this since it isn't implemented in sage (yet!).

 -- 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: Notebook listing usernames

[William Stein]

On Dec 20, 2007 10:57 PM, William Stein <[EMAIL PROTECTED]> wrote:
> On Dec 20, 2007 6:24 PM, Robert Miller <[EMAIL PROTECTED]> wrote:
> >
> > As pointed out by Michael Abshoff, it seems like an information leak
> > to list all the usernames on a notebook when you fail to use a valid
> > one to log in. Thoughts?
>
> This exact question comes up about every other week.   Are you talking
> about a public notebook like sagenb.org or sagenb.com?  If so, then
> note that *anybody* can make a new account, and once they login
> with that account, it is trivial for them -- in several different ways -- to 
> get
> a list of all user names.  If you're talking about a server that you 
> personally
> run but with no user accounts, then there is just one name, i.e., "admin".
> In both cases, security by obscuring the existing usernames is no security
> at all.
>
> So maybe you are talking about semi-private servers that have a fixed list
> of accounts and users, like a normal UNIX system say, where potential
> users cannot sign up for a new account -- only an admin can create accounts.
> In this case getting a list of users would be a security issue.  But
> you probably
> don't mean this since it isn't implemented in sage (yet!).

I should have finished by adding that there is no point at all in
not listing usernames in the scenarios in the first paragraph above -- that
would just be security by obscurity.  There is a point in not listing
user names in paragraph two above.  When Sage actually supports
what is described in paragraph two, then when the notebook is in
that mode it shouldn't list usernames.

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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 2.9.1.alpha2

[William Stein]

On Dec 20, 2007 7:30 PM, Robert Miller <[EMAIL PROTECTED]> wrote:
>
> Sage 2.9.1 alpha2 is out, available at:
>
> http://sage.math.washington.edu/home/rlmill/sage-2.9.1.alpha2.tar

Robert,

What's the plan?  What needs to happen to go from 2.9.1.alpha2 to a release
candidate and a release?

 -- William


> Closed tickets:
> alpha2:
> #1064 - Robert Miller - permutation __call__ type check
> #1175 - Michael Abshoff - circular link in sage/local/lib/python2.5
> #1233 - Michael Abshoff, John Cremona - mwrank wrapper causes crashes
> and error on non-minimal curves
> #1240 - Michael Abshoff - wrong unix rights of some files
> #1424 - William Stein - threaded map function, as requested by Peter
> Doyle
> #1459 - Mike Hansen - make notebook ? behavior like command line
> behavior
> #1546 - Michael Abshoff - Update FLINT.spkg to 1.03 release
> #1556 - Yi Qiang - make usernames legible on bad login name to
> notebook
> #1562 - Robert Bradshaw - inverse trig
> #1563 - Robert Miller - ./sage -r main
> #1569 - William Stein - solve() fails if one list element is True
> #1572 - Michael Abshoff - memleak in graph_fast.pyx
> #1573 - Michael Abshoff - Mismatched free() / delete / delete [] in
> wrap.cc
>
> alpha1:
> #1139 - Mike Hansen - nintegral raises helpful error if precision is
> too high
> #1318 & #1319 - Robert Miller - eigenspaces/charpoly of a graph
> #1363 - Carl Witty - sqrt for complex intervals
> #1380 - Martin Albrecht - R.=QQ[]; x.subs(x=1/y); now works
> #1421 - Paul Zimmerman, Craig Citro - finer control in ECM interface
> #1432 - William Stein - plotting examples
> #1540 - Michael Abshoff - remove linux elf binaries during lapack
> build
> #1542 & #1543 - Craig Citro - R/rpy build issues fixed
> #1548 - Michael Abshoff - numerical noise in doctests in calculus.py
> #1551 - Robert Miller - is_subgraph
> #1555 - bill.p, William Stein - typos in documentation
>
>
>
> >
>



-- 
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---

[sage-devel] Re: Notebook listing usernames

[boothby]

That was my initial reaction, too.  In a closed system, it makes sense -- for 
the public notebook, it doesn't immediately seem like such a bad thing, but it 
lends to a scary attack.

Robert makes an account on the public notebook.
Robert sees William's account on the failure page, so creates an account -- 
then from the notebook, Robert launches a zero-latency brute-force attack to 
discover William's password.
Now, Robert logs into William's account.  From there, he inserts malicious 
javascript into William's most-recently edited worksheet.
Next time William opens his favorite worksheet, Robert pwns his machine, logs 
in, and edits the grade chart for William's Math 581 class, scoring himself a 
well-deserved 4.1...



On Thu, 20 Dec 2007, Robert Miller wrote:

>
> As pointed out by Michael Abshoff, it seems like an information leak
> to list all the usernames on a notebook when you fail to use a valid
> one to log in. Thoughts?
> >
>



--~--~-~--~~~---~--~~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---