วันพุธที่ 31 สิงหาคม พ.ศ. 2554

[sage-devel] Trac #11401 (magma interface vs. newlines) has a fix

Just a ping that http://trac.sagemath.org/sage_trac/ticket/11401 now
has a proper fix and explanation on it. It was already marked "needs
review" with a poor, symptomatic fix. The new one solves the heart of
the problem, I hope. So if someone feels up to reviewing it ... In
principle it could affect other optional interfaces I don't have
access to, so it would be good to test those as well.

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

[sage-devel] Free Software Supporter

Free Software Supporter, the Free Software Foundation's monthly news
digest and action update.

Encourage your friends to subscribe and help us build an audience by

* Subscribe: http://www.fsf.org/free-software-supporter
* Widget: http://www.fsf.org/associate/widget

Miss an issue? You can catch up on back issues at http://www.fsf.org/free-software-supporter
.

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

Re: [sage-devel] status on lion and xcode 4

Thanks for the quick response. That sounds exiting! So with a bit of luck the problems with building Maxima will be solved somewhere in the near future.

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

[sage-devel] help needed with making FreeModule_generic_pid work with generic pid's

Dear All,

At http://trac.sagemath.org/sage_trac/ticket/11751 I try to fix some problems with FreeModule_generic. I've put a patch up there wich makes the code work wich I want to work (only very small changes where needed, since it is just fixing some bugs in the code wich is already there). The only problem is that the my changes make other doctests not work. I've been trying to find the source of the problem for some time now but fail miserably. I hope there is someone here willing to help me out.

The main goal why I want that ticket to work is to finally get the function fields code into sage. For that we need to do calculation in free modules over univariate polynomial rings over fields. The patch there makes this possible (as shown in the description) of the patch.

BTW, sorry for the large ammount of messages from me lately, but I just want to do a lot of sage stuff before college starts again.

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

Re: [sage-devel] status on lion and xcode 4

On Wed, Aug 31, 2011 at 7:10 PM, Maarten Derickx
<m.derickx.student@gmail.com> wrote:
> On sage support there was a question on building sage on lion and using
> xcode 4. So I was wondering is there any news in this area?

The main thing holding it back right now were problems building
boehm_gc and ECL, but both have been fixed in (unreleased) upstream
versions of the libraries. sqrt5.cs.washington.edu has been
unresponsive so I have not been able to test ECL and Maxima yet.

--Mike

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

[sage-devel] status on lion and xcode 4

On sage support there was a question on building sage on lion and using xcode 4. So I was wondering is there any news in this area?

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

[sage-devel] Re: imposing limits on rank in matrix generators, e.g. in random_matrix

On Aug 31, 12:05 am, Dima Pasechnik <dimp...@gmail.com> wrote:
> On a second thought, I just fix the error message, make it less cryptic, by
> throwing an exception explicitly.

I don't see a ticket yet - please cc me when you make one. The
"second thought" sounds like a good improvement.

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

[sage-devel] Re: global namespace

Hi Martin, Paul and William,

On 31 Aug., 19:46, William Stein <wst...@gmail.com> wrote:
> Random Thoughts:  Since we banned using "is_MPolynomial", and we do
> have Polynomial in the global namespace, I can't see an alternative to
> having MPolynomial.  That said, it's perhaps bad that we have
> Polynomial in the global namespace.

I wouldn't mind to remove Polynomial from the global name space, since
it is hardly useful and may actually be confusing (polynomials ought
to be created differently), as William has pointed out.

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

[sage-devel] Purple

It seems the icons on the main page as well as the favicon were
changed from blue to purple. Why is this? I think it looked better
before; now it looks somewhat washed-out.

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

Re: [sage-devel] Re: MATLAB: viable alternative...?

On Wed, Aug 31, 2011 at 10:41 AM, Maarten Derickx
<m.derickx.student@gmail.com> wrote:
> Sorry, don't have acces to matlab, maybe I should have stayed out of this
> discussion and forget my prejudice about matlab.

No worries! I've been hanging out on sage-flame too much recently, so
I'm sorry that my response was so inappropriate.

By the way, try typing "matlab" on sage.math.washington.edu.

-- William

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

--
William Stein
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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] global namespace

On Wed, Aug 31, 2011 at 9:43 AM, Martin Albrecht
> Hi,
>
> at
>
>    http://trac.sagemath.org/sage_trac/ticket/11764
>
> Paul Zimmermann writes:
>
> """
> for univariate polynomials we have the class Polynomial:
>
> sage: R.<x> = QQ[]
> sage: isinstance(x+1, Polynomial)
> True
> However for multivariate polynomials we have to write:
>
> sage: R.<x,y> = QQ[]
> sage: isinstance(x+y, sage.rings.polynomial.multi_polynomial.MPolynomial)
> True
> I suggest MPolynomial is defined as an alias for
> sage.rings.polynomial.multi_polynomial.MPolynomial so that we can
> simply write:
>
> sage: R.<x,y> = QQ[]
> sage: isinstance(x+y, MPolynomial)
> True
> """
>
> I suggested this needs a discussion on [sage-devel] because it's about
> adding *more* stuff to the global namespace, while we try to keep that
> to a minimum.

Random Thoughts: Since we banned using "is_MPolynomial", and we do
have Polynomial in the global namespace, I can't see an alternative to
having MPolynomial. That said, it's perhaps bad that we have
Polynomial in the global namespace. I wonder how many people have
done:

sage: Polynomial(2)
boom!
sage: Polynomial([1,2,3])
boom!
sage: Polynomial(QQ,[1,2,3])
boom!
sage: Polynomial?
pages, with nothing about how to make a polynomial using "the
Polynomial command"...

-- William

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

Re: [sage-devel] Re: MATLAB: viable alternative...?

Sorry, don't have acces to matlab, maybe I should have stayed out of this discussion and forget my prejudice about 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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: MATLAB: viable alternative...?

On Wed, Aug 31, 2011 at 10:20 AM, Maarten Derickx
<m.derickx.student@gmail.com> wrote:
> There was one very concrete thing that I found out recently that would
> probably have set me off if I was a matlab user trying to switch to sage.
> sage: (-2.0)^(1/3)
> 0.629960524947437 + 1.09112363597172*I

(1) If I remember correctly, things are this way because Paul
Zimmerman was "set off" by the above returning a real root, which it
used to do (the default in Maxima, by the way). He had some very good
consistency reasons for preferring the complex branch by default.

(2) Just out of curiosity, did you even *try* the above in Matlab!?
You might be surprised to find that it returns the same thing as Sage!

< M A T L A B >
Version 7.2.0.283 (R2006a)
January 27, 2006

To get started, type one of these: helpwin, helpdesk, or demo.
For product information, visit www.mathworks.com.

>> (-2.0)^(1/3)

