Re: [sage-devel] Re: spkgs assumed for doctesting but not default installed

[Johan S. R. Nielsen]

Hi,

I've now recompiled Sage after rolling back llvm-libs to 3.7.1-1 (was 
3.8.0.1). That fixed the GLIBCXX errors spewing out of ar and ranlib, but 
it didn't fix the problem: my newly compiled version of Sage is still born 
without most of the default spkgs, including sympy, jmol, palp, 
cremona-minidatabase, R, and probably many other.

I don't see any problems in install.log. llvm is not mentioned anywhere, 
and neither is any of the above packages. In logs/pkgs I don't have any log 
files for the above packages (I do have for many other packages though, all 
of which I guess are installed.)

I'm at a total loss...

Best,
Johan

-- 
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] Deprecate the use of properties in all public API

[Johan S. R. Nielsen]

I've created #20904 to deprecate the Matrix.I property which is ready for 
review.

This seemed to be the only case that most people agreed was bad. There 
remains Matrix.T and Matrix.H as well as a handful of other public API 
properties scattered randomly across Sage.

Best,
Johan

-- 
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] Call to `__cmp__` method on `list` in `Factorization` class fails

[Johan S . R . Nielsen]

> /sage/local/lib/python2.7/site-packages/sage/structure/factorization.pyc
> in __cmp__(self, other)
>  426 c = cmp(self.__unit, other.__unit)
>  427 if c: return c
> --> 428 return list.__cmp__(self, other)
>  429
>  430 def __copy__(self):
>
> AttributeError: type object 'list' has no attribute '__cmp__'
>

This is really old code, added in #1805, written by William. The
offending line seems to be run when self.value() or other.value()
throws an Exception. I don't understand when this should be the case,
and evidently, there's no doctest for it. The discussion on #1805
doesn't reveal the intention either.

list implements the rich-style comparisons __gt__, __lt__, etc. So
presumably, the list.__cmp__ line should be somehow rewritten to this?
It would be nice to have an example where the code line is run, though.

Best,
Johan

-- 
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] Global namespace and independent python packages

[Johan S . R . Nielsen]

> from sage.misc.misc import inject_variable
> from mytest.test import atest
> inject_variable('atest',atest)
>
> *Question*: do people think that it is reasonable for a package to do this?

I would also say "No". The reason is that if that is what the user
wanted, he could just have done "from mytest import *". If he explicitly
does "import mytest" it's because he wants the control over the
namespace.

Best,
Johan

-- 
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] Global namespace and independent python packages

[Johan S . R . Nielsen]

Hi Andrew,

To import into the global namespace use

sage: from mytest import *

As a package author, you shouldn't force the user to load the functions into
the global namespace. However, it might be possible by getting hold of the
globals() object or something.

If you want to import the package into the global namespace *on your
own setup*, you could put the "from mytest import *" in the file
~/.sage/init.sage.

Best,
Johan


Andrew writes:

> I have been playing around with ta stand-alone python package for sage. It 
> works
> really well except that I have not found a "nice" way to import classes into 
> the
> global namespace. I suspect that it is just something in the way that I have
> configured things, so I've distilled my code down to a minimal example in the
> hope that some one can tell me how to fix it.
>
> My package layout is:
> package/
> |- setup.py
> |- mytest/
> |- __init__.py
> |- test.py
>
> where the files setup.py, __init__.py and test.py are as follows:
>
> setup.py
> from setuptools import setup
> setup(name='mytest', packages=['mytest'])
>
> __init__.py
> from __future__ import absolute_import
> from .test import atest
> from mytest import *
>
> test.py
> def atest():
> print 'A working test'
>
> To install this "package" you can either use plain setup tools with
> sage setup.py install
>
> but I decided to pip instead, installing it "locally" and in development mode 
> with:
>
> sage -pip install -e --user .
>
> This works fine in that I can start sage and import and use the package, but 
> not
> quite as easily as I'd like:
>
> sage: import mytest
> sage: mytest.atest()
> A working test
> sage: atest()
> ---
> NameError Traceback (most recent call last)
>  in ()
> > 1 atest()
>
> NameError: name 'atest' is not defined
> sage: from mytest import atest # manually import atest
> sage: atest()
> A working test
>
> I thought that `atest` would be automatically available from the global
> namespace because of either the second and or the third lines of __init__.py.
> Instead, it still needs to be manually imported. Is there a way to put atest
> into the global namespace when the package is imported?
>
> Of course, it would be even better if the mytest package was automatically
> imported into the global namespace at run-time.
>
> Andrew


-- 

-- 
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] Users can permanently modify GF(5).list()

[Johan S . R . Nielsen]

Volker Braun writes:
> I've said it before: list() should always return a tuple. Yes I know its 
> called list, but its just an English thing that verb and noun can't be 
> distinguished. Certainly no excuse to cache mutable data structures.

This is now #20743. Since I am currently unable to compile Sage (see the
Brial thread), I unfortunately can't fix this myself.

Best,
Johan

-- 
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] Users can permanently modify GF(5).list()

[Johan S . R . Nielsen]

>>
>> No. Better use a immutable data structure instead of a list. 

Thinking more about it, what should that be? A tuple? That suddenly
makes the name of the function pretty strange. And does a tuple behave
exactly like a list in all regards?

This touches a very fundamental class in Sage: Parent. I'm sure
Parent.list() is used for all sorts of stuff everywhere in Sage. I'm
seriously surprised this bug hasn't shown up before...

Best,
Johan

Johan S. R. Nielsen writes:

> On Tuesday, May 31, 2016 at 2:35:46 PM UTC+2, Jeroen Demeyer wrote:
>>
>> No. Better use a immutable data structure instead of a list. 
>>
>
> Oh yeah, that's much better. 


-- 

-- 
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] Users can permanently modify GF(5).list()

[Johan S. R. Nielsen]

On Tuesday, May 31, 2016 at 2:35:46 PM UTC+2, Jeroen Demeyer wrote:
>
> No. Better use a immutable data structure instead of a list. 
>

Oh yeah, that's much better. 

-- 
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] Users can permanently modify GF(5).list()

[Johan S . R . Nielsen]

Hi sage-devel

We just came across the following bizarre behaviour:

sage: F = GF(5)
sage: F.list()
[0, 1, 2, 3, 4]
sage: F.list().remove(0)
sage: F.list()
[1, 2, 3, 4]
sage: GF(5).list()
[1, 2, 3, 4]

Which means that the user has just forever destroyed GF(5) in this Sage
session! This currently causes a bug in a decoding algorithm in
sage.coding.linear_code.

My first thought was to simply fix this behaviour with finite fields.
But looking in sage/structure/parent.pyx:1356 it turns out that this
behaviour is not only known but also tested for! In #10470, caching of
list() was introduced and tested for exactly by modifying the returned
list.

Do people agree with me that this behaviour is crazy? And that the small
penalty in returning a *copy* of the list in each call to list() is a
small price to pay for mitigating user errors? Or do you agree with the
authors of #10470 and that the current behaviour should be retained.

Best,
Johan

-- 
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] Renaming generic curve classes

[Johan S . R . Nielsen]

Hi Grayson,

I'm really looking forward to your GSoC on curves!

> Currently, the plane curve classes do not inherit from the space curve 
> ...
> It seems that it would be a lot clearer to have a different naming
> scheme, such as having ProjectiveCurve_generic be called
> ProjectiveCurve_plane, and having ProjectiveSpaceCurve_generic be
> called ProjectiveCurve_generic (similarly for the affine curve
> classes).

I think that makes sense: if you restructure the class hierarchy to
modernise and accommodate more powerful code sharing, it makes sense to
rename. I would say that you shouldn't feel too many constraints wrt.
restructuring/renaming these specific structures if it makes sense in
the long run. I haven't been involved in sage.schemes, however, so
someone more invested in that folder might disagree. I believe that the
curves structure hasn't been refactored much from the very first years
of Sage.

I'm a bit surprised at the naming scheme "_generic", etc. in the first
place. We don't use that very often, and it's not very Pythonic. Would a
completely different and simpler naming scheme be appropriate? E.g.:

ProjectiveCurve  - the generic class
ProjectivePlaneCurve - the plane curves

as well as AffineCurve, AffinePlaneCurve (or simply Curve and
PlaneCurve? I.e. you get affine if you don't ask for projective?).

Are you envisioning other specialisations than plane?

Also, you should think about which constructors you want to import in the
top-level, and which constructors should be accessible from a catalogue,
e.g. curves..

Technically, the renaming can get a bit tricky with deprecation
warnings, especially if you're reusing a name for another thing.

> Also, since there eventually will be more functionality implemented
> for generic curves and not just plane curves, would it be possible to
> rename the plane_curves folder to something more general such as
> "curves" or "curves_generic"?

I vote for "curves". Everything without a specialising denotation is
generic by default ;-)

I don't know how this works wrt. deprecation. If you rename a folder
which contains functions that were meant to be "top-level importable",
you need to still make that module name available with a deprecation
warning. That might require dynamically injecting a module into the
sage.schemes?


Best,
Johan


Grayson Jorgenson writes:

> Hi all,
>
> I am working on revising the class structure for generic curves to make it 
> easier to implement functionality for the GSoC 2016 project on algebraic 
> curves. The main curve classes right now are ProjectiveSpaceCurve_generic, 
> ProjectiveCurve_generic, AffineSpaceCurve_generic, and AffineCurve_generic, 
> with ProjectiveCurve_generic and AffineCurve_generic representing plane 
> curves. The implementations of these classes reside in 
> /schemes/plane_curves.
>
> Currently, the plane curve classes do not inherit from the space curve 
> classes and there isn't any functionality specific to the space curve 
> classes. The goal of ticket #20697  is 
> to make the plane curve classes inherit the space curve classes so that the 
> space curve classes act as the generic classes for projective/affine 
> curves. However, doing this makes the class names a bit inaccurate, since 
> for example the ProjectiveCurve_generic class really represents plane 
> curves and ProjectiveSpaceCurve_generic is the more general class. It seems 
> that it would be a lot clearer to have a different naming scheme, such as 
> having ProjectiveCurve_generic be called ProjectiveCurve_plane, and having 
> ProjectiveSpaceCurve_generic be called ProjectiveCurve_generic (similarly 
> for the affine curve classes).
>
> Is there a policy for changing class names in Sage? Also, since there 
> eventually will be more functionality implemented for generic curves and 
> not just plane curves, would it be possible to rename the plane_curves 
> folder to something more general such as "curves" or "curves_generic"?
>
> Thank you,
> Grayson


-- 

-- 
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] Re: print to python3

[Johan S . R . Nielsen]

> Let me try to summarize. We seem to more or less agree that we should not 
> repeatedly break the code of all users of sage. To avoid that, it would be 
> better to switch completely to python3 in just one major change. And then 
> there will be something like the "last py2 release" and the "first py3 
> release".

Does this entail that in this "last py2 release", we insert deprecation
warnings for all py2 \setminus py3 features that we possibly can,
simultaneously? That way, users would only change all their code that
one time, to get rid of all the deprecation warnings. And then their
code would (usually) work in the py3 version.

I'm intrigued by what Fernando wrote, namely supporting both py2 and py3
for a long time/forever. But I don't know enough about whether the
development overhead would be big -- to me, it sounds like it.

Best,
Johan

-- 
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] print to python3

[Johan S . R . Nielsen]

> Breaking "print a" will cause a truly epic level of pain to our users for
> no real gain...  So much so that probably no matter what is decided here I
> would fork sage to add handling this to the pre-processor for sage on SMC.
> I'm here from endless users (eg each year at the sage booth) about minor
> deprecations that piss them off.  This print thing will be horrible.
>  Truly horrible.
> ...
> (Personally i really like Python3 and the new print function. However, I
> (and you) are not the only user of sage.)

I also think that this will annoy a lot of users. On the other hand,
Python 3 is already old, and the transition has to come at some point.
In 2020, at the latest we shouldn't be supporting Python 2 at all.

Perhaps a tolerable amount of pain would be to do the deprecation in
several steps:

1) For year, issue only a deprecation *the first time* "print a" is used
in a session.
2) After that, for X years, issue a deprecation warning *every time*
"print a" is used.
3) After that, remove support for "print a" completely.

Best,
Johan



William Stein writes:

> Breaking "print a" will cause a truly epic level of pain to our users for
> no real gain...  So much so that probably no matter what is decided here I
> would fork sage to add handling this to the pre-processor for sage on SMC.
> I'm here from endless users (eg each year at the sage booth) about minor
> deprecations that piss them off.  This print thing will be horrible.
>  Truly horrible.
>
> I programmed in python3 many of my waking hours for the last 2 weeks and
> even last night I was still  making mistakes with print.   I'm absolutely
> certain users will have similar trouble, both adapting their own code and
> in changing.   It's just psychology.
>
> (Personally i really like Python3 and the new print function. However, I
> (and you) are not the only user of sage.)
>
> William
>
> On Tuesday, May 24, 2016, John Cremona  wrote:
>
>> We seem to be stuck.  The possibilities are
>>
>> (1) make "print a" just stop working at some point (maybe not yet)
>> (2) as (1) but with a deprecation warning
>> (3) continue to support "print a" for ever.
>>
>> All three have had some negative votes!
>>
>> Jeroen, I also do not like "endless" deprecation warnings, but if it
>> was limited to one per session (assuming that is technically possible)
>> it would not be so bad?
>>
>> John
>>
>> On 24 May 2016 at 14:35, Jeroen Demeyer > > wrote:
>> > On 2016-05-24 15:27, Travis Scrimshaw wrote:
>> >>
>> >> every time, not just the first
>> >
>> >
>> > -1. We should not annoy our users with endless deprecation warnings.
>> >
>> >
>> > --
>> > 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.
>>
>> --
>> 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.
>>
>
>
> -- 
> Sent from my massive iPhone 6 plus.


-- 

-- 
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] Why do we discard (repeatedly) all warning filters?

[Johan S . R . Nielsen]

> At the moment any time a deprecation warning is issued all warning filters 
> are thrown away:
> https://github.com/sagemath/sage/blob/master/src/sage/misc/superseded.py#L138
> which means that Python functionality for tuning warnings is completely 
> useless. Why??? If the point is to change the default behaviour of not 
> showing deprecation warnings, how about just adjusting that particular 
> filter and only once when Sage starts?

I asked a similar question recently:
https://groups.google.com/forum/#!topic/sage-devel/RxMNjVWBeI0

There seems to be some code outside sage/misc/superseded.py which
removes some warnings so they will be issued only once. I have no idea
how or where, or if it's just because I can't read the warning code in
superseded.py right...

I ended up monkey-patching the one type of warning I was interested in
at the time: http://trac.sagemath.org/ticket/20601

Best,
Johan

-- 
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] Re: Should we close all tickets with milestone "sage-duplicate/invalid/wontfix"?

[Johan S . R . Nielsen]

>>>But maybe for examplehttp://trac.sagemath.org/ticket/8170could be justclosed?
>> 
>> Was that a typo for another ticket?
>
> No. It is a good example of what Jeroen said, I think. A reasonable 
> suggestion made 6 years ago, no comments at all after that, no comments 
> telling how this should be done etc.
>
> There is nothing wrong with the ticket. But will it help to have it open?

That ticket notes an API inconsistency in Sage (which is a type of
defect/bug), and it is a valuable observation that it's there and should
be fixed (at some point). If don't think such a ticket should be closed
except if we maintain some sort of list of stuff to fix (but what is a
ticket system other than exactly that?). Once in a while, people do
browse through open tickets on their favourite component of Sage.

I have this example which I understand to be closer to what Jeroen
meant: http://trac.sagemath.org/ticket/13252
It was completely unspecific, had no code contents and was old, so I
closed it as invalid. Even had it been more specific (like "Implement
Information-Set decoding for linear codes") it could have been closed
since it's only value would be to state that Sage currently doesn't have
that feature -- which is obvious.

In the ACTIS team working on coding theory, we wrote up a list of
small-to-medium issues with LinearCode and friends that we, in the long
run, wanted to change: 

https://bitbucket.org/lucasdavid/sage_coding_project/issues/155/problems-with-linear_codepy

But this is an inferior solution to making Trac tickets out of all those
issues -- we went with the above list only out of laziness.

Best,
Johan




Jori Mäntysalo writes:

> On Thu, 19 May 2016, kcrisman wrote:
>
>>>But maybe for examplehttp://trac.sagemath.org/ticket/8170could be justclosed?
>> 
>> Was that a typo for another ticket?
>
> No. It is a good example of what Jeroen said, I think. A reasonable 
> suggestion made 6 years ago, no comments at all after that, no comments 
> telling how this should be done etc.
>
> There is nothing wrong with the ticket. But will it help to have it open?
>
> This could be also a part of larger metaticket "Additions to group 
> theory", maybe?


-- 

-- 
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] content of polynomials

[Johan S . R . Nielsen]

>3. Make `content` always return an element, create a method `
>content_ideal` to return an ideal, and implement `content` only over 
>PIDs.

I vote 3 as well. It limits confusion when coming from other systems
while not really being confusing for new-CAS users.

> A. What kind of deprecation should be implemented?
I have no opinion on that.

> B. What should the content (element) over QQ (or other fraction fields) be? 
> Of course, 1 is a possible answer, but note that gcd(2/3, 4/5) = 2/15 for 
> instance. So another possible answer is `gcd(pol.coefficients())`.

Since gcd(pol.coefficients()) could potentially be useful while 1 is
never useful, I vote for that :-)

Best,
Johan

-- 
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] Re: Certain warning messages are issued many times

[Johan S. R. Nielsen]

On Thursday, May 12, 2016 at 12:44:31 PM UTC+2, Johan S. R. Nielsen wrote:
>
> A related warning is that of @experimental. It seems that if one uses 
> @experimental in the __init__ of a class, then a FutureWarning message 
> is issued every time an element of that class is constructed. Needless 
> to say, this is unnecessary noise for both users and in doctests (every 
> single doctests should include the warning)


This is now fixed in #20601.

Best,
Johan 

-- 
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] Certain warning messages are issued many times

[Johan S . R . Nielsen]

Many warning messages are currently being issued every time the
offending code is being run, instead of only the first time:

sage: C = codes.RandomLinearCode(4, 2, GF(2))
sage: C.decode(C.ambient_space().random_element())
/home/jsrn/local/sage/sage-6.3/src/bin/sage-ipython:1: DeprecationWarning: 
decode is deprecated and will be removed from sage soon. Please call 
decode_to_code instead
See http://trac.sagemath.org/18813 for details.
#!/usr/bin/env python
(1, 0, 1, 1)
sage: C.decode(C.ambient_space().random_element())
/home/jsrn/local/sage/sage-6.3/src/bin/sage-ipython:1: DeprecationWarning: 
decode is deprecated and will be removed from sage soon. Please call 
decode_to_code instead
See http://trac.sagemath.org/18813 for details.
#!/usr/bin/env python
(0, 0, 1, 0)
...

I was under the impression that deprecation warning messages should only
be issued the first time? I tried some other places in Sage and some
deprecation warnings act as above, while others issue a message only the
first time:

sage: random_matrix(CFF, 2)

/home/jsrn/local/sage/sage-6.3/local/lib/python2.7/site-packages/sage/rings/contfrac.py:298:
 DeprecationWarning: CFF (ContinuedFractionField) is deprecated, use QQ instead
See http://trac.sagemath.org/20012 for details.
[ [0]  [6]]
[[-5]  [0]]
sage: random_matrix(CFF, 2)
[  [-2] [0; 2]]
[[-1; 1, 2]   [-1]]

I tried to understand why the code above issues the warning only once,
but I failed.



A related warning is that of @experimental. It seems that if one uses
@experimental in the __init__ of a class, then a FutureWarning message
is issued every time an element of that class is constructed. Needless
to say, this is unnecessary noise for both users and in doctests (every
single doctests should include the warning).

At first I was extremely puzzled by the fact that the asymptotic_ring
code uses @experimental but doesn't have this doc-test problem: but then
I realised that all their experimental classes inherit from
UniqueRepresentation, so objects are instantiated only once for a set of
input. And the module doc string includes explicit @experimental-warning
tests that instantiate the cases used in the later doc tests.

But that doesn't work for classes that *don't* inherit from
UniqueRepresentation. What to do for them? The current @experimental is
so annoying as to be useless.

Best,
Johan

-- 
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] Re: How to implement conversion between LaurentPolynomial and Symbolic rings?

[Johan S . R . Nielsen]

>> sage: R. = PolynomialRing(QQ)
>> sage: (x + 1/x).parent()
>> Fraction Field of Univariate Polynomial Ring in x over Rational Field
>
> Is it really expected by all users (I see a sum,
> not a fraction)? I thought algebraists don't touch
> symbolics with a long stick...

I would certainly yes! If f is in k[x] then I expect Sage to
accept 1/f as the respective element in k(x). It would be annoying to
have to convert explicitly (though, admittedly, the magic coercion
sometimes causes computation being done in k(x) by mistake).

And of course, adding an element in k(x) with one from k[x] gives
something in k(x) without warning.

Best,
Johan

-- 
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] Deprecate the use of properties in all public API

[Johan S . R . Nielsen]

