[sage-devel] Fwd: [sage-release] Re: Sage 9.5 released

[John Cremona]

[copied from sage-release]

-- Forwarded message -
From: John Cremona 
Date: Mon, 31 Jan 2022 at 13:47
Subject: Re: [sage-release] Re: Sage 9.5 released
To: 


I just successfully built 9.5 from a fresh tarball.  After completing
the build I installed (as I usually do) an optional package with the
command-line "./sage -i database_cremona_ellcurve" and now it is
rebuilding gmp.  What is going on here?  Has the way of installing
optional packages changed -- in which case, surely the use of "sage
-i" should tell you what to do instead,  instead of doing the 'wrong'
thing?

John

PS In the end it seemed to rebuild just about everything, even though
installing that package only involves copying one data file; it took a
couple of hours.  It would be nice to know how to avoid it happening
again (I have several other machines I want to install Sage on and I
do always need this package;))

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAD0p0K7it%2BwUc4%3DjonanmkEpGTrWzVOpmtdZrReu%2BQVjEb%3DXVw%40mail.gmail.com.

[sage-devel] Fwd: sage | Fix some compiler warnings, mostly use size_t for indexing (!46)

[Dima Pasechnik]

please  have a look

-- Forwarded message -
From: Ivan Komarov 
Date: Sun, Jul 26, 2020 at 4:42 AM
Subject: Re: sage | Fix some compiler warnings, mostly use size_t for
indexing (!46)
To: 


Ivan Komarov  started a new discussion on
src/sage/geometry/triangulation/triangulations.cc
:
18 18

 void triangulations::find_hash_position(const compact_simplices& t,

19 19

 hash_value& pos, bool& is_new) const

20 20

 {

21

-  hash_value freespace;

unused

—
Reply to this email directly or view it on GitLab
.
You're receiving this email because of your account on gitlab.com. If you'd
like to receive fewer emails, you can unsubscribe

from this thread or adjust your notification settings.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq3zRRtWqJLXRdYzjuAVWRzHGYi2mztUYwwHZCQeX7vYDg%40mail.gmail.com.

[sage-devel] Fwd: sage | Fix some compiler warnings, mostly use size_t for indexing (!46)

[Dima Pasechnik]

please have a look

-- Forwarded message -
From: Ivan Komarov 
Date: Sun, Jul 26, 2020 at 4:33 AM
Subject: sage | Fix some compiler warnings, mostly use size_t for indexing (!46)
To: 


Ivan Komarov created a merge request:

Project:Branches: IvaKom/sage:size_t to sagemath/sage:develop
Author: Ivan Komarov
Assignees:

Reduce the amount of warnings, mostly with changing for (int i=0;
ihttps://groups.google.com/d/msgid/sage-devel/CAAWYfq3MPEai10PerPR1J8uUoMdrV3TB_sEUeQ_btjjafJbaAA%40mail.gmail.com.

[sage-devel] Fwd: sage | Fix some compiler warnings, mostly use size_t for indexing (!46)

[Dima Pasechnik]

please have a look:

-- Forwarded message -
From: Ivan Komarov 
Date: Sun, Jul 26, 2020 at 4:42 AM
Subject: Re: sage | Fix some compiler warnings, mostly use size_t for
indexing (!46)
To: 


Ivan Komarov  started a new discussion on
src/sage/schemes/hyperelliptic_curves/hypellfrob/hypellfrob.cpp
:
161 161

   zz_p::init(to_long(modulus));

162 162

  163 163

   // Convert input data to single-precision format

164

-  int dim = M0.NumRows();

unused

—
Reply to this email directly or view it on GitLab
.
You're receiving this email because of your account on gitlab.com. If you'd
like to receive fewer emails, you can unsubscribe

from this thread or adjust your notification settings.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq2CEyy%2BV1_SPkQb_FcY7xEN9a36XA8273e5%2BZ9%3DvPmNbg%40mail.gmail.com.

[sage-devel] Fwd: [sage-trac] #30000: Implement a Q-curve test for elliptic curves over number fields

[John Cremona]

I woke up to see ticket #2 sitting there so could not resist.

-- Forwarded message -
From: sage-trac 
Date: Sat, 27 Jun 2020 at 09:16
Subject: [sage-trac] #3: Implement a Q-curve test for elliptic
curves over number fields
To:


#3: Implement a Q-curve test for elliptic curves over number fields
+---
   Reporter:  cremona   | Type:  enhancement
 Status:  new   | Priority:  major
  Milestone:  sage-9.2  |Component:  elliptic curves
   Keywords:|Merged in:
Authors:|Reviewers:
Report Upstream:  N/A   |  Work issues:
 Branch:|   Commit:
   Dependencies:| Stopgaps:
+---
 An in teresting property of elliptic cuves over number fields is being a
 Q-curve (i.e. isogenous to all its Galois conjugates).  I am working on
 efficient ways to test this, have implsmented some, and will include it in
 Sage when done.

--
Ticket URL: 
Sage 
Sage: Creating a Viable Open Source Alternative to Magma, Maple,
Mathematica, and MATLAB

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAD0p0K7DXg3P94MorWvkzizkEzQAdBYj7sGb9cmGqsgmRkporw%40mail.gmail.com.

[sage-devel] Fwd: [sage-trac] #29314: update GAP to version 4.11

[Dima Pasechnik]

new version of GAP, 4.11, is out, we should upgrade. Here is the ticket.

-- Forwarded message -
From: sage-trac 
Date: Wed, Mar 11, 2020 at 11:12 AM
Subject: [sage-trac] #29314: update GAP to version 4.11
To:


#29314: update GAP to version 4.11
+--
   Reporter:  dimpase   | Type:  enhancement
 Status:  new   | Priority:  major
  Milestone:  sage-9.1  |Component:  packages: standard
   Keywords:|Merged in:
Authors:|Reviewers:
Report Upstream:  N/A   |  Work issues:
 Branch:|   Commit:
   Dependencies:| Stopgaps:
+--
 GAP 4.11.0 has been released.

 tarball:
 https://www.gap-system.org/pub/gap/gap-4.11/tar.bz2/gap-4.11.0.tar.bz2

--
Ticket URL: 
Sage 
Sage: Creating a Viable Open Source Alternative to Magma, Maple,
Mathematica, and MATLAB

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq1Cj%2BFncBiPY9-o4OL0RZXQKMkFg%2BaKmff%2B9jppH5tSvA%40mail.gmail.com.

[sage-devel] Fwd: [sage-trac] #28710: update sagenb to 1.1.3

[Dima Pasechnik]

please review. it's a routine update, but still...

-- Forwarded message -
From: sage-trac 
Date: Fri, Nov 8, 2019 at 10:47 PM
Subject: Re: [sage-trac] #28710: update sagenb to 1.1.3
To:


#28710: update sagenb to 1.1.3
-+-
   Reporter:  dimpase|Owner:
   Type:  enhancement|   Status:  needs_review
   Priority:  critical   |Milestone:  sage-9.0
  Component:  packages:  |   Resolution:
  optional   |
   Keywords: |Merged in:
Authors:  Dima Pasechnik |Reviewers:
Report Upstream:  N/A|  Work issues:
 Branch: |   Commit:
  u/dimpase/packages/sagenb113   |  4b9bc7cfb9a3ae22290bedbaa4ab717c9722a987
   Dependencies: | Stopgaps:
-+-
Changes (by dimpase):

 * status:  new => needs_review


--
Ticket URL: 
Sage 
Sage: Creating a Viable Open Source Alternative to Magma, Maple,
Mathematica, and MATLAB

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq09Y6QRiVpO6rO5obzxvFZCb2LAMfovLcpEi7fnxxQ%3D9w%40mail.gmail.com.

[sage-devel] Fwd: [sage-cell] Re: Is sagecell python3-ready?

[kcrisman]

On sage-cell, Py3 was brought up.  I mentioned how permalinks there may 
cause trouble at the eventual Py3 changeover for Sage, since at the very 
least print statements will be gone.  William brings up an interesting 
possibility, and I wonder how/whether this would be useful for Sage proper. 
 A lot of broken code overnight won't make anyone happy; I don't know how 
easy to use the various converters Py2->Py3 are to use for non-sage-devel 
people who might just have some random scripts or Sage/Jupyter notebook 
worksheets.  Anyway, hopefully people might have useful commentary on a 
broader email list, thanks!
- kcrisman

> Along these lines, it occurs to me that if/when Sage switches to Py3, 
>
> "when", I hope!   E.g., I personally always use the python3 version of 
> Sage, and it works well for me. 
>
> > there will be a lot of broken permalinks - especially if people used 
> "print blah" instead of "print(blah)".  Is there any way to avoid this? 
>
> It could be avoided using the preparser, with a deprecation warning 
> printed.  There's probably a trac ticket about this somewhere. 
>
> William 
>

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

[sage-devel] Fwd: [sage-trac] #27462: move toolchain into a separate package

[Dima Pasechnik]

I've opened this ticket/task to move to a simpler build system...
-- Forwarded message -
From: sage-trac 
Date: Mon, Mar 11, 2019 at 11:25 AM
Subject: [sage-trac] #27462: move toolchain into a separate package
To:


#27462: move toolchain into a separate package
--+-
   Reporter:  dimpase | Type:  task
 Status:  new | Priority:  major
  Milestone:  sage-8.8|Component:  build
   Keywords:  |Merged in:
Authors:  |Reviewers:
Report Upstream:  N/A |  Work issues:
 Branch:  |   Commit:
   Dependencies:  #27212, #27258, #27259  | Stopgaps:
--+-
 Subject to relatively easy to complete  #27212, #27258, and #27259,
 every Sage toolchain part and dependency need not be built any more.

 This allows moving the toolchain into a separate package, with
 parts seldom needed on sufficiently new Linux, Cygwin, and OSX+Homebrew
 (or whatever that comes with gfortran).

--
Ticket URL: 
Sage 
Sage: Creating a Viable Open Source Alternative to Magma, Maple,
Mathematica, and MATLAB

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

Re: [sage-devel] Fwd: [sage-trac] #26795: Some memory leaks

[Jori Mäntysalo]

On Mon, 3 Dec 2018, Dima Pasechnik wrote:

An expert in Cython/Python classes needed: __destruct__ is not called 
for a reason I don't understand.


[ Resolution: Should have been __dealloc__ ]

I grepped the source, and this was the only __destruct__(). Of course 
there might be other misnamed methods. By


egrep -R 'def __d[^ (]+' src/sage -o --no-filename | colrm 1 4 | sort | uniq -c 
| sort -rn

I found only __delete__, but that seems not to be like this one was. (Btw, 
why schemes/elliptic_curves/ell_tate_curve.py has __delta() etc, not 
_delta() and so?)


Here is again the test code I used:


 > {{{
 > import gc
 >
 > i = 0
 > GG = graphs()
 > _ = next(GG); _ = next(GG);
 > for P in GG:
 >     if i > 2: break
 >     if i % 1000 == 0:
 >         _ = gc.collect()
 >         print get_memory_usage(), P.order()
 >     i += 1
 >     _ = P.convexity_properties()
 > }}}


I did some other tests, and found no more leaks. It may make sense to run 
this in a more systematic way after leaks in MILP interface has been 
resolved. And it's not a bad idea to do similar tests in, say, matrix 
functions over finite field etc.


--
Jori Mäntysalo

[sage-devel] Fwd: [sage-trac] #26795: Some memory leaks

[Dima Pasechnik]

An expert in Cython/Python classes needed: __destruct__ is not called for a
reason I don't understand.

There is class Graph with a method convexity_properties

which calls cdef'd class ConvexityProperties in a separate pyx file.
A destructor for the latter is defined as
def __destruct__ but is never called. What is going on? What is the correct
design here?

Dima


-- Forwarded message -
From: sage-trac 
Date: Mon, 3 Dec 2018 15:02
Subject: Re: [sage-trac] #26795: Some memory leaks
To:


#26795: Some memory leaks
-+-
   Reporter:  jmantysalo |Owner:
   Type:  defect |   Status:  needs_work
   Priority:  major  |Milestone:  sage-8.5
  Component:  memleak|   Resolution:
   Keywords: |Merged in:
Authors:  Dima Pasechnik |Reviewers:
Report Upstream:  N/A|  Work issues:
 Branch: |   Commit:
  public/packages/glpkbackendmemleak |
c42c3bc27da534544dc62a953d5457d6c27532b5
   Dependencies: | Stopgaps:
-+-

Comment (by dimpase):

 Replying to [comment:21 jmantysalo]:
 > What's this:
 >
 > {{{
 > import gc
 >
 > i = 0
 > GG = graphs()
 > _ = next(GG); _ = next(GG);
 > for P in GG:
 > if i > 2: break
 > if i % 1000 == 0:
 > _ = gc.collect()
 > print get_memory_usage(), P.order()
 > i += 1
 > _ = P.convexity_properties()
 > }}}
 >
 > ??? There is an explicit `__destruct__` in class `ConvexityProperties`.

 however, `__destruct__` is not called, as one can see by putting a
 `print()` there.

--
Ticket URL: 
Sage 
Sage: Creating a Viable Open Source Alternative to Magma, Maple,
Mathematica, and MATLAB

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

[sage-devel] Fwd: Sage is currently #1 on Hacker News

[William Stein]

-- Forwarded message -
From: Alex Clemesha 
Date: Sat, Sep 15, 2018, 2:02 PM
Subject: Sage is currently #1 on Hacker News
To: William Stein 


Just wanted to mention:
https://news.ycombinator.com/item?id=17995031
in case you were interested :)

-Alex

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

[sage-devel] Fwd: [sage-trac] #25814: Upgrade to cysignals 1.7.2

[Erik Bray]

Volker, be reasonable.  You should know that there have been unique
challenges involved in getting a buildbot set up for Windows, not the
least of which being simply the availability of dedicated hardware.
In the meantime, I *am* the buildbot for Windows; I build and test
each tagged release myself and report back results quite reliably.
It's not ideal or sustainable long term but ''we are working on
that''.  It's kind of an insult to the hard work I've done ensuring
that Windows *is* a fully supported platform to claim that it isn't.
Meanwhile it is available on the download page and has many active
users.  If anything you could say it's better supported than most
platforms.

As for this issue, the problem in Cysignals was fixed back in April,
but the fix never included in Sage before now because it simply
required making a new release, which we figured we could get around to
before the next Sage release.  I wrote an e-mail to both you and
Jeroen personally asking that we could ensure that a new Cysignals
release is made in time for Sage 8.3.  Jeroen took care of his end of
that without complain.  Now please take care of yours.

Best,
E

-- Forwarded message -
From: sage-trac 
Date: Tue, Jul 17, 2018 at 12:03 AM
Subject: Re: [sage-trac] #25814: Upgrade to cysignals 1.7.2
To:


#25814: Upgrade to cysignals 1.7.2
-+-
   Reporter:  jdemeyer   |Owner:
   Type:  enhancement|   Status:  positive_review
   Priority:  blocker|Milestone:  sage-8.3
  Component:  packages:  |   Resolution:
  standard   |
   Keywords:  upgrade,   |Merged in:
  cysignals  |
Authors:  Jeroen Demeyer |Reviewers:  Erik Bray
Report Upstream:  N/A|  Work issues:
 Branch: |   Commit:
  u/embray/pkgs/cysignals/update-1.7.2|
a41caf4adf015103499f96e6fa69a94bfb530b82
   Dependencies: | Stopgaps:
-+-

Comment (by vbraun):

 No buildbot => not a fully supported platform

--
Ticket URL: 
Sage 
Sage: Creating a Viable Open Source Alternative to Magma, Maple,
Mathematica, and MATLAB

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

[sage-devel] Fwd: Sage coding job: combinatorial Hopf algebras, ~3 months, Hong Kong

[Dima Pasechnik]

On Saturday, November 11, 2017 at 11:30:56 AM UTC, amy...@hkbu.edu.hk wrote:
>
> Hello Sage-combinat community,
>
> I am an Assistant Professor at Hong Kong Baptist University, and I am 
> looking to hire a research assistant for ~3 months to work on code related 
> to combinatorial Hopf algebras (CHAs), e.g. ticket #13793 
> . The job can start anytime 
> between Jan and Aug 2018, later dates might also be possible. The person 
> needs to be physically on my campus. This might be a good opportunity for a 
> graduated undergrad / grad student / postdoc to travel a bit in between 
> studies / jobs. The person needs to have a good coding background, 
> preferably previous contributions to Sage; CHA knowledge would be a plus, 
> but if he/she has some abstract algebra background, it shouldn't be hard to 
> pick this up. If you know of suitable candidates, please direct them to my 
> webpage , or let me know via this 
> thread or email. Also feel free to email me for more information. Thanks.
>
> Amy
>
> --
>
> Disclaimer
>
> This message (including any attachments) may contain confidential 
> information intended for a specific individual and/or purpose. If you are 
> not the intended recipient, please delete this message and notify the 
> sender and the University immediately. Any disclosure, copying, or 
> distribution of this message, or the taking of any action based on it, is 
> prohibited as it may be unlawful.
>
> In addition, the University specifically denies any responsibility for the 
> accuracy or quality of information obtained through University E-mail 
> Facilities. Any views and opinions expressed in the email(s) are those of 
> the author(s), and do not necessarily represent the views and opinions of 
> the University. The University accepts no liability whatsoever for any 
> losses or damages that may be incurred or caused to any party as a result 
> of the use of such information.
>
> Go Green Print Less
>

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

[sage-devel] Fwd: Sage packaging template

[Maarten Derickx]

On Mon, 11 Sep 2017 at 10:30 Jean-Pierre Flori  wrote:

>
> I've made a pull request at
> https://github.com/mmasdeu/sage_package_template/pull/3 with some changes
> and info to skip some of the requirements when using it.
>

I don't have write acces to that repository so I can't accept your pull
request. But Marc Masdue (in the CC) does.
I guess it would be a good idea to put Marc his cookie cutter in the
Sagemath github repo under https://github.com/sagemath so it can be turned
into a more collaborative development experience.


I know the cookie_cutter was made base

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

[sage-devel] Fwd: [sage-trac-account] Corrections about the function "is_prime" for graphs

[Harald Schilly]

This came in via the trac account request. I don't know the sender's
email address ...

-- h


-- Forwarded message --
From: 'Jamel Dammak' via sage-trac-account 
Date: Sun, Dec 11, 2016 at 10:01 PM
Subject: [sage-trac-account] Corrections about the function "is_prime"
for graphs
To: "sage-trac-acco...@googlegroups.com" 


Dear sir,

there is an error concerning the function "is_prime" for graphs in
Sagemath, section Graph Theory.

Here is a conter-example.

g1=Graph({0:[1,4],1:[0,2,4],2:[1,3,4],3:[2],4:[0,1,2]});g2=Graph({0:[1],1:[0,2,4],2:[1,3,4],3:[2,4],4:[1,2,3]})
#g1.show();g2.show();
#[1,4] is a module of g1 so g1 is not prime
g2.is_isomorphic(g1), g1.is_prime(),g2.is_prime()

This is a conter-example with two isomorphic graphs g1 and g2 on 5
vertices giving two different results
with the function "is prime".

I have an algorithm giving the list of all prime graphs on at most 8 vertices.

Best regards.

--
--
You received this message because you are subscribed to the Google
Groups "sage-trac-account" group.
To post to this group, send email to sage-trac-acco...@googlegroups.com
To unsubscribe from this group, send email to
sage-trac-account+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sage-trac-account

---
You received this message because you are subscribed to the Google
Groups "sage-trac-account" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to sage-trac-account+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[sage-devel] Fwd: Sage at 2016 MAA Project NExT Networking Lunch

[William A Stein]

Is any Sage dev going to the MAA Mathfest?  If so, email Alissa below.

-- Forwarded message --
From: Crans, Alissa 
Date: Fri, May 13, 2016 at 9:23 PM
Subject: RE: Sage at 2016 MAA Project NExT Networking Lunch
To: William A Stein 


Hi William,

I hope you're doing well.

I still haven't been able to find someone coming to MathFest who would
be able to represent Sage to the new MAA Project NExT Fellows.  Can
you think of anyone else I might invite?  I know that Sage is very
popular amongst this group and I would hate for it not to be
represented at our lunch.

Thanks for your time,
alissa

From: William A Stein [wst...@uw.edu]
Sent: Friday, April 22, 2016 6:33 PM
To: Crans, Alissa
Cc: bee...@ups.edu; karl.cris...@gordon.edu
Subject: Re: Sage at 2016 MAA Project NExT Networking Lunch

I won't be there either, but thanks!

On Fri, Apr 22, 2016 at 12:14 PM, Crans, Alissa  wrote:
> Dear Rob, Karl, and William,
>
> I hope this message finds you well.
>
> I'm writing to invite you to attend the second annual MAA Project NExT 
> Networking Lunch for the 2015-16 and 2016-17 Fellows during MathFest 2016 in 
> Columbus, OH and represent Sage.  The purpose of the lunch is to introduce 
> the new Fellows to the variety of resources in the mathematical community.
>
> The lunch will be held on Wednesday, August 3, 2016 from 12 - 1:30 pm. Lunch 
> will be provided and you will have table space for a sign and computer. 
> Unfortunately we are unable to offer you access to MathFest or funding to 
> attend the lunch if this would require you arriving earlier to MathFest than 
> you were planning to do.
>
> Please let me know if you have any questions. In order to facilitate our 
> planning, please let me know by Wednesday, May 4 whether you will be able to 
> attend. If you are unable to attend, could you suggest someone else that 
> might be available to represent Sage? Thank you very much.   We look forward 
> to having you come introduce the new Fellows to the numerous resources 
> available to them in our community!
>
> Best,
> Alissa Crans
> Associate Director, Project NExT

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

[sage-devel] Fwd: [sage-trac-account] BUG Report

[Kannappan Sampath]

Dear Debajyoti:

Thank you for your report. We appreciate it. sage-devel is one place to
report bugs!

=

Dear all:

This is a bug report sent to sage-trac-account.

Regards,
KnS.

-- Forwarded message --
From: Debajyoti Nandi 
Date: Mon, May 9, 2016 at 1:17 AM
Subject: [sage-trac-account] BUG Report
To: sage-trac-acco...@googlegroups.com


Name: Debajyoti Nandi
Preferred Username: deehzee
Contact email: deeh...@gmail.com
Reason: BUG Report

I'm not sure if I'm at right place for reporting this. But here is the
issue:

All links in the "modules" page on docs.sagemath.org are broken.  Below is
the URL which lists the modules (but the links within this page doesn't
work):
http://doc.sagemath.org/html/en/developer/py-modindex.html

Thank you very much and best regards,
Debajyoti.

-- 
-- 
You received this message because you are subscribed to the Google Groups
"sage-trac-account" group.
To post to this group, send email to sage-trac-acco...@googlegroups.com
To unsubscribe from this group, send email to
sage-trac-account+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sage-trac-account

---
You received this message because you are subscribed to the Google Groups
"sage-trac-account" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to sage-trac-account+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[sage-devel] Fwd: [sage-trac] #10295: Upgrading pexpect

[Bill Page]

Is anyone interested in helping to resolve this old pexpect issue? Dealing
with the Sage development process and in particular Sage package management
is a bit beyond me but François Bissey created a branch almost 5 months ago
with an updated version of pexpect that worked with the version of Sage
available at that time.

http://git.sagemath.org/sage.git/commit/?id=80cd29cee620bb62b53a389cff5f7db4aa65b2d6

Recently one of the pexpect developers expressed an interest in helping to
resolve the issue and to that end committed a patch to pexpect to make the
wait in the read loop optional.  This would avoid having to apply a patch
for that purpose since Sage can now just call the new version of pexpect
with that option.

What steps would be necessary to get this ticket closer to the top of the
pile?

-- Forwarded message --
From: sage-trac 
Date: 14 October 2015 at 20:18
Subject: Re: [sage-trac] #10295: Upgrading pexpect
To:


#10295: Upgrading pexpect
-+-
   Reporter:  SimonKing  |Owner:  was
   Type:  enhancement|   Status:  new
   Priority:  major  |Milestone:  sage-6.7
  Component:  interfaces |   Resolution:
   Keywords:  pexpect upgrade|Merged in:
Authors: |Reviewers:
Report Upstream:  N/A|  Work issues:
 Branch: |   Commit:
  u/fbissey/pexpect3.3   |
80cd29cee620bb62b53a389cff5f7db4aa65b2d6
   Dependencies: | Stopgaps:
-+-

Comment (by bpage):

 See commit to pexpect


https://github.com/pexpect/pexpect/commit/40ce421051c0a54f3b3849424491882cf1339801

 by Jeff Quast.  Some discussion at

 https://gitter.im/pexpect/pexpect

 The proposal is to make it possible for Sage to stop bundling an obsolete
 version of pexpect and to take advantage of recent improvements to pexpect
 including unicode support and support for Python 3.

--
Ticket URL: 
Sage 
Sage: Creating a Viable Open Source Alternative to Magma, Maple,
Mathematica, and MATLAB

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

[sage-devel] Fwd: Sage Math on Raspbian /Raspberry Pi 2

[mmarco]

I think we should definitely have a raspbian buildbot. It is tricky because of 
the hardware limitations, but it should be possible.

Another option is to run a virtual machine emulating a raspberry pi. I recently 
compiled sage 6.5 in such a VM, an it took almost a week. I still have to build 
a bdist and test it on actual hardware.

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

[sage-devel] Fwd: Sage Math on Raspbian /Raspberry Pi 2

[William Stein]

-- Forwarded message --
From: Roberto Panai 
Date: Mon, Apr 20, 2015 at 4:00 PM
Subject: Sage Math on Raspbian /Raspberry Pi 2
To: wst...@gmail.com


Dear William,
I just bought one Raspberry Pi 2 and I saw Wolfram Mathematica is
already in. Apparently there is not a (updated) binary file for this
device and to compile it you need a couple of days.
I was wondering if you wish to have some binary for this device/os or
not. I could eventually compile it for you. An other option is to made
a small app which open a browser on cloud.sagemath.com as the gmail
app for ubuntu does.


Best,
Roberto

PS. On https://en.wikipedia.org/wiki/List_of_computer_algebra_systems
Sage Math version was not updated.


-- 
William (http://wstein.org)

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

Re: [sage-devel] Fwd: [sage-coding-theory] Coding Theory development project. Request-for-comments: New code family and encoder/decoder structu

[Nathann Cohen]

Hello,

It seems that you really implemented a lot of things before creating
any ticket on Sage's trac. Be aware that the reviews may be very
painful as a result, for some fundamental design decisions may have to
be changed in this process.

Nathann

On 20 February 2015 at 18:32, Dima Pasechnik  wrote:
> -- Forwarded message --
> From: "Johan S. R. Nielsen" 
> Date: 20 Feb 2015 17:24
> Subject: [sage-coding-theory] Coding Theory development project.
> Request-for-comments: New code family and encoder/decoder structu
> To: 
> Cc:
>
> Hello everyone,
>
> As we announced previously
> (https://groups.google.com/forum/#!topic/sage-devel/pBmeknQcyZM), we started
> October 1. a 2-year project for improving coding theory support in Sage.
> This post has two purposes: 1) It's our "going public" post, where we
> announce more precisely our plans for our 2-year project; and 2) It puts up
> for discussions our new scalable design for doing coding theory in Sage
> which comes with a fully working and documented implementation, integrated
> into a fork of Sage.
>
> Our project now has a web page, which is also our project repository:
> https://bitbucket.org/lucasdavid/sage_coding_project
>
> This page contains a description of our project, our development plan, and a
> description of what has currently been implemented including examples. It is
> also a Git repository containing a fork of the Sage project containing at
> any time the newest version of Sage with the newest (unstable) version of
> our code integrated. Little by little, our code will be cut up into tickets
> and incorporated into Sage using Trac and the review system. While tickets
> are being reviewed, new ones will be written, and our Git repository makes
> it easy to get a Sage version containing all the newest functionality.
>
> What we have done so far and our suggested design:
> Our team -- and principally our main developer David Lucas -- has been hard
> at work thinking of a scalable design for representing the core objects of
> coding theory: it should appeal to people coming from any of the many
> approaches to coding theory, and as with all things Sage, it should appeal
> to many levels of user competence. This is just the first step of our
> project, and later ones will add much more new functionality.
>
> The result is a base design and a working demo of this that we suggest to
> incorporate into Sage. It concerns principally
>
>  - Code families as classes
>  - Representation of multiple encoding and decoding methods, specific to the
> respective code family.
>
> And secondarily
>
>  - Representing communication channels, i.e. "adding errors"
>  - Some renaming of foundational methods
>
> To demonstrate this, we have implemented:
>
>  - Generalized Reed-Solomon codes as a class
>  - Hamming Codes as a class
>  - Concatenated codes as a class, demonstrating the modularity of
> class-based families
>  - 2 encoders for GRS codes
>  - 3 fast decoders for GRS codes, two half-minimum distance decoders, 1
> error-erasure decoder
>  - A channel for adding errors, and a channel for adding errors-and-erasures
>
> It will have deep consequences for the representation, use and further
> development of coding theory functionality. Before opening tickets for these
> changes, we want to present the design here, so that we can discuss and
> possibly improve it.
>
> Code examples are much better than words at conveying design: we have
> written a page going through the new ideas of the design from a user's point
> of view:
> https://bitbucket.org/lucasdavid/sage_coding_project/wiki/Examples
>
> In more technical details, the main design features that we propose are:
>
> 1) Code families are classes. This enables family-specific functionality,
> such as minimum distance bounds or fast decoders.
> 2) A code is therefore no longer always given by a generator matrix. For
> such code families, a generator matrix will only be computed on demand.
> 3) Encoders are classes. We support multiple encoders for a code family
> allowing different mappings.
> 4) The message space for an encoder can be something else than a vector
> space. Reed-Solomon codes can e.g. have an encoder which encodes polynomials
> directly.
> 5) The inverse of encoding is called "unencoding" (as opposed to "decoding"
> which we reserve for correcting errors). unencode() is a method on Encoder.
> 6) Decoders are classes. This enables multiple decoders for a code family.
> 7) Decoders have an input space which is not necessarily the ambient space
> of the code. This supports e.g. soft-decision decoders where reliability
> information is part of the input.
> 8) Decoders can decode to a codeword or directly to a message space.
> 9) There are convenience methods directly on a code for encoding, decoding
> and unencode such that users not caring about these choices are not
> burdened.
> 10) We introduce Channels which embody the concept of communication
> channels, both for adding erro