ans =

0.6300 + 1.0911i

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

--
William Stein
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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: MATLAB: viable alternative...?

There was one very concrete thing that I found out recently that would probably have set me off if I was a matlab user trying to switch to sage.

sage: (-2.0)^(1/3)
0.629960524947437 + 1.09112363597172*I

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

[sage-devel] global namespace

Hi,

at

Paul Zimmermann writes:

"""
for univariate polynomials we have the class Polynomial:

sage: R.<x> = QQ[]
sage: isinstance(x+1, Polynomial)
True
However for multivariate polynomials we have to write:

sage: R.<x,y> = QQ[]
sage: isinstance(x+y, sage.rings.polynomial.multi_polynomial.MPolynomial)
True
I suggest MPolynomial is defined as an alias for
sage.rings.polynomial.multi_polynomial.MPolynomial so that we can
simply write:

sage: R.<x,y> = QQ[]
sage: isinstance(x+y, MPolynomial)
True
"""

I suggested this needs a discussion on [sage-devel] because it's about
adding *more* stuff to the global namespace, while we try to keep that
to a minimum.

Thoughts?
Martin

--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
_www: http://www.informatik.uni-bremen.de/~malb
_jab: martinralbrecht@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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: MATLAB: viable alternative...?

-I have used MATLAB for 10 years in my research
-About 3 years ago, I mostly switched to Python+numpy/scipy/
matplotlib, and I lead a project that includes about a dozen people
developing code in Python
-I use SAGE (mainly the notebook) in my teaching.

For most MATLAB users, I think SAGE adds little or nothing to what
numpy/scipy/matplotlib already offer. Indeed, it tends to complicate
things because of the preprocessing and potential conflict of
namespaces (you can get around these, but they are potential pitfalls
for a beginner). As for using native SAGE functions and objects, the
fact that I must set up a ring or field before I create a matrix
feature I use SAGE for is the notebook, and I generally put %python at
the top of each worksheet. One other thing I've experimented with is
software that will compute exactly or in floating point, depending on
the nature of the input. In the end I went with Sympy rather than
SAGE for the exact computations

I think numpy and matplotlib are good replacements for the
corresponding parts of MATLAB. But many parts of Scipy are, in my
of the many good numerical libraries with Python interfaces (e.g.
IPopt, PETSc). I think the advantage of all of these wrappers (and
the ease of creating your own wrappers) is beginning to overtake
MATLAB's toolboxes in usefulness, but the catch is that you have to
know a bit more to use them since they're not all designed by a single
commercial entity. In my case, interfaces to these packages in some
cases represent "killer features" of Python that would prevent me from
PETSc is a prime example, since I regularly compute on tens of
thousands of cores at a time (how much would 20,000 MATLAB licenses
set you back?) And I maintain that development of larger object-
oriented code bases is much more manageable in Python than in MATLAB.

A final consideration: on some platforms it can still be challenging
for novices to install numpy, matplotlib, and scipy. SAGE is a
convenient way to get them. So is Enthought's Python Distribution

-David

On Aug 15, 10:58 pm, William Stein <wst...@gmail.com> wrote:
> Hi,
>
> If somebody walked up to *you* and asked: "Is Sage now a viable
> alternative toMATLAB?" what would you say?
> I'm especially interested in what people who do numerical/applied
> computation think.
>
> My answer: "It's very difficult for *me* to answer this question
> myself, becauseMATLABis useless for most of my own
> teaching/research/work, but I realize it is very widely used in
> applied mathematics.   Based on going to Scipy and the resources I've
> seen online, it appears that the Numpy/Scipy stack is extremely useful
> to actual people doing numerical computation.      Maybe I'll try
>
> [NOTE:  I am interested in people's answers, rather than somebody
> hijacking this thread to try to define "viable alternative" or say
> this isn't a scientific survey or something.  Please try not to hijack
>
>  -- William
>
> --
> William Stein
> Professor of Mathematics
> University of Washingtonhttp://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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: imposing limits on rank in matrix generators, e.g. in random_matrix

On a second thought, I just fix the error message, make it less cryptic, by throwing an exception explicitly.
Sorry for noise.

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

วันอังคารที่ 30 สิงหาคม พ.ศ. 2554

[sage-devel] imposing limits on rank in matrix generators, e.g. in random_matrix

random_matrix(QQ, 3, 3, algorithm='echelonizable', rank=4, upper_bound=60)
currently causes:
ValueError: number of pivots cannot exceed the number of rows or columns.

I would like to propose inserting an obvious check on rank in such functions,
resetting it, if necessary, to the min(ncols,nrows,rank).

That's a change in behaviour, so it might potentially break some user code...

Any thoughts on this? Is there a way to do it gracefully, via a deprecating or so?

Dima

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

[sage-devel] Re: Writing a piece about import in the developers guide.

On 31 Aug., 04:15, leif <not.rea...@online.de> wrote:
> On 31 Aug., 03:21, Benjamin Jones <benjaminfjo...@gmail.com> wrote:
> > Are there any tools for automating the process of finding out which imports
> > aren't used in a large module?
>
> See for examplehttp://trac.sagemath.org/sage_trac/ticket/11749(h/t
> Robert B.).

P.S.:

I've written a crude shell script which patches arbitrary Cython-
generated C/C++ code to print when a Cython module gets imported /
initialized, actually for debugging something else, but this can also
be used to see the order in which Cython modules get imported.
(Doesn't [yet] show when Python modules get imported though.)

-leif

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

[sage-devel] Re: Writing a piece about import in the developers guide.

On 31 Aug., 03:21, Benjamin Jones <benjaminfjo...@gmail.com> wrote:
> On Wed, Aug 31, 2011 at 1:09 AM, Volker Braun <vbraun.n...@gmail.com> wrote:
> > +1 for any tool to reduce/simplify the number of imports. Everybody adds
> > imports if something is missing, but nobody takes out imports after
> > rewriting a module. Its not hard to find unused imports, as a random example
> > sage/rings/polynomial/polynomial_rational_flint.pyx imports is_Polynomial
> > but doesn't use it. But without manually searching around in the source code
> > its hard to find which imports are seldomly-used and hence good candidates
> > to move function/methods.
>
> Are there any tools for automating the process of finding out which imports
> aren't used in a large module?

See for example http://trac.sagemath.org/sage_trac/ticket/11749 (h/t
Robert B.).

-leif

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

[sage-devel] Re: Trac: No space left on device

On 31 Aug., 02:50, William Stein <wst...@gmail.com> wrote:
> Hi,
>
> This should be fixed now.
>
> There will be some *.sagenb.org downtime sometime in the next two days
> though to make it far more unlikely for something like this to happen
> again...