Michael Orlitzky writes:
> I have a matrix m... how come,
>
>   * m.rank gives me bullshit
>   * m.rank() works
>   * m.T() crashes
>   * m.T works?

This is in my mind the most compelling reason to phase out properties in
Sage. I think Erik makes many good points, but ultimately I think
consistency is more important. The problems with ? and tab-completion
seem manageable, so I leave that aside.

In many ways, programming math is a software designers worst nightmare,
where designing the good API that is logical and works in all cases
quickly becomes daunting. Michael's example above is nice: the rank of a
matrix is an invariant, so it should just be a read-only property, just
like all the my-first-@property-tutorials tells us, right? But by that
logic, tons and tons of zero-argument methods should be read-only
properties in Sage. And if someone later on implements a clever
algorithm2 for computing the rank of certain types of matrices, and
would like to toggle that by an optional argument, @property is suddenly
a problem. And so where would you draw the line?

Properties are preciously little used in Sage. And I see no clear way of
using them in a consistent manner, in the type of objects that is Sage.
So I feel the rule of consistency tells us we should therefore not use
properties at all (perhaps except for the types of exceptions discussed
by Nicolas Thiery and Simon King).

Best,
Johan

-- 
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] Deprecate the use of properties in all public API

[Johan S . R . Nielsen]

William Stein writes:
> Unless the above messed up dichotomy is fixed in every possible way
> people might use Sage interactively, I'm personally 100% against using
> properties for objects users interact with at the top level.  They
> have only snuck in in a couple of places because I wasn't paying
> attention.

For the record, the Matrix-properties seem to have been snuck in in
#8094, closed 5 years ago. As mentioned earlier, there are a number of
other @properties in public API here and there, several of them in the
recent AsymptoticRing code.

Best,
Johan

-- 
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] Rank Metric Codes in Sage

[Johan S . R . Nielsen]

Welcome to the Sage community, Arpit! I'm sure this GSoC project will
become a very nice addition to Sage :-)

Best,
Johan

-- 
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] Deprecate the use of properties in all public API (was: Heavy-computation @property in Matrix class)

[Johan S . R . Nielsen]

> Consistency is a definitive plus, as well as not impeding
> introspection. So I would tend to agree to officially phase out
> properties from the public API.
>
> There is one use case for properties in the public API though which I
> would like to bring up, namely "glorified methods".
> ...

Yes, this is a good example of where such syntactic micro-magic can be a
very pleasant experience for the user. I think the cases of properties
that both Jeroen and Erik are arguing to allow are exactly things like
this. It seems that possible doc-issues can be managed, more or less.

So I concede that the rigid stance of officially disallowing all
properties would be "asking for trouble". Perhaps a more realistic
stance is something like:

[ ] Rule of thumb: don't use properties, except if there is a clear,
syntactic benefit that presents a logical exception (to the "method
default") for the user. Properties should particularly be avoided if
exceptions could be thrown or heavy computation performed.

OK, so that's not perfectly well-defined either, but at least things
like MPolynomialIdeal.basis should be method'ized by this rule, as
should the list of properties in the recent AsymptoticRing class (e.g.
summands, growth_group, coefficient_ring, ao.).

Going back to Matrix, I would argue that Matrix.T, Matrix.H, etc. also
fall for this rule. Certainly, Matrix.I does.

Best,
Johan

-- 
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] Deprecate the use of properties in all public API (was: Heavy-computation @property in Matrix class)

[Johan S . R . Nielsen]

> Wouldn't you have to get rid of all public attributes as well when doing
> this?
> Or why should
> sage: x.some_attribute
> work and
> sage: x.some_attribute_by_at_property
> be forbidden?

My impression is that public attributes generally are frowned upon, in
Sage as in many other projects and languages.

Best,
Johan

-- 
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] Deprecate the use of properties in all public API (was: Heavy-computation @property in Matrix class)

[Johan S . R . Nielsen]

In the previous discussion concerning properties on Matrix, there seemed
to be consensus that Matrix.I was a problem. More generally, only
little defence of the general use of properties in the public API was
given.

Therefore, I suggest that we phase out *all* uses of properties in the
public API. The main reasoning is consistency: we are much more
ubiquitously using methods to get information on objects, and it is
inconsistent, confusing and unnecessary to use properties in arbitrary
places, just to save a two keystrokes.

I grep'ed for @property and found no instances of public properties that
could not easily be methods instead (*). Some cases are even
super-inconsistent, such as MPolynomialIdeal.basis (basis() is a method
on all other classes I know of).


I call for the following vote:

[ ] Phase out all uses of properties in the public API and make them
into methods that take no arguments. Add in the developer's manual
somewhere that this is the general policy.

[ ] Phase out properties which perform any non-trivial computation, and
officially condone the use of properties as "getters" of trivial
private information.

[ ] Phase out properties that might (expectedly) throw exceptions, such
as Matrix.I. Condone the use of properties as "getters" of derived
information, such as Matrix.T (transpose).

[ ] Keep things as they are.


For the record, my vote is on phasing out all properties.

There is a technical problem with how to issue proper deprecation
warnings. One possibility is to insert deprecation warnings now for >1
year, and then do the change at a major version. But I think it's more
important to decide how extensively we want to change things first.

Best,
Johan

(*): Simon King hinted earlier at possible performance degradations,
 though. I don't know much about this.

-- 
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] Re: Heavy-computation @property in Matrix class

[Johan S . R . Nielsen]

VulK writes:
> sage: B = matrix()
> sage: B.T.roo
>
> and get
>
> sage: B.T.rook_vector

I see, didn't know that.

Of course, the reason that IDEs follow this is the underlying convention
that

a) Properties are blazingly fast to compute.
b) Properties don't throw exceptions.

Neither of which are satisfied for Matrix.I. If B is a 1000x1000
matrix over ZZ(x), then B.I.roo is going to hang your IDE for a
while :-)

Best,
Johan

-- 
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] Re: Heavy-computation @property in Matrix class

[Johan S . R . Nielsen]

> One advantage of properties over methods is that they autocomplete

I don't understand? Tab-completion covers both methods and properties in
all IDEs I'm aware of.

Best,
Johan

-- 
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] Re: Heavy-computation @property in Matrix class

[Johan S . R . Nielsen]

> Would it be feasible to let properties return some kind of "Undefined"
> or "NotImplemented" or "None", rather than throwing an exception?

That would side-step the entire purpose of exceptions: catching errors
fast and where they occur. This is extremely bad for debugging, and yet
another source of inconsistency that we should definitely not be
teaching our prospective Sagesters.

And the benefit of this sidestepping is to omit an empty pair of
parentheses?

> - I am -1 to deprecate properties in general (here I include lazy
>   attributes, which I find handy).

Can you give me an example of a handy lazy attribute, to make it
concrete for me?

Essentially, I find the use of properties to go directly against a
general pattern in Sage (and OOP): that private fields are only
accessible through methods. For instance, there is no Matrix.nrows --
there is Matrix.nrows(). Why is this not a property? Consistency! In
sage.coding, we also recently refactored everything so that length,
dimension, etc. of a code is private fields, publicly accessible through
method calls. Everywhere I look in Sage, we have methods, not
properties. Why should these four examples in Matrix be so special?

Best,
Johan

-- 
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] Re: Heavy-computation @property in Matrix class

[Johan S . R . Nielsen]

> well, deprecating ".T", etc, just because it breaks an emacs mode, looks like
> a huge overkill, especially from the vim camp :-\)

Ah, you misunderstand me. I'm not arguing against the sugar due to the
Emacs mode - I'm arguing against the sugar because it's Bad For
Consistency.

> Besides, ".T" is bog-standard all over the numerical world. Removing nice
> syntactic sugar should not be done so easily.

>From that point of view, I would agree that there should be a *method*
"Matrix.T()". Leaving out the parentheses by making T a property is a
micro-optimisation which is bad for consistency reasons. The fact that
Matrix.I throws an exception in the general case is even worse.

There was a discussion on sage-devel a while back involving properties,
and multiple people posited that it was sick to make a property that
often throws exceptions...

> I don't quite understand the problem however. Are you saying that emacs mode
> triggers an attempt to actually compute ".T", etc, when you do
> tab completion?

The Emacs mode was simply how I stumbled across the issue, because it --
incidentally -- *does* currently break tab-completion. Exactly why this
happens is not clear to me, but apparently pressing m. in
ipython-mode will call all properties on m; if one of those throw an
exception, the method poll is cancelled and the lisp code determines
that m has no methods at all. m.I throws an exception if m is singular.

This is clearly a problem with ipython-mode! But as I said: I'm not
against the properties on Matrix due to that Emacs mode but because it's
inconsistent, and hence confusing, syntactic sugar.

Best,
Johan

-- 
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] Deprecating Matrix.T, Matrix.I, etc. (was: Heavy-computation @property in Matrix class)

[Johan S. R. Nielsen]

Attempting to change the subject to focus on the suggestion to deprecate 
the properties.

-- 
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] Deprecating Matrix.T, Matrix.I, etc. (was: Heavy-computation @property in Matrix class)

[Johan S . R . Nielsen]

> I agree those things are a problem. I think I know why it was done:
>
> Transposition of a matrix is often written as M^T . It's difficult to
> support that syntax, so using M.T seems like a nice approximation. Once you
> have that, doing the same for conjugate and conjugate-transpose is a small
> step. And now that we have all these properties for order-two matrix
> operations, it's only natural to introduce one for inverses too.

That seems like a sensible explanation. 

> Given the ubiquity of tab-completion I agree that this is now probably a bad
> idea. I don't know if it's bad enough to break existing code, though.
> Perhaps deprecate their use? Even that has a cost.

I think that such magic is bad, for all the properties (transpose,
conjugate, conj-transp, inverse). It is not helpful to newcomers to Sage
to see that, apparently, *some* methods on objects don't require
parentheses, while almost everything else does -- such exceptions might
seem convenient the first 10 seconds, but afterwards it becomes
confusing.

New-comers to Sage often meet matrices as one of the first things. The
impression that leaves is important. In particular, they should
definitely not experience exceptions to Python conventions that arise
nowhere else in Sage.

In the interest of moving Sage to where it should be, as fast as
possible, I would vote for deprecating the behaviour. As you say,
deprecation - and in the end, removal - has a cost, but the greater goal
of having a coherent Sage is more important, I feel.

For the record, I would be OK with supporting abbreviations of the
methods (i.e. Matrix.T() == Matrix.transpose()). I don't know how/if
that could be implemented simultaneously with deprecating "Matrix.T".

Best,
Johan

-- 
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] Heavy-computation @property in Matrix class

[Johan S . R . Nielsen]

Hi

I came across the following in sage/matrix/matrix2.pyx:14367:

@property
def I(self):
r"""
Returns the inverse of the matrix, if it exists.

"""
return ~self

Basically, I don't understand why this def should be a property, and it
seems to me to be problematic. Specifically:

1) This is a property that can throw an exception. Isn't that a problem?

2) This is a property that runs a heavy computation when called. Isn't
that a problem?

I came across this because it currently breaks tab-completion on
matrices in the Emacs sage-mode: perhaps due to a bug, IPython inspects
the properties when tab-completing, so when a property throws an
exception, no tab-completion is given. That means that invertible
matrices don't tab-complete in sage-mode. The terminal is OK, and I
don't know about other interfaces.

There are other @property defs in that class, like conjugate and
hermitian.

Best,
Johan

-- 
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] Re: Integration of function and it's simplified version yields different results

[Johan S . R . Nielsen]

> Why so offensive?

Don't worry - rjf is always spectacularly offensive. His tone is not
representative of how the rest of us write on this list.

Thanks for taking the time to start this discussion (on which I have no
technical input).

Best,
Johan

-- 
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] Re: how we develop sage

[Johan S . R . Nielsen]

> I don't agree with Dima that putting their code into Sage is what 
> researchers should do, no matter what.
>
> I do care a lot about my research code, and I know some of it has no place 
> inside Sage. Maintaining it outside of Sage is not just carelessness or 
> laziness, it's a design choice.

For sure - and you were not in the group of people I meant, since you
clearly stated you cared enough to rebase your code.

Changes to Sage so that external packages like yours break is
unfortunate. But I'm questioning how much we should shape our
development methodology around research projects whose developers
*don't* care enough to fix their code when it breaks. And it will break
once in a while, as long as it is not part of Sage proper.

How often do you feel that changes in Sage breaks your code?

Best,
Johan

-- 
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] Re: how we develop sage

[Johan S . R . Nielsen]

> But there is a way to make code work in Sage as upgrades happen - making it 
> a part of Sage :-)
> Thus I don't buy this "future-proof" statement (well, of course, Sage may 
> fold if sufficient number of right people get hit by a bus - but the same 
> is true for Magma)

It has something to do with the friction that William mentioned, though:
researchers barely has the time and motivation to implement their
algorithms, but they don't want to afterwards go through the - for
new-comers - rather arduous trac/ticket/reviewing process. One reason is
probably that they don't want to mature the doc and API of their code
sufficiently for it to enter sage-proper. I used to maintain a coding
theory library on bitbucket for exactly this reason.

Their work could be more available if Sage wasn't so monolithic, or at
least, if there was more of a culture of having small Sage packages
floating around. If you want their not-completely-nicely-documented
code, install their package into your Sage and be at your own risk.

What Luca is talking about poses a problem for that strategy though:
their code will work with only a few versions of Sage before breaking.
Note that I don't personally share this experience: in my own coding
theory library for Sage, no function was (AFAIK) broken in the last 5
years due to a Sage update (except for my own bugs, and some stuff
related to non-standard packaging).

But of course: if research developers 1) don't care enough about their
own code to polish it enough for going through our review process, and
2) don't care enough to fix it when incompatibilities with Sage occurs;
then is it really code we should be caring about? Won't it quickly rot
on github anyway? The research code going into Magma is exactly polished
during those visits to Magma HQ that Dima mentions.

Best,
Johan

-- 
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] What to global namespace?

[Johan S . R . Nielsen]

Jori Mäntysalo writes:
>
> For graphs we have
>
> from sage.graphs.generators.smallgraphs import *
>
> and
>
> from sage.graphs.generators.platonic_solids import *
>
> and it seems unnecessary but not that harmful to have two set to import.
>
>   * * *
>
> So, we could have also something like
>
> numbertheory.a_special_function(42)
>
> for casual use, and "power user" might just start with
>
> from numbertheory import *
>
> ?

Right. Except that sticking to plain old Python packaging without
shenanigans, then it would probably have to be something like:

from sage.numbertheory_catalog import *

I played around a bit to write a catalogue module that behaved as a
catalogue for casual use (i.e. codes.HammingCode) and a module for power
users (from codes import *). This was in a previous version of #18107.
But a reviewer didn't like it, so I rolled it back to the current state
of affairs where `codes` is in the variable name space, and "import
codes" directly therefore doesn't work.

I don't know if a catalogue "numbertheory" is the desired scope for
these functions, but otherwise I completely agree. I note that there are
no top-level folders named similarly. "is_prime_power" is in arith, for
instance.

Best,
Johan

-- 
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] Request to extend the binomial function by the reflection formula

[Johan S . R . Nielsen]

Overall, I think the proposed change makes sense in the long run, and
Peter presents a good case. But there are some dangers.

Foremost, Clemens argues that a change will potentially brake user code:
while this is true, I think it should be overruled for the long
benefits, if another behaviour is mathematically preferable. Note also
that the proposed change *only* differs from current behaviour when
*both* n and k are negative (and |n| <= |k|); I think that the most
common out-of-ordinary-bounds call on binomial coefficients has k
negative while n positive (*).

As Nils Bruin points out on #17123, agreement with Maxima is also a
concern. But Nils Bruin's own test demonstrates that Sage currently
*doesn't* agree to Maxima. Maxima seems to use a strange mix between
Knuth's definition and the one proposed in #17123: it seems to match
#17123 except on binomial(n, n) for negative n, where it is zero while
#17123 dictates 1. binomial(n, n), n<0 is a case explicitly discussed in
Concrete Mathematics, so that might be why Maxima does this?

Volker Braun argued to add an optional argument `extension` to allow
choosing which behaviour to use. This covers all bases but leaves the
question as to which default to choose.

I vote for having #17123 as the default *in the long run*. If so, what
to do in the short run to mitigate user problems. We could
1) Return the value of #17123 but print a deprecation warning on input
   with conflicting behaviour. The warning tells the user to explicitly
   set the optional argument if he wants to disable the warning. Warning
   is removed in ~1 year.
2) Return the current value, but print a deprecation warning on input
   with conflicting behaviour. After one year, change the behaviour with
   no more deprecation warnings.

Best,
Johan

(*): Admittedly, that might be a total bogus impression.



Peter Luschny writes:

>  > Sage seems to use the definition from Concrete Mathematics by Graham,
>> Knuth and Patashnik:
>> That gives e.g.
>>  sage: binomial(-4, 5)
>>  -56
>
> Right. GKP call it "upper negation". If you look at my demo-function
> you will see that this condition is preserved in the suggested extension
> (case 3). The proposal returns a superset of the current values.
>
>> Concrete Mathematics is seen as something
>> of a bible in large parts of computer science, and it's unfortunate to
>> disagree with a basic definition in there.
>
> It /extends/ this definition. As long as k>=0 nothing will change
> compared to the GKP definition. Upper negation will be untouched.
>
> Peter


-- 

-- 
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] Request to extend the binomial function by the reflection formula

[Johan S . R . Nielsen]

Sage seems to use the definition from Concrete Mathematics by Graham,
Knuth and Patashnik:

binomial(r, k) = r*(r-1)*...*(r-k+1)/(k * (k-1) *...* 1)
   if k >= 0 and r any real number, and
binomial(r, k) = 0
   if k < 0

That gives e.g.
  sage: binomial(-4, 5)
  -56

Though Peter's suggestion seems to make sense from one point of view, so
does the above I would guess. Concrete Mathematics is seen as something
of a bible in large parts of computer science, and it's unfortunate to
disagree with a basic definition in there. The book has a long chapter
devoted to convoluted identities on binomial coefficients -- I don't
know how many of them are left true by the proposed change.

Best,
Johan

Peter Luschny writes:

> Hi all,
>
> I have already reported the unsatisfactory state of the binomial
> function as implemented in Sage on 'Ask Sage' and had opened 
> a request for enhancement with ticket #17123. 
>
> Here I take up a suggestion of John Palmieri to discuss the
> issue on this list. The request is:
>
>Extend binomial(n,k) by the reflection formula, i. e. set
>for n>=1 and k>=1
>   
>binomial(-k, -n) = (-1)^(n+k) binomial(n-1, k-1).
>   
> The reasons are:
>
> (1) The current behavior introduces incompatibility with
> Maple and Mathematica. This does not only question Sage as an
> alternative for the other M-systems; because of the ubiquity
> and importance of the binomial function it becomes difficult 
> to recommended Sage for implementing sequences on the OEIS. 
>
> The behaviour of Maple and Mathematica (which support the
> reflection formula) seems to be the de facto standard. Many 
> mathematicians write their formulas in the OEIS without 
> explicitly mentioning when they assume the reflection formula.
> And this extension was used by mathematicians prior to Maple
> and Mathematica. (So it is certainly not a question of 'do we
> have to mimic all the crap of other M-systems' like some 
> commentators seem to suggest.) 
>
> (2) The extension appears natural as the extended binomial
> has the same behaviour as:
>
> def limit_binomial(n,r):
> return limit(gamma(n+x+1)/(gamma(r+x+1)*gamma(n+x-r+1)), x=0) 
>
> for n in (-5..5): print [limit_binomial(n,k) for k in (-5..5)]
>
> Indeed I find it confusing that the current implementation 
> does not exhibit this behavior.
>
> (3) Also the basic representation of Pascal's triangle in terms
> of the matrix exponential (see the Wikipedia reference below)
> makes the reflection extension appear natural as it is an extension
> from the matrix with 1, 2, 3, ... subdiagonal and zero everywhere
> else to the matrix with .., -3, -2, -1, 0, 1, 2, 3, .. as subdiagonal.
>
> (4) For a comparison of different extensions run this:
>
> def _binomial(n,k, pascal = true, reflection = true, uppernegation = true):
> def b(n,k): return factorial(n)/(factorial(k)*factorial(n-k))
> if pascal and n >= 0 and k >= 0 and k <= n: return b(n,k) 
> if reflection and n < 0 and k < 0 and k <= n: return 
> (-1)^(n-k)*b(-k-1,n-k) 
> if uppernegation and n < 0 and k >= 0: return (-1)^k*b(k-n-1,k) 
> return 0
>
> R = [n for n in (-5..5)]
> print "(1) Pascal's triangle, for the ultra-orthodox."
> print "(cf. [BP])" 
> for n in R: print [_binomial(n,k,true,false,false) for k in R]
> print "(2) Current behavior of Sage, also Magma, extends (1)."
> for n in R: print [_binomial(n,k,true,false,true) for k in R]
> print "(3) Suggested behavior."
> print "Also Maple and Mathematica, extends (1) and (2)."
> print "(cf. [RS], p.5071)" 
> for n in R: print [_binomial(n,k,true,true,true) for k in R]
> print "(4) Extends (1) by reflection only."
> print "(cf. [LMMS], p.637)" 
> for n in R: print [_binomial(n,k,true,true,false) for k in R]
>
> (5) References
>
> [BP] Blaise Pascal; Traité du triangle arithmétique; G. Desprez, 1665. 
> [LMMS] Ana Luzón, Donatella Merlini, Manuel A. Morón, Renzo Sprugnoli;
> Identities induced by Riordan arrays; Linear Algebra and its Applications, 
> 436 (2012) 631-647
> [WP] Pascal's triangle
> https://en.wikipedia.org/wiki/Pascal's_triangle#Extensions
> [MJK] M. J. Kronenburg; The Binomial Coefficient for Negative Arguments; 
> arXiv:1105.3689v2
> [RS] Renzo Sprugnoli; Negation of binomial coefficients; Discrete 
> Mathematics 308 (2008) 5070–5077
> [PL] Peter Luschny; Extensions of the binomial; Blog post;
> http://oeis.org/wiki/User:Peter_Luschny/ExtensionsOfTheBinomial
> [trac] http://trac.sagemath.org/ticket/17123
>
> I'd like to hear your opinions.
>
> Peter