[sage-devel] Fwd: [sage-coding-theory] Coding Theory development project. Request-for-comments: New code family and encoder/decoder structu

[Dima Pasechnik]

-- Forwarded message --
From: "Johan S. R. Nielsen" 
Date: 20 Feb 2015 17:24
Subject: [sage-coding-theory] Coding Theory development project.
Request-for-comments: New code family and encoder/decoder structu
To: 
Cc:

Hello everyone,

As we announced previously (
https://groups.google.com/forum/#!topic/sage-devel/pBmeknQcyZM), we started
October 1. a 2-year project for improving coding theory support in Sage.
This post has two purposes: 1) It's our "going public" post, where we
announce more precisely our plans for our 2-year project; and 2) It puts up
for discussions our new scalable design for doing coding theory in Sage
which comes with a fully working and documented implementation, integrated
into a fork of Sage.

Our project now has a web page, which is also our project repository:
https://bitbucket.org/lucasdavid/sage_coding_project

This page contains a description of our project, our development plan, and
a description of what has currently been implemented including examples. It
is also a Git repository containing a fork of the Sage project containing
at any time the newest version of Sage with the newest (unstable) version
of our code integrated. Little by little, our code will be cut up into
tickets and incorporated into Sage using Trac and the review system. While
tickets are being reviewed, new ones will be written, and our Git
repository makes it easy to get a Sage version containing all the newest
functionality.

What we have done so far and our suggested design:
Our team -- and principally our main developer David Lucas -- has been hard
at work thinking of a scalable design for representing the core objects of
coding theory: it should appeal to people coming from any of the many
approaches to coding theory, and as with all things Sage, it should appeal
to many levels of user competence. This is just the first step of our
project, and later ones will add much more new functionality.

The result is a base design and a working demo of this that we suggest to
incorporate into Sage. It concerns principally

 - Code families as classes
 - Representation of multiple encoding and decoding methods, specific to
the respective code family.

And secondarily

 - Representing communication channels, i.e. "adding errors"
 - Some renaming of foundational methods

To demonstrate this, we have implemented:

 - Generalized Reed-Solomon codes as a class
 - Hamming Codes as a class
 - Concatenated codes as a class, demonstrating the modularity of
class-based families
 - 2 encoders for GRS codes
 - 3 fast decoders for GRS codes, two half-minimum distance decoders, 1
error-erasure decoder
 - A channel for adding errors, and a channel for adding errors-and-erasures

It will have deep consequences for the representation, use and further
development of coding theory functionality. Before opening tickets for
these changes, we want to present the design here, so that we can discuss
and possibly improve it.

Code examples are much better than words at conveying design: we have
written a page going through the new ideas of the design from a user's
point of view:
https://bitbucket.org/lucasdavid/sage_coding_project/wiki/Examples

In more technical details, the main design features that we propose are:

1) Code families are classes. This enables family-specific functionality,
such as minimum distance bounds or fast decoders.
2) A code is therefore no longer always given by a generator matrix. For
such code families, a generator matrix will only be computed on demand.
3) Encoders are classes. We support multiple encoders for a code family
allowing different mappings.
4) The message space for an encoder can be something else than a vector
space. Reed-Solomon codes can e.g. have an encoder which encodes
polynomials directly.
5) The inverse of encoding is called "unencoding" (as opposed to "decoding"
which we reserve for correcting errors). unencode() is a method on Encoder.
6) Decoders are classes. This enables multiple decoders for a code family.
7) Decoders have an input space which is not necessarily the ambient space
of the code. This supports e.g. soft-decision decoders where reliability
information is part of the input.
8) Decoders can decode to a codeword or directly to a message space.
9) There are convenience methods directly on a code for encoding, decoding
and unencode such that users not caring about these choices are not
burdened.
10) We introduce Channels which embody the concept of communication
channels, both for adding errors and for changing representation. They
provide a modular and convenient structure for user-friendliness and
code-reusability in e.g. benchmarking frameworks.
11) Renaming of some methods in LinearCode: gen_mat into generator_matrix
and check_mat to parity_check_matrix.

We invite for discussion on this design and for contributions by everyone
motivated by coding theory. As soon as we agree on this thread, we will
create a ticket on Trac with the first few changes. Reviewe

[sage-devel] Fwd: [sage-support] Bug in polynomial GCD (FLINT)

[John Cremona]

If ever there was a blocker, surely this is it!

John


-- Forwarded message --
From: Anton Mellit 
Date: 16 February 2015 at 23:54
Subject: [sage-support] Bug in polynomial GCD (FLINT)
To: sage-supp...@googlegroups.com


Here is the code:
R.=QQ[]
X=3*q^12 - 8*q^11 - 24*q^10 - 48*q^9 - 84*q^8 - 92*q^7 - 92*q^6 -
70*q^5 - 50*q^4 - 27*q^3 - 13*q^2 - 4*q - 1
Y=q^13 - 2*q^12 + 2*q^10 - q^9
print gcd(X,Y)
print X(1)
Here is the output:
q - 1 -510
The bug is extremely serious because it affects all computations with
rational functions. It is also quite rare, I believe. I traced it down
to the function _fmpz_poly_gcd_heuristic in FLINT. The bug is
triggered when the heuristic algorithm fails, one of the divisibility
checks fails, but still the value is returned as o.k.
The fix is easy, just one line needs to be added
if (divides) /* quotient really was exact */ { ---> divides=0;

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

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

[sage-devel] Fwd: [sage-cloud] Google Summer of Code Alternative

[William A Stein]

I'm forwarding this to the sage-devel list, since sage-cloud isn't
sage (and sage-cloud isn't FOSS, so can't participate in this
program), but Sage can.


-- Forwarded message --
From: Андрей Ширшов 
Date: Wed, Sep 10, 2014 at 4:19 AM
Subject: [sage-cloud] Google Summer of Code Alternative
To: sage-cl...@googlegroups.com


Hi!
Just now I've found http://semesterofcode.com/ - the alternative for GSOC.
There is no contest for open source projects, so Sage project seems
can participate in it.
Some information from FAQ:

What are the goals of Semester of Code?

The Semester of Code pilot will work with higher education (HE) and
free and open source software (FOSS) projects to provide real-world
experience for students in the software industry, while providing
projects with valuable contributions.

Following the pilot, the VALS project of which the Semester of Code is
part will use the knowledge gained to produce a methodology and
guidelines for running similar schemes in the future.

What is the timeline of the pilot?

Project idea submissions from FOSS projects open week ending July 21st
and close Sep 12th.
Proposal submissions from students open Sep 12th and close Nov 14th
Selection of submitted proposals opens Sep 12th and closes Nov 21st.
Final announcements are on Fri Nov 28th

Note that, unlike in Google Summer of Code, there is no fixed project
end deadline; instead mentors, students and academic supervisors need
to set agreed deadlines. We recommend a similar length of projects to
GSoC

What will the benefits to the FOSS project be?

The purpose of the Semester of Code is to develop students engagement
with and appreciation of being a part of the free software and open
source communities. In some cases this may mean that students continue
to contribute to projects after the semester is over, or once they
graduate.

However, even where an individual student doesn’t contribute to that
particular project once their academic work is completed, by
participating in SoC we are growing the number of students actively
engaged with open source, and developing the next generation of talent
that all FOSS projects need for the future.

What commitment is needed from FOSS project mentors?

The mentor is responsible for connecting students with the project’s
community, for getting them up t speed with using the project
communication channels, and following the rules and norms of the
project. Mentors need to engage with students to help them submit
their work to the project, for example by getting set up to use any
project-specific tools, advising on architectural and code style
considerations, and breaking the project work up into smaller patches
where appropriate.

We expect mentors to be in regular contact with students, to
acknowledge communications from students, to review student work, and
to complete a brief final evaluation of the project.

It is up to mentors, students and academic supervisors to agree on
specific expectations for their SoC project, such as communication
times and channels. “Regularly” may be an email each morning, a weekly
Skype chat, or anything else that the participants agree on; for
example, if students are submitting regular patches and issues into
the project’s tracker, this may obviate the need for some of the
communication.

We also expect mentors to communicate with the Academic Supervisor and
the SoC team about any issues that arise and to provide occasional
status updates.

I’m worried that participating in Semester of Code will be wasted
effort. What does the Semester of Code have in place to prevent high
rate of failure from student projects?

One of the common problems in mentoring programmes is where there is a
breakdown in communication between mentors and mentees; another is
where students do not deliver to deadlines. Sometimes its as simple as
the student not letting the mentor know about other commitments such
as resits or holidays. Sometimes its a deeper problem around
motivation.

In these situations, given that mentor and mentee are rarely in the
same location, there is very little a mentor can do to get the project
moving.

However, in Semester of Code we have two ways to keep projects on
track. One is the additional relationship in SoC between the mentor
and the academic supervisor, who mentors can contact if there are any
problems with the project.

Academic supervisors can conduct the sort of chasing and motivating of
students that mentors cannot (and usually don’t want to) undertake,
usually by virtue of being able to talk face to face with students.

They also of course have the recourse of academic sanctions; unlike in
GSoC there is no financial incentive to students, but there is a
requirement to satisfy the academic standards for their course.

The second option we offer is the SoC team itself. As a fairly small
pilot programme our team can help troubleshoot any problems and keep
things moving. Between us we have a lot of experience in FOSS
proj

[sage-devel] Fwd: SAGE in the cloud and Python 3

[William A Stein]

(This is a sage-devel question, not one for me personally or for
sage-cloud; please join that mailing list.)

For example, Volker remarks "There has been some steady progress by
Wilfried Luebbe and André Apitzsch to move towards Python 3.
Meta-tickets:

http://trac.sagemath.org/ticket/16052
http://trac.sagemath.org/ticket/15980
"



-- Forwarded message --
From:  
Date: Tue, Sep 2, 2014 at 9:12 AM
Subject: Re: SAGE in the cloud and Python 3
To: William A Stein 


Ok, but I saw that SciPy and Numpy were Py3 compatible now :
  http://www.scipy.org/scipylib/faq.html#do-numpy-and-scipy-support-python-3-x
So, why ? Isn’t Py3 the obvious future of Python ? Most universities
here teach Python 3.
Thanks,

-jpr

Le 2 sept. 2014 à 18:06, William A Stein  a écrit :

> On Tue, Sep 2, 2014 at 8:41 AM,   wrote:
>> Hi William !
>> When will SAGE be Python 3 compatible ? I tried with range and it’s still 
>> Python 2…
>> Thanks,
>
> As far as I know, we currently have no specific concrete plans for
> transition sage from Python 2 to Python 3. I've cc'd the
> sage-devel list in case there's something brewing.
>
> You could use command-line Python 3 in a terminal on SMC by creating a
> terminal then typing "python3".
>
> -- William
>
> --
> William Stein
> Professor of Mathematics
> University of Washington
> http://wstein.org
> wst...@uw.edu
>



-- 
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
wst...@uw.edu

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

[sage-devel] Fwd: Sage on Ubuntu 13.04

[Jan Groenewald]

Hi Pablo,

At the moment the PPA is 64bit only. I might do 32bit in a few months.
There is a binary for 13.04 here:
http://boxen.math.washington.edu/home/sagemath/sage-mirror/linux/32bit/sage-5.10-linux-32bit-ubuntu_13.04-i686-Linux.tar.lzma

Regards,
Jan


-- Forwarded message --
From: Pablo Fernando Zubieta Rico 
Date: 15 July 2013 23:15
Subject: Sage on Ubuntu 13.04
To: "j...@aims.ac.za" 


Hi again

I wrote you before to explain that I wasn't able to install de
sagemath-upstream-binary adding the Sage PPA, but looking into the packages
details, I found they were 64-bit packages. I have a 32-bit installation.
Is there any plan on uploading 32-bit versions?

Thank you,
Pablo Zubieta



-- 
  .~.
  /V\ Jan Groenewald
 /( )\www.aims.ac.za
 ^^-^^

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

Re: [sage-devel] Fwd: Sage Man Page

[Kannappan Sampath]

Hello YMADEC,

You might be glad to note that, there is a ticket relevant to this. You
might want to apply for a trac account and get involved with the sage
development.

The Trac Homepage http://trac.sagemath.org/sage_trac/  has instructions for
requesting a trac account and the ticket you might want to look at is:

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

Cheers,
KnS


On Sat, Jul 13, 2013 at 12:40 AM, William Stein  wrote:

> -- Forwarded message --
> From: "YMADEC" 
> Date: Jul 12, 2013 11:46 AM
> Subject: Fwd: Sage Man Page
> To: 
> Cc:
>
>  Sorry, I forgot attaching the file...
>
>
>
>  Message original   Sujet: Sage Man Page  Date : Fri, 12
> Jul 2013 20:42:07 +0200  De : YMADEC  
>  Pour :
> wst...@gmail.com
>
> Hello,
>
> I'm a new user of Sage and I had some difficulties to find the Sage
> command-line options.
> I tried sage -h, that worked, and then I could find the sage -advanced
> command that printed what I was looking for.
> But it would be better if Sage had a man page, that could be found with
> man sage.
> Thats's why I adapted the advanced help message to a man page, which is
> joined to this message. I hope that it would be useful.
>
> Regards,
>
> YMADEC
>
>
> P.S. Sorry for my bad english, I'm just a young french student...
> I also could help translating Sage, if needed.
>
>
>
>   --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

[sage-devel] Fwd: Sage Man Page

[William Stein]

-- Forwarded message --
From: "YMADEC" 
Date: Jul 12, 2013 11:46 AM
Subject: Fwd: Sage Man Page
To: 
Cc:

 Sorry, I forgot attaching the file...



 Message original   Sujet: Sage Man Page  Date : Fri, 12
Jul 2013 20:42:07 +0200  De : YMADEC
  Pour :
wst...@gmail.com

Hello,

I'm a new user of Sage and I had some difficulties to find the Sage
command-line options.
I tried sage -h, that worked, and then I could find the sage -advanced
command that printed what I was looking for.
But it would be better if Sage had a man page, that could be found with
man sage.
Thats's why I adapted the advanced help message to a man page, which is
joined to this message. I hope that it would be useful.

Regards,

YMADEC


P.S. Sorry for my bad english, I'm just a young french student...
I also could help translating Sage, if needed.

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


.\" 

.\" This man page was adapted from the Sage advanced help message (run sage 
-advanced) by Ymadec 
.\" 

.\" 
.TH SAGE 1 2013-07-12 "Sage Version 5.8, Release Date: 2013-03-15"

.SH NAME
Sage \- Free, open-source math sowtware

.SH SYNOPSIS
.B sage
[\fIfile\fR | \fIoptions...\fR]
.LP
.B sagemath
[\fIfile\fR | \fIoptions...\fR]
.LP
.B \fIfile\fR can be a .sage, .py or .spyx file.

.SH DESCRIPTION
Sage is free, open-source math software that supports research and teaching
in algebra, geometry, number theory, cryptography, numerical computation,
and related areas.
The overall goal of Sage is to create a viable, free, open-source alternative
to Maple, Mathematica, Magma, and MATLAB.

.SH OPTIONS

You can also use \fB--\fP before a long option, e.g., \fBsage --optional\fP.

.SS "Running Sage"
.TP
\fB\-advanced\fP
print an advanced help message
.TP
\fB\-c\fP \fIcmd\fP
Evaluates \fIcmd\fP as sage code
.TP
\fB\-h\fP, \fB\-?\fP
print short help message
.TP
\fB\-min\fP [...]
do not populate global namespace (must be first option)
.TP
\fB\-preparse\fP \fIfile.sage\fP
preparse \fIfile.sage\fP and produce corresponding \fIfile.sage.py\fP
.TP
\fB\-q\fP
quiet; start with no banner
.TP
\fB\-root\fP
print the Sage root directory
.TP
\fB\-gthread\fP, \fB\-qthread\fP, \fB\-q4thread\fP, \fB\-wthread\fP, 
\fB\-pylab\fP
pass the option through to ipython
.TP
\fB\-v\fP, \fB\-version\fP
print the Sage version

.SS "Running the notebook"
.TP
\fB\-bn\fP, \fB\-build-and-notebook\fP [...]
build the Sage library then start the Sage notebook
.TP
\fB\-inotebook\fP [...]
start the insecure Sage notebook
.TP
\fB\-n\fP, \fB\-notebook\fP [...]
start the Sage notebook (options are the same as for the \fBnotebook()\fP 
command in Sage)

.SS "Running external programs"
.TP
\fB\-cleaner\fP
run the Sage cleaner
.TP
\fB\-cython\fP [...]
run Cython with given arguments
.TP
\fB\-ecl\fP [...]
run Common Lisp
.TP
\fB\-gap\fP [...]
run Sage's Gap with given arguments
.TP
\fB\-gdb\fP
run Sage under the control of gdb
.TP
\fB\-gp\fP [...]
run Sage's PARI/GP calculator with given arguments
.TP
\fB\-hg\fP [...]
run Sage's Mercurial with given arguments
.TP
\fB\-ipython\fP [...]
run Sage's IPython using the default environment (not Sage), passing additional 
options to IPython
.TP
\fB\-kash\fP [...]
run Sage's Kash with given arguments (if not installed currently, run \fBsage 
\-i kash\fP)
.TP
\fB\-lisp\fP [...]
run Lisp interpreter included with Sage
.TP
\fB\-M2\fP [...]
run Sage's Macaulay2 with given arguments (if not installed currently, run 
\fBsage \-i macaulay2\fP)
.TP
\fB\-maxima\fP [...]
run Sage's Maxima with given arguments
.TP
\fB\-mwrank\fP [...]
run Sage's mwrank with given arguments
.TP
\fB\-python\fP [...]
run the Python interpreter
.TP
\fB\-R\fP [...]
run Sage's R with given arguments
.TP
\fB\-scons\fP [...]
run Sage's scons
.TP
\fB\-sh\fP [...]
run \fB$SHELL\fP (/bin/bash) with Sage environment variables
.TP
\fB\-singular\fP [...]
run Sage's singular with given arguments
.TP
\fB\-sqlite3\fP [...]
run Sage's sqlite3 with given arguments
.TP
\fB\-twistd\fP [...]
run Twisted server

.SS "Installing packages and upgrading"
.TP
\fB\-experimental\fP
list all experimental packages that can be installed
.TP
\fB\-f\fP [\fIopts\fP] [\fIpackages\fP]
shortcut for \fB\-i \-f\fP: force build of the given Sage \fIpackages\fP
.TP
\fB\-i\fP [\fIopts\fP] [\fIpackages\fP]
install the given Sage \fIpackages\fP (unless they are already installed);
if no \fIpackages\fP are given,

[sage-devel] Fwd: Sage Man Page

[William Stein]

I haven't read this...
-- Forwarded message --
From: "YMADEC" 
Date: Jul 12, 2013 11:42 AM
Subject: Sage Man Page
To: 
Cc:

Hello,

I'm a new user of Sage and I had some difficulties to find the Sage
command-line options.
I tried sage -h, that worked, and then I could find the sage -advanced
command that printed what I was looking for.
But it would be better if Sage had a man page, that could be found with man
sage.
Thats's why I adapted the advanced help message to a man page, which is
joined to this message. I hope that it would be useful.

Regards,

YMADEC


P.S. Sorry for my bad english, I'm just a young french student...
I also could help translating Sage, if needed.

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

[sage-devel] Fwd: [sage-algebra] Boundary cases

[David Kohel]

In a ring of characteristic 0, it seems that 0^0 (= 1) is well-defined.
In my view this is correct.  It makes it much simpler to define the
matrix (e.g. FF a finite field):

G = matrix([ [ a^i for a in FF ] for i in range(k) ])

However, in finite fields or any of the the following rings, 0^0
gives an error:

FF. = FiniteField(32)
FF = FiniteField(31)
PF. = PolynomialRing(FF)

The correct behaviour can be faked in an isomorphic ring which
is a quotient of something in characteristic zero:

PZ. = PolynomialRing(ZZ)
R = PZ.quotient_ring([x-1,31])

Here R(0)^0 (= 1) is fine.  Is there any objection to reporting this
as a bug and fixing it?

--David


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Fwd: [Sage] #13141: implement constructing the dual of a linear program

[Dima Pasechnik]

As there might be more people interested in this feature, I forward this here.


-- Forwarded message --
From: Sage 
Date: 20 June 2012 12:08
Subject: [Sage] #13141: implement constructing the dual of a linear program
To:
Cc: sage-t...@googlegroups.com


#13141: implement constructing the dual of a linear program
--+-
  Reporter:  dimpase             |             Owner:  ncohen
      Type:  enhancement         |            Status:  new
  Priority:  major               |         Milestone:  sage-5.2
 Component:  linear programming  |          Keywords:
Work issues:                      |   Report Upstream:  N/A
 Reviewers:                      |           Authors:
 Merged in:                      |      Dependencies:
  Stopgaps:                      |