leif@boxen:~$quota The program 'quota' is currently not installed. To run 'quota' please ask your administrator to install the package 'quota' -bash: quota: command not found leif@boxen:~$ ls /sbin/*quota* /usr/sbin/*quota*
ls: cannot access /sbin/*quota*: No such file or directory
ls: cannot access /usr/sbin/*quota*: No such file or directory

;-)

-leif

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

[sage-devel] marketing signs, posters, etc.

Just to follow up on my threads from several weeks ago, I've posted the
sources for all of the marketing material that I revised and printed for
mathfest here:

http://sage.math.washington.edu/home/jason/marketing/

In particular, you might be interested in:

http://sage.math.washington.edu/home/jason/marketing/sage-quarter-page.pdf

http://sage.math.washington.edu/home/jason/marketing/letter-size-sage-expanded-poster.pdf

http://sage.math.washington.edu/home/jason/marketing/legal-size-sage-poster.pdf

Other things are variations on these or material that has been posted
and used previously, but just copied into this directory for my convenience.

I know there are some great suggestions from the previous thread that
didn't make it into these versions. Hopefully we'll revise things again
before the Joint Meetings.

Thanks,

Jason

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

Re: [sage-devel] Writing a piece about import in the developers guide.

On Wed, Aug 31, 2011 at 1:09 AM, Volker Braun wrote:
+1 for any tool to reduce/simplify the number of imports. Everybody adds imports if something is missing, but nobody takes out imports after rewriting a module. Its not hard to find unused imports, as a random example sage/rings/polynomial/polynomial_rational_flint.pyx imports is_Polynomial but doesn't use it. But without manually searching around in the source code its hard to find which imports are seldomly-used and hence good candidates to move function/methods.

Are there any tools for automating the process of finding out which imports aren't used in a large module?

--
Benjamin Jones

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

Re: [sage-devel] Writing a piece about import in the developers guide.

+1 for any tool to reduce/simplify the number of imports. Everybody adds imports if something is missing, but nobody takes out imports after rewriting a module. Its not hard to find unused imports, as a random example sage/rings/polynomial/polynomial_rational_flint.pyx imports is_Polynomial but doesn't use it. But without manually searching around in the source code its hard to find which imports are seldomly-used and hence good candidates to move function/methods.

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

Re: [sage-devel] Re: Trac: No space left on device

Hi,

This should be fixed now.

There will be some *.sagenb.org downtime sometime in the next two days
though to make it far more unlikely for something like this to happen
again...

William

On Tue, Aug 30, 2011 at 3:59 PM, leif <not.really@online.de> wrote:
> On 31 Aug., 00:26, leif <not.rea...@online.de> wrote:
>> Getting worse:
>>
>> ==========================================================
>> Oops…
>>
>> Trac detected an internal error:
>> ProgrammingError: could not write to hash-join temporary file: No
>> space left on device
>> There was an internal error in Trac. It is recommended that you inform
>> your local Trac administrator and give him all the information he
>> needs to reproduce the issue.
>>
>> To that end, you could create a ticket.
>>
>> The action that triggered the error was:
>>
>> GET: /ticket/11686
>> ==========================================================
>
>
> leif@boxen:~$df > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/sda1 71117180 67531708 1376 100% / > varrun 66146796 348 66146448 1% /var/run > varlock 66146796 0 66146796 0% /var/lock > udev 66146796 72 66146724 1% /dev > devshm 66146796 44 66146752 1% /dev/shm > /dev/sdc1 1938113040 1788464212 51973632 98% /padic > /dev/sdd1 1938113040 16558904 1823878940 1% /mazur > tmpfs 16777216 102524 16674692 1% /tmp > sage:/mnt/home/ 3875897344 3133476864 547086336 86% /home > > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com > For more options, visit this group at http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- William Stein 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org [sage-devel] Re: Problem install graphviz because of duplicate entry in libpng12.pc On 25 Aug., 15:04, leif <not.rea...@online.de> wrote: > On 22 Aug., 14:07, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote: > > > On 2011-08-22 00:38, MartinX wrote: > > > > Graphviz would not install as pkg-config was not reading the > > > pangocairo.pc in the grphviz configure file in the sage environment so > > > it was not setting the includes correctly. Cause is a duplication of > > > SAGE_ROOT definition in sage's local libpng12.pc. This problem with > > > the libpng.pc file also featured in ticket #11686 on matplotlib. > > > With which version of Sage is this? > > This is not specific to (or originally caused by) the libpng spkg > itself, but happens since the "fix exactly once" logic w.r.t. pkg- > config files is currently broken. > > Reinstalling the libpng spkg also fixes the duplicate definition of > SAGE_ROOT in libpng.pc (which is a symbolic link to libpng12.pc), at > least until the Sage installation gets moved again. I've opened a 4.7.2 blocker ticket [1] for this issue, i.e. for avoiding the creation of duplicate definitions in .pc files. There's no patch to review yet, but atm trac doesn't work anyway. -leif [1] #11760: 'sage-location' shouldn't "initialize" .pc (pkg-config) files more than once http://trac.sagemath.org/sage_trac/ticket/11760 -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org [sage-devel] Re: Trac: No space left on device On 31 Aug., 00:26, leif <not.rea...@online.de> wrote: > Getting worse: > > ========================================================== > Oops… > > Trac detected an internal error: > ProgrammingError: could not write to hash-join temporary file: No > space left on device > There was an internal error in Trac. It is recommended that you inform > your local Trac administrator and give him all the information he > needs to reproduce the issue. > > To that end, you could create a ticket. > > The action that triggered the error was: > > GET: /ticket/11686 > ========================================================== leif@boxen:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 71117180 67531708 1376 100% /
varrun 66146796 348 66146448 1% /var/run
varlock 66146796 0 66146796 0% /var/lock
udev 66146796 72 66146724 1% /dev
devshm 66146796 44 66146752 1% /dev/shm
/dev/sdc1 1938113040 1788464212 51973632 98% /padic
/dev/sdd1 1938113040 16558904 1823878940 1% /mazur
tmpfs 16777216 102524 16674692 1% /tmp
sage:/mnt/home/ 3875897344 3133476864 547086336 86% /home

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

[sage-devel] Re: Trac: No space left on device

Getting worse:

==========================================================
Oops…

Trac detected an internal error:
ProgrammingError: could not write to hash-join temporary file: No
space left on device
There was an internal error in Trac. It is recommended that you inform
needs to reproduce the issue.

To that end, you could create a ticket.

The action that triggered the error was:

GET: /ticket/11686
==========================================================

-leif

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

[sage-devel] Re: Trac: No space left on device (where the attachments are stored)

On 30 Aug., 22:25, leif <not.rea...@online.de> wrote:
> As the subject says.
>
> I even cannot attach a 5 KB file.

P.S.: This also seems to stop trac notifications again.

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

[sage-devel] Trac: No space left on device (where the attachments are stored)

As the subject says.

I even cannot attach a 5 KB file.

==========================================================
Oops…
Trac detected an internal error:
IOError: [Errno 28] No space left on device
There was an internal error in Trac. It is recommended that you inform
your local Trac administrator and give him all the information he needs
to reproduce the issue.

To that end, you could create a ticket.

The action that triggered the error was:

POST: /attachment/ticket/11686/
==========================================================

-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML Email

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

[sage-devel] Re: bug lists of maple, matlab, mathematica, Magma

I can only speak from my experience.

There is a Maxima bug tracker. If I find what I think is a bug, I do
not look at the
bug list. I also do not look at it "pre-emptively" to have in my mind
a list of things
I should not expect to work. I do not know for sure, but I doubt that
when Dr. David Kirkby
reported what he thought were Maxima bugs, he bothered to look either.

It is not part of my job description to survey bugs, though if
behavior (of a program I wrote) is a bug or a feature, I would
ordinarily respond.
That does not happen automatically via the trac system, does it?

For many years the MIT Macsyma system had a public bug list; in some
sense the code was open,
since anyone could read (or write) any file on the ITS system. Yet no
one else ran ITS so it was in some other sense proprietary to MIT. It
would not have made sense to have a secret bug list
since nothing on that system had any security, except via obscurity.

RJF

On Aug 29, 7:36 am, Volker Braun <vbraun.n...@gmail.com> wrote:
> On Sunday, August 28, 2011 11:32:56 PM UTC-4, rjf wrote:
>
> > Let me see if I understand this right.  You are campaigning to have
> > bug lists available (sure, why keep them secret?).  My claim is that
> > in practice this is not as useful as one might initially think.
>
> I also posted an example from my experience where access to the bug tracker
> for a commercial piece of software was very helpful for my work. Even though
> I could only see the bug that I reported, and that this privilege was paid
> for handsomely.
>
> While we do appreciate your input, it would be nice if you could

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

Re: [sage-devel] Re: short article on Sage

Hi,

I've updated the article based on everybody's feedback. Thanks.

The new version is here: http://wstein.org/papers/focm11/

I can still make some last minute changes in the next day.

(Don't worry about the weird formatting of the first two pages.)

William

On Tue, Aug 30, 2011 at 6:18 AM, Niles <nilesj@gmail.com> wrote:
>
> Thanks for the article -- I agree that it should end up somewhere
> easily accessible for people who are sage-curious.  Here are some
> things I noticed, which of course you're free to ignore :)
>
>
> * The phrase "..at least.." rubs me the wrong way in the two places
> you've used it (describing the many bugs listed on Trac, and
> describing how you can shoot yourself in the foot with Cython).  To my
> eyes, it reads as an implicit confession that these are weaknesses,
> not strengths of Sage.  I bet you didn't mean it that way!
>
> * The warning about overflow in the middle of page 5 interrupts the
> train of thought in that section, and seems especially out of place
> since you address overflow later.  Maybe that warning should be
> removed or moved to a footnote.
>
> * In the second paragraph of section 3, you use \emph (or \textit or
> something) for "distribuion", "including Python", and "interface".  Of
> these three, I think the first and third are aligned with the point of
> the paragraph, but the second is tangential and therefore
> distracting.  One way to reorganize that sentence without the \emph
> might be
>
> normal functioning of Sage, including Python itself."
>
> * The paragraph at the end of page 5, beginning of page 6 "Much of the
> work that hundreds of Sage developers does . . ." seems weaker than
> the rest of the article.  I think some thorough rewriting is needed
> there.
>
>
>
> On Aug 30, 12:51 am, William Stein <wst...@gmail.com> wrote:
>
>> I'm going to remove that graphic from the paper, since it seems to
>> annoy too many people.  Also, I don't have a good pdf version of it
>> (only png).    It would be really cool to have a canonical high
>> quality graphic along those lines though, for the Sage website, etc.
>
> That's a real shame, but I can understand not wanting to be drawn into
> a long process of community graphic designing.  Hopefully this will
> prompt someone else to put some work into it.  For that person, I have
> a couple of suggestions:  1. it's redundant to list names like
> "Singular" and "Gap" when they can be clearly read from the images.
> 2. The diagram *looks* complete because the contributing programs make
> a complete circle -- leaving 1/4 or 1/3 of the circle open might be a
> way to visually communicate that this is only a partial list.
>
>
> Thanks again,
> Niles
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>

--
William Stein
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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: short article on Sage

Thanks for the article -- I agree that it should end up somewhere
easily accessible for people who are sage-curious. Here are some
things I noticed, which of course you're free to ignore :)

* The phrase "..at least.." rubs me the wrong way in the two places
you've used it (describing the many bugs listed on Trac, and
describing how you can shoot yourself in the foot with Cython). To my
eyes, it reads as an implicit confession that these are weaknesses,
not strengths of Sage. I bet you didn't mean it that way!

* The warning about overflow in the middle of page 5 interrupts the
train of thought in that section, and seems especially out of place
since you address overflow later. Maybe that warning should be
removed or moved to a footnote.

* In the second paragraph of section 3, you use \emph (or \textit or
something) for "distribuion", "including Python", and "interface". Of
these three, I think the first and third are aligned with the point of
the paragraph, but the second is tangential and therefore
distracting. One way to reorganize that sentence without the \emph
might be

normal functioning of Sage, including Python itself."

* The paragraph at the end of page 5, beginning of page 6 "Much of the
work that hundreds of Sage developers does . . ." seems weaker than
the rest of the article. I think some thorough rewriting is needed
there.

On Aug 30, 12:51 am, William Stein <wst...@gmail.com> wrote:

> I'm going to remove that graphic from the paper, since it seems to
> annoy too many people.  Also, I don't have a good pdf version of it
> (only png).    It would be really cool to have a canonical high
> quality graphic along those lines though, for the Sage website, etc.

That's a real shame, but I can understand not wanting to be drawn into
a long process of community graphic designing. Hopefully this will
prompt someone else to put some work into it. For that person, I have
a couple of suggestions: 1. it's redundant to list names like
"Singular" and "Gap" when they can be clearly read from the images.
2. The diagram *looks* complete because the contributing programs make
a complete circle -- leaving 1/4 or 1/3 of the circle open might be a
way to visually communicate that this is only a partial list.

Thanks again,
Niles

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

[sage-devel] Re: what do you find the most usefull developer tool in sage

On 30 Aug., 14:24, Maarten Derickx <m.derickx.stud...@gmail.com>
wrote:
> Do you mean putting? and ?? behind a command with introspection?

Yes.

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

[sage-devel] Re: what do you find the most usefull developer tool in sage

Do you mean putting? and ?? behind a command with introspection?

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

[sage-devel] Re: what do you find the most usefull developer tool in sage

On 30 Aug., 05:39, Rob Beezer <goo...@beezer.cotse.net> wrote:
> > to find out what you think are the nicest tools
>
> Definitely  search_src()  and  search_def().  Indispensable when you

Introspection and edit() is nice as well!

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

วันจันทร์ที่ 29 สิงหาคม พ.ศ. 2554

Re: [sage-devel] Re: short article on Sage

On Mon, Aug 29, 2011 at 6:00 AM, Jason Grout
<jason-sage@creativetrax.com> wrote:
> On 8/28/11 1:00 PM, William Stein wrote:
>>
>> Hello,
>>
>> I'm writing a short paper about the motivation and history of the Sage
>> project for the FoCM 2011 conference proceedings, where I was one of
>> the plenary speakers.
>>
>> I've attached the first draft to this email.  Feedback welcome!
>>
>> The paper is due before September 1.
>
> Very nice!  A couple of comments:
>
> 1. Mathematica has a Compile function [1], which should probably be
> mentioned when you mention Cython.

That's exactly like Sage's fast_float and fast_callable functions, and
the expression is still interpreted at runtime. I'll add to the
footnote, and I'll emphasize what I mean by a compiler. "None of the
Ma's has an optimizing compiler that converts programs written in
their language to a fast binary form that is not
interpreted at runtime."

> Additionally, it should also probably be
> mentioned that most (all?) of the systems have support for linking and
> communicating with outside C programs (and other languages as well).  Then
> you could emphasize that Cython is both broader (more than mma's Compile
> function) and more seamless (more than a link to to an outside program) than
> the other options.

I'm not sure I want to go there, since ffi's are available in most
modern languages, and it is arguable whether Cython-as-ffi (or ctypes)
is really better than what is available in other languages...
It is however, a solid fact that the other languages don't have
compilers (as defined above), and my desire for this was a real
motivation for Sage. To clarify this connection, I'll add that I
programmed in C++ for many years before I started using Magma, and
found the loss of a compiler in Magma to be extremely frustrating. The
only way to get compiled code with Magma is to modify the closed
source kernel, which is something only "insiders" are *allowed* to do,

> 2. In the nice graphic on p. 5, you have the matplotlib picture labeled as
> "numpy".  Maybe you could put "numpy, scipy, matplotlib" where you now have
> "numpy" and you could list ipython where you have scipy.  Also, the central
> picture looks like a jmol image.  It would be a nice nod to mention it as
> well, though I'm not sure where you could.  Maybe you could make C/C++ into
> C/C++/Java and put jmol in that list.  I realize the list is incomplete; I'm
> just trying to make it internally consistent (i.e., at the last programs
> responsible for the images should be listed).

I'm going to remove that graphic from the paper, since it seems to
annoy too many people. Also, I don't have a good pdf version of it
(only png). It would be really cool to have a canonical high
quality graphic along those lines though, for the Sage website, etc.

>
> Thanks,
>
> Jason
>
>
> [1]
> http://reference.wolfram.com/mathematica/tutorial/CompilingMathematicaExpressions.html
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to
> For more options, visit this group at
> URL: http://www.sagemath.org
>

--
William Stein
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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: short article on Sage

On Aug 29, 9:02 pm, William Stein <wst...@gmail.com> wrote:
> > Will you have rights to it, independent of the conference
> > proceedings?
>
> If they don't let me keep distribution rights, then I will refuse to
> publish it with them.

Very good! Ship me the source when you are done.

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

Re: [sage-devel] Re: short article on Sage

On Mon, Aug 29, 2011 at 8:36 PM, Rob Beezer <google@beezer.cotse.net> wrote:
> On Aug 28, 11:00 am, William Stein <wst...@gmail.com> wrote:
>> I'm writing a short paper about the motivation and history of the Sage
>> project for the FoCM 2011 conference proceedings, where I was one of
>> the plenary speakers.
>
> That is a nice concise history of, and rationale for, Sage.  It would
> be a great thing to have prominently available off the main page of
> sagemath.org.
>
> Will you have rights to it, independent of the conference
> proceedings?

If they don't let me keep distribution rights, then I will refuse to
publish it with them.

>  Could an HTML-ized and single-cell-ized version be
> posted?  (Yes, I'm volunteering to convert it to HTML if that would be
> useful.)
>
> 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+unsubscribe@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>

--
William Stein
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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: what do you find the most usefull developer tool in sage

On Aug 29, 10:35 am, Maarten Derickx <m.derickx.stud...@gmail.com>
wrote:
> to find out what you think are the nicest tools

Definitely search_src() and search_def(). Indispensable when you

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

[sage-devel] Re: short article on Sage

On Aug 28, 11:00 am, William Stein <wst...@gmail.com> wrote:
> I'm writing a short paper about the motivation and history of the Sage
> project for the FoCM 2011 conference proceedings, where I was one of
> the plenary speakers.

That is a nice concise history of, and rationale for, Sage. It would
be a great thing to have prominently available off the main page of
sagemath.org.

Will you have rights to it, independent of the conference
proceedings? Could an HTML-ized and single-cell-ized version be
posted? (Yes, I'm volunteering to convert it to HTML if that would be
useful.)

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

[sage-devel] Re: Writing a piece about import in the developers guide.

Thanks for the usefull replies till so far. I've decides to keep the results of this discsion summarised on
http://wiki.sagemath.org/import
I hope that other people have the same interpretation of the arguments till so far as me. If not feel free to edit the wiki.
I want to mention again that concrete examples of real live sage developement problems are also highly apriciated.

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

[sage-devel] Re: Writing a piece about import in the developers guide.

has some good information.

On Aug 29, 5:33 pm, Robert Bradshaw <rober...@math.washington.edu>
wrote:
> On Mon, Aug 29, 2011 at 4:21 PM, William Stein <wst...@gmail.com> wrote:
> > On Mon, Aug 29, 2011 at 2:56 PM, Maarten Derickx
> > <m.derickx.stud...@gmail.com> wrote:
> >> At the last sage-days there were some people working on making sage start up
> >> faster. I think it would be nice to have a short piece in the documentation
> >> about "best practices for importing" so that all sage developers have a
> >> reference point on how to deal with these difficulties.
> >> Before I can write down such a piece I would like to have heard the opinion
> >> of several sage developers on this. In particular it would be nice to have
> >> hear from all the people who have been thinking about these problems verry
> >> hard on the last sage days what causes of slowdown they found and how to
> >> work around these causes, the more general the case the better of course.
> >> Also feel free to give your opinion if you weren't at the last sage days!
> >> I will start with giving my opinion on one of the causes of slowdown. I
> >> heard from William that during sage startup there is a huge amount of
> >> filesystem acces going on, this causes a very bad startup time behaviour if
> >> you startup sage from a slow filesystem. I heard him complaining that there
> >> where a lot of useless checks if certain files existed before they where
> >> loaded (a lot of looking in different places and finding nothing). I think
> >> the reason for this is that we use way to many absolute imports. Importing
> >> stuff from the top level as:
> >> import sage.some_module.some_submodule
> >> will search for stuff in a lot of different places (this is also what
> >> William observed IIRC).
> >> A quote from:
> >>http://docs.python.org/tutorial/modules.html#intra-package-references
>
> >> The submodules often need to refer to each other. For example,
> >> the surround module might use the echo module. In fact, such references are
> >> so common that the import statement first looks in the containing package
> >> before looking in the standard module search path.
>
> >> So it seems to me we should make more use of this. And also more use of the
> >> explicit relative import statements described there.
>
> >> from . import echo
> >> from .. import formats
> >> from ..filters import equalizer
>
> >> I also have the feeling that a part of the slowness comes from our custom
> >> all.py import construction and not using the __all__ construction in
> >> __init__.py as described on
> >>http://docs.python.org/tutorial/modules.html#importing-from-a-package
>
> >> altough I have to explicitly test that to check wether this has something to
> >> do with it.
> >> To give you a feeling on how much none relative imports occur on the top
> >> level of files and to proof that this is really an issue see the output of
> >> the following commands in the $SAGE_ROOT/devel/sage directory > >> egrep -r "^from sage." ./ | nl > > >> gives 5312 absolute sage imports! > >> and: > >> egrep -r "^import sage." ./ | nl > >> another 893. Some of these are of course imported multiple times, so not all > >> of them cause trouble but it at least shows that this is really an issue. > > > I don't think avoiding absolute imports is the right solution to this > > problem at all. Much better is the code that Volker Braun wrote that > > caches import locations between Sage runs. Basically, his code > > uniformly solves the above problem once and for all without requiring > > any unnatural changes at all to the Sage library. > > +1. This might help some, but is a lot more work for a lot less > benefit than the "cached import locations" hack. Also I find absolute > imports easier to read in many cases. > > >> Another two things I think that should be avoided as much as possible are: > >> 1. Code execution in modules, a module should have mainly function and class > >> declarations, executing code makes the startup time longer. Explicit > >> examples of where this happend, and how a workaround was found are > >> appriciated. > > +1 > > >> Maybe we should make a lazy decorator decorator (decorating a > >> function also causes code execution) so that the execution of decorators > >> which have an expensive initialization can be delayed (it depends on how > >> much time is spend in decoration right now if it's worth the effort). > > Decorators are usually quite cheap, so I don't think this is a concern > here. On that note, however, the cached_method/function decorator > should be pointed out as an alternative to pre-computing things in the > module global space. > > > > > > > > > > > I remember trying to referee one purported example of this, which > > involved elliptic curve isogenies and big precomputed polynomials... > > >> 2. using > >> from some_module import some_function, some_class > >> this should mainly be avoided because of problems with circular imports. > >> when doing imports you are not sure whether some_module has been initialized > >> yet so this could give problems. For the same reason the following should be > >> avoided: > >> import some_module > >> some_module.some_function() > >> since you are not sure wether some_module is initialized yet. Even if you > >> are sure that some_module will be initialized it will make the whole sage > >> liberary harder to maintain since removing "unused" import statements from > >> other files might change the way modules are initialized an give unexpected > >> import errors. The following however is ok to do: > >> from module import sub_module > >> Since this will never lead to circular import problems on its own (if > >> sub_module was not initialized yet the above statement will initialize > >> sub_module, however if you use it to import an explicit class of function it > >> might lead to problems read for example > >>http://effbot.org/zone/import-confusion.htmfor a better explanation). > > There are pros and cons to this. In particular, if you have "import > sage.rings.all" and then in your code you use "sage.rings.all.ZZ" you > are forcing 4 lookups per access. It also makes when the module in > question is actually imported much harder to track down. Of course > there are valid usecases (e.g. when circular imports are necessary). > > >> Ps. maybe we should also change our custom all.py initialization method and > >> use the __init__.py method. This will make it possible in the future to only > >> import certain sub modules of sage. > > > It is unfortunately naive to think that replacing all.py's by > > __init__.py will magically "make it possible to only import certain > > sub modules of sage". > > I've been looking into using __init__.py files to clean things up, but > not necessarily (at least not at this point) getting rid of the all.py > files. In particular, having __init__.py import * from all.py prevents > one from cherry-picking submodules without proper initialization of > their context, which is one of the reasons sage startup and changing > imports is so fragile. Though it wouldn't help with startup time per > se, it would I think make things much easier to follow and debug (e.g. > as part of a greater strategy to both simplify and streamline things). > > > > > > > > >> For example if I was bothered by the > >> startup time from sage, and I only want to do stuff with rings this would > >> make it possible to make an optional argument for sage such that > >> sage -import rings > >> would only load the rings submodule and it's dependancies. > >> Of course we could also do that right now with or all.py files, but it would > >> be good if we obeyed the python standards. (does anybody now why we use > >> all.py and not __init__.py for initialization?) > >> Ok. this became a longer post than I anticipated, but I still hope on > >> feedback from others :) > > > It's great that you've raised this issue for discussion, and I hope > > this thread turns out to be long. > > > Even after banging on startup time, etc., a lot last week, I > > personally do not know what the "best practices" should be for imports > > in Sage. There are pro's and con's with several things you suggest > > above. > > > -- William > > > -- > > To post to this group, send an email to sage-devel@googlegroups.com > > To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com > > For more options, visit this group athttp://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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org Re: [sage-devel] Writing a piece about import in the developers guide. On Mon, Aug 29, 2011 at 4:21 PM, William Stein <wstein@gmail.com> wrote: > On Mon, Aug 29, 2011 at 2:56 PM, Maarten Derickx > <m.derickx.student@gmail.com> wrote: >> At the last sage-days there were some people working on making sage start up >> faster. I think it would be nice to have a short piece in the documentation >> about "best practices for importing" so that all sage developers have a >> reference point on how to deal with these difficulties. >> Before I can write down such a piece I would like to have heard the opinion >> of several sage developers on this. In particular it would be nice to have >> hear from all the people who have been thinking about these problems verry >> hard on the last sage days what causes of slowdown they found and how to >> work around these causes, the more general the case the better of course. >> Also feel free to give your opinion if you weren't at the last sage days! >> I will start with giving my opinion on one of the causes of slowdown. I >> heard from William that during sage startup there is a huge amount of >> filesystem acces going on, this causes a very bad startup time behaviour if >> you startup sage from a slow filesystem. I heard him complaining that there >> where a lot of useless checks if certain files existed before they where >> loaded (a lot of looking in different places and finding nothing). I think >> the reason for this is that we use way to many absolute imports. Importing >> stuff from the top level as: >> import sage.some_module.some_submodule >> will search for stuff in a lot of different places (this is also what >> William observed IIRC). >> A quote from: >> http://docs.python.org/tutorial/modules.html#intra-package-references >> >> The submodules often need to refer to each other. For example, >> the surround module might use the echo module. In fact, such references are >> so common that the import statement first looks in the containing package >> before looking in the standard module search path. >> >> So it seems to me we should make more use of this. And also more use of the >> explicit relative import statements described there. >> >> from . import echo >> from .. import formats >> from ..filters import equalizer >> >> I also have the feeling that a part of the slowness comes from our custom >> all.py import construction and not using the __all__ construction in >> __init__.py as described on >> http://docs.python.org/tutorial/modules.html#importing-from-a-package >> >> altough I have to explicitly test that to check wether this has something to >> do with it. >> To give you a feeling on how much none relative imports occur on the top >> level of files and to proof that this is really an issue see the output of >> the following commands in the$SAGE_ROOT/devel/sage directory
>>     egrep -r "^from sage." ./ | nl
>>
>> gives 5312 absolute sage imports!
>> and:
>>     egrep -r "^import sage." ./ | nl
>> another 893. Some of these are of course imported multiple times, so not all
>> of them cause trouble but it at least shows that this is really an issue.
>
> I don't think avoiding absolute imports is the right solution to this
> problem at all.   Much better is the code that Volker Braun wrote that
> caches import locations between Sage runs.  Basically, his code
> uniformly solves the above problem once and for all without requiring
> any unnatural changes at all to the Sage library.

+1. This might help some, but is a lot more work for a lot less
benefit than the "cached import locations" hack. Also I find absolute
imports easier to read in many cases.

>> Another two things I think that should be avoided as much as possible are:
>> 1. Code execution in modules, a module should have mainly function and class
>> declarations, executing code makes the startup time longer. Explicit
>> examples of where this happend, and how a workaround was found are
>> appriciated.

+1

>> Maybe we should make a lazy decorator decorator (decorating a
>> function also causes code execution) so that the execution of decorators
>> which have an expensive initialization can be delayed (it depends on how
>> much time is spend in decoration right now if it's worth the effort).

Decorators are usually quite cheap, so I don't think this is a concern
here. On that note, however, the cached_method/function decorator
should be pointed out as an alternative to pre-computing things in the
module global space.

> I remember trying to referee one purported example of this, which
> involved elliptic curve isogenies and big precomputed polynomials...
>
>> 2. using
>>     from some_module import some_function, some_class
>> this should mainly be avoided because of problems with circular imports.
>> when doing imports you are not sure whether some_module has been initialized
>> yet so this could give problems. For the same reason the following should be
>> avoided:
>>     import some_module
>>     some_module.some_function()
>> since you are not sure wether some_module is initialized yet.  Even if you
>> are sure that some_module will be initialized it will make the whole sage
>> liberary harder to maintain since removing "unused" import statements from
>> other files might change the way modules are initialized an give unexpected
>> import errors. The following however is ok to do:
>>     from module import sub_module
>> Since this will never lead to circular import problems on its own (if
>> sub_module was not initialized yet the above statement will initialize
>> sub_module, however if you use it to import an explicit class of function it
>> http://effbot.org/zone/import-confusion.htm for a better explanation).

There are pros and cons to this. In particular, if you have "import
sage.rings.all" and then in your code you use "sage.rings.all.ZZ" you
are forcing 4 lookups per access. It also makes when the module in
question is actually imported much harder to track down. Of course
there are valid usecases (e.g. when circular imports are necessary).

>> Ps. maybe we should also change our custom all.py initialization method and
>> use the __init__.py method. This will make it possible in the future to only
>> import certain sub modules of sage.
>
> It is unfortunately naive to think that replacing all.py's by
> __init__.py will magically "make it possible to only import certain
> sub modules of sage".

I've been looking into using __init__.py files to clean things up, but
not necessarily (at least not at this point) getting rid of the all.py
files. In particular, having __init__.py import * from all.py prevents
one from cherry-picking submodules without proper initialization of
their context, which is one of the reasons sage startup and changing
imports is so fragile. Though it wouldn't help with startup time per
se, it would I think make things much easier to follow and debug (e.g.
as part of a greater strategy to both simplify and streamline things).

>>  For example if I was bothered by the
>> startup time from sage, and I only want to do stuff with rings this would
>> make it possible to make an optional argument for sage such that
>>     sage -import rings
>> would only load the rings submodule and it's dependancies.
>> Of course we could also do that right now with or all.py files, but it would
>> be good if we obeyed the python standards. (does anybody now why we use
>> all.py and not __init__.py for initialization?)
>> Ok. this became a longer post than I anticipated, but I still hope on
>> feedback from others :)
>
> It's great that you've raised this issue for discussion, and I hope
> this thread turns out to be long.
>
> Even after banging on startup time, etc., a lot last week, I
> personally do not know what the "best practices" should be for imports
> in Sage.  There are  pro's and con's with several things you suggest
> above.
>
>  -- William
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+unsubscribe@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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Writing a piece about import in the developers guide.

On Mon, Aug 29, 2011 at 2:56 PM, Maarten Derickx
<m.derickx.student@gmail.com> wrote:
> At the last sage-days there were some people working on making sage start up
> faster. I think it would be nice to have a short piece in the documentation
> about "best practices for importing" so that all sage developers have a
> reference point on how to deal with these difficulties.
> Before I can write down such a piece I would like to have heard the opinion
> of several sage developers on this. In particular it would be nice to have
> hear from all the people who have been thinking about these problems verry
> hard on the last sage days what causes of slowdown they found and how to
> work around these causes, the more general the case the better of course.
> Also feel free to give your opinion if you weren't at the last sage days!
> I will start with giving my opinion on one of the causes of slowdown. I
> heard from William that during sage startup there is a huge amount of
> filesystem acces going on, this causes a very bad startup time behaviour if
> you startup sage from a slow filesystem. I heard him complaining that there
> where a lot of useless checks if certain files existed before they where
> loaded (a lot of looking in different places and finding nothing). I think
> the reason for this is that we use way to many absolute imports. Importing
> stuff from the top level as:
> import sage.some_module.some_submodule
> will search for stuff in a lot of different places (this is also what
> William observed IIRC).
> A quote from:
> http://docs.python.org/tutorial/modules.html#intra-package-references
>
> The submodules often need to refer to each other. For example,
> the surround module might use the echo module. In fact, such references are
> so common that the import statement first looks in the containing package
> before looking in the standard module search path.
>
> So it seems to me we should make more use of this. And also more use of the
> explicit relative import statements described there.
>
> from . import echo
> from .. import formats
> from ..filters import equalizer
>
> I also have the feeling that a part of the slowness comes from our custom
> all.py import construction and not using the __all__ construction in
> __init__.py as described on
> http://docs.python.org/tutorial/modules.html#importing-from-a-package
>
> altough I have to explicitly test that to check wether this has something to
> do with it.
> To give you a feeling on how much none relative imports occur on the top
> level of files and to proof that this is really an issue see the output of
> the following commands in the $SAGE_ROOT/devel/sage directory > egrep -r "^from sage." ./ | nl > > gives 5312 absolute sage imports! > and: > egrep -r "^import sage." ./ | nl > another 893. Some of these are of course imported multiple times, so not all > of them cause trouble but it at least shows that this is really an issue. I don't think avoiding absolute imports is the right solution to this problem at all. Much better is the code that Volker Braun wrote that caches import locations between Sage runs. Basically, his code uniformly solves the above problem once and for all without requiring any unnatural changes at all to the Sage library. > Another two things I think that should be avoided as much as possible are: > 1. Code execution in modules, a module should have mainly function and class > declarations, executing code makes the startup time longer. Explicit > examples of where this happend, and how a workaround was found are > appriciated. Maybe we should make a lazy decorator decorator (decorating a > function also causes code execution) so that the execution of decorators > which have an expensive initialization can be delayed (it depends on how > much time is spend in decoration right now if it's worth the effort). I remember trying to referee one purported example of this, which involved elliptic curve isogenies and big precomputed polynomials... > 2. using > from some_module import some_function, some_class > this should mainly be avoided because of problems with circular imports. > when doing imports you are not sure whether some_module has been initialized > yet so this could give problems. For the same reason the following should be > avoided: > import some_module > some_module.some_function() > since you are not sure wether some_module is initialized yet. Even if you > are sure that some_module will be initialized it will make the whole sage > liberary harder to maintain since removing "unused" import statements from > other files might change the way modules are initialized an give unexpected > import errors. The following however is ok to do: > from module import sub_module > Since this will never lead to circular import problems on its own (if > sub_module was not initialized yet the above statement will initialize > sub_module, however if you use it to import an explicit class of function it > might lead to problems read for example > http://effbot.org/zone/import-confusion.htm for a better explanation). > Ps. maybe we should also change our custom all.py initialization method and > use the __init__.py method. This will make it possible in the future to only > import certain sub modules of sage. It is unfortunately naive to think that replacing all.py's by __init__.py will magically "make it possible to only import certain sub modules of sage". > For example if I was bothered by the > startup time from sage, and I only want to do stuff with rings this would > make it possible to make an optional argument for sage such that > sage -import rings > would only load the rings submodule and it's dependancies. > Of course we could also do that right now with or all.py files, but it would > be good if we obeyed the python standards. (does anybody now why we use > all.py and not __init__.py for initialization?) > Ok. this became a longer post than I anticipated, but I still hope on > feedback from others :) It's great that you've raised this issue for discussion, and I hope this thread turns out to be long. Even after banging on startup time, etc., a lot last week, I personally do not know what the "best practices" should be for imports in Sage. There are pro's and con's with several things you suggest above. -- William -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org [sage-devel] Writing a piece about import in the developers guide. At the last sage-days there were some people working on making sage start up faster. I think it would be nice to have a short piece in the documentation about "best practices for importing" so that all sage developers have a reference point on how to deal with these difficulties. Before I can write down such a piece I would like to have heard the opinion of several sage developers on this. In particular it would be nice to have hear from all the people who have been thinking about these problems verry hard on the last sage days what causes of slowdown they found and how to work around these causes, the more general the case the better of course. Also feel free to give your opinion if you weren't at the last sage days! I will start with giving my opinion on one of the causes of slowdown. I heard from William that during sage startup there is a huge amount of filesystem acces going on, this causes a very bad startup time behaviour if you startup sage from a slow filesystem. I heard him complaining that there where a lot of useless checks if certain files existed before they where loaded (a lot of looking in different places and finding nothing). I think the reason for this is that we use way to many absolute imports. Importing stuff from the top level as: import sage.some_module.some_submodule will search for stuff in a lot of different places (this is also what William observed IIRC). A quote from: http://docs.python.org/tutorial/modules.html#intra-package-references The submodules often need to refer to each other. For example, the surround module might use the echo module. In fact, such references are so common that the import statement first looks in the containing package before looking in the standard module search path. So it seems to me we should make more use of this. And also more use of the explicit relative import statements described there. from . import echo from .. import formats from ..filters import equalizer I also have the feeling that a part of the slowness comes from our custom all.py import construction and not using the __all__ construction in __init__.py as described on http://docs.python.org/tutorial/modules.html#importing-from-a-package altough I have to explicitly test that to check wether this has something to do with it. To give you a feeling on how much none relative imports occur on the top level of files and to proof that this is really an issue see the output of the following commands in the$SAGE_ROOT/devel/sage directory

egrep -r "^from sage." ./ | nl

gives 5312 absolute sage imports!

and:

egrep -r "^import sage." ./ | nl

another 893. Some of these are of course imported multiple times, so not all of them cause trouble but it at least shows that this is really an issue.

Another two things I think that should be avoided as much as possible are:
1. Code execution in modules, a module should have mainly function and class declarations, executing code makes the startup time longer. Explicit examples of where this happend, and how a workaround was found are appriciated. Maybe we should make a lazy decorator decorator (decorating a function also causes code execution) so that the execution of decorators which have an expensive initialization can be delayed (it depends on how much time is spend in decoration right now if it's worth the effort).

2. using

from some_module import some_function, some_class

this should mainly be avoided because of problems with circular imports. when doing imports you are not sure whether some_module has been initialized yet so this could give problems. For the same reason the following should be avoided:

import some_module
some_module.some_function()

since you are not sure wether some_module is initialized yet.  Even if you are sure that some_module will be initialized it will make the whole sage liberary harder to maintain since removing "unused" import statements from other files might change the way modules are initialized an give unexpected import errors. The following however is ok to do:

from module import sub_module

Since this will never lead to circular import problems on its own (if sub_module was not initialized yet the above statement will initialize sub_module, however if you use it to import an explicit class of function it might lead to problems read for example http://effbot.org/zone/import-confusion.htm for a better explanation).

Ps. maybe we should also change our custom all.py initialization method and use the __init__.py method. This will make it possible in the future to only import certain sub modules of sage. For example if I was bothered by the startup time from sage, and I only want to do stuff with rings this would make it possible to make an optional argument for sage such that

sage -import rings

would only load the rings submodule and it's dependancies.
Of course we could also do that right now with or all.py files, but it would be good if we obeyed the python standards. (does anybody now why we use all.py and not __init__.py for initialization?)

Ok. this became a longer post than I anticipated, but I still hope on feedback from others :)

Thanks Maarten

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