-- 

-- 
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] Query about SageMath for GSOC

[Johan S . R . Nielsen]

> Can you tell me some top priority projects of Sage for GSoC in which
> you can guide me?

See the following list of suggested projects that a dev is ready to
mentor:

https://wiki.sagemath.org/GSoC/2016

I'm on the project "Rank-metric codes" which has already received lots
of attention from prospective students.

Best,
Johan

Amritpal Singh writes:

> On Thu, Mar 10, 2016 at 6:09 PM, Johan S. R. Nielsen
> <santaph...@gmail.com> wrote:
>> Sorry, apart from answering the odd email on this list, I'm not going to
>> guide such a project. I'm not particularly interested in the
>> "print_computation"-idea, and for the other idea on certificates, I
>> simply don't know enough about certificated algorithms to be of
>> significant help there. It's great that you're motivated about
>> contributing to Sage though!
>
> Can you tell me some top priority projects of Sage for GSoC in which
> you can guide me?
>
> -- 
> Amritpal Singh
> http://www.amritpals.com/
> https://github.com/amrit3701


-- 

-- 
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] Query about SageMath for GSOC

[Johan S . R . Nielsen]

Hi Amritpal,

> If we can make a function of "computation of expressions" then we have a 
> certificate or proof that how Sage solve the particular equation. If this 
> thing is physically (internally) happening with Sage then, why can't we do 
> it?

Just giving a transcript of all elementary computations done when
calling some function f does not constitute a good certificate of the
correctness of the output of f: to verify it, the user would have to
verify every single step, and this would be as computationally expensive
as doing the computation himself. "Certificates" are supposed to be
small and easy to verify. See e.g. this paper on certificates for linear
algebra computations, such as the rank:

http://www.math.ncsu.edu/~kaltofen/bibliography/14/DuKa14.pdf


> Not only asking for GSOC, but can you guide me regarding this. Because I'm 
> willing to implement this thing in Sage. If we are able to implement this 
> in Sage then Sage will go to a next level which can't be imagined by 
> anyone. Also, you cleared all my doubts in a single email. Thank you for 
> that.  

Sorry, apart from answering the odd email on this list, I'm not going to
guide such a project. I'm not particularly interested in the
"print_computation"-idea, and for the other idea on certificates, I
simply don't know enough about certificated algorithms to be of
significant help there. It's great that you're motivated about
contributing to Sage though!

Best,
Johan



Amritpal Singh writes:

> On Wednesday, March 9, 2016 at 2:24:22 PM UTC+5:30, Johan S. R. Nielsen 
> wrote:
>> Hi Amritpal,
> 
>> A related, and mathematically quite important feature, is that of
>> "certificates": that a function returns together with its output a
>> certificate, a kind of proof, that output is really correct. For
>> instance, say I call M.rank() on a matrix M. How do I know that the
>> output 5 is correct? It would be nice to have a proof that I could
>> check, possibly in a probabilistic way, and preferably much faster than
>> the rank computation itself, to be certain that 5 is indeed the rank of
>> M. Making fast algorithms that also output certificates is an active
>> area of research and would be a cool addition to Sage. (I wouldn't be
>> able to mentor such a project though: I don't know much about
>> certificates, and I will likely be mentoring another project).
>
> Thanks for the reply and guidance.
> You explained it very well that how this thing can be implemented with 
> Sage. According to you, we can make a separate function i.e. 
> print_computation which will take input in the form of string and print all 
> its occurrences which can be processed for solving the equation. It is a 
> good idea that it's very difficult to hack all of the Sage so we can create 
> different functions which deal with computation of expression.
>
> If we can make a function of "computation of expressions" then we have a 
> certificate or proof that how Sage solve the particular equation. If this 
> thing is physically (internally) happening with Sage then, why can't we do 
> it?
>
> Not only asking for GSOC, but can you guide me regarding this. Because I'm 
> willing to implement this thing in Sage. If we are able to implement this 
> in Sage then Sage will go to a next level which can't be imagined by 
> anyone. Also, you cleared all my doubts in a single email. Thank you for 
> that.  
>
>
> -- 
> Amritpal Singh
> http://www.amritpals.com/
> https://github.com/amrit3701


-- 

-- 
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] Query about SageMath for GSOC

[Johan S . R . Nielsen]

> For example: We have an equation (2+3*(8/2)) and when I solve this
> equation in SageMath it gives the exact answer i.e 14. However, it's
> really interesting to imagine if Sage prints all the steps that how
> they solve the above equation to find its answer like first it print
> this (2+3*4) by solving inner bracket and then it print (2+12) by
> multiplying 3 and 4 and at least it prints the last answer i.e 14.
> This can be done by using BODMAS rule. If by some algorithm or
> logic Sage prints every step of BODMAS operation then Sage have the 
> capability to prints
> all the steps that how they solve the particular equation.

Hi Amritpal,

It sounds to me like you mean "computation of expressions" and not
"solving equations". The difference is that "solving an equation" is
e.g. finding x under the requirement that
  x^2 - 2*x + 1 = 0 ,
i.e. something that contains at least one unknown x. For solving the
above equation in x, one *could* write something like

  x^2 - 2*x + 1 = 0   <=>
  (x-1)^2 = 0 <=>
  x-1 = 0

but more likely, the backend system will just apply the closed formula
for solving a second-degree equation, which would give the somewhat less
enlightening derivation

  x^2 - 2*x + 1 = 0   =>
  x = -(-2)/(2*1) +- sqrt((-2)^2 - 4 * 1 * 1)/(2*1) <=>
  x = 1

In other words, there's two major problems with asking a system like
Sage to write out the derivation in solving an equation:

1) A derivation useful for a computer is often not the most readable or
useful for a human.

2) Most non-obvious computations will be done using complicated
algorithms - not even formulas - whose intermediate steps would not hold
much sense for a human to read.

If we restrict ourselves to "computation of expressions" like what
you're actually writing about, then you seem to basically suggest:

- writing out the BNF form of a computation tree, e.g. (2+3*8/2) could
be written

  +
2 *
3/
8 2

- The expression should now be computed by simplifying nodes which have
only leaves as children. In the above there is only one choice, namely
the "/".

- After each such simplification, print the new expression (flattening
  the updated BNF back to a string, with the necessary parentheses added).


Since Sage uses various backends for the actual computations, and
simplifies in many different locations, it won't be easy to modify Sage
itself to do this everywhere. I also don't think that would be a
particularly sensible option for Sage.

However, it could be achieved, I think, by working on the level of
strings:

sage: print_computation("2+3*8/2")
2+3*8/2
2+3*4
2+12
14

The print_computation function thus takes a *string*, and it has
complete control over when the computations should take place. The
print_computation function could be implemented by scanning over the
string, emulating (or using?) the Python parser, and constructing the
BNF expression tree. The print_computation would then itself carry out
the computation step-wise and printing every time, instead of hacking
into the rest of Sage.

Note that this should be extendable to also allow more complicated Sage
objects to be printed:

sage: M = matrix(ZZ, [ 1, 2, 3, 4])
sage: print_computation('(3 * M) * M')
 [1 2]  [1 2]
(3 * [3 4] ) *  [3 4]

[3  6] * [1 2]
[9 12]   [3 4]

[21 30]
[45 66]

(it could probably be typeset better, though)

However, I'm not convinced such a functionality is really super-cool and
important to have in Sage? As Ralf pointed out, at this level, you could
achieve it manually without too much trouble, so why should Sage offer
the functionality internally -- how often will it be used?

A related, and mathematically quite important feature, is that of
"certificates": that a function returns together with its output a
certificate, a kind of proof, that output is really correct. For
instance, say I call M.rank() on a matrix M. How do I know that the
output 5 is correct? It would be nice to have a proof that I could
check, possibly in a probabilistic way, and preferably much faster than
the rank computation itself, to be certain that 5 is indeed the rank of
M. Making fast algorithms that also output certificates is an active
area of research and would be a cool addition to Sage. (I wouldn't be
able to mentor such a project though: I don't know much about
certificates, and I will likely be mentoring another project).

Best,
Johan

-- 
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] promotional video

[Johan S . R . Nielsen]

Cool! You have a good narration voice :-)

> You made this to promote SageMathCloud. Don't call it a SageMath
> promotional video.

Oh man, not *that* discussion again...

Best,
Johan


William Stein writes:

> We made a SageMath promotional video this weekend
>
>  https://youtu.be/AEKOjac9obk
>
> -- 
> 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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Matrix unicode output

[Johan S . R . Nielsen]

>
> help() with parameters to show longer help? (And smaller default than 
> help() now prints.)

help() could definitely be more helpful on concepts. For instance, the
typesetting we're talking about here could appear if you typed
`help("terminal")` or something. There could be a list of predefined
concepts. But of course, that's yet another entry-point documentation
that needs to be maintained...

Another possibility is that help() given a string could have a behaviour
similar to (the intention of) search_doc(). Right now, help() doesn't
mention the search_* functions, so you don't see those. So how would you
try to find information on typesetting?

Note that doing `search_doc("display")` gives completely unhelpful
output since it matches on the html-code (and therefore matches on the
CSS "display: none").

Best,
Johan

-- 
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] Should a // b really be the same as a / b in fields?

[Johan S . R . Nielsen]

The behaviour for ZZ--QQ--RR decided in that other thread are taking
quotients over the sub-ring ZZ. More specifically:

if a,b are in ZZ, QQ or RR then it was decided that a % b should
implicitly satisfy:

  a == (a//b) * b + a%b

and a//b in ZZ and a%b has norm smaller than b (norm as in euclidean
domain, and some fix to disallow a%b < 0). If we decided instead that
when a,b in QQ then the a//b should be taken in Q, that would imply a//b
= a/b and a%b = 0. The difference is really which ring a//b should be
required to land in.

More generally, if we have a ring R and a subring S, we could introduce
a function //_S and %_S such that for a,b in R then

  a == (a //_S b) * b + a %_S b

where (a //_S b) in S and (a %_S b) has norm < |b|. I'm not sure what
the requirements of R and S should be for such functions to exist.
Apart from all the examples with ZZ, QQ and RR, it seems to work for
e.g. R = K(x) and S = K[x] for a field K with |f1/f2| being deg f1 - deg
f2.

It might seem mathematically "arbitrary" to say that // defaults to
//_ZZ according to the above notation, whenever a,b in RR, if the above
holds for a wide variety of R and S.

Best,
Johan

 1. Should we always have

a == a//b + a%b

John Cremona writes:

> On 19 January 2016 at 12:37, Vincent Delecroix
> <20100.delecr...@gmail.com> wrote:
>> On 19/01/16 09:31, John Cremona wrote:
>>>
>>> On 19 January 2016 at 11:49, Vincent Delecroix
>>> <20100.delecr...@gmail.com> wrote:

 As far as I know we do not have any specifications for //. In euclidean
 ring
 it would be natural for it to be the quotient. But in other situations?

 1. Should we always have

a == a//b + a%b

 2. Should // always be internal?

 On 19/01/16 08:28, Jeroen Demeyer wrote:
>
>
> Feature or bug?
>>>
>>>
>>> I would say "feature" since these are field elements so division is
>>> always exact, unlike ZZ(7)//ZZ(2).
>>>
>
> sage: QQ(7) // QQ(2)
> 7/2
>
> I would expect
>
> sage: QQ(7) // QQ(2)
> 3
>>>
>>>
>>> This would only make sense if ZZ was the only ring of which QQ was the
>>> field of fractions.  Similarly with rational function fields, in my
>>> opinion.
>>>
>>> But I think that
>>>
>>> sage: QQ(7) % QQ(2)
>>> 1
>>>
>>> is definitely a bug, for the same reason!  (Should be 0).
>>
>>
>> That contradicts the proposal at
>>
>> https://groups.google.com/forum/#!topic/sage-devel/PfMop0nyiL0
>
> You are right, it does.  The trouble is that there seem to be two ways
> to generalize % from ZZ to QQ or RR:  I was thinking of it as the
> quotient, or approximate quotient for ZZ;  but the other thread sees
> x%y as the integer part of x/y.
>
> I agree that it might be useful to have a computation with (say) 100 % pi:
>
> sage: 100.0 % RR(pi)
> -0.530964914873380
>
> (without the RR one gets as error since % is not defined for SR,SR
> arguments), and it would be pretty stupid to give 0 just because a
> pure mathematician says that RR is a field so the division is exact.
>
> So provided that the documentation is very clear, defining x%y as the
> integer paert of x/y, for any subset of RR, makes sense.
>
> (What about CC?)
>
> John
>
>>
>>
>> --
>> 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.


-- 

-- 
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] Re: Sage GSOC 2016

[Johan S . R . Nielsen]

How does it work with Sage's application to GSoC and what are the
relevant deadlines? Also, in what period should the project be conducted?

I have an idea for a project I would like to mentor, but I have to be
sure that I'm available in the period.

Best,
Johan

Samuel Lelièvre writes:

> Mentors should also consider subscribing to sage-gsoc
>
> https://groups.google.com/forum/#!forum/sage-gsoc
>
> where applicants will introduce themselves.
>
> 2016-01-18 12:21 GMT+00:00 Samuel Lelièvre :
>> Hi all,
>>
>> Sage will be applying to Google Summer of Code (GSOC) again this year.
>>
>> Information for applicants is on this wiki page.
>>
>> http://wiki.sagemath.org/GSoC/2016
>>
>> Anyone with ideas for projects, please add them there.
>>
>> See last year's Sage GSOC wiki page
>>
>> http://wiki.sagemath.org/GSoC/2016
>>
>> for inspiration and formatting (copy-paste and adapt from there).
>>
>> Samuel


-- 

-- 
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] Re: Trac - internal error

[Johan S . R . Nielsen]

Same thing here, #19251.

Johan

david.lu...@inria.fr writes:

> Hello,
>
> Same thing with some of tickets: #19653, #19666, #19722, #19422 and #19623
>
> David
>
> Le vendredi 15 janvier 2016 15:37:58 UTC+1, Clemens Heuberger a écrit :
>>
>> Trac detected an internal error: 
>>
>> OSError: [Errno 2] No such file or directory: '/tmp/tmp7BmVNV' 
>>
>> The action that triggered the error was: 
>>
>> GET: /ticket/19306 
>>
>>

-- 

-- 
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] The coefficients() method of a MultivariatePowerSeriesRing is unreasonably slow

[Johan S . R . Nielsen]

The call to f.coefficients() run the following lines (self = f):

tmp = {}
for j in self._bg_value.coefficients():
for m in j.monomials():
tmp[self.parent(m)]=j.monomial_coefficient(self.parent()._poly_ring(m))

I may be missing something, but it seems that instead of the inner loop,
one could just loop over j.dict(). The values of this are already in the
right parent. Converting the keys should not be too expensive (and would
have to be done in any case, if one wants to use the output of
f.polynomial().dict() while retaining the return type of
f.coefficients()).

Johan


Ralf Stephan writes:

> On Friday, January 8, 2016 at 1:51:27 AM UTC+1, Daniel Lowengrub wrote:
>>
>> 1) If we are just reading the coefficients of the power series, why should 
>> it matter if we first cast it to a polynomial?
>>
>
> We are not. There are substitutions happening, leading to expensive 
> computation of powers.
>  
>
>> 2) If the issue lies in the details of the PowerSeries implementation, 
>> then would it make sense to simply cast powerseries to polynomials before 
>> calling methods that do not distinguish between the two?
>>
>
> In this special case yes. I don't know for the general case.
>
> Regards,

-- 

-- 
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] subs semantic

[Johan S . R . Nielsen]

Hi,

+1, that seems to make sense, and it's a good idea to have both
semantics available.

Note that there are also complicated mixes:

sage: R. = RR[]
sage: Zxy = PolynomialRing(ZZ,'x,y,z')
sage: xx,yy,zz = Zxy.gens()
sage: (xx+yy).subs(x=x).parent()
Multivariate Polynomial Ring in x, y, z over Real Field with 53 bits of 
precision
sage: (xx+yy)(x=x).parent()
Multivariate Polynomial Ring in x, y, z over Real Field with 53 bits of 
precision

Your proposal is that the latter should only be RR[x,y], I guess?

Best,
Johan


Jonas Jermann writes:

> Hi
>
> +1 by me.
> How is the order of variables for "call" determined?
> How would this work for SR?
>
>
> Regards
> Jonas
>
> On 06.12.2015 15:24, Vincent Delecroix wrote:
>> Hello,
>>
>> We have substitution available for various objects (e.g. matrices when
>> the base ring is a polynomial ring). I would like to fix the conventions
>> of the parent of
>>
>>   my_object.subs(var1=val1, var2=val2)
>>
>> versus
>>
>>   my_object(var1=val1, var2=val2)
>>
>> With .subs, univariate polynomial ring somehow chooses the "minimal ring"
>>
>>  sage: R. = ZZ[]
>>  sage: (x+3).subs(x=2).parent()
>>  Integer Ring
>>  sage: (x+3).subs(x=x+4).parent()
>>  Univariate Polynomial Ring in x over Integer Ring
>>  sage: (x+3).subs(x=4.).parent()
>>  Real Field with 53 bits of precision
>>
>> Whereas multivariate are somehow "undecided"
>>
>>  sage: (x+3).subs(x=2).parent()
>>  Multivariate Polynomial Ring in x, y over Integer Ring
>>  sage: (x+3).subs(x=x+4).parent()
>>  Multivariate Polynomial Ring in x, y over Integer Ring
>>  sage: (x+3).subs(x=4.).parent()
>>  Real Field with 53 bits of precision
>>
>> Whereas the symbolic ring is as always a black hole
>>
>>  sage: x = SR('x')
>>  sage: x.subs(x=3.).parent()
>>  Symbolic Ring
>>  sage: x(x=3.).parent()
>>  Symbolic Ring
>>
>> My proposition is:
>>
>>   - .subs should be considered as an *internal* operation. Hence, the
>> result will always be in the same parent (or the result of a pushout).
>> In particular we would have
>>
>>  sage: R. = ZZ[]
>>  sage: x.subs(x=4).parent()
>>  Univariate Polynomial Ring in x over Integer Ring
>>  sage: x.subs(x=4.).parent()
>>  Univariate Polynomial Ring in x over Real Double Field
>>
>> - __call__ is considered as an external operation. The result should
>> (more or less) be the smallest parent in which the result belong.
>>
>>  sage: R. = ZZ[]
>>  sage: x(3,5).parent()
>>  Integer Ring
>>  sage: (x+y)(3., polygen(ZZ))
>>  Univariate Polynomial Ring in x over Real Field with 53 bits of
>> precision
>>
>> Does it look reasonable?
>>
>> Best,
>> Vincent
>>

-- 

-- 
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] reviewing prevented code written by a cat from getting into Sage

[Johan S . R . Nielsen]

Cats on the keyboard are dangerous! My cat once ran over my keyboard
while I was in Vim. The result: deleted all contents of the file, saved
AND nuked the undo buffer!

Thank goodness for version control...


kcrisman writes:

> I usually catch those before committing. I still don’t know how one of our 
>> cats open iTunes on my laptop (there are no icons for it on the desktop or 
>> panel). 
>>
>
> I like also that this could have been caught by doctesting that specific 
> error being raised :) 

-- 

-- 
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] A new book on Sage, for high school students in Poland

[Johan S . R . Nielsen]

Congratulations on your book! It looks beautiful and well-motivating. I
don't read any polish, so I can't judge contents, but I can tell you
that the "browsability value" of the book is very high, which is
important when you're judging which book to take home from the book
store or library :-) Beautiful and light-hearted art-work, and very well
typeset.

It's also great news for Sage! I hope it'll be a big success in Poland.

Best,
Johan

Andrzej Giniewicz writes:

> Hello,
>
> I'd like to mention a new book using Sage I co-authored, that got
> released last week.
>
> It is in Polish and covers all mathematics topics from high school,
> according to the current core curriculum in Poland. It is not a
> textbook, but supplemental material, which aims to wake up the
> imagination on the way to proper understanding of mathematics topics.
> This is why decided to use mathematical package to remove the burden
> of calculations, and this is why we also decided to use lot of
> references to pop-culture and imagined stories - sea snake named
> Ssstefan approaching the Viking ship helps to understand function
> transformations, Brian the crocodile tamer helps to see overlapping
> intervals.
>
> We covered all major interfaces (Cell, Cloud, Notebook, iPhone,
> Android apps). It is 352 pages, typeset using PDFLaTeX+SageTeX package
> (we had to adjust it a bit, because we decided to save images in SVG
> and then convert to TikZ using https://github.com/kjellmf/svg2tikz -
> for 3D graphics we decided to output png from Tachyon and then added
> overlay in TikZ, which was more tricky, but also worked).
>
> It would be cool if our book could be mentioned on
> http://www.sagemath.org/library-publications.html#books - and it would
> be also very helpful if we could hear some opinions. Especially, that
> we have some plans on making an English version in the future - and
> any opportunity to improve would be great (we need to find some budget
> for professional translation service, as there are jokes and ideas in
> the book that do not translate 1-1).
>
> Below are some release informations:
>
> Authors: Andrzej Giniewicz, Katarzyna Zajączkowska
> Title: "Zrozumieć matematykę z pakietem Sage" (translation:
> "Understand mathematics with the Sage package")
> Publisher: GiS (http://www.gis.wroc.pl/)
> ISBN: 978-83-62780-42-6
> Year: 2015
> Web page: http://www.eurekacode.com/matematyka
>
> Sorry, but web pages are in Polish.
>
> It is kind of self-promotion, but I think it is still relevant. (btw,
> do we have separate list for such announcements?)
>
> We are looking forward to hearing some opinions,
> Thanks,
> Andrzej Giniewicz & Katarzyna Zajączkowska.

-- 

-- 
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] Re: About abbreviation in function names

[Johan S . R . Nielsen]

> I tried that in emacs as I had not heard of it and it sounded useful
> -- but (in a python file) got an error message about requiring a
> python process to be running.

I'm just referring to (dabbrev-expand), bound to M-/ on a clean Emacs in
most major modes. There's "dynamic expansion using inferior shell" that
various Python packages try to do, but I've never had anything really
work well for me with Sage. dabbrev-expand never fails ;-)

Best,
Johan

-- 
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] Re: About abbreviation in function names

[Johan S . R . Nielsen]

> rings.integral_domains.DVR()
> instead of 
> rings.integral_domains.DiscreteValuationRing()

I would definitely prefer DiscreteValuationRing() here.

Mathematics is pretty verbosely written, and I think Sage should reflect
how most mathematics is written. I'm in a research field with strong
interaction with electrical engineers, and I find their papers very
difficult to read because they put abbreviations everywhere: the
abstract introduces the first 10, and the rest are scattered throughout
the paper.

Code is read and modified many more times than its written. It's much
more important that one immediately understands the code, than it is to
save a few keystrokes. Add to that the aforementioned benefits from
search (in Sage, on Google, etc), as well as for new Sage-users and
people outside the field.

But we're not writing Java, and I agree with shortening of function
names etc. when it's not a standard term and no added information is
given, e.g.:
  not compute_hermite_normal_form()
  not get_hermite_normal_form()
  not hnf()
  but hermite_normal_form()

(OK, stupid example but I couldn't immediately think of a better one)

About tab-completion in Vim/Emacs: I have many files open, and if I'm
working on something, e.g. GeneralizedReedSolomonCode, then probably one
of those files contains that word. Then I have tab-completion for it.

Best,
Johan


Dima Pasechnik writes:

> On Wednesday, 23 September 2015 11:10:46 UTC-7, Jeroen Demeyer wrote:
>>
>> On 2015-09-23 19:43, Dima Pasechnik wrote: 
>> > There are well-accepted abbreviations in various areas of maths, e.g. 
>> > ILP for Integer Linear Programming. 
>>
>> Let me answer this with a real life anecdote: 
>>
>> When I was a young graduate student, I attended some seminar. Literally 
>> the first sentence of the talk was "Let R be a D.V.R.". The speaker said 
>> the abbreviation "D.V.R.". I couldn't understand anything of the 
>> introduction and only after 10 minutes or so, I realized that the talk 
>> was about discrete valuation rings, a concept which I knew. So, 
>> "well-accepted" is not the same as "known by everybody". 
>>
>
> I don't buy it, for lectures are often much less interactive compared to 
> using Sage.
> We're talking about being able to have 
>
> rings.integral_domains.DVR()
> instead of 
> rings.integral_domains.DiscreteValuationRing()
>
> (well, we don't have rings.TAB, but we do have graphs.TAB, with plenty of 
> graphs.BlahBlahGraph() there)
>
>
>
>> Jeroen. 
>>

-- 

-- 
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] Re: What are catalogs (groups.tab, matrices.tab) supposed to contain exactly?

[Johan S . R . Nielsen]

 To sum up, I would put a class/function in the respective catalogue if:
  1) It's polished as in nicely callable by the user in a Sage session.
  2) It's reasonably useful for people interested in the field of the
 catalogue.
  3) It's not imported in the global name space.

 I tend to disagree with point 3. In the case of designs, we have some
 objects (the old ones) available in the global namespace, and some others
 (the more recent ones) which are not.

 It woud be messy to have some of them in the catalog, and some others
 in the global namespace. If some must be put inside of the catalog, then
 let it be all of them.

Yeah, I see the point. Number 3 was to avoid having the super-generic
constructors like Graph and LinearCode in the catalogue. But there will
only be few of them anyway, so perhaps one should rather strive for
consistency here.


 Though I know nothing about two-graphs, it therefore seems that I would
 vote for putting TwoGraph in graphs.tab.

 Well, a TwoGraph is not a graph but that's another problem :-P


Hehe, OK. But you can see where my confusion came from ;-)

Best,
Johan

-- 
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] Re: What are catalogs (groups.tab, matrices.tab) supposed to contain exactly?

[Johan S . R . Nielsen]

Hi,

In catalogues, I would only put classes and functions that are directly
useful for users and should be easily accessible. It that way, it is
exactly like exporting into the global name space, except that the
catalogue's classes and functions are strongly related, and possibly
more specialised and appeals to a smaller subset of users.

In particular, I don't feel that catalogues should only contain famous
constructions and families (PetersenGraph, NathannCohenGraph, etc.). For
one thing, the distinction is not well-defined: there is no real
difference between generic constructors and gigantic but specifically
named families of objects (e.g. Alternant codes in coding theory).

To sum up, I would put a class/function in the respective catalogue if:
 1) It's polished as in nicely callable by the user in a Sage session.
 2) It's reasonably useful for people interested in the field of the
catalogue.
 3) It's not imported in the global name space.

Though I know nothing about two-graphs, it therefore seems that I would
vote for putting TwoGraph in graphs.tab.

Best,
Johan






Dima Pasechnik writes:

 On Tuesday, 25 August 2015 11:20:39 UTC-7, Nathann Cohen wrote:

 Hello everybody, 

 In a discussion on a ticket, Dima raised an interesting question: what 
 are catalogs (i.e. groups.tab, codes.tab, graphs.tab) *supposed* 
 to contain? 

 To me, it seems natural to have graphs.PetersenGraph, but not 
 graphs.Graph (the class constructor) nor graphs.DiGraph. 

 Similarly, we do not have a groups.permutations.PermutationGroup 
 even though the groups that can be obtained from 
 groups.permutations.tab are all permutation groups ! 

 It is a needless obstacle from a user point of view, that a non-exposed 
 through catalog or global namespace
 class has to be explicitly imported (sometimes via an arcane sequence of 
 module names) before one can create an object from it.
 (Needless to say, such classes are hard to discover, too).

 Clearly there are classes with constructors meant to be called directly by 
 a user, and these have to be exposed in
 one way or another, from useability point of view.
 (I wrote a bit longer explanation here: 
 http://trac.sagemath.org/ticket/18972#comment:119)



  

 In the present case, we discuss with Dima whether we should include a 
 class in designs.tab (whose role is similar to Graph, or to 
 IncidenceStructure). It is important to note that this class is *not* 
 exported in the global namespace. We expect it to be rarely used, 
 however. 

 Nathann 

 P.S.: If we make a difference between classes exported in the global 
 namespace and the others, we cannot have some classes in catalog X 
 because they are not exported, and not have other because those *are* 
 exported. 


-- 

-- 
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] Re: questions about option: inplace vs copy

[Johan S . R . Nielsen]

Basically +1 for Volker's suggestion. Vincent's suggestion on the
semantics of copy in constructors seem very dangerous: even if my
construction of MyNewObject works today, a seemingly unrelated change to
either the caller code or MyNewObject tomorrow could completely break
things in highly surprising ways. Don't share mutable objects in subtle
ways, when it's natural to think about mathematical objects in an
immutable way.

About the naming of the copying form versus in-place form, note that
matrices currently have e.g. echelon_form/echelonize and
hessenberg_form/hessenbergize. Standardisation would dictate echeloned
or echelon_formed?

Best,
Johan




Volker Braun writes:

 IMHO both foo(copy=True) and foo(inplace=False) are fugly and best avoided. 
 They are unintuitive and not discoverable. Basically they are patterns for 
 an API that you can only use by constantly looking up the documentation. 

 If possible, methods should act in-place since that is the most versatile 
 (you cannot un-copy, but you can easily make a copy before acting). So that 
 should always be the default. Of course if the object can be immutable then 
 you can't act in-place. Use past tense to name the copying form of the 
 method. 

 E.g. list.sort() vs. sorted(). 

 * The in-place operation is more useful and therefore the list method
 * The -ed implies copy.

 In constructors its best to make copies of mutable data and reference 
 immutable data. Just do the right thing, don't trick the user into 
 introducing subtle errors MyNewObject(data_list, copy=False) or 
 unnecessarily waste memory MyNewObject(data_tuple, copy=True).



 On Friday, August 21, 2015 at 2:08:45 PM UTC-4, vdelecroix wrote:

 Hello, 

 While looking at #18481, I realized that we have two argument names that 
 have the same purpose: copy and inplace (one being the contrary of 
 the other of course). As it is worth a convention, I am just asking for 
 your preferences: 
   1. It does not matter 
   2. Functions should accept both, ie both my_function(copy=True) and 
 my_function(inplace=True) should work 
   2. inplace is better 
   3. copy is better 
   4. we need another argument name 
   5. ? 

 Best, 
 Vincent 


-- 

-- 
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] [sage-cloud] slowness with sums of ideals in ZZ[a, b]

[Johan S . R . Nielsen]

Hi,

The test takes about 92ms on my laptop (Sage 6.8.rc1, core i7-4600 @ 2.10 GHz).

So if it's a Sage 6.7-thing, it's fixed again :-)

Johan


William Stein writes:

 On Fri, Jul 31, 2015 at 8:36 AM, Pierre pierre.guil...@gmail.com wrote:
 Hi,

 I have asked a version of this question here:

 https://groups.google.com/forum/#!topic/sage-support/2KJQhOf-N7Y

 However I now have a minimal working example, and sage-devel is perhaps
 better than sage-support for this question (is it?)

 So when working with multivariable polynomials over ZZ and taking the sum of
 two ideals, things are inexplicably slow on sagemathcloud. Try the
 following:

 S.a, b= ZZ[]
 L= [ S.random_element() for i in range(500) ]
 def test():
 foo= []*S
 for P in L:
 foo= foo + [P]*S

 %timeit test()

 On my local machine (macbook with sage 6.2), which for anything else is
 slower than the cloud, i get about 170ms (i've tried it with L reconstructed
 a few times).
 On sagemathcloud, it's about 3.8 seconds. 20 times slower !

 Using %prun, it seems that a lot of time is spend by {map} ... 

 Also note that on the cloud, there is a warning message about computations
 over ZZ, using singular, not being trustworthy. Sage 6.2 doesn't have that.
 Could it have an effect on the speed?

 Anyway, just wanted to point this out. It would be lovely if this could be
 fixed as some point. I'm really enjoying the cloud !


 This isn't really a question relevant to SageMathCloud.  It's a
 question about Sage-6.7 (which is the current version in the cloud)
 and Sage-6.2, which is what you're comparing with. I would not be
 surprised if you were to do the same test on Sage-6.7 on your laptop,
 if it would also be slow.

 It is, of course, a good question to be asking.  I hope somebody will
 run your benchmark on a sage-6.7 install not in SageMathCloud and
 report.

 I will upgrade SMC to sage-6.8 sometime soon -- I don't know if that will 
 help.

  -- William


 Thanks,
 Pierre


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



 -- 
 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] Sage-enabled textbook for Abstract Algebra

[Johan S . R . Nielsen]

Hi Rob,

This is really very nice!

I took my first steps in algebra reading Tom Judson's book on my own,
quite some years ago. Already back then, math and programming were both
major interests of mine. Having Tom Judson's book containing intriguing
Sage examples and challenges makes it, it seems to me, a perfect
course/self-study book for young students who are like I was.

When I'll be teaching my own algebra courses in the not-so-far future, I
will definitely consider this book.

Thanks for doing this, and for making it freely available! And to Tom
Judson for open sourc'ing his book, and his collaboration in this
project.

Regards,
Johan


Rob Beezer writes:

 I have had it in my head for many years to integrate Sage tightly with 
 textbook material.  The first full result of this idea, produced through a 
 general system, is now available.  (Perhaps this excuses my near-total 
 absence from core Sage development the past two or three years.)

 Tom Judson's Abstract Algebra: Theory and Applications is available as a 
 collection of Sage-enabled web pages, in addition to a traditional PDF with 
 static Sage examples - all with an open license, and both versions are 
 produced from the same source files with no intermediate editing.

 Stable URL: http://abstract.pugetsound.edu/aata/

 Features:

 * 710 Sage Cell examples, doctested every six months

 * 121 classroom-tested Sage exercises, ranging from very computational to 
 open-ended guided explorations

 * 23 chapters, 672 traditional exercises, enough for a year-long course or 
 less

 * knowls (implemented by Harald Schilly and David Farmer) for proofs and 
 cross-referenced content

 * CSS, MathJax, and SVG images from tikz source, together make pages scale 
 uniformly

 * web interface reacts to small screens (responsive design)

 We are running a Public Beta for the few weeks prior to North American 
 courses beginning in September.  We expect Lon Mitchell to publish a 
 hardcopy version (without Sage material, with new numbering) to be 
 available (US only?, I'm not sure) for US$ 25 or so in the next few weeks.  
 See website for details.

 Short-Lived URL: http://abstract.pugetsound.edu/beta.html
 Faithful PDF (beta): http://abstract.pugetsound.edu/beta/aata-20150729.pdf

 Next:

 * I have limited conversions to Sage Notebook worksheets, SageMathCloud 
 worksheets and Jupyter notebooks in various stages of disarray.  I'll 
 likely get the Sage exercises posted in at least one of these formats 
 before my course begins in September.

 * EPUB is the next major output format we will target.

 * Convert my linear algebra book to the new system.

 If you teach modern algebra to advanced undergraduates and want to expose 
 your students to computation, this book would be an excellent choice.  

 If you want to author your own material like this, the system requires no 
 more technical skill than writing in LaTeX.  Making Sage-enabled lecture 
 notes available to your students on the web is a great way to get started.

 This project relies on multiple open source projects built up by many 
 people, but I will just single out Tom Judson for his willingness to open 
 source his textbook, his patience as we converted the original LaTeX source 
 over the past year, and allowing me to incorporate Sage material and 
 exercises within his book.

 http://abstract.pugetsound.edu/contact.html

-- 

-- 
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] Functions returning sub-structure

[Johan S . R . Nielsen]

Jori Mäntysalo writes:

 I understood. But when do user have an object of class lattice and he or 
 she wants to check that it is a lattice?

This could easily happen in a function that accepts any poset but can do
clever stuff when the input happens to be a lattice.

Say I have a ProductPoset class which takes two posets and returns a
poset representing the cartesian product (is this already in Sage?). I
might very well in real life research use this construction with both
sides being lattices, in which case the product is a lattice (right?).

Thus ProductPoset.is_lattice should be overrriden and look something like

  def is_lattice(self):
  if self.left_poset().is_lattice() and self.right_poset().is_lattice():
  return True
  else:
  #More complicated logic perhaps



 Some of the unnecessary re-computation might be alleviated by using 
 @cached_method on strategic methods, such as join_matrix() and 
 meet_matrix(). You should strive for a design that is easy, comfortable 
 and efficient to use, for experts and novices alike. Don't rely on 
 strange things like unsetting private variables in order to get decent 
 performance.

 Yes, but should it be cached when creating a lattice or when first used? 
 (Of course the whole question arises because check for a poset to be a 
 lattice is done by computing meet- and join-matrix. I don't know if there 
 is some easier way for it.)

I imagine something like the following:

At lattice creation time you *usually* want to check to see that the
input *is* a lattice. So e.g. __init__() would call self.join_matrix(),
which would compute and cache the result for later use (automatically,
done by @cached_method).

If the check had been deactivated by the user or calling code, then the
user's first call to self.join_matrix() would compute the matrix.


 Then there should be implementation for AntichainPoset, BooleanLattice 
 etc. I guess that properties for those are already known, so they are not 
 used in real life other than testing algorithm, showing something to 
 students etc.

My derived constructions example above with ProductPoset is, I
believe, a reasonable example of why you would want trivial
constructions to have high performance on known properties.

But teaching and testing is not bad reasons either. It makes you able to
test on big, albeit simple, examples. And it's sort of embarrassing if
Sage has terrible performance on clearly trivial examples because it
uses squared, cubic or worse algorithms to compute something everyone
can do in their head.

We have the exact same issues in coding theory :-)

 Do Sage has normal users? Is somebody making goat cheese, and using Sage 
 to compute how many goats are needed for a given amount of cheese?

I don't know about goats, but definitely cows.

Anyway. I don't think that the basic needs from a computer algebra
system of a math enthusiast/student/researcher/farmer are that
different. All of them needs the trivial, basic things to be fast and
with lots of services such that they can be played around with, build
upon, and extended.

Johan

-- 
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] Functions returning sub-structure

[Johan S . R . Nielsen]

Jori Mäntysalo writes:

 At least for now we don't have parameter like 
 trust_me_i_know_what_i_am_doing=True for posets or lattices.

Such a parameter would make lots of sense, I think.

 This can be 
 seen for example with C500=Posets.ChainPoset(500), and after that even 
 C500.join(100,200) will take few seconds for first time. That means that 
 ChainPoset() makes a digraph, that is tested to be a poset, then tested to 
 be a lattice by creating join- an meet-matrix and then those matrices are 
 thrown away.

Wow, such terrible performance on trivial examples is surprising to me!
Would it make sense to make special sub-classes of FiniteLatticePoset
for the special cases, where join, meet, etc. is overwritten? It
depends, of course, on what people usually do with lattices (I'm not an
expert).

 (Funnier example is C500.is_lattice() taking few seconds, even if it's 
 class is lattice.)
??? Why is is_lattice not overwritten by FiniteLatticePoset?


 Yes, if the choises are - and will be - a list and a lattice. But maybe 
 somebody wants to return a poset or a set?

A lattice can be trivially converted to a poset or set. So if
construction of the lattice object is cheap, with the aforementioned
dont-check parameter, then returning a lattice seems better better.

Johan

-- 
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] Functions returning sub-structure

[Johan S . R . Nielsen]

Jori Mäntysalo writes:

 At least for now we don't have parameter like
 trust_me_i_know_what_i_am_doing=True for posets or lattices.

 Such a parameter would make lots of sense, I think.

 I have thinked about it. It needs some more thinking - how much should be 
 trusted? But at least for lattices it could just override the check of 
 DiGraph being a lattice. Posets are maybe harder part.

Trust fully. If the user willingly disables checks AND passes illegal
stuff, then it's the user's own fault. You see this in e.g. constructing
fields (where the irreducibility of the optional modulus can be
disabled)

The check would mostly be used in Sage source code for making conversion
and construction cheaper when the check is known to pass.


 ??? Why is is_lattice not overwritten by FiniteLatticePoset?

 I don't know if that would be used feature...

Perhaps we're misunderstanding each other. I mean, in the class
FiniteLatticePoset, I would add:

   def is_lattice(self):
   return True

Since any finite lattice poset is a lattice.

 But let's suppose that a 
 function f returns a poset with at least elements 1 and 2. We want to 
 print foo if the poset is not a lattice and join of 1 and 2 if it is.

 P = f(x)
 if P.is_lattice():
  L = LatticePoset(L)
  print L.join(1, 2)
 else:
  print foo

 First Sage tries to compute meet- and join-matrix to see if P is a 
 lattice. If it is, then they are computed again when making L from P. And 
 then third time - now only join-matrix - when printing join of 1 and 2.

 Advanced user migth say try: L = LatticePoset(P) and catch ValueError. So 
 maybe for is_lattice() it is good to throw away just computed matrices. 
 But when creating a lattice it feels unnecessary. Why to make a lattice if 
 not for computing meets and joins? And in any case advanced user can say - 
 after reading the code - something like unset(L._meet) or so.

Some of the unnecessary re-computation might be alleviated by using
@cached_method on strategic methods, such as join_matrix() and
meet_matrix(). You should strive for a design that is easy, comfortable
and efficient to use, for experts and novices alike. Don't rely on
strange things like unsetting private variables in order to get decent
performance.