--+-
 There is currently no support for constructing the classic LP dual of a
 linear program (LP).
 It would be very useful for various reasons, last but not the least
 constructing certificates of
 optimality and of infeasibility of an LP.

--
Ticket URL: 
Sage 
Sage: Creating a Viable Open Source Alternative to Magma, Maple,
Mathematica, and MATLAB

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

[sage-devel] Fwd: Sage and LinBox >= 1.3.0

[Martin Albrecht]

Argh, pressed sent by accident. Now again:

Hi [sage-devel], (CC [linbox-devel] FYI)

Brice (for [sage-devel]: he's from the LinBox project) and I are at
the "Efficient Linear Algebra for Gröbner Basis Computations" workshop
at the moment and got kind of sidetracked into updating LinBox in
Sage.

Sage still uses version 1.1.6 which was released 4 years ago, this is
embarrassing!

Anyway, we got it to compile and Sage starts!

See

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

which has a bunch of dependencies:

 * Givaro update: http://trac.sagemath.org/sage_trac/ticket/9511
 * M4RIE update (because of Givaro update):
http://trac.sagemath.org/sage_trac/ticket/12840
 * M4RI update (because of the Givaro update):
http://trac.sagemath.org/sage_trac/ticket/12841

However, we found two bugs already. One of them is definitely in
upstream (reduced row echelon forms are wrong when using
EchelonDomain's but work when one is using FFPACK directly). I believe
Brice will report this bug to LinBox properly. Another but which is a
segfault in determinants over the Integers. However, we cannot
reproduce this outside of Sage, so this bug needs some tracking down.
It is plausible that there are more bugs.

Hence, I'd appreciate help. That is, please try to compile this code
and try to track down issues and perhaps fix them. It seems we are
closer to upgrading LinBox than we were before and I would hate to see
this bitrot. For that to happen, we need your help.

Cheers,
Martin

--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
_www: http://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de


-- 
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
_www: http://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de

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

[sage-devel] Fwd: [sage-edu] Abelian Groups: comments and suggestions

[John Cremona]

I cannot post to sage-devel so am sending this to a couple of other groups.


-- Forwarded message --
From: John Cremona 
Date: 3 May 2012 22:47
Subject: Re: [sage-edu] Abelian Groups: comments and suggestions
To: Rob Beezer 
Cc: sage-...@googlegroups.com, David Joyner 


Don't forget that we do have things like

sage: E = EllipticCurve('11a1')
sage: T = E.torsion_subgroup()
sage: T.element_class

sage: T
Torsion Subgroup isomorphic to Z/5 associated to the Elliptic Curve
defined by y^2 + y = x^3 - x^2 - 10*x - 20 over Rational Field
sage: O = T(0)
sage: type(O)

sage:

using the abelian group wrapper for the PID modules code.  It's
already used in quite a few places.

John

On 3 May 2012 21:52, Rob Beezer  wrote:
>
>
> On Thursday, March 15, 2012 1:50:08 PM UTC-7, William Stein wrote:
>>
>> It would be good if somebody rewrote abelian groups from scratch
>> taking into account your comments above.  Personally, I would probably
>> make the user interface be similar to Magma's abelian groups, which is
>> pretty well thought out, and will make it easier for people (like me)
>> to use both Sage and Magma:
>
> (Been away for a while and missed this thread.)
>
> Agreed.  I might be the 7th attempt.  I started this once, and then when I
> came back to it a year later, the category code had changed so much that it
> needed a severe rewrite (which I may have lost).  But I have support this
> summer for exactly this task and a good idea of how to attack it.
>
> Mike O'S - I'll take your comments into account and would love further
> feedback.  First attempt is at:
>
> http://trac.sagemath.org/sage_trac/ticket/9773
>
> General strategy:  extend a good idea of Cremona and others (iirc) to build
> on William's code for finitely generated modules over PID's.  A lot of
> things (like forming a subgroup, nee submodule) then come for free.
>
> I wanted to build one abstract class, then extend it into additive and
> multiplicative flavors.  These would then be suitable for building generic
> cyclic groups, the group of units mod n, the multiplicative subgroup of a
> finite field, etc, etc.
>
> Rob

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

[sage-devel] Fwd: [sage-trac-account] El Gamal

[Minh Nguyen]

Hi,

I'm forwarding the message below to sage-devel where more people can
join in the discussion.


-- Forwarded message --
From: charls mathew 
Date: Mon, Jul 4, 2011 at 12:15 AM
Subject: Re: [sage-trac-account]
To: sage-trac-account 


I have an Elgamal Algorithm implementation based on the "Applied
Cryptography by Bruce Schneier".  It works well in version 4.7.

-- 
Regards
Minh Van Nguyen

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

[sage-devel] Fwd: sage-4.7.alpha4 segfaults on MacOSX

[Dima Pasechnik]

forwarding here, in case someone has seen this...


-- Forwarded message --
From: Dima Pasechnik 
Date: Apr 19, 12:18 am
Subject: sage-4.7.alpha4 released
To: sage-release


on MacOSX (x86 64bits) 10.6.7 Sage built with gcc from Xcode 4
segfaults at startup.
(and during the final stages of installation there are lot of related
segfaults)

Running ./sage -gdb gives:

[lots of output edited out ...]

warning: Could not find object file "/usr/local/src/sage/
sage-4.7.alpha4/spkg/build/pynac-0.2.1/src/ginac/.libs/wildcard.o" -
no debug information available for "wildcard.cpp".

. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x
0x000107a07c54 in PyInt_FromLong (ival=-5) at Objects/intobject.c:
91
91      Objects/intobject.c: No such file or directory.
        in Objects/intobject.c
(gdb)

the install.log is athttp://www1.spms.ntu.edu.sg/~dima/tmp/sage47alpha4.log.gz

Dima

On Apr 11, 9:45 pm, Jeroen Demeyer  wrote:



> ear Sage lovers,

> We're releasing Sage 4.7.alpha4.

> Source archive:

>http://sage.math.washington.edu/home/release/sage-4.7.alpha4/sage-4.7...

> Upgrade path:

>http://sage.math.washington.edu/home/release/sage-4.7.alpha4/sage-4.7...

> Please build, test, and report!  We'd love to hear about your
> experiences with this release.

> == Known issues ==

>  * Some doctests fail on bsd.math (OS X 10.6 i386), when compiling in
>    64-bit mode due to SAGE64 verbosity.  This is #10303.

> == Tickets ==
[...]

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

[sage-devel] Fwd: sage-4.7.alpha3 released -ECL problem?

[Dima Pasechnik]

-- Forwarded message --
From: Dima Pasechnik 
Date: Apr 3, 10:35 pm
Subject: sage-4.7.alpha3 released
To: sage-release


it doesn't build on MacOSX 10.5.8 PPC, getting stuck at ECL.
Any idea why?

[...]
;*** Lisp core booted 
ECL (Embeddable Common Lisp)

;;;
;;; Welcome to bare.lsp. Let's bring this instance up!
[...]
;;; Loading src:lsp;process.lsp
;;; Loading lsp/format.lsp
;;; About to load cmp/load.lsp
;;;
;;; Now we are in shape to do something useful.
;;; End of bare.lsp

Internal or unrecoverable error in:
not a lisp data object
  [2: No such file or directory]

;;; ECL C Backtrace
;;; 0   ecl_min                             0x000414c4
si_dump_c_backtrace + 52
;;; 1   ecl_min                             0x00033600
ecl_internal_error + 128
;;; 2   ecl_min                             0x0001f8ec cl_class_of +
588
;;; 3   ecl_min                             0x00016274 ecl_interpret +
1620
;;; 4   ecl_min                             0x00015240 cl_funcall +
208
;;; 5   ecl_min                             0x00020258
si_clear_gfun_hash + 168
;;; 6   ecl_min                             0x000208d4
_ecl_standard_dispatch + 436
;;; 7   ecl_min                             0x000156a4 cl_apply + 564
;;; 8   ecl_min                             0x00016488 ecl_interpret +
2152
;;; 9   ecl_min                             0x00015518 cl_apply + 168
;;; 10  ecl_min                             0x00016488 ecl_interpret +
2152
;;; 11  ecl_min                             0x00016520 ecl_interpret +
2304
;;; 12  ecl_min                             0x00015240 cl_funcall +
208
;;; 13  ecl_min                             0x00020910
_ecl_standard_dispatch + 496
;;; 14  ecl_min                             0x000156a4 cl_apply + 564
;;; 15  ecl_min                             0x00016488 ecl_interpret +
2152
;;; 16  ecl_min                             0x000156a4 cl_apply + 564
;;; 17  ecl_min                             0x00016488 ecl_interpret +
2152
;;; 18  ecl_min                             0x00016520 ecl_interpret +
2304
;;; 19  ecl_min                             0x00015240 cl_funcall +
208
;;; 20  ecl_min                             0x000336fc cl_error + 188
;;; 21  ecl_min                             0xd1f8 APPLY + 808
;;; 22  ecl_min                             0x000156a4 cl_apply + 564
;;; 23  ecl_min                             0x00016488 ecl_interpret +
2152
;;; 24  ecl_min                             0x000156a4 cl_apply + 564
;;; 25  ecl_min                             0x252c
si_signal_simple_error + 140
;;; 26  ecl_min                             0x00032e54
FEwrong_type_nth_arg + 260
;;; 27  ecl_min                             0x00035a14 ecl_char_set +
84
;;; 28  ecl_min                             0x000361e4
ecl_string_push_extend + 340
;;; 29  ecl_min                             0x00025354 cl_both_case_p
+ 8212
;;; 30  ecl_min                             0x00040064
_ecl_write_base_string + 196
;;; 31  ecl_min                             0x0003e9d4
si_write_ugly_object + 180
/bin/sh: line 1: 61605 Abort trap              ECLDIR=`pwd`/ ./ecl_min
compile
make[3]: *** [bin/ecl] Error 134
make[2]: *** [all] Error 2
Error - Failed to build ECL ... exiting

[...]

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

Re: [sage-devel] Fwd: [sage-combinat-devel] permutation group perspectives

[Jason B Hill]

On Tue, May 18, 2010 at 12:28 AM, Robert Bradshaw <
rober...@math.washington.edu> wrote:

> I full heartedly agree with the idea that permutation groups should be able
> to act on more than just the set 1..n, using a dictionary to do the mapping
> transparently to the user under the hood (and this is technically totally
> feasible). I'm not as convinced that we should throw out the notion of fixed
> points. For example, given Sn, n>2, I would not say all Z/2Z subgroups are
> "transitive" but it sounds like you want it to.
>
>
Good question. Your point aims at the notion that transitivity is not
inherently an invariant of a group, but is a property of a specific
representation. Yes, something such as a group generated by (100,101) should
be considered transitive... while a group generated by (98,99)(100,101) as a
single generator is clearly not transitive. They are both of course
representations of Z/2Z. At present, Sage considers neither of these to be
transitive. I also agree that we should not throw away the notion of fixed
points. But, my argument is that fixed points of a permutation
representation should be made explicit when defining the representation. So,
a group generated by (2)(100,101) is not transitive while a group generated
by (100,101) is.



> Would it be sufficient to provide a method that, given a group, returns a
> representation that keeps the permuted set names the same, but restricts the
> domain to non-fixed points?
>

I do think this would be sufficient, yes. Keep in mind though that this
should be easily restricted to subgroups and subrepresentations.

Jason B Hill


>
> - Robert
>
>
> On May 17, 2010, at 3:06 PM, Mike Hansen wrote:
>
>  -- Forwarded message --
>> From: Jason B Hill 
>> Date: Mon, May 17, 2010 at 3:05 PM
>> Subject: [sage-combinat-devel] permutation group perspectives
>> To: sage-combinat-de...@googlegroups.com
>>
>>
>>
>> This comes after a discussion I had with several at Sage days 20.5 in
>> Toronto relating to the underlying structure of permutation
>> representations in Sage. Sorry for the length, but it does completely
>> express the situation.
>>
>> I'll start by saying that I'm relatively new to Sage development (I'm
>> from the lands of GAP and C), but I do have some time and desire to
>> contribute in this area, depending on what results from this
>> discussion. I've also posted a ticket (#8929) on trac.sagemath.org
>> that adds some minimal functionality along these lines to the
>> permutation group methods in permgroup.py.
>>
>> Here's my basic issue: Sage constructs permutation groups in a very
>> intuitive, but arguably less robust and less mathematically consistent
>> way when compared to GAP. I want to explain these differences, to
>> explain why Sage's current perspective makes conducting my research in
>> Sage very challenging, and also to explain how the two perspectives
>> may potentially be brought together to add more functionality to
>> permutation group methods in Sage than currently exist in either Sage
>> or GAP.
>>
>> Here's an example of the same permutation group (really, a permutation
>> representation or action) in Sage and in GAP:
>>
>> sage: G=PermutationGroup([[(2,3,4,5,6,7,8)]])
>> gap> G:=Group([(2,3,4,5,6,7,8)]);
>>
>> To illustrate the differences between Sage and GAP, we can consider
>> transitivity:
>>
>> sage: G.is_transitive()
>> False
>> gap> IsTransitive(G);
>> true
>>
>> This difference is caused by GAP understanding G to be a permutation
>> representation acting on [2 ... 8], while Sage understands the action
>> to be on the set [1 ... 8], where 1 is in the domain of the action and
>> is simultaneously never moved by this specific representation. Sage
>> determines the degree of a permutation group to be the largest integer
>> moved by any of the generators. GAP considers the degree of a
>> permutation group to be the number of non-fixed points of the
>> representation. Hence, any notion of transitivity, regularity,
>> primitivity, etc. will be considerably different between GAP and Sage.
>> In fact, Sage currently has no is_primitive method, and I don't think
>> it is possible to implement such a method consistently given Sage's
>> current implementation of G.degree(). In our above example, GAP does
>> rightly think that G is primitive. However, in Sage, not only do we
>> have a block system / equivalence relation on the domain (composed on
>> blocks having different sizes, that's bad), but the representation of
>> G is not even transitive.
>>
>> Note about the ticket mentioned above: I have rewritten
>> is_transitive() and allowed for optional arguments in the form of
>> integers (in which case [1 .. input] is the domain) or lists of
>> integers (in which case the list is the domain). In the patch is also
>> a method for determining fixed and non-fixed points as a list, which
>> may then be used for transitivity, regularity and primitivity
>> calculations.
>>
>>
>>
>> Sage's approach is very intuitive.

Re: [sage-devel] Fwd: [sage-combinat-devel] permutation group perspectives

[Robert Bradshaw]

I full heartedly agree with the idea that permutation groups should be  
able to act on more than just the set 1..n, using a dictionary to do  
the mapping transparently to the user under the hood (and this is  
technically totally feasible). I'm not as convinced that we should  
throw out the notion of fixed points. For example, given Sn, n>2, I  
would not say all Z/2Z subgroups are "transitive" but it sounds like  
you want it to.


Would it be sufficient to provide a method that, given a group,  
returns a representation that keeps the permuted set names the same,  
but restricts the domain to non-fixed points?


- Robert

On May 17, 2010, at 3:06 PM, Mike Hansen wrote:


-- Forwarded message --
From: Jason B Hill 
Date: Mon, May 17, 2010 at 3:05 PM
Subject: [sage-combinat-devel] permutation group perspectives
To: sage-combinat-de...@googlegroups.com



This comes after a discussion I had with several at Sage days 20.5 in
Toronto relating to the underlying structure of permutation
representations in Sage. Sorry for the length, but it does completely
express the situation.

I'll start by saying that I'm relatively new to Sage development (I'm
from the lands of GAP and C), but I do have some time and desire to
contribute in this area, depending on what results from this
discussion. I've also posted a ticket (#8929) on trac.sagemath.org
that adds some minimal functionality along these lines to the
permutation group methods in permgroup.py.

Here's my basic issue: Sage constructs permutation groups in a very
intuitive, but arguably less robust and less mathematically consistent
way when compared to GAP. I want to explain these differences, to
explain why Sage's current perspective makes conducting my research in
Sage very challenging, and also to explain how the two perspectives
may potentially be brought together to add more functionality to
permutation group methods in Sage than currently exist in either Sage
or GAP.

Here's an example of the same permutation group (really, a permutation
representation or action) in Sage and in GAP:

sage: G=PermutationGroup([[(2,3,4,5,6,7,8)]])
gap> G:=Group([(2,3,4,5,6,7,8)]);

To illustrate the differences between Sage and GAP, we can consider
transitivity:

sage: G.is_transitive()
False
gap> IsTransitive(G);
true

This difference is caused by GAP understanding G to be a permutation
representation acting on [2 ... 8], while Sage understands the action
to be on the set [1 ... 8], where 1 is in the domain of the action and
is simultaneously never moved by this specific representation. Sage
determines the degree of a permutation group to be the largest integer
moved by any of the generators. GAP considers the degree of a
permutation group to be the number of non-fixed points of the
representation. Hence, any notion of transitivity, regularity,
primitivity, etc. will be considerably different between GAP and Sage.
In fact, Sage currently has no is_primitive method, and I don't think
it is possible to implement such a method consistently given Sage's
current implementation of G.degree(). In our above example, GAP does
rightly think that G is primitive. However, in Sage, not only do we
have a block system / equivalence relation on the domain (composed on
blocks having different sizes, that's bad), but the representation of
G is not even transitive.

Note about the ticket mentioned above: I have rewritten
is_transitive() and allowed for optional arguments in the form of
integers (in which case [1 .. input] is the domain) or lists of
integers (in which case the list is the domain). In the patch is also
a method for determining fixed and non-fixed points as a list, which
may then be used for transitivity, regularity and primitivity
calculations.



Sage's approach is very intuitive. If I input a single generator
[(100,101)], then my permutation group is isomorphic to Z_2 and acts
on [1 ... 101]. Unfortunately, I think this approach has more pitfalls
than bonuses. While it does mimic a human's permutation group
intuition, it removes a naive algorithmic understanding that makes
more in-depth calculations (those beyond a normal person's intuition)
run cleanly. Here's a simple example that is easy for intuition to
handle:

sage: H=PermutationGroup([[(1,2,3,4)],[(5,6,7)]])
sage: S=H.stabilizer(2)
sage: S.degree()
7

Here's one that isn't so intuitive: Randomly number the edges and
vertices of the unit cube. Define the rotational group of this cube in
terms of permutation generators. Rotational actions are clearly not
transitive on this collection of objects (it is a degree 20
representation of S_4), so pick the smallest orbit and define a
homomorphism (actually, an isomorphism) from your original group to an
action on this single orbit (vertices only). This new action is
transitive, but not primitive. So, do the same thing and create a
homomorphism (again, isomorphism) to an action on a block system. Now,
tell me the degree of this new action (it should be 4), the s

[sage-devel] Fwd: [sage-combinat-devel] permutation group perspectives

[Mike Hansen]

-- Forwarded message --
From: Jason B Hill 
Date: Mon, May 17, 2010 at 3:05 PM
Subject: [sage-combinat-devel] permutation group perspectives
To: sage-combinat-de...@googlegroups.com



This comes after a discussion I had with several at Sage days 20.5 in
Toronto relating to the underlying structure of permutation
representations in Sage. Sorry for the length, but it does completely
express the situation.

I'll start by saying that I'm relatively new to Sage development (I'm
from the lands of GAP and C), but I do have some time and desire to
contribute in this area, depending on what results from this
discussion. I've also posted a ticket (#8929) on trac.sagemath.org
that adds some minimal functionality along these lines to the
permutation group methods in permgroup.py.

Here's my basic issue: Sage constructs permutation groups in a very
intuitive, but arguably less robust and less mathematically consistent
way when compared to GAP. I want to explain these differences, to
explain why Sage's current perspective makes conducting my research in
Sage very challenging, and also to explain how the two perspectives
may potentially be brought together to add more functionality to
permutation group methods in Sage than currently exist in either Sage
or GAP.

Here's an example of the same permutation group (really, a permutation
representation or action) in Sage and in GAP:

sage: G=PermutationGroup([[(2,3,4,5,6,7,8)]])
gap> G:=Group([(2,3,4,5,6,7,8)]);

To illustrate the differences between Sage and GAP, we can consider
transitivity:

sage: G.is_transitive()
False
gap> IsTransitive(G);
true

This difference is caused by GAP understanding G to be a permutation
representation acting on [2 ... 8], while Sage understands the action
to be on the set [1 ... 8], where 1 is in the domain of the action and
is simultaneously never moved by this specific representation. Sage
determines the degree of a permutation group to be the largest integer
moved by any of the generators. GAP considers the degree of a
permutation group to be the number of non-fixed points of the
representation. Hence, any notion of transitivity, regularity,
primitivity, etc. will be considerably different between GAP and Sage.
In fact, Sage currently has no is_primitive method, and I don't think
it is possible to implement such a method consistently given Sage's
current implementation of G.degree(). In our above example, GAP does
rightly think that G is primitive. However, in Sage, not only do we
have a block system / equivalence relation on the domain (composed on
blocks having different sizes, that's bad), but the representation of
G is not even transitive.

Note about the ticket mentioned above: I have rewritten
is_transitive() and allowed for optional arguments in the form of
integers (in which case [1 .. input] is the domain) or lists of
integers (in which case the list is the domain). In the patch is also
a method for determining fixed and non-fixed points as a list, which
may then be used for transitivity, regularity and primitivity
calculations.



Sage's approach is very intuitive. If I input a single generator
[(100,101)], then my permutation group is isomorphic to Z_2 and acts
on [1 ... 101]. Unfortunately, I think this approach has more pitfalls
than bonuses. While it does mimic a human's permutation group
intuition, it removes a naive algorithmic understanding that makes
more in-depth calculations (those beyond a normal person's intuition)
run cleanly. Here's a simple example that is easy for intuition to
handle:

sage: H=PermutationGroup([[(1,2,3,4)],[(5,6,7)]])
sage: S=H.stabilizer(2)
sage: S.degree()
7

Here's one that isn't so intuitive: Randomly number the edges and
vertices of the unit cube. Define the rotational group of this cube in
terms of permutation generators. Rotational actions are clearly not
transitive on this collection of objects (it is a degree 20
representation of S_4), so pick the smallest orbit and define a
homomorphism (actually, an isomorphism) from your original group to an
action on this single orbit (vertices only). This new action is
transitive, but not primitive. So, do the same thing and create a
homomorphism (again, isomorphism) to an action on a block system. Now,
tell me the degree of this new action (it should be 4), the socle of
the corresponding group (it is affine, this calculation is easy if you
can compute a point stabilizer complement in the final action), and
then compute the EARNS of my original group as a lift back through my
isomorphisms from this socle. Once you abstract a permutation group
beyond an intuitive level, Sage loses its ability to calculate these
properties and invariants. In GAP, this calculation is relatively
painless.


My goal here is to spark a conversation about what can be done in this
situation. I would love to have Sage more in-line with GAP's
understanding of the underlying structure of permutation actions. And,
I'm not sure that much has to be done to make this

[sage-devel] Fwd: [sage-support] Is there an efficient method of producing indexed variables?

[Franco Saliola]

I forgot to more the conversation below from sage-support to sage-devel.

-- Forwarded message --
From: Franco Saliola 
Date: Fri, Apr 2, 2010 at 1:45 PM
Subject: Re: [sage-support] Is there an efficient method of producing
indexed variables?
To: sage-supp...@googlegroups.com


On Thu, Apr 1, 2010 at 10:50 PM, Minh Nguyen  wrote:
> Hi,
>
> On Fri, Apr 2, 2010 at 12:36 PM, scott.h  wrote:
>
> 
>
>> It seems like this should be simple but for the life of me I can't
>> figure out how to do it.
>
> Here I'm taking a guess at what you really want to do. See the
> following Sage session:
>
> [mv...@sage ~]$ sage
> --
> | Sage Version 4.3.5, Release Date: 2010-03-28                       |
> | Type notebook() for the GUI, and license() for information.        |
> --
> sage: n = 3
> sage: M = random_matrix(ZZ, nrows=n); M
> [ 2  2 -2]
> [ 4  2 -7]
> [ 2 -1  1]
> sage: # create a list of unknown constants; these are actually
> symbolic variables
> sage: C = [var("C_%s" % i) for i in range(n)]; C
> [C_0, C_1, C_2]
> sage: X = [randint(1, 10) for i in range(n)]; X
> [2, 3, 2]
> sage: F = [C[i] * exp(M[i,i] * x) for i in range(n)]; F
> [C_0*e^(2*x), C_1*e^(2*x), C_2*e^x]
> sage: [F[i].substitute(x=X[i]) for i in range(n)]
> [C_0*e^4, C_1*e^6, C_2*e^2]

It might be useful to have a constructor to simplify this.
One would be able to do something like this:

   sage: a = SymbolicVariables('a')
   sage: sum(a[i]*x^i for i in range(3))
   a2*x^2 + a1*x + a0

and Minh's session above would become:

   sage: n = 3
   sage: M = random_matrix(ZZ, nrows=n)
   sage: c = SymbolicVariables('c')
   sage: [c[i] * exp(M[i,i] * x) for i in range(n)]
   [c0*e^(-x), c1*e^(-5*x), c2*e^(13*x)]

Here is a very simple implementation of SymbolicVariables.

   class SymbolicVariables(SageObject):
       def __init__(self, prefix='x'):
           self._prefix = prefix
       def __getitem__(self, i):
           return var("%s%s"%(self._prefix, i))

Thoughts?

Franco

--

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

To unsubscribe, reply using "remove me" as the subject.

Re: [sage-devel] Fwd: Sage releases

[Dr. David Kirkby]

Robert Bradshaw wrote:

On Apr 1, 2010, at 8:55 PM, Dr. David Kirkby wrote:


Robert, before saying +1 to all the above, you should ask yourself if 
all of the above is practical. IMHO, it is not.


I think this is the main point of disagreement, IMHO it is practical and 
worthwhile (though a lot of work, and we may have to temporarily thin 
the list). 


One very obvious example of something that is not practical is to state that the 
latest developer version of Solaris 10, with the latest developer libraries 
should be used to build Sage. A full install of Solaris 10, which includes 
everything except a few OEM bits, has gcc 3.4.3, which will not build Sage. So 
that is certainly not practical.


Much more will become practical with a test farm, but that seems unlikely to be 
in place by the next release of Sage, which is scheduled for 13 days time. I 
reckon it will take close to 10 working days to set that up fully.


I agree with you that "latest official release" should be 
taken a bit loosely--it may take some time to upgrade our build farms 
and if there are issues to sort them out. I think the main point was 
that we're not making promises if the OS is not reasonably up to date 
(though technically there's no reason it shouldn't still work, and we 
make all past releases available as well).


Why not be more precise and state the exact versions of the distributions we 
test on, just like MATLAB does? See:


http://www.mathworks.com/support/sysreq/current_release/

It seems better to me.

I'd put as supported platforms something like this, which are examples only, and 
not meant to imply anything in particular.


##
SUPPORTED PLATFORMS

All official Sage releases, which have versions of the form Sage-X.Y.Z are 
always tested fully on the following platforms. Experimental versions of Sage 
with the words "alpha", "beta" or "rc" in the version would only be tested on a 
subset of these platforms, and may not work fully even on those.


We would expect later versions of the operating systems to work, and some 
earlier versions may work, though the probability of a successful installation 
will decrease with very old versions of the operating systems.


If an operating system has been mis-configured by a user, then this can often 
lead to build failures for which the Sage developers have no control.


In all cases, gcc versions >= 4.0.1 are expected to work, but this has are not 
verified except on OS X.


Apple Mac
*  OS X 10.5.x and 10.6.x on with Intel or AMD processor
*  OS X 10.4.x with PPC processor.

Linux:
Debian 5.0 32-bit with Intel or AMD processor
OpenSUSE 11.1 32-bit with Intel or AMD processor
OpenSUSE 11.1 64-bit with Intel or AMD processor


Solaris:
Solaris 10 update 7 (05/09) 32-bit mode on SPARC processors, with with gcc 4.3.1

Microsoft Windows:
* XP Service Pack 3 with Cygwin 1.7.2
* Vista Business edition 32-bit with Cygwin 1.7.2
* Windows 7 with Cygwin 1.7.0

[1] Solaris users must install a recent version of gcc configured to use the Sun 
linker and Sun assembler. Only a 32-bit version of Solaris can currently be 
built, despite the fact 64-bit processors are needed for Solaris 10 on SPARC 
hardware.


[2] OpenSolaris (also known as Solaris 11) will not currently build Sage.


REPORTED TO WORK.
The following operating systems versions have been reported to build some 
versions of Sage, although such combinations are not tested on a regular basis 
(if at all) by Sage developers, so support for these platforms, (especially 
installation problems), is likely to be lower than on the supported version.


* Solaris 10 (first release, dated 03/05) 32-bit, with with gcc 4.3.4.
* Windows Home Basic edition 32-bit with Cygwin 1.7
* Windows Server 2000 with Cygwin

If you successfully build Sage on another platform, please let us know.

==

As time goes by, this can be extended. But at any point in time, people know 
what we test on.


I believe is is highly desirable that we try to support a version of the 
operating system at least 18-months old, as well as the current stable release 
That would enable a lecturer to install  Sage on a server, and be reasonably 
confident that updating Sage during the year will not cause problems. (If they 
chose to install a version of the OS more than 6 months old, then they can't 
expect that).


Expecting people to always have the latest version of an operating system is a 
bit unreasonable. Many people are reluctant to upgrade systems if they work. I 
do not think I have a single computer at home running the latest version of the 
operating system, though one of my Suns might do (it is off now, and I can't be 
bothered to power it up to verify it).


I regularly test Sage on Solaris using a 5 year old version, and have no 
problems, though Solaris offers better backward compatibility than probably any 
other operating system, so I don't think 5 years is practical, bu

Re: [sage-devel] Fwd: Sage releases

[Robert Bradshaw]

On Apr 1, 2010, at 8:55 PM, Dr. David Kirkby wrote:


Robert Bradshaw wrote:
I believe this is very relevant to the discussion that's taking  
place on sage-devel.


Thank you Robert. Forwarding that was very useful.


Begin forwarded message:

From: William Stein 
Date: March 21, 2010 11:09:31 AM PDT
To: sage-release 
Subject: [sage-release] Sage releases
Reply-To: sage-rele...@googlegroups.com

Hi,

The last release (sage-4.3.4) illustrates that there are some
misunderstandings about when a release manager should actually  
make an

official release.

The README.txt lists the following as the supported Sage platforms:

"PROCESSOROPERATING SYSTEM
x86  32-bit Linux -- Debian, Ubuntu, CentOS (=Red Hat),
   Fedora, openSUSE, Mandriva
x86_64   64-bit Linux -- Debian, Ubuntu, CentOS (=Red Hat),
   Fedora, openSUSE, Mandriva
IA-64 Itanium 2  64-bit Linux -- Red Hat, SUSE
x86  Apple Mac OS X 10.5.x
PPC  Apple Mac OS X 10.5.x"

To me, this means that we're claiming that each Sage release works  
on

those platforms.

This suggests some ideas for how to do things better:

(1) We should change the above matrix to the following:

PROCESSOROPERATING SYSTEM
x86  32-bit Linux -- Debian, Ubuntu, CentOS (=Red Hat),
   Fedora, openSUSE, Mandriva
x86_64   64-bit Linux -- Debian, Ubuntu, CentOS (=Red Hat),
   Fedora, openSUSE, Mandriva
IA-64 Itanium 2  64-bit Linux -- Red Hat, SUSE
x86  Apple Mac OS X 10.5, 10.6
PPC  Apple Mac OS X 10.4, 10.5
SPARC  Solaris 10

since OS X 10.6 support is very good now, and we decided a while ago
*not* to drop OS X 10.4, but to carefully officially support it.
Also, we better add Solaris 10 soon enough.  There will also be
another line soon, I hope:

x86Cygwin (Microsoft Windows)


(2) We should also specify that we only claim that Sage will build
with a generic install (+devel packages) of the latest officially
released version of one of the above OS's.  We make no claims about
old or crufty OS versions.



IMHO, point 2 should be changed significantly.

It's not always possible for someone to install the latest release  
of the operating system. People do not always have time. William  
remarks he has installed Linux 1000 times and is fed up with it.


Florent Hivert remarks he tests Sage on openSUSE 11.1 and also said  
he believes there is a release 11.1 virtual machine on boxen.  
However, the latest official stable release of openSUSE is 11.2  
which was released on November 12th, 2009.


We should not claim support on the latest stable release unless we  
test on it.


If a newer release of some distribution is made, it would obviously  
be useful to  have that as a test platform, but until such time as  
that is done, we should not claim to work on the latest stable  
release. If at all possible, we should not break Sage so it fails to  
work on older releases. If we have a 11.1 openSUSE virtual machine  
now, then if a build farm is available, testing on 11.1 and the 11.2  
should be possible if someone has the time to install an 11.2  
virtual machine.


Linux has a poor record of backward compatibility (some  
distributions are worst than others), so it's always possible a new  
release of some distribution will be made which can not build Sage.  
IMHO, there is no need to remove that distribution from the support  
Matrix. It is better to just list the version we know works, and  
hopefully try to sort things out so Sage builds on the latest version.


Likewise, t2.math is not running the latest release of Solaris 10,  
but Solaris 10 update 7 (05/09). I usually test Sage on Solaris 10  
(03/05 - the first release). If it builds on that, you can be  
99.999% sure it will build on the latest release of Solaris, as  
Solaris has an excellent record of backwards compatibility. But we  
can't claim it works on the first release of Solaris 10 unless we  
test every release on it, which is not practical given there is no  
machine running the first release generally available, and  
furthermore, 't2' would not support the first release of Solaris 10.


Also, at least in the case of Solaris 10, there are no suitable  
development packages officially available. Installing a developer  
release of Solaris 10, you get gcc 3.4.3, which is too old to build  
Sage. It is better to say gcc 4.4.1 configured to use the Sun linker  
and assembler, which is what is used on 't2' now, though we would  
expect any gcc >= 4.0.1 to work.




(3) We should never, never, ever release another version of Sage,
unless it actually builds and passes its test suite on all of the
above.


I'm glad William has come around to my way of thinking on this -  
i.e. we need to test on all the supported platforms before any  
release is made. I think Minh's matrix he made we be a go

Re: [sage-devel] Fwd: Sage releases

[Dr. David Kirkby]

Robert Bradshaw wrote:
I believe this is very relevant to the discussion that's taking place on 
sage-devel.


Thank you Robert. Forwarding that was very useful.


Begin forwarded message:


From: William Stein 
Date: March 21, 2010 11:09:31 AM PDT
To: sage-release 
Subject: [sage-release] Sage releases
Reply-To: sage-rele...@googlegroups.com

Hi,

The last release (sage-4.3.4) illustrates that there are some
misunderstandings about when a release manager should actually make an
official release.

The README.txt lists the following as the supported Sage platforms:

"PROCESSOROPERATING SYSTEM
x86  32-bit Linux -- Debian, Ubuntu, CentOS (=Red Hat),
Fedora, openSUSE, Mandriva
x86_64   64-bit Linux -- Debian, Ubuntu, CentOS (=Red Hat),
Fedora, openSUSE, Mandriva
IA-64 Itanium 2  64-bit Linux -- Red Hat, SUSE
x86  Apple Mac OS X 10.5.x
PPC  Apple Mac OS X 10.5.x"

To me, this means that we're claiming that each Sage release works on
those platforms.

This suggests some ideas for how to do things better:

(1) We should change the above matrix to the following:

PROCESSOROPERATING SYSTEM
x86  32-bit Linux -- Debian, Ubuntu, CentOS (=Red Hat),
Fedora, openSUSE, Mandriva
x86_64   64-bit Linux -- Debian, Ubuntu, CentOS (=Red Hat),
Fedora, openSUSE, Mandriva
IA-64 Itanium 2  64-bit Linux -- Red Hat, SUSE
x86  Apple Mac OS X 10.5, 10.6
PPC  Apple Mac OS X 10.4, 10.5
SPARC  Solaris 10

since OS X 10.6 support is very good now, and we decided a while ago
*not* to drop OS X 10.4, but to carefully officially support it.
Also, we better add Solaris 10 soon enough.  There will also be
another line soon, I hope:

x86Cygwin (Microsoft Windows)


(2) We should also specify that we only claim that Sage will build
with a generic install (+devel packages) of the latest officially
released version of one of the above OS's.  We make no claims about
old or crufty OS versions.



IMHO, point 2 should be changed significantly.

It's not always possible for someone to install the latest release of the 
operating system. People do not always have time. William remarks he has 
installed Linux 1000 times and is fed up with it.


Florent Hivert remarks he tests Sage on openSUSE 11.1 and also said he believes 
there is a release 11.1 virtual machine on boxen. However, the latest official 
stable release of openSUSE is 11.2 which was released on November 12th, 2009.


We should not claim support on the latest stable release unless we test on it.

If a newer release of some distribution is made, it would obviously be useful to 
 have that as a test platform, but until such time as that is done, we should 
not claim to work on the latest stable release. If at all possible, we should 
not break Sage so it fails to work on older releases. If we have a 11.1 openSUSE 
virtual machine now, then if a build farm is available, testing on 11.1 and the 
11.2 should be possible if someone has the time to install an 11.2 virtual machine.


Linux has a poor record of backward compatibility (some distributions are worst 
than others), so it's always possible a new release of some distribution will be 
made which can not build Sage. IMHO, there is no need to remove that 
distribution from the support Matrix. It is better to just list the version we 
know works, and hopefully try to sort things out so Sage builds on the latest 
version.


Likewise, t2.math is not running the latest release of Solaris 10, but Solaris 
10 update 7 (05/09). I usually test Sage on Solaris 10 (03/05 - the first 
release). If it builds on that, you can be 99.999% sure it will build on the 
latest release of Solaris, as Solaris has an excellent record of backwards 
compatibility. But we can't claim it works on the first release of Solaris 10 
unless we test every release on it, which is not practical given there is no 
machine running the first release generally available, and furthermore, 't2' 
would not support the first release of Solaris 10.


Also, at least in the case of Solaris 10, there are no suitable development 
packages officially available. Installing a developer release of Solaris 10, you 
get gcc 3.4.3, which is too old to build Sage. It is better to say gcc 4.4.1 
configured to use the Sun linker and assembler, which is what is used on 't2' 
now, though we would expect any gcc >= 4.0.1 to work.




(3) We should never, never, ever release another version of Sage,
unless it actually builds and passes its test suite on all of the
above.


I'm glad William has come around to my way of thinking on this - i.e. we need to 
test on all the supported platforms before any release is made. I think Minh's 
matrix he made we be a good starting point for this.



(4) However, sometimes a pseudo-release that doesn't pass (3) is 

[sage-devel] Fwd: Sage releases

[Robert Bradshaw]

I believe this is very relevant to the discussion that's taking place  
on sage-devel.


Begin forwarded message:


From: William Stein 
Date: March 21, 2010 11:09:31 AM PDT
To: sage-release 
Subject: [sage-release] Sage releases
Reply-To: sage-rele...@googlegroups.com

Hi,

The last release (sage-4.3.4) illustrates that there are some
misunderstandings about when a release manager should actually make an
official release.

The README.txt lists the following as the supported Sage platforms:

"PROCESSOROPERATING SYSTEM
x86  32-bit Linux -- Debian, Ubuntu, CentOS (=Red Hat),
Fedora, openSUSE, Mandriva
x86_64   64-bit Linux -- Debian, Ubuntu, CentOS (=Red Hat),
Fedora, openSUSE, Mandriva
IA-64 Itanium 2  64-bit Linux -- Red Hat, SUSE
x86  Apple Mac OS X 10.5.x
PPC  Apple Mac OS X 10.5.x"

To me, this means that we're claiming that each Sage release works on
those platforms.

This suggests some ideas for how to do things better:

(1) We should change the above matrix to the following:

PROCESSOROPERATING SYSTEM
x86  32-bit Linux -- Debian, Ubuntu, CentOS (=Red Hat),
Fedora, openSUSE, Mandriva
x86_64   64-bit Linux -- Debian, Ubuntu, CentOS (=Red Hat),
Fedora, openSUSE, Mandriva
IA-64 Itanium 2  64-bit Linux -- Red Hat, SUSE
x86  Apple Mac OS X 10.5, 10.6
PPC  Apple Mac OS X 10.4, 10.5
SPARC  Solaris 10

since OS X 10.6 support is very good now, and we decided a while ago
*not* to drop OS X 10.4, but to carefully officially support it.
Also, we better add Solaris 10 soon enough.  There will also be
another line soon, I hope:

x86Cygwin (Microsoft Windows)


(2) We should also specify that we only claim that Sage will build
with a generic install (+devel packages) of the latest officially
released version of one of the above OS's.  We make no claims about
old or crufty OS versions.

(3) We should never, never, ever release another version of Sage,
unless it actually builds and passes its test suite on all of the
above.

(4) However, sometimes a pseudo-release that doesn't pass (3) is very
useful, e.g., before Sage Days (like right now), and targeted for
experts.  In such cases, we could do a "beta" release, e.g., 4.3.4
could have been:
sage-4.3.4.beta.tar
and there could never be a 4.3.4 that isn't beta.  In case of a beta,
this would mean that:
  (a) we continue to host everything related to 4.3.3 on the main  
website.

  (b) we make the beta source and binaries available.


+1 to all of the above. And Kudos top those who actually put in the  
insane amount of work required to do release management (as opposed to  
those who just sit around and talk about it).



(5) Regarding the technical issues with testing the above, it's of
course possible using a build farm.  However, maintaining such a thing
takes a lot of effort, and so far I have had to do it all myself on
boxen, and I simply don't have the time (or inclination).We might
have to *temporarily* shrink our list of supported platforms until
either I can hire somebody, I get more time, or somebody steps up and
volunteers to manage a virtual build farm.I've probably installed
Linux more than 1000 times in my life, and I'm tired of installing,
upgrading, etc. Linux.  I used to love it.  Thus I'm sure somebody out
there loves to.  Anybody in Seattle?


I'll try my hand at doing something this summer. Ideally this will be  
a pull system, so anyone can easily donate cycles to make sure Sage  
keeps working on his or her platform of choice.


- Robert

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

To unsubscribe, reply using "remove me" as the subject.

Re: [sage-devel] Fwd: [sage-nt] Embeddings into QQbar hang

[John Cremona]

On 10 March 2010 18:07, William Stein  wrote:
> On Wed, Mar 10, 2010 at 9:38 AM, John Cremona  wrote:
>> I am taking the liberty of forwarding this to sage-devel since it
>> seems much too important for just sage-nt.  OK, so that was my machine
>> David locked up (apparently!).  It has 128GB of RAM so does not easily
>> run out...
>>
>> John
>
> It is easy to change your linux install so that normal users *can't*
> crash/hang the machine by using too much RAM.  I do that on the
> sage.math cluster.    You probably have kernel virtual memory
> overcommit set to "on" with your machines, and this is a bad idea,
> since it means any users can trivially  crash them (or at least make
> them totally nonresponsive).
>
> This article describes virtual memory overcommit:
>    http://lwn.net/Articles/104179/
>
> At the end of the charming article, it says to turn it off all you
> have to do is put these lines at the end of /etc/sysctl.conf":
>
> # Get rid of OOM. See http://lwn.net/Articles/104179/
> vm.overcommit_memory=2
>
> Do this to make the effect immediate (without rebooting):
>
> wst...@boxen:~$ sudo sysctl vm/overcommit_memory=2
> vm.overcommit_memory = 2

Thanks for the tip - I have just done that.  Fingers crossed...

John

>
> --
> William Stein
> Associate Professor of Mathematics
> University of Washington
> http://wstein.org
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to 
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group at 
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>

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

Re: [sage-devel] Fwd: [sage-nt] Embeddings into QQbar hang

[William Stein]

On Wed, Mar 10, 2010 at 9:38 AM, John Cremona  wrote:
> I am taking the liberty of forwarding this to sage-devel since it
> seems much too important for just sage-nt.  OK, so that was my machine
> David locked up (apparently!).  It has 128GB of RAM so does not easily
> run out...
>
> John

It is easy to change your linux install so that normal users *can't*
crash/hang the machine by using too much RAM.  I do that on the
sage.math cluster.You probably have kernel virtual memory
overcommit set to "on" with your machines, and this is a bad idea,
since it means any users can trivially  crash them (or at least make
them totally nonresponsive).

This article describes virtual memory overcommit:
http://lwn.net/Articles/104179/

At the end of the charming article, it says to turn it off all you
have to do is put these lines at the end of /etc/sysctl.conf":

# Get rid of OOM. See http://lwn.net/Articles/104179/
vm.overcommit_memory=2

Do this to make the effect immediate (without rebooting):

wst...@boxen:~$ sudo sysctl vm/overcommit_memory=2
vm.overcommit_memory = 2

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

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

[sage-devel] Fwd: [sage-nt] Embeddings into QQbar hang

[John Cremona]

I am taking the liberty of forwarding this to sage-devel since it
seems much too important for just sage-nt.  OK, so that was my machine
David locked up (apparently!).  It has 128GB of RAM so does not easily
run out...

John


-- Forwarded message --
From: daveloeffler 
Date: 10 March 2010 15:33
Subject: [sage-nt] Embeddings into QQbar hang
To: sage-nt 


Is there any reason why one shouldn't be able to work with number
fields embedded into QQbar? Since our QQbar class permits exact
calculation, but has a canonical embedding into CC, it seems the
natural place for the "default embeddings" of cyclotomic fields,
quadratic fields and so on. I was playing with this a bit, and found a
bug that locked up our research group's server so hard it was out of
action for 24 hours.

sage: QuadraticField(-7,'a',embedding=QQbar(-7).sqrt())
Number Field in a with defining polynomial x^2 + 7

That's all well and good, but if I then type *exactly the same command
again*, Sage locks up totally! It becomes completely unresponsive
(Control-C doesn't work) and the memory usage climbs until the machine
jams up totally, unless you can kill it quickly from another console
session.

 tried running this with the "trace" command, and it gets as far as
computing the square root the second time round, but then gets locked
up what looks like the beginning of an infinite loop involving the
files sage.misc.function_mangling, sage.misc.cachefunc, and
sage.categories.category -- I think it's trying to compute some join
operation on categories, but what that has to do with computing the
square root of -7 is a mystery to me. Does anyone know what's going on
here?



--
You received this message because you are subscribed to the Google
Groups "sage-nt" group.
To post to this group, send an email to sage...@googlegroups.com.
To unsubscribe from this group, send email to
sage-nt+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-nt?hl=en-GB.

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

[sage-devel] Fwd: [sage-support] sage-mode completion not quite working with sage 4.3.2

[Nicolas M. Thiery]

Dear all,

My patch #7921 broke tab completion under emacs in 4.3.2 due to a
variant of the other tab completion bug. I know how painful this can
be, and apologize for this. I just created ticket #8296 for this, and
posted a patch which should fix the issue. Please try and review!

Best,
Nicolas

> -- Forwarded message --
> From: Pierre 
> Date: Wed, Feb 17, 2010 at 8:05 AM
> Subject: [sage-support] sage-mode completion not quite working with sage 4.3.2
> To: sage-support 
> 
> 
> hi,
> 
> i've upgraded to sage 4.3.2, and it seems to have disturbed the emacs-
> mode. When i go
> 
> sage: n=1
> sage: n.[TAB]
> 
> emacs says 'no completions of n.'. It used to give me all the
> possibilities in a buffer, which i got addicted to ! It still works
> when there isn't a dot, so Ma[TAB] does list MatrixSpace etc.
> 
> i've tried to re-install sage-mode of course, to no effect.
> 
> is anyone else affected by this ?
> 
> pierre
> 
> --
> To post to this group, send email to sage-supp...@googlegroups.com
> To unsubscribe from this group, send email to
> sage-support+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-support
> URL: http://www.sagemath.org
> 
> 
> 
> -- 
> William Stein
> Associate Professor of Mathematics
> University of Washington
> http://wstein.org
Nicolas
--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

- End forwarded message -
Nicolas
--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

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

[sage-devel] Fwd: SAGE ignores Ctrl-C?!? Is this a bug or a feature

[John Cremona]

I am forwarding to sage-devel this posting from Simon King (originally
to sage-support), since he asks a question which should be debated by
developers:  see below.


-- Forwarded message --
From: Simon King 
Date: Dec 30, 11:07 am
Subject: SAGE ignores Ctrl-C?!? Is this a bug or a feature
To: sage-support


Hi Alex!

On 30 Dez., 06:37, Alex P  wrote:



> Here is the code:

> --
> | Sage Version 4.2.1, Release Date: 2009-11-14                       |
> | Type notebook() for the GUI, and license() for information.        |
> --
> sage: q = 3
> sage: F. = FiniteField(q)
> sage: P. = PolynomialRing(F)
> sage: PP. = PolynomialRing(P)
[...]
> sage: time (z^3 + T*z)^(3^7)
> ^CException KeyboardInterrupt: KeyboardInterrupt() in
> 'sage.rings.polynomial.polynomial_zmod_flint.get_cparent' ignored
> ^C

> 
> Unhandled SIGFPE: An unhandled floating point exception occured in
> SAGE.
> This probably occured because a *compiled* component
> of SAGE has a bug in it (typically accessing invalid memory)
> or is not properly wrapped with _sig_on, _sig_off.
> You might want to run SAGE under gdb with 'sage -gdb' to debug this.
> SAGE will now terminate (sorry).
> 

That's certainly a bug. I created a ticket for it:http://
trac.sagemath.org/sage_trac/ticket/7794

As it is defined, PP is a polynomial ring in one variable over a
polynomial ring in one variable.
Would it be a good thing to  automatically convert this into a
polynomial ring with *two* variables? What do people think?

I think: no, I do not want this automatic conversion and I can think
of situations where it is a bad idea.  But it would be good to have
very easy conversions between them.  For example, if I have created k
[x,y,z] then it would be nice to have a way of converting it to k[x,y]
[z], k[y,z][x] (etc) and k[x][y,z] (etc) and even k[x][y][z] (and
permutations).  That's a lot of possibilities so some thought would be
needed in the interface;  the result would be a new polynomial ring
and some kind of isomorphism between the old and a new. ("Some kind"
meaning at least a ring isomorphism, and at least a k-module
morphism.)

John

If you
have an opinion about it, you might also comment
onhttp://trac.sagemath.org/sage_trac/ticket/7580, where I do those
conversions for Infinite Polynomial Rings.

Note that Alex' example reveals another bug, this time in
MPolynomialRing_libsingular:
  sage: F. = FiniteField(3)
  sage: P. = PolynomialRing(F)
  sage: type(P)
  
  sage: (z^3 + T*z)^(81*3) # immediate answer
  z^729 + T^243*z^243
  sage: (z^3 + T*z)^(2^20)
  /home/king/SAGE/sage-4.3/local/bin/sage-sage: line 206: 20889
Segmentation fault      sage-ipython "$@" -i

This was without Ctrl-C.

Certainly there should  be no segfault. If anything, there should an
error be raised.
I made this another ticket,http://trac.sagemath.org/sage_trac/ticket/
7795

Thanks for the report!
Simon

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

[sage-devel] Fwd: [sage-grants] Re: A Sage NSF proposal to the Computational Mathematics Program

[William Stein]

-- Forwarded message --
From: John H Palmieri 
Date: Sun, Nov 22, 2009 at 7:03 PM
Subject: [sage-grants] Re: A Sage NSF proposal to the Computational
Mathematics Program
To: sage-grants 


On Nov 20, 4:24 am, William Stein  wrote:
> Hi,
>
> Me and several people have been putting together a proposal to this NSF 
> program:
>
>      http://www.nsf.gov/funding/pgm_summ.jsp?pims_id=5390
>
> I currently have a grant from them for Sage that will expire soon, and
> would like another one :-)

I've posted a new pdf file here:

http://www.math.washington.edu/~palmieri/Sage/compmath.pdf

I've tried to take into account the comments that people have provided
(William forwarded them to me), although I haven't necessarily
followed all suggestions precisely.  Please take a look at the new
version and send more comments, posting them here or sending them to
both me and William.

Thanks,
 John



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

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

[sage-devel] Fwd: Sage Participation at Educause 2009

[William Stein]

Hi,

I am curious if anybody can go to the Educause 2009 conference in
Denver,CO.  Sun was really hoping there could be some Sage
representation, and I can't go.  See below if you're interested.

William


-- Forwarded message --
From: Corinne Cho-Beaulieu 
Date: Wed, Sep 23, 2009 at 11:43 AM
Subject: Sage Participation at Educause 2009
To: william stein 


HI William,

I hope this email finds you well.  I don't know if you received my
first request, but wanted to let you know that Sun will be
participating
in the upcoming Educause Show Nov 3-6 in Denver,CO and we would like
to invite SAGE to participate in our booth this year.

We are currently in planning stages for the show so would like to hear
from you if you plan to participate.

Please feel free to contact me directly is you would like to further
discuss this.

Thanks,
Corinne
(650.786.4645)



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

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

[sage-devel] Fwd: [sage-release] Re: Sage 4.1.2.alpha2 released

[Minh Nguyen]

-- Forwarded message --
From: Minh Nguyen 
Date: Tue, Sep 22, 2009 at 1:22 PM
Subject: Re: [sage-release] Re: Sage 4.1.2.alpha2 released
To: sage-rele...@googlegroups.com


Hi William,

On Tue, Sep 22, 2009 at 12:13 PM, William Stein  wrote:



> I finally fixed this.  See
>
>     http://trac.sagemath.org/sage_trac/ticket/6981
>
> Somebody needs to referee that.  It's an updated of the standard
> fortran spkg so that it seamlessly works on OS X 64-bit.

I can test these updated packages on OS X 10.5 (bsd.math) and OS X
10.4 (I now have access to that platform). But I have to leave the
testing on OS X 10.6 to someone else who has access to Snow Leopard,
since I don't have access to a machine running 10.6.

--
Regards
Minh Van Nguyen



-- 
Regards
Minh Van Nguyen

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

[sage-devel] Fwd: sage-devel posting problems

[Minh Nguyen]

I think I have fixed the problem for the case of Peter. But I can't be
sure, unless he posts to sage-devel again.


-- Forwarded message --
From: Minh Nguyen 
Date: Mon, Sep 14, 2009 at 6:34 AM
Subject: Re: sage-devel posting problems
To: Peter 
Cc: sage-devel+ow...@googlegroups.com


Hi Peter,

On Mon, Sep 14, 2009 at 6:27 AM, Peter  wrote:



> groups.google shows that I am a member and I am receiving postings via
> my correct (new) email address.

Yes, indeed you are a member of the sage-devel Google group with the
email address




>  Are you aware of anything in the sage-
> devel configuration that might cause it to bounce my postings?

I have configured the member management option to allow you to post to
sage-devel. Can you please try again to post to sage-devel? Please
inform me if you still experience the same problem.

--
Regards
Minh Van Nguyen

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

[sage-devel] Fwd: [sage-release] Re: Sage 4.1.1.rc2 released

[Minh Nguyen]

This seems more appropriate for sage-devel than sage-release.

-- 
Regards
Minh Van Nguyen


-- Forwarded message --
From: gsw 
Date: Sun, Aug 9, 2009 at 7:33 PM
Subject: [sage-release] Re: Sage 4.1.1.rc2 released
To: sage-release 



On 8 Aug., 23:21, David Joyner  wrote:
> I had a build failure on my intel macbook running OS 10.4.11.
> The install log is at sage.math.washington.edu/home/wdj/patches/install.log
> I'm not sure how important this OS is since I'll be upgrading in a
> month to 10.6 and most mac people have 10.5.
>

Hi David,
on my MacIntel with OS X 10.4.11, the new Sage-4.1.1.rc2 did build
fine. I compared the two install logs, the failed one shows:

ranlib /Users/davidjoyner/sagefiles/sage-4.1.1.rc2/local/lib/libfac.a
Singular-3-1-0
cp: singular and Singular are identical (not copied).
/Users/davidjoyner/sagefiles/sage-4.1.1.rc2/local/bin/sage-spkg: line
261: 17338 Segmentation fault      ./spkg-install

real    9m38.205s
user    5m27.117s
sys     1m1.781s
sage: An error occurred while installing singular-3-1-0-2-20090620.p0


whereas the successful log shows:


ranlib /Users/Shared/sage/sage-4.1.1.rc2/local/lib/libfac.a
Singular-3-1-0
cp: singular and Singular are identical (not copied).

real    12m56.491s
user    10m32.372s
sys     1m48.938s
Successfully installed singular-3-1-0-2-20090620.p0



I have no idea what the problem could have been. Did you try another
"make"?
Cheers,
Georg


P.S.:
I'll continue to use OS X 10.4.11 for quite some time, and plan build
Sage binaries as long as I do.

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

[sage-devel] Fwd: [sage-release] Re: Sage 4.1.1.rc1 released

[Minh Nguyen]

I'm forwarding this to sage-devel so more people know about it.

-- 
Regards
Minh Van Nguyen



-- Forwarded message --
From: Alex Ghitza 
Date: Wed, Aug 5, 2009 at 9:05 PM
Subject: [sage-release] Re: Sage 4.1.1.rc1 released
To: sage-rele...@googlegroups.com



Built from scratch on

Linux cartan 2.6.28-15-generic #48-Ubuntu SMP Wed Jul 29 08:53:35 UTC
2009 x86_64 GNU/Linux

(MacBook running 64-bit Ubuntu).

Running make test gave one failing doctest, which is repeatable:

[ghi...@cartan sage-4.1.1.rc1]$ ./sage -t devel/sage/sage/misc/sagedoc.py
sage -t  "devel/sage/sage/misc/sagedoc.py"
**
File "/opt/sage-4.1.1.rc1/devel/sage/sage/misc/sagedoc.py", line 360:
   sage: 'abvar/homology' in _search_src_or_doc('doc', 'homology',
'variety', interact=False)
Expected:
   True
Got:
   False
**
1 items had failures:
  1 of   6 in __main__.example_5
***Test Failed*** 1 failures.
For whitespace errors, see the file /opt/sage-4.1.1.rc1/tmp/.doctest_sagedoc.py
        [5.6 s]
exit code: 1024

--
The following tests failed:


       sage -t  "devel/sage/sage/misc/sagedoc.py"
Total time for all tests: 5.6 seconds



Best,
Alex


On Wed, Aug 5, 2009 at 3:14 PM, Minh Nguyen wrote:
>
> Hi folks,
>
> The Sage 4.1.1.rc1 release has been about sorting out a number of
> doctest failures reported in previous alpha and rc releases. Source
> and binary are available at
>
> http://sage.math.washington.edu/home/mvngu/release/sage-4.1.1.rc1.tar
> http://sage.math.washington.edu/home/mvngu/release/sage-4.1.1.rc1-sage.math.washington.edu-x86_64-Linux.tar.gz
>
> and the upgrade path is
>
> http://sage.math.washington.edu/home/mvngu/release/sage-4.1.1.rc1/
>
> With the sage.math only binary version of 4.1.1.rc1, after
> uncompressing it and invoking Sage, you would get a complaint about
> non-ASCII characters in the module SAGE_ROOT/sage/graphs/graph.py as
> described in the session transcript below. A temporary work-around is
> to exit Sage and then load it again with
>
> ./sage -br main
>
> This should get rid of the warning about non-ASCII characters. The
> issue is tracked at ticket #6674
>
> http://trac.sagemath.org/sage_trac/ticket/6674
>
> I have made this a blocker for the 4.1.1 release cycle. Any volunteers
> to review the ticket?
>
> *** Begin transcript ***
>
> [mv...@sage sage-4.1.1.rc1-sage.math.washington.edu-x86_64-Linux]$ ./sage
> --
> | Sage Version 4.1.1.rc1, Release Date: 2009-08-04                   |
> | Type notebook() for the GUI, and license() for information.        |
> --
> **
> *                                                                    *
> * Warning: this is a prerelease version, and it may be unstable.     *
> *                                                                    *
> **
> The Sage install tree may have moved.
> Regenerating Python.pyo and .pyc files that hardcode the install PATH
> (please wait at most a few minutes)...
> Do not interrupt this.
> ---
> SyntaxError                               Traceback (most recent call last)
>
> /scratch/mvngu/sage-4.1.1.rc1-sage.math.washington.edu-x86_64-Linux/local/lib/python2.6/site-packages/IPython/ipmaker.py
> in force_import(modname)
>     64         reload(sys.modules[modname])
>     65     else:
> ---> 66         __import__(modname)
>     67
>     68
>
> /scratch/mvngu/sage-4.1.1.rc1-sage.math.washington.edu-x86_64-Linux/local/bin/ipy_profile_sage.py
> in ()
>      5     preparser(True)
>      6
> > 7     import sage.all_cmdline
>      8     sage.all_cmdline._init_cmdline(globals())
>      9
>
> /scratch/mvngu/sage-4.1.1.rc1-sage.math.washington.edu-x86_64-Linux/local/lib/python2.6/site-packages/sage/all_cmdline.py
> in ()
>     12 try:
>     13
> ---> 14     from sage.all import *
>     15     from sage.calculus.predefined import x
>     16     preparser(on=True)
>
> /scratch/mvngu/sage-4.1.1.rc1-sage.math.washington.edu-x86_64-Linux/local/lib/python2.6/site-packages/sage/all.py
> in ()
>     83 from sage.modular.all    import *
>     84 from sage.schemes.all    import *
> ---> 85 from sage.graphs.all     import *
>     86 from sage.groups.all     import *
>     87 from sage.databases.all  import *
>
> /scratch/mvngu/sage-4.1.1.rc1-sage.math.washington.edu-x86_64-Linux/local/lib/python2.6/site-packages/sage/graphs/all.py
> in ()
> > 1
>      2
>      3 from graph_generators import graphs, digraphs
>      4 from graph_database import GraphDatabase, GenericGraphQuery, GraphQuery
>

[sage-devel] Fwd: SAGE lecturer needed

[Marshall Hampton]

I think this is worth forwarding here since I suspect many qualified
people don't read sage-edu much.
-M. Hampton


-- Forwarded message --
From: jan.groenew...@gmail.com
Date: Jun 24, 6:13 am
Subject: SAGE lecturer needed
To: sage-edu


Hi,

The African Institute for Mathematical Sciences (AIMS) is looking
for a lecturer to teach an introductory course in python scripting
for science, from 30 August for six weeks as part of the postgraduate
diploma in the mathematical sciences for 2009/10.

Pedagogical skills and good communication skills are very important
in our diverse environment.

http://www.aims.ac.zahttp://www.aims.ac.za/english/courseguidelines.php

The focus of this course should be around python,
scipy, matplotlib, and SAGE for scientific modelling
in diverse fields of application:http://www.scipy.orghttp://
matplotlib.sourceforge.net/http://www.sagemath.org

I'd be happy to answer any queries you have or give
you more information if you were interested. Please contact
me off-list.

regards,
Jan
--
   .~.
   /V\ Jan Groenewald
  /( )\www.aims.ac.za
  ^^-^^

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

[sage-devel] Fwd: [Sage Bug Report] sage.rings.arith.is_prime is not passing the flag parameter to pari

[William Stein]

I'm forwarding this to sage-devel.

-- Forwarded message --
From: Sigurd Torkel Meldgaard 
Date: Wed, Jun 3, 2009 at 7:51 AM
Subject: [Sage Bug Report] sage.rings.arith.is_prime is not passing
the flag parameter to pari
To: wst...@gmail.com


Hi

sage.rings.arith.is_prime is not passing the flag parameter to pari

This is true in rev 8e22f8d0955e
http://hg.sagemath.org/sage-main/file/8e22f8d0955e/sage/rings/arith.py#l1

Line 383:

 return pari(n).isprime()

Should be

 return pari(n).isprime(flag=flag)


Same problem with is_pseudoprime ()

Line 433:
 return pari(n).ispseudoprime()

should be:
 return pari(n).ispseudoprime(flag=flag)

Best regards Sigurd Meldgaard



-- 
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 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Fwd: Sage 3.4 OS 10.4 PowerPC Install Error

[William Stein]

Hi Sage-Devel,

Here's yet *another* person that can't use our binary on OS X 10.4
PPC.  Michael, can you change the binary name to make it clear that it
won't work?

Hi Tom,

Currently the only way to install sage-3.4 on a G4 is to upgrade an
existing install or build from source.

William


-- Forwarded message --
From: Tom Hagedorn 
Date: Mon, Mar 16, 2009 at 8:08 AM
Subject: Sage 3.4 OS 10.4 PowerPC Install Error
To: wst...@gmail.com



Dear William,

Sorry for not posting this on the sage-bug tracker but I wanted to
send this to you ASAP.  Last night, I tried installing sage 3.4 on my
PowerBook g4 running OS 10.4.  I have Sage (old version) running on my
Intel-Mac 10.5 without a problem.   I got a fatal error (below).  The
primary part seems to be:

ImportError: 
dlopen(/Applications/sage/local/lib/python2.5/site-packages/sage/misc/randstate.so,
2): Library not loaded:
/home/wstein/varro/build/sage-3.4/local/lib/libgmp.3.dylib
 Referenced from: /Applications/sage/local/lib//libcsage.dylib
 Reason: no suitable image found.  Did find:
      /Applications/sage/local/lib//libgmp.3.dylib: incompatible cpu-subtype
WARNING: Failure executing code: 'import sage.misc.preparser_ipython;
sage.misc.preparser_ipython.magma_colon_equals=True'

as it seems to be looking for one of your directories.   I wonder if
the link needs to be fixed.

Best,
Tom

ps.  I have another Sage question that I want to ask you later today.

__


Last login: Mon Mar 16 03:50:56 on ttyp2
/Applications/sage/sage; exit
Welcome to Darwin!
Fermat:~ hagedorn$ /Applications/sage/sage; exit
--
| Sage Version 3.4, Release Date: 2009-03-11                         |
| Type notebook() for the GUI, and license() for information.        |
--
---
ImportError                               Traceback (most recent call last)

/Applications/sage/local/bin/ in ()

/Applications/sage/local/lib/python2.5/site-packages/sage/misc/preparser_ipython.py
in ()
    6 
###
    7
> 8 import sage.misc.interpreter
    9
   10 import preparser

/Applications/sage/local/lib/python2.5/site-packages/sage/misc/interpreter.py
in ()
  100
  101 import os
--> 102 import log
  103
  104 import remote_file

/Applications/sage/local/lib/python2.5/site-packages/sage/misc/log.py
in ()
   63
   64 import interpreter
---> 65 import latex
   66 import misc
   67

/Applications/sage/local/lib/python2.5/site-packages/sage/misc/latex.py
in ()
   41 import random
   42
---> 43 from misc import tmp_dir
   44 import sage_eval
   45 from sage.misc.misc import SAGE_DOC

/Applications/sage/local/lib/python2.5/site-packages/sage/misc/misc.py
in ()
   26
   27 import operator, os, stat, socket, sys, signal, time, weakref,
resource, math
---> 28 import sage.misc.prandom as random
   29
   30 from banner import version, banner

/Applications/sage/local/lib/python2.5/site-packages/sage/misc/prandom.py
in ()
   54 # setting seeds should only be done through sage.misc.randstate .
   55
---> 56 from sage.misc.randstate import current_randstate
   57
   58 def _pyrand():

ImportError: 
dlopen(/Applications/sage/local/lib/python2.5/site-packages/sage/misc/randstate.so,
2): Library not loaded:
/home/wstein/varro/build/sage-3.4/local/lib/libgmp.3.dylib
 Referenced from: /Applications/sage/local/lib//libcsage.dylib
 Reason: no suitable image found.  Did find:
      /Applications/sage/local/lib//libgmp.3.dylib: incompatible cpu-subtype
WARNING: Failure executing code: 'import sage.misc.preparser_ipython;
sage.misc.preparser_ipython.magma_colon_equals=True'
---
ImportError                               Traceback (most recent call last)

/Applications/sage/local/lib/python2.5/site-packages/IPython/ipmaker.pyc
in force_import(modname)
   64         reload(sys.modules[modname])
   65     else:
---> 66         __import__(modname)
   67
   68

/Applications/sage/local/bin/ipy_profile_sage.py in ()
    1 import os
    2 if 'SAGE_CLEAN' not in os.environ:
> 3     import sage.misc.misc
    4     from sage.misc.interpreter import preparser, _ip
    5     preparser(True)

/Applications/sage/local/lib/python2.5/site-packages/sage/misc/misc.py
in ()
   26
   27 import operator, os, stat, socket, sys, signal, time, weakref,
resource, math
---> 28 import sage.misc.prandom as random
   29
   30 from banner import version, banner

/Applications/sage/local/lib/python2.5/site-packages/sage/misc/prandom.py
in ()
   54 # setting seeds should only be done through sage.misc.randstate .
   55
---> 56 from sage.misc.randstate import current_randstate
   57
   58 def _pyrand():

ImportError: 
dlopen(/Applications/sage/local/

[sage-devel] Fwd: [sage-combinat-devel] Documentation...

[William Stein]

-- Forwarded message --
From: Florent Hivert 
Date: Sun, Mar 1, 2009 at 12:44 PM
Subject: [sage-combinat-devel] Documentation...
To: Sage Combinat Devel 



     Dear All,

I had some trouble with the new documentation system. Therefore I wrote a tiny
page on the wiki about it hoping it can help. Please correct and expand at will.

  http://wiki.sagemath.org/combinat/HelpOnTheDoc

Cheers,

Florent





-- 
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 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Fwd: sage @ Quantnet.org - Financial Engineering Forum

[William Stein]

-- Forwarded message --
From: Harald Schilly 
Date: Sat, Feb 21, 2009 at 3:09 AM
Subject: sage @ Quantnet.org - Financial Engineering Forum
To: William Stein 


Hi, my google-alert just told me about this. I think you maybe want to
follow that thread or answer there!

http://www.quantnet.org/forum/showthread.php?t=4297

h



-- 
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 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Fwd: Sage & Sun Followup

[William Stein]

Hi Sage-Devel,

Is anybody here interested in possibly giving a talk about Sage at
Sun's CommunityOne open source conference in San Francisco June 1-3?
If so, see below.

 -- William


"Hi Michael, William,

I've heard back from the program committees of CommunityOne.
San Francisco June 1-3 is still open for paper submission.

CommunityOne San Francisco is described here in more detail:
http://developers.sun.com/events/communityone/2009/west/index.jsp

I am only suggesting this as a venue for you to evangelize Sage to a wide
Open Source community, get free wide publicity via the web publication
of your talk in the proceedings, etc.

The program committee is still taking abstracts until Feb 2.  They'd
like to have:

Title
One sentence description
Short abstract
Speaker name
Speaker company / organization


If you decide you want to attend, I am pretty sure we can get your
full conference pass covered, so all you'd need to cover is your travel.
I will also attempt to arrange a preso at Stanford to evangelize as well.
Let me know and send me your data above.

Best,
--

Casey Palowitch
Director, Systems Engineering
Global Education, Government, Healthcare

Sun Microsystems, Inc
400 Atrium Dr.
Somerset, NJ 08873

casey.palowi...@sun.com
Phone: (732) 302-3904
Fax: (732) 302-3939

Get Solaris
Enterprise
System



-- 
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 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Fwd: [Sage] #4249: [with patch] Inconsistency in number field integral bases

[John Cremona]

John Voight and I are having trouble with the patch I attached to
#4249 (see below).  On my machines I get a doctest failure, while on
his he does not.  Please could someone else try?  the patch should
apply equally to 3.1.3 or 3.1.4.

John


-- Forwarded message --
From: Sage <[EMAIL PROTECTED]>
Date: 2008/10/20
Subject: Re: [Sage] #4249: [with patch] Inconsistency in number field
integral bases
To:
Cc: [EMAIL PROTECTED]


#4249: [with patch] Inconsistency in number field integral bases
---+
 Reporter:  cremona|Owner:  was
Type:  defect |   Status:  new
 Priority:  major  |Milestone:  sage-3.2
Component:  number theory  |   Resolution:
 Keywords:  number fields  |
---+
Changes (by cremona):

 * summary:  [with patch, not ready for review] Inconsistency in number
 field integral bases => [with patch]
 Inconsistency in number field integral bases

Comment:

 Replying to [comment:10 jvoight]:
 > I downloaded a clean 3.1.3 and installed it on a 32-bit Ubuntu and it
 again worked fine.  I'm not sure what's going on.  JV

 Nor me.  I just tried again on a fresh 3.1.4 and got the same problem as
 before.

 I think we need to ask someone else to help with this!  JEC

--
Ticket URL: 
Sage 
Sage - Open Source Mathematical Software: Building the Car Instead of
Reinventing the Wheel

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

[sage-devel] Fwd: [SAGE] #3102: [with patch, with review, issue remains] debugging output in p-adics with print mode "digits"

[John Cremona]

Are there any other output formats which have three dots "..." in them
as standard?  If so they are not getting doctested as much as they
should be!

John


-- Forwarded message --
From: SAGE <[EMAIL PROTECTED]>
Date: 2008/9/8
Subject: Re: [SAGE] #3102: [with patch, with review, issue remains]
debugging output in p-adics with print mode "digits"
To:
Cc: [EMAIL PROTECTED]


#3102: [with patch, with review, issue remains] debugging output in p-adics with
print mode "digits"
--+-
 Reporter:  dmharvey  |Owner:  somebody
Type:  defect|   Status:  new
 Priority:  major |Milestone:  sage-3.1.2
Component:  basic arithmetic  |   Resolution:
 Keywords:|
--+-
Changes (by cremona):

 * summary:  [with patch, needs review] debugging output in p-adics with
 print mode "digits" => [with patch, with
 review, issue remains] debugging output in
 p-adics with print mode "digits"

Comment:

 Well, the patch applied fine and doctests pass.  BUT  when I manually type
 in
 {{{
sage: K = Qp(7, print_mode="digits")
sage: repr(K(1/2))
 }}}
 I do NOT get what the doctest says I should:
 {{{
'...3|3|3|3|3|3|3|3|3|3|3|3|3|3|3|3|3|3|3|4'
 }}}
 but instead I get this:
 {{{
 '...3334'
 }}}

 I don't know why the vertial lines a re missing, or whether they should be
 there;  but I do know that the doctester ignores what comes after three
 dots ... so any p-adics print mode which includes the dots is going to be
 rather hard to doctest.

--
Ticket URL: 
SAGE 
Sage - Open Source Mathematical Software: Building the Car Instead of
Reinventing the Wheel

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

[sage-devel] Fwd: [SAGE] #3999: [with patch, needs review] Wrapper class to treat additive groups as multiplicative goups

[John Cremona]

I'm forwarding this entry from trac#3999 to sage-devel so it gets a
wider readership.

I certainly agree that the "main" abelian groups implementation in
Sage should be based on (additive) Z-modules.  Then this wrapper idea
would be the way to go to implement multiplcative notation.  But
that's premature right now, since no-one has yet done the "great
 abelian groups rewrite".

The existing abelian groups code has an underlying additive structure
(at heart every element is a vector of integers, the group op is
componentwise addition with reduction mod n if the associated
generators has order n), but the element class is derived from
MultiplicativeGroupElement, and it is that which makes trying to use
additive notation a pain.

I might spend a little more time doing the additive interface to the
current AbelianGroup class, but not a lot since it's only a stop-gap
until we have an all-new AbelianGroups class, which would take more
time than I have right now.

John


-- Forwarded message --
From: SAGE <[EMAIL PROTECTED]>
Date: 2008/9/3
Subject: Re: [SAGE] #3999: [with patch, needs review] Wrapper class to
treat additive groups as multiplicative goups
To:
Cc: [EMAIL PROTECTED]


#3999: [with patch, needs review] Wrapper class to treat additive groups as
multiplicative goups
--+-
 Reporter:  robertwb  |Owner:  somebody
Type:  defect|   Status:  new
 Priority:  major |Milestone:  sage-3.1.2
Component:  basic arithmetic  |   Resolution:
 Keywords:|
--+-
Comment (by robertwb):

 > I am trying hard to see how this might actually be useful in practice.

 The first thing that comes to mind is the generic discrete log code that
 you wrote a while back. One then wouldn't have to use the cumbersome (and
 slower) op(x,y) notation for the group operations to be able to handle
 both additive (via the wrapper) and multiplicative groups.

 I had assumed the implementation of abelian groups was, at its core,
 additive using Z-modules and all (this seems more natural to me, as well
 as much more efficient). I'm not sure if this is part of the "great
 abelian groups rewrite" or not, but IMHO I think it should be. I also
 wrote the patch this direction because (in Sage) additive groups are all
 abelien (they inherit from modules), and there is a functor from them to
 generic non-abelien groups but not the other way around. It could also be
 handy in trying to (formally) implement Z[G] where G is initially
 presented as an additive group.

 Trying to add additive notation to these would be difficult, as they do
 not inherit from ModuleElement. Were you trying to make it so if I took
 elements of a multiplicative group (say, a permutation group) and did
 {{{a+b}}} it would instead do {{{a*b}}}. I would probably rather have it
 throw an error in this case.

 I could pretty easily write a patch going the other way if you would find
 it useful (though strange stuff might happen if one tries to use it on
 non-abelien groups, depending on the assumptions people make throughout
 the rest of the Sage library).

--
Ticket URL: 
SAGE 
Sage - Open Source Mathematical Software: Building the Car Instead of
Reinventing the Wheel

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

[sage-devel] Fwd: [sage-devel] Re: Sphinx and the Sage Documentation

[William Stein]

Hi John,

This is from the guy organizing a lot of the transition of the
numpy docs over to Sphinx...


-- Forwarded message --
From: Stéfan van der Walt <[EMAIL PROTECTED]>
Date: Fri, Aug 22, 2008 at 1:00 AM
Subject: Re: [sage-devel] Re: Sphinx and the Sage Documentation
To: William Stein <[EMAIL PROTECTED]>


Hey William,

They can always use the source tree:

Development branch:

URL: http://svn.python.org/projects/doctools/branches/0.4.x

Stable branch:

URL: http://svn.python.org/projects/doctools/trunk

Could be the other way around, not sure.

I'll take a look at the proposal, thanks for bringing it to my attention!

Cheers
Stéfan

2008/8/21 William Stein <[EMAIL PROTECTED]>:
> -- Forwarded message --
> From: John H Palmieri <[EMAIL PROTECTED]>
> Date: Thu, Aug 21, 2008 at 10:58 PM
> Subject: [sage-devel] Re: Sphinx and the Sage Documentation
> To: sage-devel 
>
>
>
>
>
> On Aug 21, 5:35 pm, "Mike Hansen" <[EMAIL PROTECTED]> wrote:
>> Hello all,
>>
>> Carl Witty and I wrote a proposal for the use of the Sphinx
>> documentation system in Sage.  It can be found 
>> athttp://wiki.sagemath.org/SphinxSEPWe'd appreciate any comments /
>> questions / concerns that people have.
>>
>> --Mike
>
> Do you know where I can download the latest version (0.5) of Sphinx,
> so I can try it out?  From  index.html>, for example, which says the latest version is 0.5, it
> says "Get Sphinx from the Python package index", and when I follow
> that link, I get to a page where I can download 0.4.2, which doesn't
> (as far as I can tell) have the math stuff in it.
>
>  John
>
>
> >
>
>
>
> --
> 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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Fwd: [sage-devel] Minor documentation error

[William Stein]

Hi Harald,

What happened to the hg repos?  Before you modified the
web page,

   http://sagemath.org/hg

pointed to all the hg repos for sage.  Now it doesn't anymore.
We need to have a www2/hg directory, I think.


-- Forwarded message --
From: Bill Hart <[EMAIL PROTECTED]>
Date: Thu, Jul 17, 2008 at 11:23 PM
Subject: [sage-devel] Minor documentation error
To: sage-devel 



This page:

http://www.sagemath.org/doc/html/prog/node72.html

claims:

You can browse the official repositories for Sage with your web
browser here: http://sagemath.org/sage/hg

This appears to not be valid at present. It returns a 404.

Bill.




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

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

[sage-devel] Fwd: SAGE article in the biggest student magazin at the ETH university

[William Stein]

-- Forwarded message --
From: Samuel Gaehwiler <[EMAIL PROTECTED]>
Date: Thu, May 29, 2008 at 4:32 AM
Subject: SAGE article in the biggest student magazin at the ETH university
To: [EMAIL PROTECTED]


Hi William,

as I promised in the SAGE support mailinglist a couple of weeks ago I
wrote an introductional article about SAGE. It was published in the
biggest student magazin of the federal institute of technology of
switzerland (www.ethz.ch) - the one of the mechanical and electronic
engineering students - last monday, May 26. (it's issue #12 of this
student-year and should be available soon at
http://www.blitz.ethz.ch/archive.html. SAGE was even mentioned at the
frontpage)

Its written in german with the main purpose of letting people know
about the existence of SAGE.
For this article I also made a little webpage to get them started with
SAGE: http://people.ee.ethz.ch/~samuelg/

Sadly, the IT-support-group of the electronic engineering facility
told me, that they don't have time to set up a SAGE server at the
moment. Maybe later this year.
The IT-support-group of the whole university did not even reply to my concern.
I also contacted two professors about how to spread the usage uf SAGE
at our university. Sadly, they also havn't answerd.

Just wanted to let you know.

btw: the shadow of the SAGE logo on http://www.sagemath.org/ is a
little cropped at the right and bottom edge.

Best regards,
Samuel



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

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

[sage-devel] Fwd: [sage-devel] Re: Fwd: SAGE 3.0.1 doc errata, mostly w.r.t. tutorial (doc dated 2007.10.28)

[William Stein]

Hi,

Here is a response by Johann about the issues he pointed out.He says
I ship some very old version of the tutorial in the binary for intel os x 10.4.
Indeed, it turns out that that binary just happens to be the *only* binary I
distribute that is obtained by doing "sage -upgrade" repeatedly since
2.8.10, and "sage -upgrade" doesn't fully upgrade the html versions of
the docs at present.

I'll build a fresh binary of intel os x 10.4 sage

William


-- Forwarded message --
From: Johann Tonsing <[EMAIL PROTECTED]>
Date: Sun, May 18, 2008 at 3:38 AM
Subject: Re: [sage-devel] Re: Fwd: SAGE 3.0.1 doc errata, mostly
w.r.t. tutorial (doc dated 2007.10.28)
To: William Stein <[EMAIL PROTECTED]>


William,

John wrote:
>
> I'm not even sure which part of the document is being referred to, since my 
> node numbers
> differ from the ones listed here.  Maybe node38.html?

FYI the tutorial shipped with SAGE 3.0.1 for Intel MacOSX Tiger
(v10.4.x) is dated October 28, 2007.  On the web, the latest
(http://www.sagemath.org/doc/html/tut/tut.html) appears to be dated
May 4, 2008.  Many of the issues I reported seem to have been fixed in
the later version of the documentation.  I would suggest determining
why the later version of the documentation was not included in v3.0.1.

Regards
Johann




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

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

[sage-devel] Fwd: SAGE 3.0.1 doc errata, mostly w.r.t. tutorial (doc dated 2007.10.28)

[William Stein]

Hi Sage-Devel,

Can somebody volunteer to make a trac ticket and put all the following
fixes into sage?

William


-- Forwarded message --
From: Johann Tonsing <[EMAIL PROTECTED]>
Date: Sat, May 17, 2008 at 4:17 PM
Subject: SAGE 3.0.1 doc errata, mostly w.r.t. tutorial (doc dated 2007.10.28)
To: [EMAIL PROTECTED]


William,
Thanks for your efforts.  Having used SAGE for a few hours I am duly impressed.
Herewith a few minor corrections to the tutorial + other documentation.

help:
a.
The variable DATA contains the directory with data files that you
upload into the worksheet. For example, to open a file in that
directory, do "open(DIR+'filename')".
DIR => DATA
b. Inconsistent capitalisation: "Split and join cells" should perhaps
be "Split and Join Cells", also "DATA variable" should be "DATA
Variable", etc.

Tutorial:
1. doc/live/tut/node9.html:
Note: You should not type the triple dots ... above; they are just to
emphasize that the code is indented.
The dots do not appear in the HTML live notebook version.  Ideally the
tools would provide a way to omit some text in this version.  If
impossible write something like:
Note: The interactive interpreter may display three dots ("...") to
indicate that code is indented - these don't need to be entered.
---
2. doc/live/tut/node20.html:
Type p.show(axes=false) to see this without any ases.
ases => axes
---

3. doc/live/tut/node13.html
Next lets do some arithmetic.
suggest rather:
Next, let's do some arithmetic.
---
4. doc/live/tut/node23.html
equatoins => equations
---
5. doc/live/tut/node24.html
pari and maxima => PARI and Maxima
The Sage notebook version displays
&vellip#vdots;
in the table (whether viewed in Opera for Mac version +- 9.5 or Safari
3.1).  Just "⋮" might have worked.  The static version exhibits
the same problem.
---
6. doc/live/tut/node40.html
gap.console(): You are completely using another program, e.g., Gap/Magma/GP
a. Add "." after "GP".
b. Suggest replacing entire sentence with:
gap.console(): This opens the GAP console, i.e. transfers control to GAP.
as the phrase "completely using" is unclear.
c. Suggest replacing occurrences of "Gap" that refer to the GAP
software with "GAP" --- this applies to this page and possibly other
documentation files, perhaps search for the word Gap.
---
7. doc/live/tut/node56.html
Please note that you cannot do a stats = prun -r A*A for some internal reason.
replace with
Note: entering stats = prun -r A*A displays a syntax error message
because prun is an IPython shell command, not a regular function.
---
8.
See SAGE_ROOT/examples/pyrex/factorial.spyx for an example of a
compiled implementation of the factorial function that directly uses
the GMP C library
Replace
examples/pyrex
with
examples/programming/sagex
as the file seems to have moved.  Please confirm the exact directory
name to list here as there are two instances of factorial.spyx shipped
with v3.0.1.
---
9. doc/live/tut/node46.html
Suggest replacing
In particular, attach has the side effect of (auto-reload), very handy
when debugging code, while load does not.
with
The attach command automatically reloads a file whenever it changes,
which is handy when debugging code, whereas the load command only
loads a file once.
as "(auto-reload)" is not defined anywhere (is this a LISP command?)
and therefore might not make sense.
---
10. doc/static/ref/node57.html
Heierarchy => Hierarchy
---
11. doc/static/ref/node58.html
DD NOT => DO NOT
(IMHO "***NOT***" can be replaced with "NOT" - shouting (capital
letters) should surely be enough?  Alternatively render the NOT in
bold.)
---
12. doc/static/ref/node18.html
SAGE includes the Moin Moin Wiki interactive web page system standard.
just omit " standard"
-or-
standard => as standard
-or-
standard => by default
---
13. doc/static/ref/module-sage.plot.plot.html
We combine together  => We combine

Intuitive usage and completeness notes
The following are not really errors, just potential sources of confusion.
1. doc/live/tut/node10.html
When reading
the complex numbers CC (which uses I (or i), as usual, for the square
root of −1).
I tried
(1+2*I) in CC
(1+2*i) in CC
and was surprised to receive False.  Eventually I figured out one has
to define I or i first.
Suggest rather
the complex numbers CC (which uses I (or i) for the square root of −1
-- just enter I=CC.0 to define I).
---
2. doc/live/tut/node10.html
It might have been handy if
optional_packages()
and
install_package('database_gap-4.4.10')
were already executable blocks.
---
3. doc/live/tut/node10.html
I installed database_gap.  The actual output of
K.galois_group()
and
K.class_group()
when evaluated were not what was pre-computed + stored in the
tutorial.  I was using sage 3.0.1 and database_gap 4.4.10.
---
4. doc/live/tut/node13.html
(The object MPolynomialRing(GF(5),3,"z") is the same as the object
MPolynomialRing(GF(5),3,"z").)
Oh, so x == 

[sage-devel] Fwd: [sage-support] Re: X range (plotting).

[John Cremona]

-- Forwarded message --
From: William Stein <[EMAIL PROTECTED]>
Date: 2008/5/1
Subject: [sage-support] Re: X range (plotting).
To: [EMAIL PROTECTED]

 Yes. Use the figsize= option, which takes "inches" as input:

 sage: plot(cos(x),1,2).show(xmin=1,xmax=2, ymin=-0.5,ymax=0.5, figsize=[12,15])

 If we are going for world domination, please may we use metric units?

If Sage is one day going to help land spacecraft on Mars (and why
not?) we need to be *really* clear wht our units are ;)

John

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

[sage-devel] Fwd: sage-devel "exact" numerical integration

[David Harvey]

Begin forwarded message:

> From: Andrzej Chrzęszczyk <[EMAIL PROTECTED]>
> Date: March 5, 2008 6:23:53 PM EST
> To: [EMAIL PROTECTED]
> Subject: sage-devel "exact" numerical integration
>
> Dear David
> Try
>
> sage: maxima_console()
> (%i1) integrate(%e^(-x^2),x,0,0.1);
> ...
> `rat' replaced .05623145800914245 by 2066/36741 = .05623145804414686
> 2066 sqrt(%pi)
> (%o1)   --
> 36741
>
> then you will see that (behind the scene)
> maxima replaces more accurate result .05623145804414686 sqrt(%pi)
> by the less accurate one:  2066 sqrt(%pi)/36741 (default maxima  
> behaviour)
>
> Your exact calculations are OK but why do you mix the exact-inexact.
> Pure numerical version using GSL:
>
> sage: numerical_integral(lambda x:e^(-x^2),0,-.1)
> (-0.099667664290336327, 1.1065333570574191e-15)
>
> is in a good accordance with your exact calculations
>
> Andrzej Chrzeszczyk
>
> (I'm not in sage-devel so I'm using your  e-mail adress,
> I hope You will excuse me)

Okay, I can see this makes sense from within Maxima, since you get to  
see the "replacement" message.

But in Sage, it's really terrible! When I do

sage: f = e^(-x^2)
sage: f.integral(x, 0, 0.1)
2066*sqrt(pi)/36741

I have absolutely no idea what is going on in the background. It  
could be maxima, or sympy, or some other library that someone plugged  
in, or who knows what.

How am I supposed to tell that 2066*sqrt(pi)/36741 is not an exact  
answer? Since it contains sqrt(pi), it's very suggestive that it's  
supposed to be exact.

Another example: if I do

sage: f = x*e^(2*x)
sage: f.integral(x, 0, 1)
e^2/4 + 1/4

Is that an exact answer? Or it just "close enough" to e^2/4? What use  
is the answer if I can't tell?

david


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

[sage-devel] Fwd: [SAGE] #277: Add generic_discrete_logarithm and order computation using Pollard's rho algorithm

[John Cremona]

For anyone interested in generic discrete logs, as discussed here in
February, please take a look at #277.  The patch I put there (based on
by earlier patch for #2356 which has a positive review so hopefully
will make it into 2.10.3) is just a first step, on which I would like
some feedback.

I already gave an example to show that the same code which (replacing
the older discrete_log_generic() function) passes all existing
doctests which were multiplicative,  also gives elliptic curve
discreet logs.  I would really like suggestions of other examples for
more testing!

John

-- Forwarded message --
From: SAGE <[EMAIL PROTECTED]>
Date: 2 Mar 2008 22:37
Subject: Re: [SAGE] #277: Add generic_discrete_logarithm and order
computation using Pollard's rho algorithm
To:
Cc: [EMAIL PROTECTED]


#277: Add generic_discrete_logarithm and order computation using Pollard's rho
 algorithm
 ---+
  Reporter:  ncalexan   |
  Owner:
 Type:  enhancement|
Status:  new
  Priority:  minor  |
  Milestone:  sage-wishlist
 Component:  group_theory   |
 Resolution:
  Keywords:  discrete log shanks pollard rho order group structure  |
 ---+
 Changes (by cremona):

  * component:  number theory => group_theory

 Comment:

  The attached patch (8758.patch) is a first stab at doing these things more
  generically.  For any multiplicative or additive situation the new version
  of discrete_log_generic() now works, using a baby-step-giant-step
  approach.  For example (see doctest) this gives a BSGS implementation of
  DLOGS for elliptic curves.

  If people think this is a reasonable way to go (and it is certainly a
  simple interface) then there is more which can be added very easily:  a
  more general BSGS function (solve {{{a=b^n}}} with {{{n}}} in some
  specified interval) which would be called by discrete_log() and also allow
  for computation of orders of elements in any group, etc.

  Then one could have other algorithms implemented in the same framework
  such as Pollard Rho or the more sophisticated ones mentioned in earlier
  comments.

  More comments please!


 --
 Ticket URL: 
 SAGE 
 Sage - Open Source Mathematical Software: Building the Car Instead of
Reinventing the Wheel

-- 
John Cremona

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

[sage-devel] Fwd: Sage

[William Stein]

Hi Sage-Devel,

Here is some more fan mail:


-- Forwarded message --
From: Tom Radcliffe <>
Date: Wed, Feb 20, 2008 at 7:22 PM
Subject: Sage
To: [EMAIL PROTECTED]


Just a note to say I've just installed Sage and it really looks like it
 rocks.  Longtime Mathematica user (since just before the 2.0 release!)
 and I've been looking for a free/open replacement for a while.  Sage
 looks like the right tool built in the right way.  I really appreciate
 the way it is built on existing packages rather than reinventing the
 wheel, and also that it comes with all the dependencies installed.

 The install (on Slackware 12.0) from the Debian binary was clean, and it
 runs fine.

 Nice work!

 --Tom

 Tom Radcliffe, Ph.D., P.Eng.
 President, Predictive Patterns Software Inc.
 http://www.predictivepatterns.com
 Adjunct Assistant Professor, Queen's University
 Department of Pathology and Molecular Medicine




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

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

[sage-devel] Fwd: SAGE for FPGA development

[William Stein]

--- Forwarded message ---
From: "Blubaugh, David A." <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc:
Subject: SAGE for FPGA development
Date: Thu, 07 Feb 2008 14:26:13 -0800

Sir,


I was wondering if it was possible to integrate MyHDL into SAGE???  This
would hopefully allow for the development of a system that could be
utilized to develop numerical algorithms onto FPGAs.


Thanks,

David Blubaugh

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.



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

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

[sage-devel] Fwd: Sage for Engineering

[William Stein]

Robert,

Thanks for your suggestions.  I've forwarded it to sage-devel.


-- Forwarded message --
From:  <[EMAIL PROTECTED]>
Date: Feb 1, 2008 1:56 PM
Subject: Sage for Engineering
To: [EMAIL PROTECTED]





Hello Mr. Stein,



Sage is great for mathematics!  If it included PhysicalQuantities.py
(and dependencies) from the Scientific package it would be great for
combined mathematics / engineering calculations as well!  (I could
probably add it myself, but IMHO Sage would be more readily adopted by
engineers if it was included.  Customizing Python installations on
virtual machines might be intimidating for a Python newbie.)



Thanks,



Robert Veelenturf


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

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

[sage-devel] Fwd: Sage download procedure

[Nick Alexander]

Hi everyone, I have no idea if this is true, or if it was auto- 
generated and is spam, or what, but some people here might care.

Nick

Begin forwarded message:

> From: lou blaine <[EMAIL PROTECTED]>
> Date: January 22, 2008 7:41:18 AM PST
> To: [EMAIL PROTECTED]
> Subject: Sage download procedure
> Reply-To: lou blaine <[EMAIL PROTECTED]>
>
> I'm not sure whether you are the proper person to address this to,  
> but if not you may know who it is.
>
> If Sage were compressed with 7-zip from sourceforge rather than  
> zipped the resulting self extracting executable is 474MB instead of  
> 749MB This would save you countless hours of download time and  
> would allow the addition of a significant amount of material of  
> interest
> source code, examples, archived journals, etc. to be added to a CD  
> or ISO image. the extract time is also significantly shorter.
>
> Lou Blaine
>


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

[sage-devel] Fwd: [sage-newbie] Re: Sage for MacOS 10.5 (PPC)

[William Stein]

On Jan 21, 2008 2:49 PM, mabshoff
<[EMAIL PROTECTED]> wrote:
>
>
>
> On Jan 21, 11:45 pm, boyfarrell <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > Is there a binary download of the PowerPC version of MacOS 10.5
> > Leopard?
> >
> > If not, it it possible to build from source on a 10.5  PPC system?
> >
> > Regards,
> >
> > Daniel
>
> Hi Daniel,
>
> I know for a fact that Craig Citro builds Sage on OSX 10.5 PPC, so
> building Sage does work. Maybe Craig can supply binaries in the future
> since we do not have a PPC build box with OSX 10.5 on it?

I can confirm that I definitely do not have a PPC build box with OS X
10.5 on it.
Right now I build all Sage binaries -- it's almost completely automatic.  I am
very reluctant to have to depend on some complicated pinging of people to
build binaries for me, etc., (and also somewhat worried about the security
implications of posting random binaries made by people).
It would complicate my workflow.  Thus I think
we should post binaries for architure/OS XYZ if and only if somebody will give
me a net-accessible account on machine XYZ.

So Craig, can I have an account on your computer? :-).

If anybody else wishes that Sage had binaries for their favorite architecture,
but currently doesn't, e.g., SUSE, Gentoo, etc., consider providing me
with an account.


 -- William



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

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

[sage-devel] Fwd: SAGE testing?

[William Stein]

-- Forwarded message --
From: Werner Krandick <[EMAIL PROTECTED]>
Date: Jan 16, 2008 7:43 AM
Subject: SAGE testing?
To: [EMAIL PROTECTED]


Dear William,

I am currently writing on the testing of computer algebra programs and
systems. For this purpose I would like to know how you generate test
inputs for those parts of SAGE that compute mathematical results, that
is, not user interface functions and other functions.

Also in case you have any general hints about how test inputs for
computer algebra programs outside of SAGE are generated I would
appreciate those hints as well.

Thanks and best regards,

Werner



-- 
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] Fwd: SAGE and SOCR

[William Stein]

-- Forwarded message --
From: Ivo Dinov <[EMAIL PROTECTED]>
Date: Sun, 13 Jan 2008 10:25:17 -0800
Subject: SAGE and SOCR
To: [EMAIL PROTECTED]

Dear Dr. Stein:

I came across your SAGE (http://modular.math.washington.edu/sage/)
developments and visited your booth at the Joint Math meeting in SD last
week.

I wanted to see if you may have an interest in exploring the
possibility of integrating your open-source mathematical developments with
our efforts on developing a National Internet-based Science Educational
Resource (www.NSER.org). We have been very successful with our prototype of
developing instructional materials, learning modules and computational
library for probability and statistics (www.StatisticsResource.org). And we
have teamed up with faculty in biology, chemistry, engineering, physics and
math to extend these resources.

Our goals are to develop open-source materials that are completely
accessible via the Internet and provide human (GUI) and machine (comp libs)
interfaces across disciplines. We have chosen to disseminate:

1. GUI components via Java (e.g.,
socr.ucla.edu/htmls/SOCR_DistributionFunctors.html)
2. Educational/instructional materials via Wiki (e.g.,
wiki.stat.ucla.edu/socr/index.php/SOCR_EduMaterials_Activities_LawOfLargeNum
bers)
3. Main resource interface via Hyperbolic Graph Viewer (e.g.,
www.NSER.org/NISER_HT_ResourceViewer.html)

Please let me know if you think there may be common ground for
collaboration.

Best regards,

 - Ivo

*
Ivo Dinov[EMAIL PROTECTED]
UCLA StatisticsTel: 310-825-8430
SOCR Resource   Fax: 310-206-5658
8125 Mathematical Science Bldg   www.SOCR.ucla.edu
Los Angeles, CA 90095www.stat.ucla.edu/~dinov
**




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


-- Forwarded message --
From: Ivo Dinov <[EMAIL PROTECTED]>
Date: Sun, 13 Jan 2008 10:25:17 -0800
Subject: SAGE and SOCR
To: [EMAIL PROTECTED]

Dear Dr. Stein:

I came across your SAGE (http://modular.math.washington.edu/sage/)
developments and visited your booth at the Joint Math meeting in SD last
week.

I wanted to see if you may have an interest in exploring the
possibility of integrating your open-source mathematical developments with
our efforts on developing a National Internet-based Science Educational
Resource (www.NSER.org). We have been very successful with our prototype of
developing instructional materials, learning modules and computational
library for probability and statistics (www.StatisticsResource.org). And we
have teamed up with faculty in biology, chemistry, engineering, physics and
math to extend these resources.

Our goals are to develop open-source materials that are completely
accessible via the Internet and provide human (GUI) and machine (comp libs)
interfaces across disciplines. We have chosen to disseminate:

1. GUI components via Java (e.g.,
socr.ucla.edu/htmls/SOCR_DistributionFunctors.html)
2. Educational/instructional materials via Wiki (e.g.,
wiki.stat.ucla.edu/socr/index.php/SOCR_EduMaterials_Activities_LawOfLargeNum
bers)
3. Main resource interface via Hyperbolic Graph Viewer (e.g.,
www.NSER.org/NISER_HT_ResourceViewer.html)

Please let me know if you think there may be common ground for
collaboration.

Best regards,

 - Ivo

*
Ivo Dinov[EMAIL PROTECTED]
UCLA StatisticsTel: 310-825-8430
SOCR Resource   Fax: 310-206-5658
8125 Mathematical Science Bldg   www.SOCR.ucla.edu
Los Angeles, CA 90095www.stat.ucla.edu/~dinov
**




-- 
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] Fwd: SAGE in Iran

[William Stein]

Hi Sage-Devel,

Some of you might find this interesting -- it's an email I just got from
a professor in Iran who is very excited about Sage and plans to
run a workshop there on Sage soon.   Write to him if you have any
thoughts.

 -- William

-- Forwarded message --
From: Amir Mohammad Naderi <[EMAIL PROTECTED]>
Date: Jan 10, 2008 12:31 AM
Subject: SAGE
To: [EMAIL PROTECTED]


Dear Dr. William Stein,
Hi

I'm one of the Number theory instructor in Isfahan Mathematics House
IMH(http://mathhouse.org).
i found SAGE and i work on it to my research and i like to use to my
teaching number theory and other courses .
it is a very simple and efficients for work .

in 12-15 August 2008 we have a 10th Iranian Mathematics Education
Conference in Iran(http://www.imec10yazd.com/).
i have a plan that i introduce SAGE to this conference and have a
workshop on it.

i like run workshop with your guidance,if not problem please help me.


thanks
with best regards
Naderi


-- 
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] Fwd: [sage-support] Re: Sage 2.9 VMWare image released

[William Stein]

-- Forwarded message --
From: Adam Getchell <[EMAIL PROTECTED]>
Date: Jan 8, 2008 11:24 AM
Subject: Re: [sage-support] Re: Sage 2.9 VMWare image released
To: William Stein <[EMAIL PROTECTED]>


I just uploaded vmware-sage-deluxe-2.9.3.7z to my home directory on
sage.math. It's slightly smaller than the previous (2.9.1.1) version.

Adam


On Jan 7, 2008 1:02 PM, Adam Getchell <[EMAIL PROTECTED]> wrote:
> I've uploaded vmware-sage-deluxe.7z (which is just over 2GB) onto my
> home directory on sage.math.washington.edu.
>
> Let me know if you see any problems with it!
>
>
> Adam
> --
> "Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu
>



--
"Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu



-- 
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] Fwd: Sage Mac application bundle

[William Stein]

Hi,

Can some Mac user try this code submission from NASA out
and make it part of Sage?   It looks pretty sweet.


-- Forwarded message --
From: Ted Wright <@ NASA>
Date: Jan 8, 2008 10:44 AM
Subject: Sage Mac application bundle
To: [EMAIL PROTECTED]


Hi,

Thanks for Sage - it's awesome. I need to convince my coworkers to
switch from their proprietary programs to Sage.

I've attached a little script that uses the Platypus program
(http://www.sveinbjorn.org/software) to bundle the sage directory
into a clickable Mac application. It has some code to update the
SAGE_ROOT variable so that things still work if a user drags the
program around.

My code is public domain, so feel free to use it if you like it.

Ted



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



sageMac.tgz
Description: GNU Zip compressed data

[sage-devel] Re: [Jmol-developers] [sage-devel] Fwd: [sage-devel] Re: Jmol andMathematics Visualization

[Robert Bradshaw]

On Jan 1, 2008, at 12:28 PM, Bob Hanson wrote:

> The zip file business is complete. What you do is, in 11.5.2,
>
>  set defaultdirectory "whateverfile.zip"
>
> then when you issue
>
>  load myfile.xyz
>
> or
>
> script "test.spt"
>
> those files are drawn from the zip file, just as though it were a  
> real directory. To go back to normal operation, issue
>
>  set defaultDirectory ""

Perfect!

> Also, I modified the pmesh binary specs just a bit. I decided we  
> really needed four full bytes of magic number, so it's the fifth  
> byte that indicates big/little-endian.

That's fine, but I really liked being able to write (short)1 to  
indicate the endianness--much more straightforward than trying to  
detect it (e.g. writing to some temporary buffer and reading the  
result), so I'd like to keep this field 2 bytes (\0 \1 or \1 \0)

> We could compress this a bit more by using bytes instead of ints  
> for each polygon # of vertices, but maybe that's not necessary?

If one cares about space, one will be gzipping it anyways--that's the  
level to take care of it IMHO. Most of the ints here would fit into  
smaller words (though one wants to allow > 2^16 vertices/polygons).

> For now, consider this binary format HIGHLY experimental and  
> subject to change.

Sure. Any reason for (exactly) 64 bytes reserved? Why not make it n  
bytes reserved (for an arbitrary header) and let (int)n be given at  
the top?

> # new feature: pmesh BINARY "filename"
> #   BINARY keyword is optional, but recommended for efficiency
> #
> #   *  4 bytes: P M \1 \0
> #   *  1 byte: \0 for bigEndian
> #   *  3 bytes: reserved
> #   *  4 bytes: (int) vertexCount
> #   *  4 bytes: (int) polygonCount
> #   * 64 bytes: reserved
> #   *  --
> #   *  float[vertexCount*3]vertices {x,y,z}
> #   *  [polygonCount] polygons
> #   *  --each polygon--
> #   *4 bytes: (int)nVertices (1,2,3, or 4)
> #   *[4 bytes * nVertices] int[nVertices]
> #   *
> #   * note that there is NO redundant extra vertex in this format
> #
> #  see little-endian example at http://chemapps.stolaf.edu/jmol/ 
> docs/misc/pmesh.bin
> #  and http://chemapps.stolaf.edu/jmol/docs/misc/pmesh.bin.txt
>
> Nico will release 11.5.2 probably later today.

Great.

- 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: [Jmol-developers] [sage-devel] Fwd: [sage-devel] Re: Jmol andMathematics Visualization

[Bob Hanson]

The zip file business is complete. What you do is, in 11.5.2,

  set defaultdirectory "whateverfile.zip"

then when you issue

  load myfile.xyz

or

 script "test.spt"

those files are drawn from the zip file, just as though it were a real 
directory. To go back to normal operation, issue

  set defaultDirectory ""

Also, I modified the pmesh binary specs just a bit. I decided we really 
needed four full bytes of magic number, so it's the fifth byte that 
indicates big/little-endian.

We could compress this a bit more by using bytes instead of ints for 
each polygon # of vertices, but maybe that's not necessary?

For now, consider this binary format HIGHLY experimental and subject to 
change.

Bob

# new feature: pmesh BINARY "filename"
#   BINARY keyword is optional, but recommended for efficiency
#
#   *  4 bytes: P M \1 \0
#   *  1 byte: \0 for bigEndian
#   *  3 bytes: reserved
#   *  4 bytes: (int) vertexCount
#   *  4 bytes: (int) polygonCount
#   * 64 bytes: reserved
#   *  --
#   *  float[vertexCount*3]vertices {x,y,z}
#   *  [polygonCount] polygons
#   *  --each polygon--
#   *4 bytes: (int)nVertices (1,2,3, or 4)
#   *[4 bytes * nVertices] int[nVertices]
#   *
#   * note that there is NO redundant extra vertex in this format
#
#  see little-endian example at 
http://chemapps.stolaf.edu/jmol/docs/misc/pmesh.bin
#  and http://chemapps.stolaf.edu/jmol/docs/misc/pmesh.bin.txt

Nico will release 11.5.2 probably later today.

Bob


Robert Bradshaw wrote:

> Thanks. Looks good to me. Where can I get some jars to play around  
> with this?
>
> Any more work on the zip file stuff?
>
> - Robert
>
>
> On Dec 31, 2007, at 8:23 PM, Bob Hanson wrote:
>
>> Jmol 11.5.1 has
>>
>>   pmesh binary "filename"
>>
>> It's just experimental -- totally up to you what you want there,  Robert
>> -- but for now it looks like this:
>>
>> http://chemapps.stolaf.edu/jmol/docs/misc/pmesh.bin
>>
>> described here:
>>
>> http://chemapps.stolaf.edu/jmol/docs/misc/pmesh.bin.txt
>>
>> seems to work with that one file. I'm hoping you can work with this  and
>> see how it goes. I'm done for some time now.
>>
>> Bob
>>
>>
>>
>> Robert Bradshaw wrote:
>>
>>> On Dec 29, 2007, at 9:15 PM, Robert Hanson wrote:
>>>
 I'm a bit lost on this thread, but I wanted to respond to the
 binary/multiple file issue.

 First, it's a fine idea to create a binary Pmesh file format. If  
 we do
 that, though, let's not rush into it and just "create a binary
 equivalent
 of a Pmesh file." If this is really useful, then let's create a
 format that


 1) allows for multiple pmesh objects
>>>
>>>
>>>
>>> Sure, though if the zip file thing is working I think it is fine to
>>> have one object per file too (as we also want to specify color, etc.
>>> and will probably have spheres, labels, etc. too, so we'll be dealing
>>> with multiple files anyway and it probably isn't worth trying to
>>> figure out a way to encode this as scripts work so nice).
>>>
 2) includes a header that clearly distiguishes the file format
 within the
 first 4 bytes -- the "magic number" idea.
>>>
>>>
>>>
>>> Yes, this is a good idea. One or two non-ascii bytes maybe (so other
>>> readers can detect that it's binary data). Perhaps a flag that
>>> specifies floats vs. doubles. Java already stores things in a endian-
>>> consistant way, so we don't need to deal with that.
>>>
 3) allows for a simpler polygon definition -- for example, there
 should not
 be the need to redundantly specify the first vertex twice, as is
 part of
 the pmesh file format.
>>>
>>>
>>>
>>> Certainly. Other than that the format is very simple to implement,
>>> and I can't think of any changes that need to be made.
>>>

 I recently added ZIP (JAR) file reading capability to Jmol -- no
 need for
 gzip here -- we can now read a zip file directory directly if we
 wanted to
 -- but that seems to me to be an unnecessary complication in this  
 case. All
 we really need is a new binary pmesh format.
>>>
>>>
>>>
>>> I often have more than just pmeshes that I want to include, and
>>> presentation stuff (color, wireframe or not, etc.) is nicely kept
>>> separate from the data in an easy-to-read ascii file.
>>>
 Note that Jmol must be able to distinguish the file type from the
 initial
 few bytes of data, not the file extension. That's the role of the
 header.

 I'd be very happy to write this reader; but before we do so, let's
 brainstorm a bit on what would be optimal.
>>>
>>>
>>>
>>> This would be great.
>>>


 On Fri, 28 Dec 2007 14:27:05 -0500 (EST), "Miguel"   <[EMAIL PROTECTED]>
 wrote:

>
> zip (jar) would be better for sets of files ... although Jmol
> currently
> doesn't have any mechanism to deal with a directory of files. That
> is, it
> woul

[sage-devel] Re: [Jmol-developers] [sage-devel] Fwd: [sage-devel] Re: Jmol andMathematics Visualization

[Robert Bradshaw]

Thanks. Looks good to me. Where can I get some jars to play around  
with this?

Any more work on the zip file stuff?

- Robert


On Dec 31, 2007, at 8:23 PM, Bob Hanson wrote:

> Jmol 11.5.1 has
>
>   pmesh binary "filename"
>
> It's just experimental -- totally up to you what you want there,  
> Robert
> -- but for now it looks like this:
>
> http://chemapps.stolaf.edu/jmol/docs/misc/pmesh.bin
>
> described here:
>
> http://chemapps.stolaf.edu/jmol/docs/misc/pmesh.bin.txt
>
> seems to work with that one file. I'm hoping you can work with this  
> and
> see how it goes. I'm done for some time now.
>
> Bob
>
>
>
> Robert Bradshaw wrote:
>
>> On Dec 29, 2007, at 9:15 PM, Robert Hanson wrote:
>>
>>> I'm a bit lost on this thread, but I wanted to respond to the
>>> binary/multiple file issue.
>>>
>>> First, it's a fine idea to create a binary Pmesh file format. If  
>>> we do
>>> that, though, let's not rush into it and just "create a binary
>>> equivalent
>>> of a Pmesh file." If this is really useful, then let's create a
>>> format that
>>>
>>>
>>> 1) allows for multiple pmesh objects
>>
>>
>> Sure, though if the zip file thing is working I think it is fine to
>> have one object per file too (as we also want to specify color, etc.
>> and will probably have spheres, labels, etc. too, so we'll be dealing
>> with multiple files anyway and it probably isn't worth trying to
>> figure out a way to encode this as scripts work so nice).
>>
>>> 2) includes a header that clearly distiguishes the file format
>>> within the
>>> first 4 bytes -- the "magic number" idea.
>>
>>
>> Yes, this is a good idea. One or two non-ascii bytes maybe (so other
>> readers can detect that it's binary data). Perhaps a flag that
>> specifies floats vs. doubles. Java already stores things in a endian-
>> consistant way, so we don't need to deal with that.
>>
>>> 3) allows for a simpler polygon definition -- for example, there
>>> should not
>>> be the need to redundantly specify the first vertex twice, as is
>>> part of
>>> the pmesh file format.
>>
>>
>> Certainly. Other than that the format is very simple to implement,
>> and I can't think of any changes that need to be made.
>>
>>>
>>> I recently added ZIP (JAR) file reading capability to Jmol -- no
>>> need for
>>> gzip here -- we can now read a zip file directory directly if we
>>> wanted to
>>> -- but that seems to me to be an unnecessary complication in this  
>>> case. All
>>> we really need is a new binary pmesh format.
>>
>>
>> I often have more than just pmeshes that I want to include, and
>> presentation stuff (color, wireframe or not, etc.) is nicely kept
>> separate from the data in an easy-to-read ascii file.
>>
>>> Note that Jmol must be able to distinguish the file type from the
>>> initial
>>> few bytes of data, not the file extension. That's the role of the
>>> header.
>>>
>>> I'd be very happy to write this reader; but before we do so, let's
>>> brainstorm a bit on what would be optimal.
>>
>>
>> This would be great.
>>
>>>
>>>
>>> On Fri, 28 Dec 2007 14:27:05 -0500 (EST), "Miguel"   
>>> <[EMAIL PROTECTED]>
>>> wrote:
>>>

 zip (jar) would be better for sets of files ... although Jmol
 currently
 doesn't have any mechanism to deal with a directory of files. That
 is, it
 wouldn't know which of the files you wanted to *open* and what you
 would
 want to do with the other files.

>>>
>>> Jmol 11.3.65 can and does read ZIP files and their directories,  
>>> and  for
>>> model files, if the ZIP file contains a "manifest" then specific
>>> files can
>>> be read or skipped, then the directory contents may be investigated
>>> prior
>>> to model loading. This capability is iterative, so zip files
>>> contained in
>>> zip files contained in zip files can be read.
>>
>>
>> This sounds perfect--where is this documented?
>>
>> - Robert
>>
>
>
> -- 
> Robert M. Hanson
> Professor of Chemistry
> St. Olaf College
> Northfield, MN
> http://www.stolaf.edu/people/hansonr
>
>
> If nature does not answer first what we want,
> it is better to take what answer we get.
>
> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>
>
>
> 

--~--~-~--~~~---~--~~
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: [Jmol-developers] [sage-devel] Fwd: [sage-devel] Re: Jmol andMathematics Visualization

[Bob Hanson]

Jmol 11.5.1 has

  pmesh binary "filename"

It's just experimental -- totally up to you what you want there, Robert 
-- but for now it looks like this:

http://chemapps.stolaf.edu/jmol/docs/misc/pmesh.bin

described here:

http://chemapps.stolaf.edu/jmol/docs/misc/pmesh.bin.txt

seems to work with that one file. I'm hoping you can work with this and 
see how it goes. I'm done for some time now.

Bob



Robert Bradshaw wrote:

> On Dec 29, 2007, at 9:15 PM, Robert Hanson wrote:
>
>> I'm a bit lost on this thread, but I wanted to respond to the
>> binary/multiple file issue.
>>
>> First, it's a fine idea to create a binary Pmesh file format. If we do
>> that, though, let's not rush into it and just "create a binary  
>> equivalent
>> of a Pmesh file." If this is really useful, then let's create a  
>> format that
>>
>>
>> 1) allows for multiple pmesh objects
>
>
> Sure, though if the zip file thing is working I think it is fine to  
> have one object per file too (as we also want to specify color, etc.  
> and will probably have spheres, labels, etc. too, so we'll be dealing  
> with multiple files anyway and it probably isn't worth trying to  
> figure out a way to encode this as scripts work so nice).
>
>> 2) includes a header that clearly distiguishes the file format  
>> within the
>> first 4 bytes -- the "magic number" idea.
>
>
> Yes, this is a good idea. One or two non-ascii bytes maybe (so other  
> readers can detect that it's binary data). Perhaps a flag that  
> specifies floats vs. doubles. Java already stores things in a endian- 
> consistant way, so we don't need to deal with that.
>
>> 3) allows for a simpler polygon definition -- for example, there  
>> should not
>> be the need to redundantly specify the first vertex twice, as is  
>> part of
>> the pmesh file format.
>
>
> Certainly. Other than that the format is very simple to implement,  
> and I can't think of any changes that need to be made.
>
>>
>> I recently added ZIP (JAR) file reading capability to Jmol -- no  
>> need for
>> gzip here -- we can now read a zip file directory directly if we  
>> wanted to
>> -- but that seems to me to be an unnecessary complication in this  
>> case. All
>> we really need is a new binary pmesh format.
>
>
> I often have more than just pmeshes that I want to include, and  
> presentation stuff (color, wireframe or not, etc.) is nicely kept  
> separate from the data in an easy-to-read ascii file.
>
>> Note that Jmol must be able to distinguish the file type from the  
>> initial
>> few bytes of data, not the file extension. That's the role of the  
>> header.
>>
>> I'd be very happy to write this reader; but before we do so, let's
>> brainstorm a bit on what would be optimal.
>
>
> This would be great.
>
>>
>>
>> On Fri, 28 Dec 2007 14:27:05 -0500 (EST), "Miguel"  <[EMAIL PROTECTED]> 
>> wrote:
>>
>>>
>>> zip (jar) would be better for sets of files ... although Jmol  
>>> currently
>>> doesn't have any mechanism to deal with a directory of files. That  
>>> is, it
>>> wouldn't know which of the files you wanted to *open* and what you  
>>> would
>>> want to do with the other files.
>>>
>>
>> Jmol 11.3.65 can and does read ZIP files and their directories, and  for
>> model files, if the ZIP file contains a "manifest" then specific  
>> files can
>> be read or skipped, then the directory contents may be investigated  
>> prior
>> to model loading. This capability is iterative, so zip files  
>> contained in
>> zip files contained in zip files can be read.
>
>
> This sounds perfect--where is this documented?
>
> - Robert
>


-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get. 

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900



--~--~-~--~~~---~--~~
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: [Jmol-developers] [sage-devel] Fwd: [sage-devel] Re: Jmol andMathematics Visualization

[Robert Bradshaw]

On Dec 31, 2007, at 11:09 AM, Bob Hanson wrote:

>
> Robert Bradshaw wrote:
>
>> On Dec 30, 2007, at 10:38 AM, Bob Hanson wrote:
>>
>>> Robert Bradshaw wrote:
>>>
>>
>> Yep, I think this is the way to go. You mentioned curves, arrows, and
>> ellipses. What are the commands for curves/arrows? (If the
>> documentation is clear, just point me there...) And I couldn't figure
>> out a way to get a non-axis aligned ellipsoid (or one with three
>> separate radii).
>>
> curves, arrows, lines, points (spheres), planes -- all simple DRAW
> objects. Curves and arrows may be any number of segments, which are
> connected using a Hermite. Lines are two points. Planes are three
> (triangle) or four (quadrilateral) points.

Excellent.

>>> In fact, just recently I expanded the zip file reading to ANY  
>>> file of
>>> any sort read by Jmol. For example, right now in Jmol 11.3.65 you  
>>> can
>>> give the command:
>>>
>>>   script "spt.zip|ta.spt"
>>>
>>> which runs the script "ta.spt" found in the zip file "spt.zip".
>>
>>
>> Cool. How does ta.spt refer to other files in that zip file?
>
>
> Right now there's no way to specify "in my zip file" -- but I  
> should add
> that --  so you would just specify the file name again, as for the
> script file.
>
>   pmesh "spt.zip|meshes|mesh1.pmesh"
>
> something like that.

OK. It'd be nice if the zip file were self-contained (e.g. one could  
rename and move them around freely). I'd like to be able to just load  
a zip file, and it would read MANIFEST (or some other standard file)  
to find what scripts/files inside the zip archive to load.

How does jmol deal with relative paths?

>> Just going to binary is going to do that (on both ends). The ascii
>> pmesh format is very simple and efficient to implement, with the
>> exception of the decimal conversions and having to close up the  
>> polygon.
>>
>> I would just as soon only allow one mesh per file--I'm thinking of
>> the TIFF file format that allows multiple images in a single file and
>> this greatly complicates the interface (not worried about the format,
>> the interface)--when reading a TIFF one always has to worry about
>> there being multiple images (though 99% of the time you want one) and
>> if there is more than one you have to worry about which one you want,
>> or how to show/pass two distinct images on to the user.
>>
> yes - well, zip files are fine, too, and a good binary header would
> allow jumping, but one problem is that web browsers must stream -- no
> random access!
>
>> E.g. If I did "load binary_pmesh.blah" and there were two meshes, how
>> would the script distinguish them. And if it couldn't, why not call
>> it all the same pmesh (as it doesn't have to be connected)? Or is it
>> an issue of being able to reset the vertex counters (e.g. specify
>> some vertices, then some faces, then some more vertices, then some
>> more faces, etc.)
>>
> keeping them separate allows full control over color of each,
> translucency, mesh vs. fill, etc.
> Quite possibly one-per-file and within a zip file would be the  
> best. You
> get the compression, plus binary, plus readability. So then the files
> them selves could be extraordinarily simple:
>
> PM[0x00][0x01]
> nVertices
> nPolyhedra
> a few other items
> float[] vertices.
> int[] polyhedra
>
> That would be about it.

My thoughts exactly. Not sure what "a few other items" would be, but  
for extensibility one could do

PM[0x00][0x01]
long chunk_length
byte[chunk_length] data
...
long 0 # chunk length 0 specifies beginning of data
nVertices
nPolyhedra
float[] vertices.
int[] polyhedra

>> If you think this kind of thing would be useful, than we could still
>> do it though.
>>
>>> 2) we use as much already-present Jmol functionality as possible,  
>>> not
>>> duplicating that
>>> 3) it provides what you really need, not an approximation
>>
>>
>> I think Jmol + binary pmesh + zip archives will do an excellent job.
>>
> Let's go for that. I have exactly 24 hours to implement something like
> this just so you can try it out, then I'm off to Jamaica for a month
> without a whole lot of time for anything.

Thanks! I'll be excited to try it out, and have a great vacation in  
Jamaica.

- 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: [Jmol-developers] [sage-devel] Fwd: [sage-devel] Re: Jmol andMathematics Visualization

[Bob Hanson]

Robert Bradshaw wrote:

> On Dec 30, 2007, at 10:38 AM, Bob Hanson wrote:
>
>> Robert Bradshaw wrote:
>>
>
> Yep, I think this is the way to go. You mentioned curves, arrows, and  
> ellipses. What are the commands for curves/arrows? (If the  
> documentation is clear, just point me there...) And I couldn't figure  
> out a way to get a non-axis aligned ellipsoid (or one with three  
> separate radii).
>
curves, arrows, lines, points (spheres), planes -- all simple DRAW 
objects. Curves and arrows may be any number of segments, which are 
connected using a Hermite. Lines are two points. Planes are three 
(triangle) or four (quadrilateral) points.

>
>>>
>> this sounds very much like a simple set of Jmol script + associated  
>> files.
>
>
> Yep.
>
>> In fact, just recently I expanded the zip file reading to ANY file of
>> any sort read by Jmol. For example, right now in Jmol 11.3.65 you can
>> give the command:
>>
>>   script "spt.zip|ta.spt"
>>
>> which runs the script "ta.spt" found in the zip file "spt.zip".
>
>
> Cool. How does ta.spt refer to other files in that zip file?


Right now there's no way to specify "in my zip file" -- but I should add 
that --  so you would just specify the file name again, as for the 
script file.

  pmesh "spt.zip|meshes|mesh1.pmesh"

something like that.


> Just going to binary is going to do that (on both ends). The ascii  
> pmesh format is very simple and efficient to implement, with the  
> exception of the decimal conversions and having to close up the polygon.
>
> I would just as soon only allow one mesh per file--I'm thinking of  
> the TIFF file format that allows multiple images in a single file and  
> this greatly complicates the interface (not worried about the format,  
> the interface)--when reading a TIFF one always has to worry about  
> there being multiple images (though 99% of the time you want one) and  
> if there is more than one you have to worry about which one you want,  
> or how to show/pass two distinct images on to the user.
>
yes - well, zip files are fine, too, and a good binary header would 
allow jumping, but one problem is that web browsers must stream -- no 
random access!

> E.g. If I did "load binary_pmesh.blah" and there were two meshes, how  
> would the script distinguish them. And if it couldn't, why not call  
> it all the same pmesh (as it doesn't have to be connected)? Or is it  
> an issue of being able to reset the vertex counters (e.g. specify  
> some vertices, then some faces, then some more vertices, then some  
> more faces, etc.)
>
keeping them separate allows full control over color of each, 
translucency, mesh vs. fill, etc.
Quite possibly one-per-file and within a zip file would be the best. You 
get the compression, plus binary, plus readability. So then the files 
them selves could be extraordinarily simple:

PM[0x00][0x01]
nVertices
nPolyhedra
a few other items
float[] vertices.
int[] polyhedra

That would be about it.



> If you think this kind of thing would be useful, than we could still  
> do it though.
>
>> 2) we use as much already-present Jmol functionality as possible, not
>> duplicating that
>> 3) it provides what you really need, not an approximation
>
>
> I think Jmol + binary pmesh + zip archives will do an excellent job.
>
Let's go for that. I have exactly 24 hours to implement something like 
this just so you can try it out, then I'm off to Jamaica for a month 
without a whole lot of time for anything.


> - Robert
>


-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get. 

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900



--~--~-~--~~~---~--~~
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: [Jmol-developers] [sage-devel] Fwd: [sage-devel] Re: Jmol andMathematics Visualization

[Robert Bradshaw]

On Dec 30, 2007, at 10:38 AM, Bob Hanson wrote:

> Robert Bradshaw wrote:
>
>> On Dec 29, 2007, at 9:15 PM, Robert Hanson wrote:
>>
>>> I'm a bit lost on this thread, but I wanted to respond to the
>>> binary/multiple file issue.
>>>
>>> First, it's a fine idea to create a binary Pmesh file format. If  
>>> we do
>>> that, though, let's not rush into it and just "create a binary
>>> equivalent
>>> of a Pmesh file." If this is really useful, then let's create a
>>> format that
>>>
>>>
>>> 1) allows for multiple pmesh objects
>>
>>
>> Sure, though if the zip file thing is working I think it is fine to
>> have one object per file too (as we also want to specify color, etc.
>> and will probably have spheres, labels, etc. too, so we'll be dealing
>> with multiple files anyway and it probably isn't worth trying to
>> figure out a way to encode this as scripts work so nice).
>
> Take some time to think about all the sorts of objects you will  
> want. We
> already have spheres and ellipses, planes, lines, curves, arrows, and
> labels. These are not pmesh objects, and there is absolutely no reason
> to encode them as such. It's quite possible that the current inline
> scripting of pmesh will suit your purpose quite well for surface data
> and Jmol scripting would allow you to deliver other objects such as
> these just fine.

Yep, I think this is the way to go. You mentioned curves, arrows, and  
ellipses. What are the commands for curves/arrows? (If the  
documentation is clear, just point me there...) And I couldn't figure  
out a way to get a non-axis aligned ellipsoid (or one with three  
separate radii).

>>> 2) includes a header that clearly distiguishes the file format
>>> within the
>>> first 4 bytes -- the "magic number" idea.
>>
>>
>> Yes, this is a good idea. One or two non-ascii bytes maybe (so other
>> readers can detect that it's binary data). Perhaps a flag that
>> specifies floats vs. doubles. Java already stores things in a endian-
>> consistant way, so we don't need to deal with that.
>
> If possible, I would prefer all floats -- it is going to be  
> converted to
> floats anyway, as Jmol does not deal in doubles at all.

Sure. It'll make for smaller files too.

>>> 3) allows for a simpler polygon definition -- for example, there
>>> should not
>>> be the need to redundantly specify the first vertex twice, as is
>>> part of
>>> the pmesh file format.
>>
>>
>> Certainly. Other than that the format is very simple to implement,
>> and I can't think of any changes that need to be made.
>>
>>>
>>> I recently added ZIP (JAR) file reading capability to Jmol -- no
>>> need for
>>> gzip here -- we can now read a zip file directory directly if we
>>> wanted to
>>> -- but that seems to me to be an unnecessary complication in this  
>>> case. All
>>> we really need is a new binary pmesh format.
>>
>>
>> I often have more than just pmeshes that I want to include, and
>> presentation stuff (color, wireframe or not, etc.) is nicely kept
>> separate from the data in an easy-to-read ascii file.
>>
> this sounds very much like a simple set of Jmol script + associated  
> files.

Yep.

> In fact, just recently I expanded the zip file reading to ANY file of
> any sort read by Jmol. For example, right now in Jmol 11.3.65 you can
> give the command:
>
>   script "spt.zip|ta.spt"
>
> which runs the script "ta.spt" found in the zip file "spt.zip".

Cool. How does ta.spt refer to other files in that zip file?

>>>
>>> Jmol 11.3.65 can and does read ZIP files and their directories,  
>>> and  for
>>> model files, if the ZIP file contains a "manifest" then specific
>>> files can
>>> be read or skipped, then the directory contents may be investigated
>>> prior
>>> to model loading. This capability is iterative, so zip files
>>> contained in
>>> zip files contained in zip files can be read.
>>
>>
>> This sounds perfect--where is this documented?
>>
> That reminds me, it isn't yet. It is demonstrated at
> http://chemapps.stolaf.edu/jmol/docs/examples-11/new.htm#topic61
> The manifest capability only applies to loading models, not pmesh  
> objects.

OK, I'll take a look at this.

>
> Let's keep thinking about this. We need to make sure that
>
> 1) the mechanism is efficient

Just going to binary is going to do that (on both ends). The ascii  
pmesh format is very simple and efficient to implement, with the  
exception of the decimal conversions and having to close up the polygon.

I would just as soon only allow one mesh per file--I'm thinking of  
the TIFF file format that allows multiple images in a single file and  
this greatly complicates the interface (not worried about the format,  
the interface)--when reading a TIFF one always has to worry about  
there being multiple images (though 99% of the time you want one) and  
if there is more than one you have to worry about which one you want,  
or how to show/pass two distinct images on to the user.

E.g. If I did "load binary_pmesh.blah" and there were two meshes, how

[sage-devel] Re: [Jmol-developers] [sage-devel] Fwd: [sage-devel] Re: Jmol andMathematics Visualization

[Robert Bradshaw]

On Dec 30, 2007, at 10:06 AM, Bob Hanson wrote:

> possibly, but let's talk first about what you are really interested in
> doing, then talk format. Arrays aren't necessarily the solution.

I agree here.

> Pmesh
> is not what you want for simple planes and objects -- that is for
> complex mathematical descriptions of surfaces.  Using specific  
> colorings
> and shadings sounds like Jmol scripting to me. So I think you are
> talking about a mix of objects, some of which are memory/filespace
> intensive, such as mathematical surfaces, and some of which are simple
> objects.

Yes. Scripts make it very easy to build up scenes like this. As for  
format, having a single zip file (with a MANIFEST that could specify  
a script to load, which could refer to other files in that same zip  
file by name) would probably be the best solution.

> Give us a few scenarios to work on. What would these sage-results  
> entail?

The simplest example is a 3d plot. This is perfectly represented by a  
pmesh. We might have points (spheres and/or labels) attached to this,  
more than one plot overlayed (or side-by-side), and would like to  
have axes too.

Another common object would be a (combinatorial) graph--spheres for  
nodes connected by lines.

As an aside--what is the best way to create a line (both thick, e.g.  
a cylindrical "molecular bond" although not necessarily between to  
"atoms") and a plain line (for axes, e.g. the bounding box of http:// 
pages.pomona.edu/~gk014747/teaching/Fall2007/ilkplot.gif )?

> Q: Do you ever map surface data with other data so as to color it  
> with,
> say, a scalar field?

Not yet, but could be very useful and valuable. For example, when  
trying to represent a complex-valued function in 3 dimensions, the  
magnitude can be used for the z-value and color can represent the  
argument. Or even for plain 3d plots color can be used (in addition  
to the z-value) to represent height (as in topo maps).

And I can imagine it could be useful to map arbitrary color data to a  
plot too. This is what the voxel stuff is about, right?

>
> Bob
>
> Fernando Perez wrote:
>
>> Howdy,
>>
>> On Dec 29, 2007 10:59 PM, Robert Bradshaw  
>> <[EMAIL PROTECTED]> wrote:
>>
>>
>> Just as an FYI: as of the last few days, numpy has developed a binary
>> format for arbitrary arrays.  The current plan is to have the base
>> file format (default extension .npy, but there's a magic string  
>> header
>> for extension-less identification) contain single arrays, and to use
>> zip files for multi-array files with a dict-like interface.
>>
>> It's in a branch right now, here's the format spec:
>>
>> http://projects.scipy.org/scipy/numpy/browser/branches/lib_for_io/ 
>> format.py
>>
>>
>>
> Bob
>
> -- 
> Robert M. Hanson
> Professor of Chemistry
> St. Olaf College
> Northfield, MN
> http://www.stolaf.edu/people/hansonr
>
>
> If nature does not answer first what we want,
> it is better to take what answer we get.
>
> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>
>
>
> 

--~--~-~--~~~---~--~~
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: [Jmol-developers] [sage-devel] Fwd: [sage-devel] Re: Jmol andMathematics Visualization

[Fernando Perez]

On Dec 30, 2007 11:06 AM, Bob Hanson <[EMAIL PROTECTED]> wrote:
> possibly, but let's talk first about what you are really interested in
> doing, then talk format. Arrays aren't necessarily the solution. Pmesh
> is not what you want for simple planes and objects -- that is for
> complex mathematical descriptions of surfaces.  Using specific colorings
> and shadings sounds like Jmol scripting to me. So I think you are
> talking about a mix of objects, some of which are memory/filespace
> intensive, such as mathematical surfaces, and some of which are simple
> objects.

I only mentioned it *in case* the project went down the road of
arrays, not suggesting it did.  Since Sage includes numpy and is
python based, it would soon have the support for writing this format
built in (as it is now part of numpy itself).  *If* it were to be a
reasonable fit, I mentioned it to prevent possible duplication of
work: this has been done only in a branch and on the numpy-dev list,
so it would be easy for the sage developers to miss it.

I'm not a sage developer (I come from the numpy/scipy end of things)
and have only followed the jmol discussion tangentially.  It may very
well be that an array-based format is not the solution for this
problem, and in that case just ignore the comments.

Cheers,

f

--~--~-~--~~~---~--~~
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: [Jmol-developers] [sage-devel] Fwd: [sage-devel] Re: Jmol andMathematics Visualization

[Bob Hanson]

Robert Bradshaw wrote:

> On Dec 29, 2007, at 9:15 PM, Robert Hanson wrote:
>
>> I'm a bit lost on this thread, but I wanted to respond to the
>> binary/multiple file issue.
>>
>> First, it's a fine idea to create a binary Pmesh file format. If we do
>> that, though, let's not rush into it and just "create a binary  
>> equivalent
>> of a Pmesh file." If this is really useful, then let's create a  
>> format that
>>
>>
>> 1) allows for multiple pmesh objects
>
>
> Sure, though if the zip file thing is working I think it is fine to  
> have one object per file too (as we also want to specify color, etc.  
> and will probably have spheres, labels, etc. too, so we'll be dealing  
> with multiple files anyway and it probably isn't worth trying to  
> figure out a way to encode this as scripts work so nice).

Take some time to think about all the sorts of objects you will want. We 
already have spheres and ellipses, planes, lines, curves, arrows, and 
labels. These are not pmesh objects, and there is absolutely no reason 
to encode them as such. It's quite possible that the current inline 
scripting of pmesh will suit your purpose quite well for surface data 
and Jmol scripting would allow you to deliver other objects such as 
these just fine.

>
>> 2) includes a header that clearly distiguishes the file format  
>> within the
>> first 4 bytes -- the "magic number" idea.
>
>
> Yes, this is a good idea. One or two non-ascii bytes maybe (so other  
> readers can detect that it's binary data). Perhaps a flag that  
> specifies floats vs. doubles. Java already stores things in a endian- 
> consistant way, so we don't need to deal with that.

If possible, I would prefer all floats -- it is going to be converted to 
floats anyway, as Jmol does not deal in doubles at all.

>
>> 3) allows for a simpler polygon definition -- for example, there  
>> should not
>> be the need to redundantly specify the first vertex twice, as is  
>> part of
>> the pmesh file format.
>
>
> Certainly. Other than that the format is very simple to implement,  
> and I can't think of any changes that need to be made.
>
>>
>> I recently added ZIP (JAR) file reading capability to Jmol -- no  
>> need for
>> gzip here -- we can now read a zip file directory directly if we  
>> wanted to
>> -- but that seems to me to be an unnecessary complication in this  
>> case. All
>> we really need is a new binary pmesh format.
>
>
> I often have more than just pmeshes that I want to include, and  
> presentation stuff (color, wireframe or not, etc.) is nicely kept  
> separate from the data in an easy-to-read ascii file.
>
this sounds very much like a simple set of Jmol script + associated files.

In fact, just recently I expanded the zip file reading to ANY file of 
any sort read by Jmol. For example, right now in Jmol 11.3.65 you can 
give the command:

  script "spt.zip|ta.spt"

which runs the script "ta.spt" found in the zip file "spt.zip".

>> Note that Jmol must be able to distinguish the file type from the  
>> initial
>> few bytes of data, not the file extension. That's the role of the  
>> header.
>>
>> I'd be very happy to write this reader; but before we do so, let's
>> brainstorm a bit on what would be optimal.
>
>
> This would be great.
>
>>
>>
>> On Fri, 28 Dec 2007 14:27:05 -0500 (EST), "Miguel"  <[EMAIL PROTECTED]> 
>> wrote:
>>
>>>
>>> zip (jar) would be better for sets of files ... although Jmol  
>>> currently
>>> doesn't have any mechanism to deal with a directory of files. That  
>>> is, it
>>> wouldn't know which of the files you wanted to *open* and what you  
>>> would
>>> want to do with the other files.
>>>
>>
>> Jmol 11.3.65 can and does read ZIP files and their directories, and  for
>> model files, if the ZIP file contains a "manifest" then specific  
>> files can
>> be read or skipped, then the directory contents may be investigated  
>> prior
>> to model loading. This capability is iterative, so zip files  
>> contained in
>> zip files contained in zip files can be read.
>
>
> This sounds perfect--where is this documented?
>
That reminds me, it isn't yet. It is demonstrated at 
http://chemapps.stolaf.edu/jmol/docs/examples-11/new.htm#topic61
The manifest capability only applies to loading models, not pmesh objects.

Let's keep thinking about this. We need to make sure that

1) the mechanism is efficient
2) we use as much already-present Jmol functionality as possible, not 
duplicating that
3) it provides what you really need, not an approximation

--Bob

-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get. 

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900



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

[sage-devel] Re: [Jmol-developers] [sage-devel] Fwd: [sage-devel] Re: Jmol andMathematics Visualization

[Bob Hanson]

possibly, but let's talk first about what you are really interested in 
doing, then talk format. Arrays aren't necessarily the solution. Pmesh 
is not what you want for simple planes and objects -- that is for 
complex mathematical descriptions of surfaces.  Using specific colorings 
and shadings sounds like Jmol scripting to me. So I think you are 
talking about a mix of objects, some of which are memory/filespace 
intensive, such as mathematical surfaces, and some of which are simple 
objects.

Give us a few scenarios to work on. What would these sage-results entail?

Q: Do you ever map surface data with other data so as to color it with, 
say, a scalar field?

Bob

Fernando Perez wrote:

>Howdy,
>
>On Dec 29, 2007 10:59 PM, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
>  
>
>Just as an FYI: as of the last few days, numpy has developed a binary
>format for arbitrary arrays.  The current plan is to have the base
>file format (default extension .npy, but there's a magic string header
>for extension-less identification) contain single arrays, and to use
>zip files for multi-array files with a dict-like interface.
>
>It's in a branch right now, here's the format spec:
>
>http://projects.scipy.org/scipy/numpy/browser/branches/lib_for_io/format.py
>
>  
>
Bob

-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get. 

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900



--~--~-~--~~~---~--~~
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: [Jmol-developers] [sage-devel] Fwd: [sage-devel] Re: Jmol andMathematics Visualization

[Fernando Perez]

Howdy,

On Dec 29, 2007 10:59 PM, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
>
> On Dec 29, 2007, at 9:15 PM, Robert Hanson wrote:
>
> > I'm a bit lost on this thread, but I wanted to respond to the
> > binary/multiple file issue.
> >
> > First, it's a fine idea to create a binary Pmesh file format. If we do
> > that, though, let's not rush into it and just "create a binary
> > equivalent
> > of a Pmesh file." If this is really useful, then let's create a
> > format that
> >
> >
> > 1) allows for multiple pmesh objects
>
> Sure, though if the zip file thing is working I think it is fine to
> have one object per file too (as we also want to specify color, etc.
> and will probably have spheres, labels, etc. too, so we'll be dealing
> with multiple files anyway and it probably isn't worth trying to
> figure out a way to encode this as scripts work so nice).
>
> > 2) includes a header that clearly distiguishes the file format
> > within the
> > first 4 bytes -- the "magic number" idea.

[...]

Just as an FYI: as of the last few days, numpy has developed a binary
format for arbitrary arrays.  The current plan is to have the base
file format (default extension .npy, but there's a magic string header
for extension-less identification) contain single arrays, and to use
zip files for multi-array files with a dict-like interface.

It's in a branch right now, here's the format spec:

http://projects.scipy.org/scipy/numpy/browser/branches/lib_for_io/format.py

That branch has the rest of the i/o utilities.

I have no idea if this format might suit your needs, but if it does,
it might be a useful way to share data with the rest of the python
world (for example, arrays in this format can be automatically used in
VTK with the Enthought TVTK library).

Below I'll paste the full PEP that Robert Kern wrote for the file
format when the discussion was taking place.

Sorry for the noise if this proves to be non-useful.

f

 PEP-style document for the array format.

Title: A Simple File Format for NumPy Arrays
Discussions-To: [EMAIL PROTECTED]
Version: $Revision$
Last-Modified: $Date$
Author: Robert Kern <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Content-Type: text/plain
Created: 20-Dec-2007


Abstract

   We propose a standard binary file format (NPY) for persisting
   a single arbitrary NumPy array on disk.  The format stores all of
   the shape and dtype information necessary to reconstruct the array
   correctly even on another machine with a different architecture.
   The format is designed to be as simple as possible while achieving
   its limited goals.  The implementation is intended to be pure
   Python and distributed as part of the main numpy package.


Rationale

   A lightweight, omnipresent system for saving NumPy arrays to disk
   is a frequent need.  Python in general has pickle [1] for saving
   most Python objects to disk.  This often works well enough with
   NumPy arrays for many purposes, but it has a few drawbacks:

   - Dumping or loading a pickle file require the duplication of the
 data in memory.  For large arrays, this can be a showstopper.

   - The array data is not directly accessible through
 memory-mapping.  Now that numpy has that capability, it has
 proved very useful for loading large amounts of data (or more to
 the point: avoiding loading large amounts of data when you only
 need a small part).

   Both of these problems can be addressed by dumping the raw bytes
   to disk using ndarray.tofile() and numpy.fromfile().  However,
   these have their own problems:

   - The data which is written has no information about the shape or
 dtype of the array.

   - It is incapable of handling object arrays.

   The NPY file format is an evolutionary advance over these two
   approaches.  Its design is mostly limited to solving the problems
   with pickles and tofile()/fromfile().  It does not intend to solve
   more complicated problems for which more complicated formats like
   HDF5 [2] are a better solution.


Use Cases

   - Neville Newbie has just started to pick up Python and NumPy.  He
 has not installed many packages, yet, nor learned the standard
 library, but he has been playing with NumPy at the interactive
 prompt to do small tasks.  He gets a result that he wants to
 save.

   - Annie Analyst has been using large nested record arrays to
 represent her statistical data.  She wants to convince her
 R-using colleague, David Doubter, that Python and NumPy are
 awesome by sending him her analysis code and data.  She needs
 the data to load at interactive speeds.  Since David does not
 use Python usually, needing to install large packages would turn
 him off.

   - Simon Seismologist is developing new seismic processing tools.
 One of his algorithms requires large amounts of intermediate
 data to be written to disk.  The data does not really fit into
 the industry-standard SEG-Y schema, but he a

[sage-devel] Re: [Jmol-developers] [sage-devel] Fwd: [sage-devel] Re: Jmol andMathematics Visualization

[Robert Bradshaw]

On Dec 29, 2007, at 9:15 PM, Robert Hanson wrote:

> I'm a bit lost on this thread, but I wanted to respond to the
> binary/multiple file issue.
>
> First, it's a fine idea to create a binary Pmesh file format. If we do
> that, though, let's not rush into it and just "create a binary  
> equivalent
> of a Pmesh file." If this is really useful, then let's create a  
> format that
>
>
> 1) allows for multiple pmesh objects

Sure, though if the zip file thing is working I think it is fine to  
have one object per file too (as we also want to specify color, etc.  
and will probably have spheres, labels, etc. too, so we'll be dealing  
with multiple files anyway and it probably isn't worth trying to  
figure out a way to encode this as scripts work so nice).

> 2) includes a header that clearly distiguishes the file format  
> within the
> first 4 bytes -- the "magic number" idea.

Yes, this is a good idea. One or two non-ascii bytes maybe (so other  
readers can detect that it's binary data). Perhaps a flag that  
specifies floats vs. doubles. Java already stores things in a endian- 
consistant way, so we don't need to deal with that.

> 3) allows for a simpler polygon definition -- for example, there  
> should not
> be the need to redundantly specify the first vertex twice, as is  
> part of
> the pmesh file format.

Certainly. Other than that the format is very simple to implement,  
and I can't think of any changes that need to be made.

>
> I recently added ZIP (JAR) file reading capability to Jmol -- no  
> need for
> gzip here -- we can now read a zip file directory directly if we  
> wanted to
> -- but that seems to me to be an unnecessary complication in this  
> case. All
> we really need is a new binary pmesh format.

I often have more than just pmeshes that I want to include, and  
presentation stuff (color, wireframe or not, etc.) is nicely kept  
separate from the data in an easy-to-read ascii file.

> Note that Jmol must be able to distinguish the file type from the  
> initial
> few bytes of data, not the file extension. That's the role of the  
> header.
>
> I'd be very happy to write this reader; but before we do so, let's
> brainstorm a bit on what would be optimal.

This would be great.

>
>
> On Fri, 28 Dec 2007 14:27:05 -0500 (EST), "Miguel"  
> <[EMAIL PROTECTED]> wrote:
>>
>> zip (jar) would be better for sets of files ... although Jmol  
>> currently
>> doesn't have any mechanism to deal with a directory of files. That  
>> is, it
>> wouldn't know which of the files you wanted to *open* and what you  
>> would
>> want to do with the other files.
>>
>
> Jmol 11.3.65 can and does read ZIP files and their directories, and  
> for
> model files, if the ZIP file contains a "manifest" then specific  
> files can
> be read or skipped, then the directory contents may be investigated  
> prior
> to model loading. This capability is iterative, so zip files  
> contained in
> zip files contained in zip files can be read.

This sounds perfect--where is this documented?

- 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: [Jmol-developers] [sage-devel] Fwd: [sage-devel] Re: Jmol andMathematics Visualization

[Robert Hanson]

I'm a bit lost on this thread, but I wanted to respond to the
binary/multiple file issue. 

First, it's a fine idea to create a binary Pmesh file format. If we do
that, though, let's not rush into it and just "create a binary equivalent
of a Pmesh file." If this is really useful, then let's create a format that


1) allows for multiple pmesh objects
2) includes a header that clearly distiguishes the file format within the
first 4 bytes -- the "magic number" idea.
3) allows for a simpler polygon definition -- for example, there should not
be the need to redundantly specify the first vertex twice, as is part of
the pmesh file format. 

I recently added ZIP (JAR) file reading capability to Jmol -- no need for
gzip here -- we can now read a zip file directory directly if we wanted to
-- but that seems to me to be an unnecessary complication in this case. All
we really need is a new binary pmesh format. 

Note that Jmol must be able to distinguish the file type from the initial
few bytes of data, not the file extension. That's the role of the header. 

I'd be very happy to write this reader; but before we do so, let's
brainstorm a bit on what would be optimal. 


On Fri, 28 Dec 2007 14:27:05 -0500 (EST), "Miguel" <[EMAIL PROTECTED]> wrote:
> 
> zip (jar) would be better for sets of files ... although Jmol currently
> doesn't have any mechanism to deal with a directory of files. That is, it
> wouldn't know which of the files you wanted to *open* and what you would
> want to do with the other files.
> 

Jmol 11.3.65 can and does read ZIP files and their directories, and for
model files, if the ZIP file contains a "manifest" then specific files can
be read or skipped, then the directory contents may be investigated prior
to model loading. This capability is iterative, so zip files contained in
zip files contained in zip files can be read.

Bob




--~--~-~--~~~---~--~~
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: [sage-newbie] Integer points on Elliptic Curves

[William Stein]

- William

(Sent from my iPhone.)

Begin forwarded message:

> From: bill purvis <[EMAIL PROTECTED]>
> Date: December 17, 2007 3:05:25 PM MST
> To: sage-newbie <[EMAIL PROTECTED]>
> Subject: [sage-newbie] Integer points on Elliptic Curves
> Reply-To: [EMAIL PROTECTED]
>

>
> Anyone have any useful sage code to locate integer points on elliptic
> curves? I wrote a very crude C program that simply searches over x  
> and y
> evaluating the LHS and RHS looking for a match, but that's crude and  
> only
> searches a limited range of X/Y. I've not seen any published  
> algorithms
> for this, but my experience is still pretty small. Any non-sage
> algortihms would also be of interest and I might try my hand at
> converting them to sage if there's nothing already available.
>
> Bill
> -- 
> +---+
> | Bill Purvis, Amateur Mathematician|
> |  email: [EMAIL PROTECTED]  |
> |  http://bil.members.beeb.net  |
> +---+
>
> >

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

[sage-devel] Fwd: sage

[William Stein]

-- Forwarded message --
From: Mario Natiello <
Date: Dec 14, 2007 1:38 AM
Subject: sage
To: [EMAIL PROTECTED]


Hallo,

> If you happen to have just read straight through
> this tutorial, and have some sense of how long
> it took you, please let me know
Hi. I browsed the tutorial in about 1 hour. But
I'm still an ignorant beginner. I'm positively
impressed about sage's functionality and very
happy to have discovered its existence. Thanks.

Yours,

M. Natiello

--
Professor in Applied Mathematics
Centre for Mathematical Sciences, Lund University
Box 118, S-221 00 LUND, SWEDEN
http://www.maths.lth.se/~mario



-- 
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] Fwd: SAGE

[William Stein]

-- Forwarded message --
From: Selim Tuncel <[EMAIL PROTECTED]>
Date: Dec 11, 2007 10:37 AM
Subject: SAGE
To: William Stein <[EMAIL PROTECTED]>


William,

The story about SAGE is now on the UW main page:
http://www.washington.edu/

Selim




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