In rethinking how linear codes should be represented in Sage, we had the
issue of when certain properties for codes were computed, including
really basic ones that are very often used (e.g. generator matrix). We
opted for making initialisation of codes as cheap as possible, i.e. no
unnecessary construction or computation. This way the user can create
thousands of codes in a loop, as long as the methods he is calling on
these codes do not compute the expensive stuff.

In posets and lattices there seems to be similar issues with
e.g. initialisation of the hasse diagram. For many special poset
constructions, e.g. chain posets it's not actually necessary to
construct the Hasse diagram most of the time. Rather for most methods,
like meet and join, you could override the implementation (if chain
posets had their own class), and provide more efficient implementations
that did not use the Hasse diagram.

But since I'm not an expert in posets and lattices, perhaps this is
overengineering it?

Johan

-- 
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] Functions returning sub-structure

[Johan S . R . Nielsen]

I think that the default of returning a sublattice makes most sense by far.

In case the speed difference is very significant (why would this be the
case?), one could add an optional argument to the function to just
return a list. Could be named as_list = False, I guess.

Johan

Jori Mäntysalo writes:

 I am making functions to compute, for example, maximal sublattices or
 Frattini sublattice of a lattice. It is somewhat faster to return only
 list of elements instead of lattice. What you think, should the function
 return

 1) a sublattice, ready to use as a lattice for further computations;
 user might say .list() when only list of elements is needed, or use
 directly function from hasse_diagram.py if more speed is needed,

 2) a list; user can say orig_lattice.sublattice(result) when really
 the lattice is needed, or

 3) both?

 If 3, what should be the name of the parameter. At least 
 element_constructor is used somewhere, but I think there is also some 
 other names used.

-- 

-- 
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] Re: Jobs involving SageMath

[Johan S. R. Nielsen]

+1. Such a page is very nice to have, and even nicer to link to from the 
main web page. The wiki, unfortunately, as a marketing page is not very 
pretty (not at all as pretty as the job offer page for the OpenDreamKit 
positions, for instance).

I added some information on the coding theory project, and divided the list 
into Open and Past offers.

Johan 

On Saturday, June 6, 2015 at 9:50:52 PM UTC+2, Samuel Lelievre wrote:

 Hi all, I created a jobs page on the SageMath wiki:

 http://wiki.sagemath.org/jobs

 I think it adding a link to that page on the sagemath.org
 homepage would make sense, what do you think?

 I also noticed that SageMath has a LinkedIn profile

 https://www.linkedin.com/grp/home?gid=2010654

 with a corresponding jobs page:

 https://www.linkedin.com/groups?jobs=gid=2010654trk=anet_ug_jobs

 Who is maintaining this LinkedIn profile?
 Could they also add a link to the wiki jobs page
 from the LinkedIn jobs page?

 Any other ideas for websites, mailing lists,
 social networks where to circulate the
 job announcements?

 Samuel


-- 
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] What is the parent() of a vector from a subspace?

[Johan S. R. Nielsen]

On Wednesday, June 3, 2015 at 11:02:42 PM UTC+2, David Roe wrote:


 For a vector space V over an inexact field, the statement that a vector v 
 belongs to a particular subspace W cannot be checked by examining an 
 approximation to v in V.  For example, (2 + O(3^50), 4 + O(3^50)) may or 
 may not be in the span of (1 + O(3^50), 2 + O(3^50)).  A better way to 
 record the precision of v is by a lattice inside W.  In the above example, 
 you could just say that the x-coordinate has uncertainty O(3^50) and that v 
 lies in the span of (1,2).  In order to enable this, you really want to be 
 able to set W as v's parent.  There are plenty of ways to get a vector in V 
 if this isn't the behavior you want.
  

  I don't think I understand what you're saying. If I do the following in 
Sage:

R = pAdicField(3)
V = R^2
W = V.subspace([vector(R, [R(1), R(2)])])
v = vector(R, ( R(2), R(4) ))
print v in W
print v.parent()== W
it prints

True
False

So v is considered a vector in W even though it doesn't have W as parent. 
Thus, when it comes to determining subspace membership we don't need to set 
the parent of W's vectors to W in order to retain the current behaviour. Or 
there's something I'm not understanding?

Johan

-- 
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] What is the parent() of a vector from a subspace?

[Johan S. R. Nielsen]

What is the sensible notion of parent() for a vector that I drew out of a 
vector subspace?
For instance, what should be printed by the following lines?

VS = (QQ^3).subspace([ (1, 1 ,1) ])
v = VS.an_element()
print v.parent()

One possibility is that QQ^3 should be printed. Alternatively, and the 
current behaviour of Sage, is to return the vector subspace VS as the 
parent.

This surprises me at least. I think of parent() vaguely in the general 
sense of type (not Python's primitive notion of type, of course, but a more 
advanced type
system). By that logic, I would say that the vector v above is foremost of 
the type QQ^3 element. It also happens to be in many vector subspaces of 
QQ^3 but
that doesn't matter. But there might be a bigger picture I'm not seeing 
here.

What do people say?

[ ]: Vectors drawn from a subspace have that subspace as parent.
[ ]: Vectors over R^n should have R^n as parent, no matter where they came 
from.


This relates to the thread 
https://groups.google.com/forum/#!topic/sage-devel/rvs5E6AEXVc and to what 
should be patched to avoid the surprising behaviour mentioned there. More 
precisely, if the current parent-behaviour should be retained, a check 
should be introduced when modifying copies of vectors from VS. If the 
parent-behaviour is changed, however, no other patch is necessary.

Best,
Johan

-- 
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] Full-time Sage developer position opening at Université Paris-Sud for Fall 2015

[Johan S. R. Nielsen]

Awesome news. Congratulations on the project!


On Tuesday, June 2, 2015 at 12:30:47 AM UTC+2, William wrote:


 This is a preliminary announcement for a full time Sage developer
 position 


 ... the first such position ever! :-)


  No... The coding theory in Sage project has been running for a little 
more than six months now, with David Lucas as full-time Sage developer:
https://bitbucket.org/lucasdavid/sage_coding_project/wiki/Home

-- 
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] Re: Vector weirdness: to be or not to be immutable

[Johan S. R. Nielsen]

Thanks for the clarifications, Vincent.

On Wednesday, May 27, 2015 at 10:36:31 PM UTC+2, vdelecroix wrote:

 What I suggesteded is to modify the code of vector subspace in such way 
 that the elements have parent the ambient space and not the subspace. 
 Which is precisely related to the end of your e-mail. 


Frankly, I completely agree. But that could have implications for many 
users in many places. Is the current behaviour a result of long discussions 
and thought? Should more people chip in before we rush in and change this?
 


 For your sided question, the fastest way is to use Element._set_parent()  
 ...

Ok, thanks.
 


 The question in your case is rather do *you* *want* that the elements 
 have parent the linear code? 


Ok, clear explanation and very good question. I certainly don't want the 
parent to be the vector subspace (as now); it should either be the full 
vector space or the code. I think the former makes most sense, but that's 
due to the same logic as above for vector subspaces...

Johan
 

-- 
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] Vector weirdness: to be or not to be immutable

[Johan S. R. Nielsen]

Hi Sage-devel

We just crashed our heads against a bug in our code due to extremely weird 
semantics of Sage. Consider the following code which creates a sub-space C 
of the four-dimensional vector space over the binary field, and then 
modifies a *copy* of a vector from the subspace:

F = GF(2)
VS = F^4
C = VS.subspace([ (F.one(),F.one(),F.one(),F.one()) ])
w = C([F.one(),F.one(),F.one(),F.one()])
y = copy(w)
y[0] = F.zero()
print y's parent is , y.parent()
print y is in C: , y in C
print y = , y

The code above is going to print:

y's parent is  Vector space of degree 4 and dimension 1 over Finite Field 
of size 2
Basis matrix:
[1 1 1 1]
y is in C:  True
y =  (0, 1, 1, 1)

So even though y is clearly not in our space C, Sage claims it is. The 
reason is that y's parent is still this sub-space.

Sage disallows that we modify w, the original vector from C. But we are 
allowed to modify the copy y (even encouraged by a warning that Sage prints 
when you try to modify c).

I assume everyone agrees the above behaviour is bad? In that case, what is 
the bug?

- Is it that the copy of c is allowed to be mutated (for instance, without 
first casting it into the ambient vector space)?

- Is it that the parent of y is still C immediately after copying?

- Or is it that the parent of y is still C after modification? 

- Or a fourth option I didn't think of?

Best,
Johan

-- 
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] Re: Vector weirdness: to be or not to be immutable

[Johan S. R. Nielsen]

 The behavior is bad but I would not call it a bug. You modified wrongly 
 the vector. 

I disagree: from a user-point of view, a superficially perfectly reasonable 
sequence of steps were taken, at the end of which Sage prints a result 
which is mathematically incorrect, without any error or warning. That 
should never happen! Even for an *unreasonable* sequence of steps.

 If it was me I would set the parent to be the ambient space and not the 
 subspace itself (but it might break a lot of code). 

Is the best/fastest/safest way to do this to cast this to the full vector 
space? I.e. something like

  y = VS(c)


On Wednesday, May 27, 2015 at 10:02:24 PM UTC+2, Volker Braun wrote:

 IMHO the bug here is a lack of validation. Its perfectly fine to have 
 mutable elements of a vector subspace, but y.__setitem__ should then check 
 that the vector really is in the subspace or raise a ValueError. Of course 
 it would almost always raise, so its not a particularly useful operation.


I agree, that's a possibility which is general and makes sense.

On a more general note, what is the rationale for defining the subspace - 
and not the full vector space - as the parent of the vectors? The vector is 
in many subspaces, and the user just happened to construct it from one of 
them; but it's just as much part of the other subspaces. I find it somehow 
slightly arbitrary that this type of sub-structure -- vector space 
subspaces -- become parents like this. Are there other examples? Perhaps 
I'm not seeing the bigger picture here.

In coding theory there's an echo of the same thing: a codeword of a linear 
code is a vector which is in the code (the code being a vector subspace). 
Currently, when you ask for a codeword of the code, you'll get a vector 
whose parent is the subspace (and not the LinearCode object). This actually 
surprised me, as I expected the parent to be the full vector space. To be 
consistent, should we change it so that the LinearCode is the parent of the 
codewords?

Johan

-- 
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] Re: [debian] Strange numerical errors in sage's libpari code

[Johan S. R. Nielsen]

On Saturday, February 21, 2015 at 3:42:28 AM UTC+1, Michael Orlitzky wrote:

 On 02/20/2015 11:02 AM, kcrisman wrote: 
  
  
  I no longer use sage for my day-to-day work, but when I was and I had 
 to 
  e.g. give a presentation, it was infuriating to find sage broken AGAIN 
  
  
  ??? I assume this is because you updated some dependency and Sage didn't 
  work quite properly somewhere in its bowels with that?  I've never once 
 had 
  that happen with Sage on Mac, since it is a distribution by necessity 
  there. To me that sounds like an argument for installing 
  sage-the-distribution, because I assume this could happen with any 
 software 
  that has a dependency, before upstream had repackaged based on that 
 updated 
  dependency.  I may be misunderstanding something in your argument, 
 though. 
  

 It happens when I update something that is a sage dependency, but for 
 which there is no spkg. 

 All of the C code that we ship depends on glibc, but we don't ship an 
 spkg for glibc. When I update glibc, sage begins to segfault until I 
 rebuild every spkg and the sage library. 

 There are two ways to fix that: first, we could bundle literally an 
 entire Linux distribution down to the kernel. Or, we could make sage 
 play nice with package managers and let the package manager reinstall 
 (i.e. rebuild) any parts of sage that are broken by the update. 

 The first solution duplicates an enormous amount of effort that Linux 
 distros have already put forth. It makes the sage download half a 
 gigabyte instead of a few megabytes. It creates security problems -- now 
 I have two version of openssl on my machine, and nobody updates the sage 
 copy. It causes the sage build process to take 4 hours instead of 5 
 minutes. It makes installation much harder for users who are used to 
 doing yum install sage. It ensures that system administrators won't go 
 near it, so sage can't be installed once globally on the department 
 server. 

 The second has none of those problems, but we can't depend on silent 
 forks of packages. I don't think there are very many packages where we 
 really need to have a full-fledged fork. Pari may be one of them, who 
 knows. But if we need to fork it we should just fork it and rename all 
 of the libs and get it over with. 

  
I find that really surprising! I run Arch linux so more or less all 
packages are upgraded on a weekly to monthly basis. Besides the package 
manager, I keep a
stable installation of Sage that I don't touch so often, maybe for 6-9 
months at a time, so that I always have something on which to do 
computations. I have
never once experienced segfaults as you describe...

-- 
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: Coding Theory development project. Request-for-comments: New code family and encoder/decoder structu

[Johan S. R. Nielsen]

Hi sage-devel,

An update from our coding theory development project.

On Friday, February 20, 2015 at 6:24:01 PM UTC+1, Johan S. R. Nielsen wrote:

 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

[sage-devel] 2-year project with full-time software developer for improving coding theory in Sage

[Johan S. R. Nielsen]

Hi sage-devel
This is to announce and get some feedback on the start of a Sage 
software-development project.

This spring, Daniel Augot, Clément Pernet and I got funding from INRIA for 
hiring a full-time software developer for two years to work on extending 
the coding theory functionality in Sage. We have hired David Lucas, who 
just started 1st October, and is already working on getting an overview of 
coding theory and Sage.

The aim of the project is to implement a much larger basis of functionality 
for coding theory which is flexible, modular and useful for the many facets 
of coding theory: algebra, combinatorics, engineering, cryptography, etc.

The current status is that there are many useful functions from a mostly 
combinatorical viewpoint. From an algebraic viewpoint, though one can 
construct the generator matrix of e.g. a Reed--Solomon code, there is no 
specific class or functionality which investigates such a code from its 
algebraic perspective (e.g. a fast decoder). We would like to implement 
such things and many other.

We would like to discuss all details with the community, and we also hope 
that this project will get a ball rolling, reinvigorating the interest in 
Sage for the coding theory community. Most of these discussions are better 
taken on sage-coding-theory, since they will be quite specific to the field.

It is my impression that such a full-time developer for Sage is a rare 
thing, and we have been thinking on how best to proceed and communicate 
goals and progress.

Of course, all code will go through the Trac and thus indirectly progress 
is tracked. However, since this will be longer-running thing, our plan is 
to make a dedicated (small) web page with a road map as well as an overview 
of already written functionality (which is furthermore annotated as already 
included in Sage or not). This is not a blog, but just an overview for 
new-comers, people interested in the development, or people who previously 
rejected Sage for coding theory use but who might now reconsider it.

One thing we have been thinking about how to handle well is development in 
parallel with the ticket/review system. Since David is working full-time, 
he will be producing a lot of code, and there will all the time be a 
significant backlog in the review process. Our fear is that juggling a 
cobweb of ticket dependencies might become clumsy if not handled well. Do 
people have ideas for handling this well?

We expect that within 2-3 months, David has made the main refactorings of 
the existing coding theory functionality, and extended it in various ways 
to exercise the new structure. This will most likely be more or less 
internal (not on Trac). After this, he will start posting these changes to 
Trac, while in parallel continuing to develop more new functionality.

Regards,
Johan S. R. Nielsen

-- 
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-coding-theory] Re: [sage-devel] Re: 2-year project with full-time software developer for improving coding theory in Sage

[Johan S. R. Nielsen]

Thanks for the feedback everyone! I'll try to comment on some of the things 
mentioned.

Indeed. I do not know if what you have in mind about coding theory somehow 
 overlaps with combinatorial designs (in particular orthogonal arrays/BIBD 
 :-P) but it would be nice to shake those areas of Sage anyway.

What we really feel is lacking right now (with respect to our own research 
areas) is a structured (i.e. object oriented, modular) way to deal with 
families of error-correcting codes, from various angles. Thus, the main 
priority is to introduce such a structure, as well as expected 
functionality for the most familiar families of codes (e.g. those everyone 
meets in a graduate course on coding theory). We are not combinatorists, so 
we know this angle poorly. Please join the discussions about structure etc. 
when we do this on sage-coding-theory 
https://groups.google.com/forum/#!forum/sage-coding-theory to make sure 
what we come up with makes sense from that angle!
 

 Make many small tickets. The best way to not have many dependencies is to 
 have your code integrated into the successive beta versions of Sage, this 
 way your 'current code' will never be too far from the develop version.  


 Whatever happens, please, don't come some day with 3Mb of changes. Respect 
 our development process: write tickets, get them reviewed. Writing code 
 takes much longer than reviewing it, so if the three of you can work by 
 reviewing the code he writes everything will run smoothly.

 Also, each commit message should begin with trac #number:, otherwise it 
 is a mess to know which commits belong to which ticket when you have many 
 dependencies.


Thanks, this is good advice. We are very aware of the threat of patch-bomb 
- this will not happen, I promise. However, in the very beginning (and only 
here) we will play around the OO-structure until we feel sure that it works 
as we would like. We'll discuss details on sage-coding-theory. Once we're 
preliminarily satisfied, we'll brake it into logical pieces and make 
tickets. After that, the new functionality will all be implemented as 
tickets directly.
 

 Once more: please, don't try to shortcut the review process. Play it fair. 
 Don't develop everything in your office only to come back later expecting 
 us to merge everything at once without reviewing it. Please create tickets, 
 please discuss the implementations on the tickets, please review 
 everything. Sage's review process makes things slower, but if you are 3+1 
 to be interested in this project you have the manpower (and the will) to do 
 this properly.


We were actually concerned that it would be regarded as too inbred if we 
review David's code? 
 

 I will be glad to help whenever I can. It sure is a a good news.

Cool :-D

Working with Vincent on Combinatorial Designs (many tickets between beta 
 releases) taught us that it is better to 'artificially' order all tickets 
 linearly. Each ticket should have a successor and a predecessor, and they 
 should all be linearly ordered. It is tempting to let some branches be 
 independent, but if for some reason you find out later that they still 
 interact somehow it will create a *LOT* of mess if you already have tickets 
 based on those two branches.

Hmm, this is a very interesting idea. We'll think about doing something 
like this.

This is great news! Is there any plan to implement semaphore codes in the 
 near future (see the book by Jean Berstel 
 http://www.goodreads.com/author/show/399140.Jean_Berstel, Dominique 
 Perrin http://www.goodreads.com/author/show/926712.Dominique_Perrin, 
 Christophe 
 Reutenauer 
 http://www.goodreads.com/author/show/399139.Christophe_Reutenauer on 

Codes and Automata)? This would be super useful!

Sorry, that's not in our road-map currently. The project will be centered 
around error-correcting codes, with a focus on algebraic coding theory. 
We'll also be touching upon the cryptographic applications (e.g. McEliece 
cryptosystem).

Also important: start small, fix a few bugs just to get used to the Sage 
 development model.

Yes, this is important. That's on David's todo-list for next week :-) 

Try to make this person attend a Sage Days early on. 

Good idea! We'll keep an eye out for one which fits. Also, there is the 
GroupeUtilisateursParis http://wiki.sagemath.org/GroupeUtilisateursParis 
which he should join.

The goal should be to have code with *positive_review*, not just to have 
 code. There is no point in continuing to produce more code if there are 10 
 needs_work tickets. 

 Totally agree! But there might well be 10 needing_review tickets :-)

I think it would also be a good idea to get in contact with the matroids 
 folk who got a lot of code integrated into Sage some time ago. Or even 
 better with Eric Gourgoulhon whos currently writing a lot of code for his 
 project and getting it integrated into Sage piece by piece. On top of that 
 he's not so far away from Polytechnique...

Thanks, we'll look 

Re: [sage-coding-theory] Re: [sage-devel] Re: 2-year project with full-time software developer for improving coding theory in Sage

[Johan S. R. Nielsen]

Repost from sage-coding-theory, by Daniel Augot:

This is great news! Is there any plan to implement semaphore codes in the 
 near future (see the book by Jean Berstel 
 http://www.goodreads.com/author/show/399140.Jean_Berstel, Dominique 
 Perrin http://www.goodreads.com/author/show/926712.Dominique_Perrin, 
 Christophe 
 Reutenauer 
 http://www.goodreads.com/author/show/399139.Christophe_Reutenauer on 

Codes and Automata)? This would be super useful!

Sorry, that's not in our road-map currently. The project will be centered 
around error-correcting codes, with a focus on algebraic coding theory. 
We'll also be touching upon the cryptographic applications (e.g. McEliece 
cryptosystem).

That is part of our road-map, but inside our road map, we have that we want 
to discuss and interact with people interested in coding theory in Sage, to 
identify various needs. It's open. 

But yes, most of our concerns will be centered around the algorithmic 
aspects of coding theory, be it for coding theory per se, cryptography 
(there is more than McEliece : proof of retrievability, proof of ownership, 
etc), theoretical computer science, math investigation.

Concerning matroids, designs, sphere packings, lattices and other domains 
connected to coding theory, since we have  man power, and time, we will try 
to be  as much as possible consistent with the existing APIs or interfaces, 
to avoid users  converting objects between different classes.

-- 
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] 2-year project with full-time software developer for improving coding theory in Sage

[Johan S. R. Nielsen]

Hi sage-devel
This is to announce and get some feedback on the start of a Sage 
software-development project.

This spring, Daniel Augot, Clément Pernet and I got funding from INRIA for 
hiring a full-time software developer for two years to work on extending 
the coding theory functionality in Sage. We have hired David Lucas, who 
just started 1st October, and is already working on getting an overview of 
coding theory and Sage.

The aim of the project is to implement a much larger basis of functionality 
for coding theory which is flexible, modular and useful for the many facets 
of coding theory: algebra, combinatorics, engineering, cryptography, etc.

The current status is that there are many useful functions from a mostly 
combinatorical viewpoint. From an algebraic viewpoint, though one can 
construct the generator matrix of e.g. a Reed--Solomon code, there is no 
specific class or functionality which investigates such a code from its 
algebraic perspective (e.g. a fast decoder). We would like to implement 
such things and many other.

We would like to discuss all details with the community, and we also hope 
that this project will get a ball rolling, reinvigorating the interest in 
Sage for the coding theory community. Most of these discussions are better 
taken on sage-coding-theory, since they will be quite specific to the field.

It is my impression that such a full-time developer for Sage is a rare 
thing, and we have been thinking on how best to proceed and communicate 
goals and progress.

Of course, all code will go through the Trac and thus indirectly progress 
is tracked. However, since this will be longer-running thing, our plan is 
to make a dedicated (small) web page with a road map as well as an overview 
of already written functionality (which is furthermore annotated as already 
included in Sage or not). This is not a blog, but just an overview for 
new-comers, people interested in the development, or people who previously 
rejected Sage for coding theory use but who might now reconsider it.

One thing we have been thinking about how to handle well is development in 
parallel with the ticket/review system. Since David is working full-time, 
he will be producing a lot of code, and there will all the time be a 
significant backlog in the review process. Our fear is that juggling a 
cobweb of ticket dependencies might become clumsy if not handled well. Do 
people have ideas for handling this well?

We expect that within 2-3 months, David has made the main refactorings of 
the existing coding theory functionality, and extended it in various ways 
to exercise the new structure. This will most likely be more or less 
internal (not on Trac). After this, he will start posting these changes to 
Trac, while in parallel continuing to develop more new functionality.

Regards,
Johan S. R. Nielsen

-- 
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] Re: GSoC New decoding error-correcting codes algorithm for Sage

[Johan S. R. Nielsen]

Hi Veronica,

This seems really interesting. How is progress on your project?

I work in algebraic coding theory myself, and I have been writing lots of 
Sage code for this. Most of it is generally useful, but I have not had time 
to add it to Sage proper, since that would require restructuring a lot of 
Sage's current error correcting code functionality (where a code is just a 
generator matrix and all known structure is thrown away).
My library is released as GPL and is available at
www.jsrn.dk/codinglib

Most functionality is related to algebraic codes such as Reed--Solomon 
codes and Goppa codes, as well as algebraic decoders for these. If any of 
it is useful for your project, then don't hesitate to use it. I have also 
been thinking how error correcting codes could be better represented in 
Sage, and if you have such concerns with your project, I would gladly join 
discussions.

Best,
Johan S. R. Nielsen


On Thursday, May 30, 2013 5:48:38 PM UTC+2, Verónica Suaste wrote:

 Hi all,

 I'm Verónica, an undergraduate math student. I'm glad to share with you 
 the fact that my project for GSoC 2013 has been selected. The main idea of 
 these work is to implement new decoding algorithm of linear codes and make 
 this contribution to Sage. 
 You can check the full proposal in this link Project 
 proposalhttp://broniks.blogspot.mx/2013/05/blog-post.html. 
 This blog will be updated with any progress about the project.
 I'll be glad to hear any comment or suggestion from you. So please, just 
 let me know.

 Also, it is very likely I'll be attending the next Sage Day in Seattle. 
 Which I consider a good start for this project.
 Hope to meet some of you there!

 Cheers,
 Verónica.


-- 
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] Re: Representation of finite field elements

[Johan S. R. Nielsen]

Wow, this opened up a can of worms I hadn't expected, but reading your
comments, I really agree.

 When I was working on similar issues for printing real numbers (i.e.,
 whether to truncate digits, etc.), Carl Witty brought up a very good
 point.  Printing representation options should be global session-wide
 defaults that apply to all output in a session, rather than options
 stored with the objects.  For example, it seems better to do something like:

 sage.print_options['finite field repr']='int'

 or

 sage.rings.finite_rings.finite_field_base.printing_style='int'

Yes! That would be a much better way of doing it. And then thinking it
through to make sure that it could work in all the places we would
like such a thing.

 You need to be careful that the generator, which currently is only
 required to have irreducible characteristic polynomial over the base
 field, is actually a multiplicative generator for the field:
 sage: R.x = ZZ[]
 sage: k.a = GF(49,modulus=x^2+5*x+2)
 sage: a.multiplicative_order()
 24

 I certainly like generator^exponent more, but we can't use the
 same name here as for the generator above.  Maybe we should have
 mult_gen_name as an option to pass to GF, with a sensible default?

I didn't realise that. That probably saved me some hours in debugging
sometime in the future ;-) Is it completely insane to change the
default field constructor to always return a multiplicative generator
instead of the above (polynomial?) generator? The above concept
certainly decreases the usefulness of printing generator^exponent. I
think it would be quite unintuitive if the user saw something like
 sage: R.x = ZZ[]
 sage: k.a = GF(49,modulus=x^2+5*x+2)
 sage: a
 beta^10
assuming that beta was the sensible default mult_gen_name. On could
of course also output
 sage: a
 (5*a+3)^10
seeing as 5a+3 is a multiplicative generator of k, but I'm not sure
we're really helping things here...

 In fact, I think it makes sense to have printing objects inherit from
 each other, so that we don't have to continually write code like
 ' + '.join([%s * x^i%(c.list()[i] for i in range(len(c.list()))])
 and make sure to debug all the corner cases.

Yes! Alternatively/Relatedly, use a sort of interface for printing
objects that print utility functions could use. In the above example,
useful features to ask for is when the exponent is 0 or 1, and whether
the coefficient needs parentheses around it. There are, as you point
out, _many_ places in the sage source code that implements printing
polynomial-like objects, and they all have special handling of various
cases. Would be nice to unify.

Cheers,
Johan

-- 
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] Representation of finite field elements

[Johan S. R. Nielsen]

Hi all
I work a lot with finite fields and polynomials over these, and the
standard string representation of finite field elements as polynomials
is not very convenient for me; I would much prefer to represent each
non-zero element as a power of the field's generator. I am having
trouble making the Sage Notebook do this for me.

Givaro fields support in their constructor an argument repr which
should set the standard representation of the elements. The
possibilities are log, int and poly. poly is the standard and log is
close to what I want. However, there are some issues with log: it
makes the str representation of a field element be just an integer
representing the power of the field generator (with the convention
that 0 is the 0 element and F.cardinality -  1 is the 1 element),
while I would like a string like generator^power and 0 for the
zero element. I have written a small patch to make it work like I
want.

More importantly, though, it seems that the Notebook does not use this
representation hint at all when showing field elements!
I have tried writing a patch for
sage.rings.finite_rings.element_givaro adding a str-method and repr-
methods with both one and two underscores around the name, but that
does not help. It works in the shell. Which method does the Notebook
call for representing finite field elements?

If someone can help me find this function so I can write a patch on my
machine, we could take up the discussion on whether it could be
sensible to let the above representation of finite fields be the
standard when specifying repr = 'log'.  Or even the standard
representation when not specifying repr?

Thanks and regards,
Johan

-- 
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] Re: Representation of finite field elements

[Johan S. R. Nielsen]

On Dec 12, 11:35 am, javier vengor...@gmail.com wrote:
 Hi Johan,

 do you have the typeset box checked in your notebook?
 If so, then things are displayed using the latex method
 instead of the repr one.

 Cheers,
 Javier

OF COURSE! Thanks for telling me. I would have thought that I had
enough Sage-experience to figure that out myself by now, but oh
well...

So now I have hacked together a patch that works as I will it, both in
the shell and notebook. I think it is a bug that the latex
representation currently ignores the repr-value of the finite field.
What do you other say?

And as long as we're on the subject, should we change the behaviour so
that when repr='log', what is output (both with _repr_ and _latex_) is
generator^exponent instead of just exponent as it is now?

Lastly, is it by general consensus that the default representation is
the polynomial representation, or could one consider to change the
default representation to be exponent of the generator? That is,
change default from repr=poly to repr=log? Log representation
seems to me to be much more useful and gives better overview for
humans that read it, as well as being much more condensed when
outputting e.g. polynomials or matrices.

Cheers,
Johan

-- 
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] Re: Asymptote (vector graphics language)

[Johan S. R. Nielsen]

On Oct 10, 10:40 am, Jason Grout jason-s...@creativetrax.com wrote:
 On 10/9/11 3:19 AM, Jeroen Demeyer wrote:

  On 2011-10-08 01:36, jsymons wrote:
  Maybe some of you, based on the experience of using it, could explain
  better than me what are the advantages/disadvantages with respect to
  Tachyon renderer.
  I think it is something very different from the Tachyon renderer.
  Tachyon is a ray-tracing for 3D rendering, Asymptote is a vector drawing
  language.  So I guess we should compare not with Tachyon, but with
  LaTeX+TikZ.  As far as I know, we do use TikZ in Sage and I don't
  immediately see a compelling advantage to switch to Asymptote.

 Asymptote does 3d graphics as well, so that is why it should be compared
 to Tachyon.  If Asymptote generated 3d *vector* graphics (unlike
 Tachyon, and like the matplotlib 3d engine), I could see it adding
 something of real value to Sage.  But from what I saw of the examples
 online, it appeared that the pdf files of 3d graphics were simply
 bitmapped graphics wrapped in a pdf file.

 As for 2d graphics, matplotlib already generates pdf, ps, svg, etc., so
 we already have a very powerful 2d vector graphics solution we use.  How
 does Asymptote compare with matplotlib for 2d graphics, and does someone
 want to add a new backend to our 2d graphics facilities for Asymptote?

 Also, if it's not callable as a library yet, it may be too soon to have
 this discussion (especially since we already have a nice library-based
 solution for 2d graphics, like matplotlib).

 Thanks,

 Jason

It seems to me that one of the coolest things about Asymptote -- an
actual programming language with (simple) equation solving -- is
already in Sage, which means that it would be somewhat superfluous to
have it in the drawing engine as well. One could argue that then the
Sage interface could be smaller, lines-of-code-wise, but on the other
hand, we would need a huge range of Sage functions to wrap the entire
language of Asymptote. This kind of defeats the purpose for both
developers and users. I would be more for putting the extra effort
into making more customisable and complex functions for matplotlib,
taking advantage of the fact that we are already in a powerful math
and programming language.

But yeah, if it could generate 3d vector, then I would be more for
it :-) Is there even a file-format for supporting this well, though?
For example, if it had to be saved in SVG, one would need to
approximate shading and color-transitions using linear and radial
gradients as well as blurring, I believe. Probably not very easy...

Regards,
Johan

-- 
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] Re: MATLAB: viable alternative...?

[Johan S. R. Nielsen]

 Seems this thread *has* been hijacked.  ;-)

Just want to add my opinion, which belongs in some void between the
original thread and the hijacked one ;-)

I am a ph.d. student in algebra, but have a background in computer
science. I don't do much numerics anymore, so I'm not exactly the
right person to ask, but I do hang around with a lot of numerics
people. So far, I agree with some of the very insightful comments on
the problems with working numerically in Sage *once you got the
matrices* that has come up (like the posts from Jordi Hermoso, Chris
Godsil and Tim Lahey).

However, I really don't believe that the current matrix-construction
syntax is what is seriously keeping Matlab people away from Sage --
and if it is, then that's simply silly! Comparing

M = [1 2;
 3 4;
 5 6]

with

M = matrix(RR,2,3,[
1, 2,
3, 4,
5, 6 ])

that's a very small syntax price to pay for 1) unambiguous,
straightforward syntax 2) complete control of element space. I always
disliked Matlab for its happy-go-lucky, ambiguous syntax, and I think
it is unnecessary to make specialised, ad-hoc syntax in Sage for (2D)
matrices (over X-bit floats).

My impression from my own math department is that a lot of Matlab
users know more or less only Matlab as a programming language, and
that they have always used this, and their advisor also used/s this.
They have the opinion that it is really difficult to learn a new
language, and will dislike *any* difference between Matlab and
Alternative X, no matter how minute (much like Jordi mentioned
earlier). I think it would be silly to start introducing Matlab syntax
and renaming functions to look as much as possible like Matlab for
this reason. The ex-Matlab users would not stop complaining until Sage
was a completely compatible superset of Matlab anyway.

On the other hand, I think it would of course think it would be great
if all functionality needed for numerics people would be readily
available in Sage. Though not at the expense of a dichotomised syntax
and namespace to cater for Matlab devotees. In time, I think this
would make people migrate to Sage because of expense, ideology and
functionality.

Cheers,
Johan S. R. Nielsen

-- 
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] Fixed: Decorators ruining documentation

[Johan S. R. Nielsen]

Hi everyone

Can someone please review ticket #9976; its patch has been there for
~6 months now.
It fixes a problem with decorators and Sphinx: as it is now, most
decorated functions will get a generic signature in the Sphinx
documentation. Notable examples include most of the plot commands,
e.g.
  http://sagemath.org/doc/reference/sage/plot/plot.html#sage.plot.plot.plot
as well as any function decorated with the deprecated-decorator
(used for deprecating named arguments).

The ticket introduces a new way of handling this by slightly patching
Sphinx and including extra information in the sage_wraps decorator.
The latter is an extension of the pure Python wraps decorator, which
is already mandatory to use in decorators meant to decorate top-level
callables.

Cheers,
Johan

-- 
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] Re: Proposal - Add notes of verification as comments to doctests

[Johan S. R. Nielsen]

On Mar 14, 10:58 am, Volker Braun vbraun.n...@gmail.com wrote:
 On Monday, March 14, 2011 6:13:54 AM UTC, Dr. David Kirkby wrote:

  1) A doctest should have a comment by it, referencing the trac ticket where
  the
  test was added. In other words, just simply Trac #1234 if the test was
  added
  on ticket 1234.

 In the few cases where the doctest was a contentious issue or we previously
 found some subtle problem with it, then its great to have a trac reference
 where more details are recorded for posterity. But the majority of the
 doctests do test rather fundamental functionality. Then I don't see the
 point of littering trac reference all over the place just so that you don't
 have to look into the mercurial log to find the original author and
 reviewer.

 2) Either the author or reviewer should justify the doctest



 Again, a lot of doctests are just checking that some object can be
 constructed as intended. What are the author/reviewer supposed to justify?
 The justification is implicit in the code. If, on the other hand, your
 doctest proves the four color theorem then a reference would be in order. It
 all depends on the specific doctest.

 Elementary tests of functionality or anything thats obvious to an expert in
 the field shouldn't require justification. The remaining 10% or so should
 have some explanation or be written in a way that the whole doctests
 performs some consistency check.

  .

  Or do you believe its fine to have a test, which nobody can justify?

  --
  A: Because it messes up the order in which people normally read text.
  Q: Why is top-posting such a bad thing?
  A: Top-posting.
  Q: What is the most annoying thing in e-mail?

  Dave

Doctests are attempting to fulfill two goals:
1) Demonstrate the purpose of the method/class etc.
2) Test that it works as expected.

I think that the focus for them should be on satisfying 1). Satisfying
2) -- as David has often brought up -- is a hard problem and often
requires a lot of code and intricate examples. Putting complicated
tests within the source code clutters the code and confuses users
trying to read the documentation. The doctests should be chosen so as
to maximise understanding for the reader.

However, I am very much with David on the notion of better and more
thorough testing of the code; also on clarifying what has been tested,
and why the tests are correct. But we shouldn't use doctests for this.
I think we should have a separate library of tests, structured in
modules just as the code, which can contain as many and as complicated
and intricate tests as code authors and reviewers wish to write.
Personally, I write many tests in parallel with my code, because I
know I will want to make sure that my code works anyway; doing this in
the notebook or terminal manually is a waste of time: as soon as I fix
one bug, I have to manually redo all the tests again. So I write these
in Sage scripts instead, which can easily be rerun. They could easily
be uploaded with the patch as well.

At least a few of the points given against David's suggestion would
disappear with such a system, as all the detailed tests (basically
almost anything not falling in #1) would be put in this separate
testing library. Thus, it would not clutter up the source code or
confuse users trying to learn this functionality in Sage. It would
also make it more acceptable to write stronger (in the sense of
testing) but less readable and pedagogic tests.
I don't think we should require that such thorough tests should be
written for every patch posted, but having a structured, uncluttered
convention on where to put these tests and how to write them, would
make coders and reviewers more succeptible to adding them (e.g. when
'manually' testing the code anyway).

We could discuss details on this, such as whether or not to distribute
these extra tests with the usual Sage bundle, whether or not to run
the automatic tests with the patch bot, and whether or not to require
they all still pass with new patches (as with doctests, thus imposing
similar timing requirements as on doctests). I don't feel very
strongly for any of these stand points. However, I would very much
like to have a structured, agreed upon convention on where to put
these extra tests.

Cheers,
Johan

-- 
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] Re: Documentation of prcedures with decorator

[Johan S. R. Nielsen]

I don't know what influence there is from Cython, but for general
python-functions, decorators need to decorate their return functions
with @sage_wraps (see e.g. sage.plots.contour_plot.contour_plot) to
get the correct doc-strings. Setting these could be done manually in
the decorator, but it is the intention that sage_wraps should
coherently take care of all this and related stuff, so this should
always be used instead of manually setting these. If decorated Cython
functions are special, perhaps we should make a Cython-version of
sage_wraps to fix this in the same, coherent manner.

Even when using sage_wraps, Sphinx still uses the argument strings of
the decorator when compiling the documentation. I posted a patch (Trac
#9976) for this several months ago, which patches Sphinx and enhances
the capabilities of sage_wraps to fix this, but there hasn't been a
reviewer.

Regards,
Johan

On Mar 1, 8:48 am, Robert Bradshaw rober...@math.washington.edu
wrote:
 On Mon, Feb 28, 2011 at 11:39 PM, Simon King simon.k...@uni-jena.de wrote:
  Hi Robert,

  On 1 Mrz., 00:15, Robert Bradshaw rober...@math.washington.edu
  wrote:
  ...
   Namely, cached_method tries to obtain certain attributes common to
   python functions from its argument. func_defaults is just one among
   others.

  We don't have as much freedom here, as C-defined and python-defined
  functions are quite different (standard library) objects. In this
  case, cached_method should recognize
  method_descriptors/builtin_function_or_method types and handle them
  differently (if possible).

  Where is the source code for method_descriptor or
  builtin_function_or_method? What is needed to be cimported from where,
  in order to access the attributes corresponding to func_defaults and
  friends?

 The source code is in the Python library itself, 
 e.g.http://svn.python.org/projects/python/trunk/Objects/methodobject.c
 There's no direct analogue to many of these fields...

 - 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

[sage-devel] Re: profiling Sage startup

[Johan S. R. Nielsen]

On Feb 23, 11:03 pm, Jason Grout jason-s...@creativetrax.com wrote:
 On 2/23/11 3:56 PM, Robert Bradshaw wrote:



  On Wed, Feb 23, 2011 at 1:47 PM, Jason Grout
  jason-s...@creativetrax.com  wrote:
  On 2/23/11 3:06 PM, Robert Bradshaw wrote:

  On Wed, Feb 23, 2011 at 11:34 AM, William Steinwst...@gmail.com    
  wrote:

  On Wed, Feb 23, 2011 at 10:57 AM, Jason Grout
  jason-s...@creativetrax.com    wrote:

  On 2/23/11 12:28 PM, William Stein wrote:

  At lunch yesterday Robert Bradshaw made the interesting suggestion to
  read the docs for importlib
  (http://docs.python.org/dev/library/importlib.html) and write a
  customized import hook, so that every time during Sage startup that a
  module is imported, the import is done from a single big in-memory zip
  file instead of done using the filesystem.    If this can be made to
  work, it would be a huge win for slow filesystems.   The basic problem
  is that some filesystems are fast but have huge*latency*.

  Is it a big win primarily because the zip file contents can be read in
  and
  cached by us?  I'm just trying to understand it better.

  Which would you rather do on a high latency filesystem:

    (1) Read/stat 20,000 little files, or
    (2) Read exactly one 40MB file.

    Is this the same idea as Jar files in java?

  I don't know.

  Yep. In that case the high latency file system was a webserver.

  You mean likehttp://docs.python.org/library/zipimport.html?

  Cool.

  Note that this should just involve putting the zip file first in the
  python path.

  I don't know for a fact that Robert Bradshaw's suggestion will be a
  big win, since nobody has tried this yet.  But I'm optimistic.  The
  idea would be to make a zip archive of
  $SAGE_ROOT/local/lib/python/site-packages (say), and do *all* imports
  using that massive zip archive.

  I'm optimistic too. This would, of course, make more sense for
  system-wide installs than development versions, but the former are
  more likely to be on a non-local filesystem anyways.

  Sounds like it is time for a trial!

  I created a directory of 2000 .py files and an __init__.py file to make it 
  a
  module

  for i in range(2000):
      with open('importtest/test_%s.py'%i,'w') as f:
          f.write(VALUE=%s\n%i)
  with open('importtest/__init__.py','w') as f:
      f.write(' ')

  Then I imported each of these so that .pyc files were created.

  for i in range(2000):
      exec 'import importtest.test_%s'%i

  Okay, then I copied the directory and zipped it up (in the shell now):

  $ cp -r importtest zipimporttest
  $ zip -r tmp.zip zipimporttest
  $ rm -rf zipimporttest

  One nice side effect is that the zip file is less than one MB, while the
  directory of python files is around 16M.

  Now for the test.  Here are my two scripts.  One imports each module in the
  directory and adds up the VALUE in each module:

  % cat mytest.py
  s=0
  for i in range(2000):
      exec 'import importtest.test_%s as tt'%i
      s+=tt.VALUE
  print s

  The other first adds the zip to the front of sys.path and then does the 
  same
  imports and summing, but using the zipped module:

  % cat mytestzip.py
  import sys
  sys.path.insert(0,'./tmp.zip')
  s=0
  for i in range(2000):
      exec 'import zipimporttest.test_%s as tt'%i
      s+=tt.VALUE
  print s

  And now for the timings:

  % time sage -python mytest.py
  Detected SAGE64 flag
  Building Sage on OS X in 64-bit mode
  1999000
  sage -python mytest.py  0.26s user 1.47s system 75% cpu 2.282 total

  % time sage -python mytestzip.py
  Detected SAGE64 flag
  Building Sage on OS X in 64-bit mode
  1999000
  sage -python mytestzip.py  0.21s user 0.11s system 99% cpu 0.327 total

  It looks like the zip is a clear winner in this case.  And this is with the
  directory presumably in the FS cache.

  Cool. Given the CPU was pegged at 99%, have you tried using an
  uncompressed zip file? It'd have more data to read, but less to do
  with it once it's read.

 In my case, using zip -0 (no compression) gives:

 % time sage -python mytestzip.py
 Detected SAGE64 flag
 Building Sage on OS X in 64-bit mode
 1999000
 sage -python mytestzip.py  0.20s user 0.10s system 99% cpu 0.309 total

 So just a slight savings.

 Jason


I had an orthorgonal thought, though I'm not sure it's completely
possible. Insted of actually loading the real functions/classes etc.,
couldn't we fast-load (or generate) stub-versions of all these, which
when called would load and replace themselves with the real version
and then run it. I'm not completely sure it's possible with Python,
but Python is pretty flexible so perhaps there is a way; in
particular, I don't know how Python supports reflection for adding new
functions to the namespace dynamically. Also, the doc-strings and
search*-functions should also somehow be thought into it.
If it's possible, as far as I can see, the user would not notice this
(except for a minute overhead the first time a function was called),
and only the very 

[sage-devel] Re: profiling Sage startup

[Johan S. R. Nielsen]

On Mar 1, 10:13 am, Robert Bradshaw rober...@math.washington.edu
wrote:
 On Tue, Mar 1, 2011 at 12:48 AM, Johan S. R. Nielsen



 j.s.r.niel...@mat.dtu.dk wrote:
  On Feb 23, 11:03 pm, Jason Grout jason-s...@creativetrax.com wrote:
  On 2/23/11 3:56 PM, Robert Bradshaw wrote:

   On Wed, Feb 23, 2011 at 1:47 PM, Jason Grout
   jason-s...@creativetrax.com  wrote:
   On 2/23/11 3:06 PM, Robert Bradshaw wrote:

   On Wed, Feb 23, 2011 at 11:34 AM, William Steinwst...@gmail.com    
   wrote:

   On Wed, Feb 23, 2011 at 10:57 AM, Jason Grout
   jason-s...@creativetrax.com    wrote:

   On 2/23/11 12:28 PM, William Stein wrote:

   At lunch yesterday Robert Bradshaw made the interesting suggestion 
   to
   read the docs for importlib
   (http://docs.python.org/dev/library/importlib.html) and write a
   customized import hook, so that every time during Sage startup that 
   a
   module is imported, the import is done from a single big in-memory 
   zip
   file instead of done using the filesystem.    If this can be made to
   work, it would be a huge win for slow filesystems.   The basic 
   problem
   is that some filesystems are fast but have huge*latency*.

   Is it a big win primarily because the zip file contents can be read 
   in
   and
   cached by us?  I'm just trying to understand it better.

   Which would you rather do on a high latency filesystem:

     (1) Read/stat 20,000 little files, or
     (2) Read exactly one 40MB file.

     Is this the same idea as Jar files in java?

   I don't know.

   Yep. In that case the high latency file system was a webserver.

   You mean likehttp://docs.python.org/library/zipimport.html?

   Cool.

   Note that this should just involve putting the zip file first in the
   python path.

   I don't know for a fact that Robert Bradshaw's suggestion will be a
   big win, since nobody has tried this yet.  But I'm optimistic.  The
   idea would be to make a zip archive of
   $SAGE_ROOT/local/lib/python/site-packages (say), and do *all* imports
   using that massive zip archive.

   I'm optimistic too. This would, of course, make more sense for
   system-wide installs than development versions, but the former are
   more likely to be on a non-local filesystem anyways.

   Sounds like it is time for a trial!

   I created a directory of 2000 .py files and an __init__.py file to make 
   it a
   module

   for i in range(2000):
       with open('importtest/test_%s.py'%i,'w') as f:
           f.write(VALUE=%s\n%i)
   with open('importtest/__init__.py','w') as f:
       f.write(' ')

   Then I imported each of these so that .pyc files were created.

   for i in range(2000):
       exec 'import importtest.test_%s'%i

   Okay, then I copied the directory and zipped it up (in the shell now):

   $ cp -r importtest zipimporttest
   $ zip -r tmp.zip zipimporttest
   $ rm -rf zipimporttest

   One nice side effect is that the zip file is less than one MB, while the
   directory of python files is around 16M.

   Now for the test.  Here are my two scripts.  One imports each module in 
   the
   directory and adds up the VALUE in each module:

   % cat mytest.py
   s=0
   for i in range(2000):
       exec 'import importtest.test_%s as tt'%i
       s+=tt.VALUE
   print s

   The other first adds the zip to the front of sys.path and then does the 
   same
   imports and summing, but using the zipped module:

   % cat mytestzip.py
   import sys
   sys.path.insert(0,'./tmp.zip')
   s=0
   for i in range(2000):
       exec 'import zipimporttest.test_%s as tt'%i
       s+=tt.VALUE
   print s

   And now for the timings:

   % time sage -python mytest.py
   Detected SAGE64 flag
   Building Sage on OS X in 64-bit mode
   1999000
   sage -python mytest.py  0.26s user 1.47s system 75% cpu 2.282 total

   % time sage -python mytestzip.py
   Detected SAGE64 flag
   Building Sage on OS X in 64-bit mode
   1999000
   sage -python mytestzip.py  0.21s user 0.11s system 99% cpu 0.327 total

   It looks like the zip is a clear winner in this case.  And this is with 
   the
   directory presumably in the FS cache.

   Cool. Given the CPU was pegged at 99%, have you tried using an
   uncompressed zip file? It'd have more data to read, but less to do
   with it once it's read.

  In my case, using zip -0 (no compression) gives:

  % time sage -python mytestzip.py
  Detected SAGE64 flag
  Building Sage on OS X in 64-bit mode
  1999000
  sage -python mytestzip.py  0.20s user 0.10s system 99% cpu 0.309 total

  So just a slight savings.

  Jason

  I had an orthorgonal thought, though I'm not sure it's completely
  possible. Insted of actually loading the real functions/classes etc.,
  couldn't we fast-load (or generate) stub-versions of all these, which
  when called would load and replace themselves with the real version
  and then run it. I'm not completely sure it's possible with Python,
  but Python is pretty flexible so perhaps there is a way; in
  particular, I don't know how Python supports

[sage-devel] Re: profiling Sage startup

[Johan S. R. Nielsen]

On Mar 1, 1:56 pm, luisfe lftab...@yahoo.es wrote:

 No, the lazy_import object keeps wrapping the original object, but
 when accessing the lazy_import object it imports the real object in
 the namespace. So, if the lazy_import has not been referenced by
 another object then it will be collected as garbage. I do not have a
 running sage right now, but if you experiment you will see that after
 calling the object the lazy_import object disappears.

 It should be something like:

 {{{
 sage: from sage.misc.lazy_import import lazy_import
 sage: lazy_import('sage.rings.all', 'ZZ')
 sage: a = ZZ
 sage: type(ZZ)
 class 'sage.misc.lazy_import.LazyImport'
 sage: ZZ(4.0)
 4
 sage: type(ZZ)
 type 'sage.rings.integer_ring.IntegerRing_class'
 sage: type(a)
 class 'sage.misc.lazy_import.LazyImport'

 }}}

I just did the above in 4.6.1 and got:
{{{
sage: lazy_import('sage.rings.all','ZZ')
sage: a = ZZ
sage: type(ZZ)
class 'sage.misc.lazy_import.LazyImport'
sage: ZZ(4.0)
4
sage: type(ZZ)
class 'sage.misc.lazy_import.LazyImport'
}}}
And naturally, the same type for a. It seems nothing I do to the ZZ
object will unwrap it from the LazyImporter; otherwise, what you say
would naturally be true, and that was exactly what I thought would be
neat to do. Even though the wrapping is very thin, if each and every
callable was wrapped as such, it would probably be quite a large
performance-penalty.

Johan

-- 
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] Re: profiling Sage startup

[Johan S. R. Nielsen]

On Mar 1, 1:56 pm, luisfe lftab...@yahoo.es wrote:

 Yes, it is not used much. Ideally, the way of improving sage
 startuptime would be:

 1.- On first execution by a user, create a pickle of lazy_import of
 the global names and save it in the .sage directory. This should not
 be slower than current startup.

 2.- Then, following executions of sage would only load that pickle
 instead of reading hundreds of different files. This will translates
 the delay from the start to the first call of the function. But note
 that you will never call each global name so globally should be
 faster...

 3.- That pickle should be updated under certain conditions. By a
 command, each time sage is updated etc.

This idea seems to be related to the zip-file and is orthogonal to
which callables should be imported lazily. Is this faster than the zip-
file?
Perhaps one could zip all the pickles, unzip the file in memory and
unpickle from this stream ;-)


 Note that currently there are lazy_import(...) in the startup of sage,
 but this command does not avoid disk access of the file, only
 execution/compilation of the module to import. That is why it has
 currently low impact.

I might have overlooked something, but as far as I can see,
lazy_import does no disk access until the lazily imported callable is
accessed. The initialiser of the object does nothing but set a few
fields, and only in the private _get_object is the actual import done;
this function is called whenever some access is needed. Anyway, a lazy
importer should and could surely have this feature.
Also, where is the lazy_import used, apart from in sage.sets.family
and sage.categories.sets_cat?

Johan

-- 
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] Re: Updating the Developer's Walk-Through

[Johan S. R. Nielsen]

On Feb 21, 2:27 am, Rob Beezer goo...@beezer.cotse.net wrote:
 I'm inclined to update the Walking Through the Development Process
 section of the Developer Guide.

 I've had some feedback (in-person) and have seen a few thoughtful
 comments in various places in sage-devel.  Other than mentioning new
 features (like hg qpush --move (!) and the patchbot) and technical
 details, I'd like to split out the notion of clones being easier
 than queues.  What I am hearing is that both have their place
 (including some very experienced developers who use clones for big
 projects), so I would like to put each on an equal footing and try to
 give some clear upsides and downsides to their use.

 I'd also like to try to streamline the walk-through to an absolute
 bare minimum of the essentials to get started reviewing or
 contributing, with a greater reliance on pointers to sections of the
 guide (which may be newly-formed from the existing walk-through).

 So this is a call for input.  I'd especially love to hear reactions/
 suggestions from folks who have used this section as a way to get
 started with Sage development.

I used the guides for getting to know the development process. I'm
still new, so there are probably better working processes than what I
do, and of course, this will be reflected in my opinons.


 * Pros/cons of clones/queues?  I have some good ideas here, but weigh-
 in if you like.  I'm not asking which *you* prefer, but instead
 *reasons* to prefer one over the other.

I'm _only_ using queues at the moment. As far as I can see, clones are
neat if you have projects of patches. However, the beginner will not
usually have this but only a few scattered fixes here and there and
patches for review, with none or few dependencies between them. For
this, I think queues are much faster and lightweight.
I began with the clones just like the guide said, but found it
tiresome and switched to the queues as soon as I got to that part of
the guide. Also, clones are time consuming in the beginning when you
are anxious to just get started. I definitely don't think that they
should be part of the beginning of this walk-through.
I would use clones if I reviewed as many patches as I should; then I
would have a clone for my work (and patches that I need), and another
clone for the non-dependent set of patches I was currently reviewing.
However, I always have a clean, completely separate install of the
last stable release of Sage. I can't remember if that is mentioned in
the guide, but I find this helpful (and necessary) in a number of
ways. This only have the patches applied which I really need.


 * Development styles/practices/strategies not mentioned in the
 Developer Guide?

I more or less already described my style though it is not very deep.

I think it would be immensely inspirational with a link to a page
where several of the veterans had described their own style (in a lot
of detail), possibly with links to various of their custom build/patch/
etc. scripts.

Regards,
Johan

-- 
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] Re: graph theory: refactor implementation of spanning tree algorithms

[Johan S. R. Nielsen]

On Dec 11, 10:56 pm, Nathann Cohen nathann.co...@gmail.com wrote:
 Hello everybody !!!

 My question on sphinx-dev was finally answered : it sounds possible to
 have one page per method ! :-)

 http://groups.google.com/group/sphinx-dev/browse_thread/thread/41a2fc...

 Nathann

Nice! However, what exactly should we do? I guess we're not interested
in doing this for _all_ classes and modules, but only certain large
ones? Should we add a keyword in the module/class docstring that
Sphinx could pick up, indicating that the docs for this file should be
split into many pages in some predefined way? Or something more fine-
grained? In general, we should be careful not to add too much
documentation-markup into the individual source code files, I think.

Johan

-- 
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] Re: buildbot testing documentation

[Johan S. R. Nielsen]

Wow, this is really cool! Great work! Also, great plans for ways to
let people run their own buildbots, hooked up to the central server.
With customisation so ones own patches will be prioritised whenever
needed, hopefully a lot of people will feel that it's really _easier_
for them to have a buildbot running than not to :-)

Question: Is there (or will there be) ways to tell the buildbot what
files to apply and so on? Example: I have two patches for Trac #9976,
but they are alternatives, so they shouldn't be applied together (the
trac is currently flagged with ApplyFailed because of this); ideally,
they should both be applied individually and run. At least, it would
be nice if I could simply ask the bot to ignore one of the patches.

Thanks,
Johan



On Dec 7, 2:09 pm, Jason Grout jason-s...@creativetrax.com wrote:
 On 12/7/10 4:41 AM, Robert Bradshaw wrote:

  That's an interesting idea, but it's not easy to expose that
  information. The way it works is that a build slave requests a list of
  tickets, rates them according to its own internal settings (which may
  be different for each bot), and then starts on a ticket (notifying the
  server to avoid overlap). I suppose as well as a pending field list,
  one could add something that collects different bots ratings at
  different points in time and their respective speeds and does an
  estimate.

 Or you could maybe pass the work on to the slave: after sorting tickets,
 the slave replies with a time estimate for each ticket.  The server then
 updates the page.  The bot could then send updated estimates whenever
 too.  In the setup for a slave, it could ask for the amount of time it
 takes to run testall (or compute that from a test run, or take a running
 average over several tickets) and use that as a multiplier.

 Or maybe it's just better to report the lowest rating a ticket receives
 from a slave, and let the user use that as a gauge for how soon the
 ticket would be tested.

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

[sage-devel] Re: When is a test not a valid test?

[Johan S. R. Nielsen]

 On the topic of verifying tests, I think internal consistency checks
 are much better, both pedagogically and for verifiability, than
 external checks against other (perhaps inaccessible) systems. For
 example, the statement above that checks a power series against its
 definition and properties, or (since you brought up the idea of
 factorial) factorial(10) == prod([1..10]), or taking the derivative to
 verify an integral. Especially in more advanced math there are so many
 wonderful connections, both theorems and conjectures, that can be
 verified with a good test. For example, computing all the BSD
 invariants of an elliptic curve and verifying that the BSD formula
 holds is a strong indicator that the invariants were computed
 correctly via their various algorithms.

 - Robert

Also a huge +1 from me. This is something I have been thinking a lot
about how to utilise most elegantly, and I think one could take it a
step further than doctests. I often myself write parameterised
tests: tests for properties of the output of functions based on
random input. For example, say I have a library of polynomials over
fields. Then a useful property to test is for any polynomials a,b to
satisfy
  a*b == b*a
I could write a test to randomly generate 100 different pairs of
polynomials a,b to check with, over random fields. I know that some
people sometimes write such tests, and it is also suggested in the
Developer's Guide somewhere.
I love the Haskell test-suite QuickCheck, which allows one to write
such tests extremely declaratively and succinctly. Haskell is way cool
when it comes to types, so it provides an elegant way of specifying
how to randomly generate your input. Transfering this directly Python
or Sage can't be as elegant, but I have been working on a small python-
script -- basically an extension to unittest -- which could make it at
least easier to write these kinds of tests. It's not done yet and can
be improved in many ways, but I use it all the time on my code; it's
quite reassuring to have written a set of involved functions over
bivariate polynomials over fields and then check their internal
consistency with 100-degree polynomials over +1000 cardinality
fields :-D
My thought is that doctests are nice for educational purposes and
basic testing, but I myself like to test my code better while writing
it. I don't want to introduce more bureaucracy, so I don't suggest
that we should _require_ such tests, but it would be nice to have a
usual/standard way of writing such tests, if an author or reviewer
felt like it. More importantly, if it could be done in a systematic
way, all such tests could share the random generating functions: for
example, all functions working over any field would need a generate a
random field-function, and if there was a central place for these in
Sage, the most common structures would quickly be available, making
parameterised test writing even easier.

- Johan

-- 
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] Re: Why Sage? Website Section

[Johan S. R. Nielsen]

On Nov 13, 4:13 pm, rjf fate...@gmail.com wrote:
 On Nov 13, 6:32 am, Johan S. R. Nielsen j.s.r.niel...@mat.dtu.dk
 wrote:

  two info boxes on this suggested Why Sage-page.

  I don't think that Python is the perfect language to write mathematics
  software with; I would definitely vote on a much more functional
  language here, e.g. OCaml or maybe even Haskell. However, this would
  cut out so many potential developers,

 ... yada yada...

 excessive boosterism.

 Consider that symbolic software systems like Maxima/Macsyma, Reduce,
 Axiom, Jacal ...
 were written in Lisp,

 and that Mathematica and Maple were written in C dialects...

 and even YOU would prefer a different, more functional language.

 And then you say Python is still better.

 Certainly not for writing math software.    Maybe for writing web
 applications?

 Because it has a coherent syntax   Compared to Lisp or Haskell or
 OCaml?
 Because people who know little mathematics and little about
 programming
 can write/alter/debug applications for SAGE???  About which they
 presumably know
 nothing?   And this is because Python is such a winner?

 And of course so much of SAGE is not even in Python, but C, Fortran, C+
 +, Lisp, whatever,
 that even that is nonsense.

 excessive boosterism.

 At best, you might say, some features of Sage can be augmented by
 writing in Python, and
 the user interface looks like Python  (actually it is not, but has to
 be pre-processed).

 RJF

Seems to me that either I completely failed at expressing my ideas
clearly, or you failed at reading my post properly. Either way, I get
no enjoyment out of discussing in that kind of mode and tone, so I'll
just leave it at my last post.

Johan

-- 
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] Re: Why Sage? Website Section

[Johan S. R. Nielsen]

First of all, I think that such a page put at a prominent place (as
the entry-page for what is now the Tour, perhaps?) will be a good
selling point. You need to hook people before they have read pages of
text, because otherwise most of them will already have continued on.

 David Kirkby wrote
 There are two separate issues

 1) The interface language

 2) What the source code is written in.
This is very true and a big issue! Maybe enough so to deserve having
two info boxes on this suggested Why Sage-page.

I don't think that Python is the perfect language to write mathematics
software with; I would definitely vote on a much more functional
language here, e.g. OCaml or maybe even Haskell. However, this would
cut out so many potential developers, and from this viewpoint, it is a
bad choice for a large-scale open source project like Sage. Python has
many merits like it is easy to learn and has little syntax. Just
trying to imagine writing mathematics algorithms in Java makes my
stomach turn; soo many type declarations and soo many interfaces, all
having to be explicitly named and imported, instead of just going
with the flow in the duck-typing of Python (of course, preferably
using the type inference of functional languages, but oh well). The
bad side is then no static validation of anything (like type-checking
and only invoking declared methods and such), which makes it so much
more important to reread, test, double-test, auto-test and re-test all
code -- all the time. But as long as the developers succeed in doing
this well, the users won't see it too much (it makes me worried for
whether there might be a sort of upper limit on how big Sage can grow
while still being stable, though).

But I digress; my point is that Python IS a selling point _both_ as
the underlying interpreter language (which is so many leagues ahead of
anything in the Ma*-software, simply because of a well-thought,
coherent syntax and standard library) and as the (main?) development
language. The first draws in users who care about ease of programming
(advanced users, teachers and potential developers. I always hated
Maple for its unsystematic syntax and Matlab for its happy-go-lucky
interpreter), and the second thing makes it easier for a user to
transition into being a developer. I personally don't know Cython yet,
but if a feature or a bug I was interested in came up, I would spend a
weekend learning it so I could develop with it on Sage; however, I
might not have cared about learning Cython when I was only a Sage
user in the first place.

Oh yeah, and Eviatar, I just can't get over the fully committed
geekyness of posting the link as ASCII binary X-D That's just plain
cool.

Johan



On Nov 13, 11:48 am, David Kirkby david.kir...@onetel.net wrote:
 On 12 November 2010 18:18, rjf fate...@gmail.com wrote:



  On Nov 12, 8:46 am, Dr. David Kirkby david.kir...@onetel.net
  I think you have a big bias against python and towards lisp.

  My view is that there has been excessive boosterism for Python,

 I agree with you there.

  asserting that
  it is the solution to some important issues in building a system that
  is supposed
  to displace Mathematica, Maple, Magma, (Maxima?).

 I don't think anyone believes it will displace those languages.

   While Python may
  have
  some merit in some situations, the case being made for it for Sage is
  weak,

 Given it's your opinion the case for Python is week, what would have
 been best as a user interface language for users?

 I can think of a few possibilities worth consideration myself.

  1) Create an entirely new language.
  2) Python
  3) Maxima
  4) A Mathematica like interface
  5) A MATLAB like interface
  6) A Maple-like interface
  7) A Magma-like interface
  8) Lisp
  9) Q - 
 seehttp://en.wikipedia.org/wiki/Q_%28equational_programming_language%29
  10) Purehttp://code.google.com/p/pure-lang/is another possibility,
 but that did not exist until 2008, but is based on  Q, which existed
 prior to Sage

 None seem perfect to me.

 Given the basic rationale of Sage is to glue various bits of code
 together, what in your opinion would have been the best language to
 glue them together?

  which is why I find some bizarre enjoyment in tweaking people who make
  these claims.

 You certainly get some enjoyment out of winding people up. I wish you
 would spend a bit more time contributing practical information though.
 You have helped me, and you have helped others too. You  almost
 certainly know more about computer algebra systems than any Sage
 developer.

 A bit less time tweaking people and a bit more time tweaking the
 Sage source code would be nice!

 I'd also have a bit more respect for your opinions if you actually
 tried Sage. It would give you a chance to point out even more
 shortcomings, which I think you would enjoy.



   Like so many people know it. (Why not use Java? or PHP?)
   Like it is slow but that's OK, you can use Cython (or something else
  that is not Python).
   

[sage-devel] Re: Blog Post: How to referee Sage Trac tickets

[Johan S. R. Nielsen]

On Nov 3, 8:59 am, Florent Hivert florent.hiv...@univ-rouen.fr
wrote:
       Hi there,



 On Mon, Nov 01, 2010 at 05:30:55AM -0500, Jason Grout wrote:
  On 11/1/10 12:23 AM, William Stein wrote:
  http://sagemath.blogspot.com/2010/10/how-to-referee-sage-trac-tickets...

  Nice.  I'll have more comments later, but I did notice that this:

  from sage.misc.misc import deprecation
  deprecation(function_name is deprecated, using new_function_name instead!)

  came out in formatting wrong (the second line looks like this in my
  firefox (3.6.12, osx snow leopard):

  deprecation(function_name is deprecated, using new

  Also, you may want to put in the Sage version number to give people
  a clue about when to remove the function (see the second argument to
  deprecation).

 Actually there is a more handy tools for this precise purpose namely
 deprecated_function_alias:

         sage: from sage.misc.misc import deprecated_function_alias
         sage: g = deprecated_function_alias(number_of_partitions,
         ...     'Sage Version 42.132')
         sage: g(5)
         doctest:...: DeprecationWarning: (Since Sage Version 42.132) g is 
 deprecated. Please use number_of_partitions instead.
         7

     This also works for methods::

         sage: class cls(object):
         ...      def new_meth(self): return 42
         ...      old_meth = deprecated_function_alias(new_meth,
         ...            'Sage Version 42.132')
         sage: cls().old_meth()
         doctest:...: DeprecationWarning: (Since Sage Version 42.132) old_meth 
 is deprecated. Please use new_meth instead.
         42

 Cheers,

 Florent

Very nice - I wasn't aware of that decorator. I have been working with
a few things regarding decorators in Sage, so I noticed some
shortcomings with deprecated_function_alias:
1) Following Trac #9907, deprecated_function_alias should perhaps be
moved to sage.misc.decorators.
2) Without the wraps-decorator, deprecated_function_alias will seem to
swallow all introspection information on the decorated callable
(actually, sage_wraps should then be used to allow for some Sage-
specific introspection, this in turn requires Trac #9919).
3) Currently, any decorator (even one using sage_wraps) will disrupt
documentation in Sphinx. This is fixed in #9976 and requires no change
in the decorators, however.
Perhaps a Trac should be opened to fix these things under the
assumption of #9907 and #9919, but I don't have time to do it myself
right now (I'm procrastinating terribly as it is)...

-- 
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] Re: Blog Post: How to referee Sage Trac tickets

[Johan S. R. Nielsen]

Very nice. Will this be put somewhere persistent where new Sage
developers can be expected to find it? E.g. as a supplement to the
Developer's Guide.

I have one comment: In the current version, sage.misc.misc.deprecation
has some steep limitations. Trac #9919 (along with #9907) fixes it so
it can  be used on non-function callables (e.g. methods). Trac #9907
moves it to sage.misc.decorators.deprecation. Trac #9976 patches
Sphinx so decorated callables in general will not have their signature
reduced to a generic one in the documentation. These tracs depend on
each other in that order and they all need review (hint hint).
Especially the relocation of the decorator should perhaps be kept in
mind for the blog entry.

Cheers, Johan

On Nov 1, 11:30 am, Jason Grout jason-s...@creativetrax.com wrote:
 On 11/1/10 12:23 AM, William Stein wrote:

 http://sagemath.blogspot.com/2010/10/how-to-referee-sage-trac-tickets...

 Nice.  I'll have more comments later, but I did notice that this:

 from sage.misc.misc import deprecation
 deprecation(function_name is deprecated, using new_function_name instead!)

 came out in formatting wrong (the second line looks like this in my
 firefox (3.6.12, osx snow leopard):

 deprecation(function_name is deprecated, using new

 Also, you may want to put in the Sage version number to give people a
 clue about when to remove the function (see the second argument to
 deprecation).

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

[sage-devel] Re: Review wranglers

[Johan S. R. Nielsen]

On Oct 22, 9:26 pm, Jason Bandlow jband...@gmail.com wrote:
 On 10/22/2010 12:20 PM, Robert Bradshaw wrote:

  Given the difficulty of finding reviewers, are you arguing we
  shouldn't try to make things even easier? Yes, it's not to bad ([copy
  the url, qimport, qpush] * n, build, test, run doctests, qpop, ...),
  but could be a lot better. Oh, and by test I mean not doctests, but
  interactively test, where it's more of a pain to context switch and
  wait for the build to complete. I'd rather be reading the code and say
  hmm... I wonder if this works... and just try it out.

 This has annoyed me on more than one occasion.  Can any trac gurus speak
 to the possibility of adding two fields to trac tickets?

 1) Patches to be applied for the current ticket
 2) Tickets on which this patch depends

 It seems to me that if we had machine-readable fields of this type, it
 would be possible (easy?) to write a shell script where one would write

 $ test_ticket #1234

 and the script would

 a) Download and apply the appropriate patches to a mercurial queue
 b) Build and run the patched version for interactive testing
 c) Clone the patched version, run all tests, email me the tail of the
 test log and delete the cloned version.  (Works in a clone so I can
 review other tickets while this is going on.)

 This little bit of automation would make me a much more productive
 reviewer, I think.  But getting the collection of patch URLs is
 currently too hard to automate.

 -Jason

+1. Nice and easy as a first step (and necessary for all the later
things). If that is not a rather doable thing in Trac, then I think we
have an answer to the earlier question in the bug wrangler thread on
whether Trac is the best solution for our needs ;-)

Johan

-- 
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] Re: Extension of category framework: Does it make sense to open a ticket for this?

[Johan S. R. Nielsen]

 Generalizing code for the sake of generalization and at the expense of
 efficiency is probably a bad choice, especially for something so
 pervasive as the category framework, but if you can show that the more
 general code is necessary to do things people actually want, it
 becomes worth evaluating what the slowdowns are and if one can avoid
 the slowdowns, or even accept them if they are unavoidable.
Agreed. Otherwise, it will never stop - there are always more
generalisations which could be done in mathematics. Otherwise, your
additions sound very compelling and nice mathematically :-)

 The 1.5% you are giving is a nice guide, but it doesn't really show
 that there is a slow-down, nor how badly this is going to affect
 existing code. Could you try to identify which things are slowed down?
 All operations? just certain coercions? Perhaps look at the timing of
 separate modules and see which contribute most to that 1.5%.

Even more importantly: try removing your new doctests to show the
slowdown on only the original doctests; otherwise, the number 1,5%
doesn't reveal much (your new tests might just be very slow compared
to the average doctest out there).

Cheers,
Johan

-- 
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] Re: Regression testing

[Johan S. R. Nielsen]

+1 to the idea of time testing doctests. I would use them all the time
for regression testing and when testing improvements; not the least
for my own Sage library.

It seems to me that only very rarely it would be interesting to look
at other's timing tests, and so, I don't really think the extra work
required in implementing and maintaining a solution which collects
everyone's timing centralised is justifiable. However, +1 for the idea
of looking for an existing Python Open Source project or contacting
others for starting a new one.

 Also, I was talking to Craig Citro about this and he had the
 interesting idea of creating some kind of a test object which would
 be saved and then could be run into future versions of Sage and re-run
 in. The idea of saving the tests that are run, and then running the
 exact same tests (rather than worrying about correlation  of files and
 tests) will make catching regressions much easier.

Not to go off topic, but am I the only one bothered about the - at
least theoretical - overhead of searching for, extracting and parsing
every single doctest each time I want to run them? Does anyone know
how much overhead is actually hidden there (timewise)? If it is the
least bit significant, we could think about extending the above
excellent idea of test objects to be what is _always_ being tested
when doctesting. And then just adding a flag -extract_doctest to ./
sage for rebuilding the test objects only whenever I know there has
been a change.

Cheers,
Johan

-- 
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] Re: Review wranglers

[Johan S. R. Nielsen]

On Oct 22, 10:49 am, Jeroen Demeyer jdeme...@cage.ugent.be wrote:
 On 2010-10-21 06:33, Robert Bradshaw wrote:

  Finally, we need more automation. Refereeing code shouldn't
  have to involve downloading and applying patches and running all
  tests--that should all be done automatically (with failing tickets
  bounced right away, or at least in a 24-48 hour window). We should
  have a notebook server with sessions of Sage with various tickets
  already applied for quick refereeing (or a CLI interface on, say,
  boxen for those who prefer that--telnet/ssh
  10921.sage.math.washington.edu would be cool, opening you immediately
  into a jailed sage session). I'll plug
 http://trac.sagemath.org/sage_trac/ticket/9967which is a requirement
  for this and I just recently started to write a per-ticket build bot.
  This would help close the gap and lag between writing code and getting
  it into Sage, and I think that having such a small gap was one of the
  key ingredients in letting Sage explode like it did.

 I'm afraid your solution is not very scalable.  I don't think it's
 realistic to have a large number of independent notebook servers with
 various tickets.  I think an automated system to do doctests is
 possible, but if you want also to log in and try things you need many
 independent Sage setups.  If each one takes several gigabytes, that
 looks not practical.

 Jeroen.

I think the idea is extremely beautiful! There are two things: having
a set of notebook servers trying out all awaiting_review patches on
the latest release for simply successful patching and compiling is
very doable (and would be a big help!). Doing actual full doctest of
course requires more computer power, but perhaps with neat things like
checking many patches in one full doctest, and then only checking each
individual patch if there were errors would reduce this.

The second thing: giving access to a notebook with a given patch
applied is perhaps more futuristic; however, that would make me much
more productive and willing to review many patches. It could be done
in a modest form with a smaller number of notebook servers and a sort
of registration system (next tuesday at 2pm, I'd like to test Trac
#10889). Perhaps a long-term goal for Sage is a system which allows a
Sage installation to be run in parallel, each branch with its own
patches applied but with a smaller overhead (my first idea is using a
huge number of symlinks linking to the files the different branches
have in common, but that's just off the top of my head). First step is
#9976 as Robert was talking about.

If we started thinking about these things, we might be able to come up
with something good. It can't be hard to beat what is currently there.

Cheers,
Johan

-- 
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] Re: bug wranglers

[Johan S. R. Nielsen]

I think that Burcin's suggestion is excellent. Development of Sage
should definitely move towards more structure, documentation, testing
and other software engineering practices, but as for any Open Source-
project, these things should come naturally as the project grows and
matures; as has already happened with Sage a lot, it seems (for a
relative new-comer like me). To require too much too soon would kill
the joy of working on the project and thus kill the project itself.

Burcin's suggestion seem to fit this curve pretty well at this time.
New developers and bugfixers -- with little overview of the monster
that is Sage -- would feel more confident in reporting and fixing bugs
if there was a feeling that there was someone (or a group of someones)
with overview and structure. If some enthusiastic veterans could be
found and agree on the exact model of this, I think it would improve
bug-tracking and -fixing in a number of ways:
 - overview of bugs, their severity and class (by cleaning up,
removing duplicates, collating related tracs, and reclassifying)
 - better classification of bugs by everyone else (by monkey-see-
monkey-do)
 - better overview over bugs to fix before releases (by better
overview over all bugs)
 - shorter pickup-time between a trac has been filed (possibly by
someone not interested in fixing it) and someone is looking at it
 - assurance that a veteran has looked at the trac, accepted it, and
maybe even given an approving nod after positive review
 - and all of this gives more confidence to developer-rookies
I think the system should entirely superseed the automatic-owner
system that is currently in Sage. Software-speaking, this would
provide an abstract interface between the tracs and those responsible
for it, which makes it more flexible to have either one, several or
many owners of a trac or class of tracs.

Personally, I like the one-week-at-a-time suggestion (though several
people should be on duty each week perhaps) sounds best. However, it's
easy for me to say, as I don't think I have the required experience to
undertake this duty (You are not bug-ninja materiAL, SOLDIER! Drop
down and give me a recursive function generating the Fibonacci
sequence!). When and if the time comes, I would be happiest with a
one-week-at-a-time schedule, though.

 Burcin wrote:
 Perhaps we should come up with a locking mechanism, to prevent two
 different people from trying to sort the same issue at the same time,
 but it feels like too much organization at the beginning.
Maybe there would not need to be a locking-mechanism to begin with,
but surely a mechanism so that a bug-wrangler could see that no other
bug-wrangler has already looked at this new trac.

Cheers,
Johan

On Oct 20, 11:37 am, Martin Albrecht martinralbre...@googlemail.com
wrote:
   The idea of having one piece of a Sage days devoted to
   people sharing ideas from books they read in a coordinated way sounds
   plausible as well, though probably it would really depend on the Sage
   days in question.

  That would sound good. If each person read a chapter of a book on a topic,
  and gave a short talk to everyone else, it should at least make people
  aware of the other issues.

  I bought this book

 http://www.amazon.com/Software-Engineering-9th-Ian-Sommerville/dp/013...
  2/ref=sr_1_1?ie=UTF8qid=1287529714sr=8-1

  though I'm not over-impressed with it.

  Despite some pretty poor reviews on Amazon, I find an old (3rd edition) of
  this book

 http://www.amazon.com/Software-Engineering-Practitioners-Roger-Pressm...
  0073375977/ref=sr_1_4?ie=UTF8qid=1287529714sr=8-4

  to be very useful.

  You can pick up a used copy of the 6th edition (2004) for less than $2 on
  Amazon.

 I'd like to return to Burcin's original proposal if possible. He made a
 *concrete* proposal for what to do with the growing number of bugs in Sage and
 somehow this turned into a threat discussing which books on Software
 Engineering we should read and how early one should should fix bugs.

 Don't get me wrong, this is a useful discussion to be had but it is a shame
 that discussions move from concrete to abstract instead of the other way
 around quite often these days ([sage-general] anyone? :))

 It seems clear to me even if we do employ all kinds of software engineering
 techniques that there will still be bugs we'll have to tackle and our current
 approach as serious issues. Even OpenBSD has bugs which they have to address
 despite the fact that they make quite an effort to scrutinize code.

 To get back to Burcin's proposal it seems while there is some support, it
 doesn't seem to spur enough interests to have enough people to distribute the
 load to or am I mistaken?

 Cheers,
 Martin

 --
 name: Martin Albrecht
 _pgp:http://pgp.mit.edu:11371/pks/lookup?op=getsearch=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] Re: bug wranglers

[Johan S. R. Nielsen]

I think that Burcin's suggestion is excellent. Development of Sage
should definitely move towards more structure, documentation, testing
and other software engineering practices, but as for any Open Source-
project, these things should come naturally as the project grows and
matures; as has already happened with Sage a lot, it seems (for a
relative new-comer like me). To require too much too soon would kill
the joy of working on the project and thus kill the project itself.

Burcin's suggestion seem to fit this curve pretty well at this time.
New developers and bugfixers -- with little overview of the monster
that is Sage -- would feel more confident in reporting and fixing bugs
if there was a feeling that there was someone (or a group of someones)
with overview and structure. If some enthusiastic veterans could be
found and agree on the exact model of this, I think it would improve
bug-tracking and -fixing in a number of ways:
 - overview of bugs, their severity and class (by cleaning up,
removing duplicates, collating related tracs, and reclassifying)
 - better classification of bugs by everyone else (by monkey-see-
monkey-do)
 - better overview over bugs to fix before releases (by better
overview over all bugs)
 - shorter pickup-time between a trac has been filed (possibly by
someone not interested in fixing it) and someone is looking at it
 - assurance that a veteran has looked at the trac, accepted it, and
maybe even given an approving nod after positive review
 - and all of this gives more confidence to developer-rookies
I think the system should entirely superseed the automatic-owner
system that is currently in Sage. Software-speaking, this would
provide an abstract interface between the tracs and those responsible
for it, which makes it more flexible to have either one, several or
many owners of a trac or class of tracs.

Personally, I like the one-week-at-a-time suggestion (though several
people should be on duty each week perhaps) sounds best. However, it's
easy for me to say, as I don't think I have the required experience to
undertake this duty (You are not bug-ninja materiAL, SOLDIER! Drop
down and give me a recursive function generating the Fibonacci
sequence!). When and if the time comes, I would be happiest with a
one-week-at-a-time schedule, though.

 Burcin wrote:
 Perhaps we should come up with a locking mechanism, to prevent two
 different people from trying to sort the same issue at the same time,
 but it feels like too much organization at the beginning.
Maybe there would not need to be a locking-mechanism to begin with,
but surely a mechanism so that a bug-wrangler could see that no other
bug-wrangler has already looked at this new trac.

Cheers,
Johan

On Oct 20, 11:37 am, Martin Albrecht martinralbre...@googlemail.com
wrote:
   The idea of having one piece of a Sage days devoted to
   people sharing ideas from books they read in a coordinated way sounds
   plausible as well, though probably it would really depend on the Sage
   days in question.

  That would sound good. If each person read a chapter of a book on a topic,
  and gave a short talk to everyone else, it should at least make people
  aware of the other issues.

  I bought this book

 http://www.amazon.com/Software-Engineering-9th-Ian-Sommerville/dp/013...
  2/ref=sr_1_1?ie=UTF8qid=1287529714sr=8-1

  though I'm not over-impressed with it.

  Despite some pretty poor reviews on Amazon, I find an old (3rd edition) of
  this book

 http://www.amazon.com/Software-Engineering-Practitioners-Roger-Pressm...
  0073375977/ref=sr_1_4?ie=UTF8qid=1287529714sr=8-4

  to be very useful.

  You can pick up a used copy of the 6th edition (2004) for less than $2 on
  Amazon.

 I'd like to return to Burcin's original proposal if possible. He made a
 *concrete* proposal for what to do with the growing number of bugs in Sage and
 somehow this turned into a threat discussing which books on Software
 Engineering we should read and how early one should should fix bugs.

 Don't get me wrong, this is a useful discussion to be had but it is a shame
 that discussions move from concrete to abstract instead of the other way
 around quite often these days ([sage-general] anyone? :))

 It seems clear to me even if we do employ all kinds of software engineering
 techniques that there will still be bugs we'll have to tackle and our current
 approach as serious issues. Even OpenBSD has bugs which they have to address
 despite the fact that they make quite an effort to scrutinize code.

 To get back to Burcin's proposal it seems while there is some support, it
 doesn't seem to spur enough interests to have enough people to distribute the
 load to or am I mistaken?

 Cheers,
 Martin

 --
 name: Martin Albrecht
 _pgp:http://pgp.mit.edu:11371/pks/lookup?op=getsearch=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