วันศุกร์ที่ 31 ธันวาคม พ.ศ. 2553

Re: [sage-devel] SAGE64

On Wed, Dec 29, 2010 at 11:27 PM, Justin C. Walker <justin@mac.com> wrote:
> Hi, all,
> When I run, say, 4.6, I get this printout prior to the sage banner:
> Detected SAGE64 flag
> Building Sage on OS X in 64-bit mode
> Is this necessary?  There's no build underway, and I imagine that it could
> be disconcerting to someone who is not comfortable with the development
> aspects of Sage.

No, this is not necessary. It is clutter, and it annoys me too.

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

I'm not going to fix this, but I hope somebody else does.

-- William

> Justin
> --
> Justin C. Walker, Curmudgeon at Large
> Institute for the Absorption of Federal Funds
> -----------
> Like the ski resort full of girls hunting for husbands
> and husbands hunting for girls, the situation is not
> as symmetrical as it might seem.
>   - Alan MacKay
> --
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>

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

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

[sage-devel] Re: [sage-notebook] Scalable Sage Server Architecture Proposal v0.1

On Thu, Dec 30, 2010 at 5:34 AM, Harald Schilly
<harald.schilly@gmail.com> wrote:
> On Thu, Dec 30, 2010 at 13:24, Alex Leone <acleone@gmail.com> wrote:
>> Comments?  It would be good to discuss this before the upcoming bug days if
>> we are going to do anything with the notebook.

Alex -- can you also post your document to the wiki (or a link to it)?
http://wiki.sagemath.org/Notebook%20scalability

>
> Hi, I read most of it and I also read your posting on mongodb-users ;)
>
> Basically, most of it is also what I would have in my mind ... just some notes:
>
> 1. I wouldn't do a "isAdmin" property for users. Rather, create one or
> more groups that are marked as isAdmin and then add the users to that
> group. This is basically how it is done nowdays in linux via the
> /etc/sudoers file where a group "admin" is marked as being special and
> the sudo command checks if the user is in the group admin.
>
> 2. The permissions, I don't really understand it. Why are they in each
> group? I understand that each worksheet has a list of users (owners)
> with permissions and groups with permissions, but at the group level I
> don't get it. What does db.groups.users.{ perms: 1 or 0 } actually do?
> I think, just a list of usernames is enough.
>
> Do you know ACLs [1]? Maybe compare your mix of usernames and
> permissions with the approach over there and do it this way!
> Therefore, I would attach such a ACL list to each worksheet.

Harald, any chance you could create some example MongoDB documents
that illustrate use of ACL's? This would be very helpful.

> 3. Worksheets reference to a collection of cells? Each document has a
> 4mb limit ... I know, that's a lot and it will probably never be hit,
> but if there is some crazy long output it might happen.

Two comments:

* the 4MB limit is officially going to be raised to 16MB soon.

* all this database stuff is aimed (in my mind) mainly to be used
by large notebook server deployments like sagenb.org, which will have
say 100,000 users. Having a <=16MB limit per worksheet is a really
good idea no matter what, even if mongodb didn't enforce it. So I
have no problem with having such a limit in our database (per
worksheet). We really really don't want people trivially making
1terabyte worksheets (right now with sagenb.org, it would be possible
for somebody to do that!).

> Second,
> updates on worksheets only happen on the cell level, never on the
> whole document. I know, mongodb has the ability to update a part of a
> document via the update command, but I think it's easier to have a
> collection of all cells and reference to them.

I'm not sure. If you read mongodb documentation/books, the way Alex
laid things (with all cells in a single document) out is repeatedly
recommended by them as the recommended way to go. The updating on
parts of documents with mongodb is very robust, in my experience.
Also, the data locality (having all the cells in the same document) is
evidently a big win efficiency wise.

> But still, when a cell is updated, only it's "out" field is modified.

It's "in" field can also be modified, right, e.g., when you modify the
input? And somebody maybe even the type (why not?).

> Therefore, I propose to define a worksheet as a list of cells [or
> later and more advanced, also as a nested list of worksheets ... i.e.
> to make it possible to reference to another worksheet, to do "dynamic"
> embeddings, sections/parts, meta-worksheet-documents ...].

A worksheet can't be defined to be a list of cells, since there is
lots of other meta data, e.g., the title, owner, etc.

One can certainly have references to other worksheets, etc., with
Alex's proposed schema, right? (via the _id field).

> Additionally, I could also envision cases, where each of those cells
> get additional permissions, e.g. a "lock" that adds a "all: ---"
> permission, so that nobody is able to edit a cell. (editing
> permissions is of course still possible by the users and users in the
> associated groups if they are allowed)

That would already fit fine with Alex's proposal. It would be good to
add it as an example to his document though. It's just another
key:value in one of the cells.

Alex, I don't think you should use an _id field in the individual
cells though. They aren't complete mongodb documents themselves, so
don't have to have an "_id" field, and if they do it isn't treated
specially like the _id of a complete monogodb document (which is
forced to be unique, etc.). Thus using _id could be misleading.

>
>
> 4. something trivial, instead of
> out: [{ t:"stdout", data: "..."} , {t:"stderr", data: "..."}]
> please just do
> out: { stdout: "...", stderr: "..." }
> Mongodb allows to list all keys in such an associative list and no
> need for this {t: "..."} thing.
> (or even better, get rid of "out" and just a stdout and stderr key is
> good enough since their relative ordering doesn't matter.)

+1 -- very good idea.

> 5. Images might probably be referenced explicitly, i.e. out: { img:
> <file-id-reference> }

There should be no actual disk-based files. The images should
themselves be stored in mongodb. It can store binary data (like
images) just fine -- mongodb's main target domain is web applications,
where multimedia data is very common.

> 6. same as 5. for data files attached to worksheets. That's probably
> what you mean with db.files anyways ... but it might be nice to know
> when attached files are no longer needed to be able to run a
> background process that removes unreferenced files.

db.files uses "GridFS" which is something mongodb provides for storing
large binary data (which can be much bigger than 4MB).

I'm fine with attached files also having a 4MB (or later 16MB) limit,
again at least for big servers like sagenb.org. Thus using GridFS
for this application (the Sage notebook) isn't (in my mind) necessary.

> h
>
>
> [1] http://linux.die.net/man/5/acl
> first, look at the "long text form", then read the algorithm for checking it.
>

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

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

[sage-devel] Re: [sage-notebook] Scalable Sage Server Architecture Proposal v0.1

On Thu, Dec 30, 2010 at 4:24 AM, Alex Leone <acleone@gmail.com> wrote:
> Hi all,
> See attached document.
> Comments?  It would be good to discuss this before the upcoming bug days if
> we are going to do anything with the notebook.
>  - Alex
> PS.  There's nothing in the document about the current sage notebook.  I
> agree that everything is premature optimization before benchmarking.
>  However, if the server isn't designed with multiple computers in mind, then
> it's not going to scale very well.  I also realize that the proposed design
> will require somewhat of a rewrite, but if we just focus on basic worksheet
> editing functionality (keeping in mind how to add other features), then we
> could get something up and running during bug days, and it would be easy to
> add stuff later without a large re-design.

I'm really glad you're thinking about architecture already, and even
put the effort in to write something this detailed up.

That said, I am personally not going to do any work on something where
the goal is just to "get something up and running during bug days".
Whatever I do, the goal will be to do something that it is possible to
_finish_ by Jan 14, and be genuinely usable. Implementing something
with functionality the same as the notebook but scalable -- basically
from scratch -- is hard.

But the actual work you're doing (e.g., database schemas, diagrams to
explain how things should work) is all very applicable to doing
additional work directly to the notebook that will make it much more
scalable.

-- William

> (The document is also available
> at https://docs.google.com/document/d/1uYJXPAWypGgb92QStJ19cW-29y4-hn5hi8oXMR-11TU/edit?hl=en&authkey=CISp9cQB
> )

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

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

Re: [sage-devel] Re: patchbot+nagbot

On Thu, Dec 30, 2010 at 3:32 PM, Marco Streng <marco.streng@gmail.com> wrote:
> Op 30-12-2010 22:16, Robert Bradshaw schreef:
>>
>> On Thu, Dec 30, 2010 at 2:04 PM, daveloeffler<dave.loeffler@gmail.com>
>>  wrote:
>>>
>>> On Dec 30, 1:41 pm, Robert Bradshaw<rober...@math.washington.edu>
>>> wrote:
>>>>
>>>> And otherwise it does a "best guess" kind of approach, which is decent
>>>> (especially if there is only one patch :). In any case, I don't think
>>>> people would mind getting a "nag" that the patchbot got confused,
>>>> indicating that it might be worth your while to give it a hint.
>>>>
>>>> - Robert
>>>
>>> Agreed. Are there docs for the patchbot extant somewhere? It would be
>>> handy to have some brief guidelines (perhaps on the Trac wiki?)
>>
>
> Could someone add
>
>> http://wiki.sagemath.org/buildbot
>>
>
> to
>
> http://www.sagemath.org/doc/developer/trac.html#patching-bugs-working-on-tickets
>
> ?

This would be done by modifying
SAGE_ROOT/devel/sage/doc/en/developer/trac.rst, then making a patch
and posting the patch to
a ticket at http://trac.sagemath.org/sage_trac/. I'm sure you could
easily do all of this. Thanks!

William

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

Re: [sage-devel] Cleaning up extcode

On Fri, Dec 31, 2010 at 1:05 PM, Robert Bradshaw
<robertwb@math.washington.edu> wrote:
> I've been looking at merging extcode into the main repository, and was
> thinking some cleanup is in order. See
> http://wiki.sagemath.org/extcode for a current listing of contents.
> IIRC, the notebook, images, and jsmath directories are completely
> redundant now, right?

Yes, definitely. (Unless there is a bizarre bug.) That information
is all in the sagenb spkg.

> Does anyone know what sagebuild is?

It is something gfurnish created, which is no longer relevant, since I
re-implemented from scratch (using multiprocessing) the thing he had
implemented. Doing "hg log sageenv.py" in the sagebuild directory
confirms this.

> They look
> years old, see also http://trac.sagemath.org/sage_trac/ticket/3399 .
> Also, is there any need for the (mostly empty) system and system/user
> directories?

I see no such directories:

deep:extcode wstein$ ls
MuPAD images mathematica octave scilab
QEPCAD javascript matlab pari singular
dist kash maxima pickle_jar sobj
gap macaulay2 mirror sage spkg-debian
genus2reduction magma mwrank sage-push spkg-dist
gnuplot maple notebook sagebuild spkg-install

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

[sage-devel] Re: Adjoint of a matrix

On Dec 30, 8:02 pm, Jason Grout <jason-s...@creativetrax.com> wrote:
> Nice.  Here's another.  If v is a vector, it would be nice to have:
>
> v.row() -- return a 1-row matrix, same as matrix(v) (i.e., a row vector)
>
> v.column() -- return a 1-column matrix, same as v.transpose() (i.e., a
> column vector)

I like this, too.

> That would take care of your ideological problem with v.transpose(), I
> think.

Yes, I'll sleep better tonight. ;-)

Rob

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

[sage-devel] Cleaning up extcode

I've been looking at merging extcode into the main repository, and was
thinking some cleanup is in order. See
http://wiki.sagemath.org/extcode for a current listing of contents.
IIRC, the notebook, images, and jsmath directories are completely
redundant now, right? Does anyone know what sagebuild is? They look
years old, see also http://trac.sagemath.org/sage_trac/ticket/3399 .
Also, is there any need for the (mostly empty) system and system/user
directories?

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

Re: [sage-devel] Re: Boost

On Sat, Dec 25, 2010 at 11:16 PM, Dima Pasechnik <dimpase@gmail.com> wrote:
> On Dec 26, 11:03 am, Mag Gam <magaw...@gmail.com> wrote:
>> I will compile boost my self. But why the cropped? is it because of
>> license, size, compile time, etc..?
>
> The subset of boost needed for polybori, another spkg (Sage package),
> is included in Sage.
> One can probably easily create a version of boost spkg that includes
> more of boost.
> (just replace what sits in src/ in the current spkg with whatever you
> like, etc...)
>
> There are no problems with the license.
> On the other hand, having extra 40Mb in the Sage download would need a
> good justification.

It makes no sense to include boost standard in Sage, just because
parts of it tend to be useful. There would have to be a very
compelling case for why it is needed for something else specific that
is included in Sage. It could make sense to have an official
optional boost spkg.

I spent some time recently making spkg's so I can build mongodb from
source, which I posted here:

http://purple.sagemath.org/packages/optional/mongodb/

One of the main depencies for mongodb is boost, and you'll find a
boost spkg above, which works for me on Linux and OS X, at least for
building Mongodb. You'll also find that I packaged boost version
1.40.0, which is maybe a year old, rather than the much newer versions
of boost available at the boost site. It turned out that _most_ of
the difficulty in getting the latest mongodb to build was figuring out
which old out of date boost it would build against! And 1.40.0 is it.
Any newer version has changed so much, that mongodb doesn't work on
top of it. Boost is under active development still, but most distros
have an older version, which is why mongodb does fine building with
them, but not the latest boost.

So even if boost were included in Sage, the question of *which* boost
is needed for a given optional package to build is nontrivial.

-- William

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

วันพฤหัสบดีที่ 30 ธันวาคม พ.ศ. 2553

[sage-devel] Re: Adjoint of a matrix

On 12/30/10 5:13 PM, Rob Beezer wrote:
> On Dec 30, 10:46 am, Jason Grout<jason-s...@creativetrax.com> wrote:
>> I was thinking of another matrix constructor that is a very thin wrapper
>> around matrix(). Something like:
>>
>> def column_matrix(*args, **kwds):
>> return matrix(*args, **kwds).transpose()
>
> I like it. See http://trac.sagemath.org/sage_trac/ticket/10535


Nice. Here's another. If v is a vector, it would be nice to have:

v.row() -- return a 1-row matrix, same as matrix(v) (i.e., a row vector)

v.column() -- return a 1-column matrix, same as v.transpose() (i.e., a
column vector)

That would take care of your ideological problem with v.transpose(), I
think.

Thanks,

Jason

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

[sage-devel] Re: Adjoint of a matrix

On Dec 30, 1:01 am, Dan Drake <dr...@kaist.edu> wrote:
> There are a number of "basic moves" in linear algebra that you do all
> the time when describing algorithms, doing proofs, and so on. The better
> Sage supports those basic moves, the easier it will be to experiment
> with basic linear algebra stuff.

That's a nice way to put it. I'm trying to make available as many of
the natural "basic moves" as possible. Mostly I've been concentrating
on vectors (as vectors, not as matrices with a single row or column),
but I'm about to move on into matrices. So, send me your wish list of
missing basic moves. Anybody.

Rob

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

[sage-devel] Re: Adjoint of a matrix

On Dec 30, 10:46 am, Jason Grout <jason-s...@creativetrax.com> wrote:
> I was thinking of another matrix constructor that is a very thin wrapper
> around matrix().  Something like:
>
> def column_matrix(*args, **kwds):
>      return matrix(*args, **kwds).transpose()

I like it. See http://trac.sagemath.org/sage_trac/ticket/10535

And if you provide just a single dimension, along with a flat list of
entries, the dimension gets interpreted as the number of *columns*.
Bonus.

sage: column_matrix(ZZ, 8, range(24))
[ 0 3 6 9 12 15 18 21]
[ 1 4 7 10 13 16 19 22]
[ 2 5 8 11 14 17 20 23]

Rob

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

Re: [sage-devel] Re: patchbot+nagbot

Op 30-12-2010 22:16, Robert Bradshaw schreef:
> On Thu, Dec 30, 2010 at 2:04 PM, daveloeffler<dave.loeffler@gmail.com> wrote:
>> On Dec 30, 1:41 pm, Robert Bradshaw<rober...@math.washington.edu>
>> wrote:
>>>
>>> And otherwise it does a "best guess" kind of approach, which is decent
>>> (especially if there is only one patch :). In any case, I don't think
>>> people would mind getting a "nag" that the patchbot got confused,
>>> indicating that it might be worth your while to give it a hint.
>>>
>>> - Robert
>>
>> Agreed. Are there docs for the patchbot extant somewhere? It would be
>> handy to have some brief guidelines (perhaps on the Trac wiki?)
>

Could someone add

> http://wiki.sagemath.org/buildbot
>

to

http://www.sagemath.org/doc/developer/trac.html#patching-bugs-working-on-tickets

?

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

[sage-devel] Re: error compiling gnutls on suse 11.3

Apparently those packages were installed, but not on the most current
version: upgrading solved the problem.

Thanks

On 29 dic, 14:00, Volker Braun <vbraun.n...@gmail.com> wrote:
> Install your distribution's lzo and lzo-devel packages.

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

Re: [sage-devel] Re: patchbot+nagbot

On Thu, Dec 30, 2010 at 2:04 PM, daveloeffler <dave.loeffler@gmail.com> wrote:
> On Dec 30, 1:41 pm, Robert Bradshaw <rober...@math.washington.edu>
> wrote:
>>
>> And otherwise it does a "best guess" kind of approach, which is decent
>> (especially if there is only one patch :). In any case, I don't think
>> people would mind getting a "nag" that the patchbot got confused,
>> indicating that it might be worth your while to give it a hint.
>>
>> - Robert
>
> Agreed. Are there docs for the patchbot extant somewhere? It would be
> handy to have some brief guidelines (perhaps on the Trac wiki?)

http://wiki.sagemath.org/buildbot

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

[sage-devel] Re: patchbot+nagbot

On Dec 30, 1:41 pm, Robert Bradshaw <rober...@math.washington.edu>
wrote:
>
> And otherwise it does a "best guess" kind of approach, which is decent
> (especially if there is only one patch :). In any case, I don't think
> people would mind getting a "nag" that the patchbot got confused,
> indicating that it might be worth your while to give it a hint.
>
> - Robert

Agreed. Are there docs for the patchbot extant somewhere? It would be
handy to have some brief guidelines (perhaps on the Trac wiki?)

David

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

[sage-devel] Re: Adjoint of a matrix

On 12/30/10 1:22 AM, Rob Beezer wrote:
> On Dec 29, 10:31 pm, Jason Grout<jason-s...@creativetrax.com> wrote:
>> Notice that there is an underlying ideology that vectors are rows:
>
> Yes, I have noticed that. Ties go to rows:
>
> sage: matrix( [vector(QQ, [1,2,3]), vector(QQ,[4,5,6])] )
> [1 2 3]
> [4 5 6]
>
> But the above is the first example where I have been tempted to
> suggest some optional keyword to cause columns to win the tie. In
> other words, I am writing instructions for beginning students on how
> to use Sage for linear algebra and I've been surprised at how little
> trouble I have had maintaining a column-oriented development alongside
> Sage's row-oriented preferences. Excepting the above - I want to
> build matrices out of sets of vectors where the vectors become columns
> (as optional behavior).
>

+1. I usually use a transpose after constructing a matrix so that the
vectors in the constructor give the columns.

I was thinking of another matrix constructor that is a very thin wrapper
around matrix(). Something like:

def column_matrix(*args, **kwds):
return matrix(*args, **kwds).transpose()

Jason

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

Re: [sage-devel] Re: patchbot+nagbot

On Thu, Dec 30, 2010 at 2:01 AM, Simon King <simon.king@uni-jena.de> wrote:
> Hi Dave,
>
> On 30 Dez., 10:21, daveloeffler <dave.loeff...@gmail.com> wrote:
>> I can see a slight problem with this. At present there's no mechanism
>> to explain to the patchbot exactly which patches to apply. So if you
>> have (say) a ticket with a patch that requires a patch from an earlier
>> ticket to be applied, or if you have three patches of which only the
>> last two should be applied (because the first was a superseded
>> attempt), or any other nontrivial situation, the patchbot will be
>> sending out loads of unnecessary messages.
>
> I may be mistaken, but as far as I know, if ticket #9876 has 4 patches
> A.patch,...,D.patch, of which only D, B and C are to be applied, after
> applying the patches from ticket #9999 and #8888, you simply need to
> provide a comment that contains the lines
>
> depends on #9999, #8888
> apply D.patch, B.patch, A.patch
>
> So, the patchbot would only send out a message if one forgot to
> indicate how the patches should be applied (which is an important
> information anyway).

And otherwise it does a "best guess" kind of approach, which is decent
(especially if there is only one patch :). In any case, I don't think
people would mind getting a "nag" that the patchbot got confused,
indicating that it might be worth your while to give it a hint.

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

[sage-devel] Re: Linear Algebra over CDF

On Dec 30, 1:50 pm, Rob Beezer <goo...@beezer.cotse.net> wrote:
> I'd like to improve the current state of the linear algebra code over
> CDF (and by extension, over RDF).  The purpose would be to make Sage
> more usable for teaching various topics involving matrices with
> complex entries and orthogonal vectors (thus introducing square
> roots).  You can actually do quite a bit of this over the rationals,
> where (to my surprise) the square roots get approximated by rationals,
> and the accumulated errors are quite small.  But it makes more sense
> to me to actually work over CDF and liberally employ the .zero_at()
> method when showing students how to interpret the results.
>
> In any event, the goal would be to work up to things like QR
> decompositions, unitary matrices, orthogonal projections, etc.  A lot
> of this is present, but not always documented well.  I have not done a
> comprehensive survey yet, but for example, everything about QR
> decomposition talks about (and doctests) real matrices, even though
> the calls to NumPy are doing the right thing with complex entries and
> returning Q as unitary (not just orthogonal).  But there needs to be
> some prerequiste gaps filled for students to study these objects, the
> algorithms, etc (such as there is not yet a function to take the
> conjugate of a vector).
>
> The inner product especially has me stumped.  The following does not
> seem to be what we want at all:
>
> sage: v = vector(CDF, [I, I])
> sage: v.inner_product(v)
> -2.0
>
> I'd like to have the "usual" version with a conjugate of one of the
> vectors prior to the dot product (the sesquilinear form).  I can't see
> that setting a custom inner product matrix can make this happen, but
> maybe I'm missing something.  Should the inner product be over-ridden
> for vector spaces over the complex numbers?  Or, I hate to ask, should
> there be something new, like .complex_inner_product(),
> or .sesquilinear_inner_product()?  (Just kidding about that last
> one.)  Or maybe this inner product is lurking somewhere and I'm not
> noticing it.

I'd call this one a Hermitian inner product.
Well, I do not see anything wrong with sesquilinear either (especially
if this is done consistently, i.e.
for any given field automorphism).

Dima


>
> I know Jason Grout has done a lot of work to integrate this with
> NumPy.  I'm trolling for anything else folks can send me that might
> help: advice, informative Trac tickets, potential pitfalls, secret
> desires.  Thanks!
>
> Rob

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

[sage-devel] Re: [sage-notebook] Scalable Sage Server Architecture Proposal v0.1

On Thu, Dec 30, 2010 at 13:24, Alex Leone <acleone@gmail.com> wrote:
> Comments?  It would be good to discuss this before the upcoming bug days if
> we are going to do anything with the notebook.

Hi, I read most of it and I also read your posting on mongodb-users ;)

Basically, most of it is also what I would have in my mind ... just some notes:

1. I wouldn't do a "isAdmin" property for users. Rather, create one or
more groups that are marked as isAdmin and then add the users to that
group. This is basically how it is done nowdays in linux via the
/etc/sudoers file where a group "admin" is marked as being special and
the sudo command checks if the user is in the group admin.

2. The permissions, I don't really understand it. Why are they in each
group? I understand that each worksheet has a list of users (owners)
with permissions and groups with permissions, but at the group level I
don't get it. What does db.groups.users.{ perms: 1 or 0 } actually do?
I think, just a list of usernames is enough.

Do you know ACLs [1]? Maybe compare your mix of usernames and
permissions with the approach over there and do it this way!
Therefore, I would attach such a ACL list to each worksheet.

3. Worksheets reference to a collection of cells? Each document has a
4mb limit ... I know, that's a lot and it will probably never be hit,
but if there is some crazy long output it might happen. Second,
updates on worksheets only happen on the cell level, never on the
whole document. I know, mongodb has the ability to update a part of a
document via the update command, but I think it's easier to have a
collection of all cells and reference to them.
But still, when a cell is updated, only it's "out" field is modified.
Therefore, I propose to define a worksheet as a list of cells [or
later and more advanced, also as a nested list of worksheets ... i.e.
to make it possible to reference to another worksheet, to do "dynamic"
embeddings, sections/parts, meta-worksheet-documents ...].
Additionally, I could also envision cases, where each of those cells
get additional permissions, e.g. a "lock" that adds a "all: ---"
permission, so that nobody is able to edit a cell. (editing
permissions is of course still possible by the users and users in the
associated groups if they are allowed)


4. something trivial, instead of
out: [{ t:"stdout", data: "..."} , {t:"stderr", data: "..."}]
please just do
out: { stdout: "...", stderr: "..." }
Mongodb allows to list all keys in such an associative list and no
need for this {t: "..."} thing.
(or even better, get rid of "out" and just a stdout and stderr key is
good enough since their relative ordering doesn't matter.)

5. Images might probably be referenced explicitly, i.e. out: { img:
<file-id-reference> }

6. same as 5. for data files attached to worksheets. That's probably
what you mean with db.files anyways ... but it might be nice to know
when attached files are no longer needed to be able to run a
background process that removes unreferenced files.

h


[1] http://linux.die.net/man/5/acl
first, look at the "long text form", then read the algorithm for checking it.

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

[sage-devel] Scalable Sage Server Architecture Proposal v0.1

Hi all,

See attached document.

Comments?  It would be good to discuss this before the upcoming bug days if we are going to do anything with the notebook.

 - Alex

PS.  There's nothing in the document about the current sage notebook.  I agree that everything is premature optimization before benchmarking.  However, if the server isn't designed with multiple computers in mind, then it's not going to scale very well.  I also realize that the proposed design will require somewhat of a rewrite, but if we just focus on basic worksheet editing functionality (keeping in mind how to add other features), then we could get something up and running during bug days, and it would be easy to add stuff later without a large re-design.

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

[sage-devel] Re: patchbot+nagbot

On Dec 30, 10:01 am, Simon King <simon.k...@uni-jena.de> wrote:
> Hi Dave,
>
> On 30 Dez., 10:21, daveloeffler <dave.loeff...@gmail.com> wrote:
>
> > I can see a slight problem with this. At present there's no mechanism
> > to explain to the patchbot exactly which patches to apply. So if you
> > have (say) a ticket with a patch that requires a patch from an earlier
> > ticket to be applied, or if you have three patches of which only the
> > last two should be applied (because the first was a superseded
> > attempt), or any other nontrivial situation, the patchbot will be
> > sending out loads of unnecessary messages.
>
> I may be mistaken, but as far as I know, if ticket #9876 has 4 patches
> A.patch,...,D.patch, of which only D, B and C are to be applied, after
> applying the patches from ticket #9999 and #8888, you simply need to
> provide a comment that contains the lines
>
> depends on #9999, #8888
> apply D.patch, B.patch, A.patch
>
> So, the patchbot would only send out a message if one forgot to
> indicate how the patches should be applied (which is an important
> information anyway).
>
> Cheers,
> Simon

I'm sorry -- I clearly haven't been keeping pace with developments on
the patchbot! It gets more and more useful every day.

David

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

[sage-devel] Re: patchbot+nagbot

Hi Dave,

On 30 Dez., 10:21, daveloeffler <dave.loeff...@gmail.com> wrote:
> I can see a slight problem with this. At present there's no mechanism
> to explain to the patchbot exactly which patches to apply. So if you
> have (say) a ticket with a patch that requires a patch from an earlier
> ticket to be applied, or if you have three patches of which only the
> last two should be applied (because the first was a superseded
> attempt), or any other nontrivial situation, the patchbot will be
> sending out loads of unnecessary messages.

I may be mistaken, but as far as I know, if ticket #9876 has 4 patches
A.patch,...,D.patch, of which only D, B and C are to be applied, after
applying the patches from ticket #9999 and #8888, you simply need to
provide a comment that contains the lines

depends on #9999, #8888
apply D.patch, B.patch, A.patch

So, the patchbot would only send out a message if one forgot to
indicate how the patches should be applied (which is an important
information anyway).

Cheers,
Simon

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

[sage-devel] Re: patchbot+nagbot

On Dec 29, 6:52 pm, Robert Bradshaw <rober...@math.washington.edu>
wrote:
> On Wed, Dec 29, 2010 at 8:58 AM, Simon King <simon.k...@uni-jena.de> wrote:
> > Hi!
>
> > I just noticed that my patch from #10296 (ready for review, improving
> > the communication with singular via pexpect) had bit rotted.
>
> > Of course, the patchbot knew  that the old patch did not apply to the
> > current Sage version. Could the patchbot be modified à la "nagbot" and
> > inform the author of a patch if it fails to apply?

I can see a slight problem with this. At present there's no mechanism
to explain to the patchbot exactly which patches to apply. So if you
have (say) a ticket with a patch that requires a patch from an earlier
ticket to be applied, or if you have three patches of which only the
last two should be applied (because the first was a superseded
attempt), or any other nontrivial situation, the patchbot will be
sending out loads of unnecessary messages.

David

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

Re: [sage-devel] Re: Adjoint of a matrix

On Thu, 30 Dec 2010 at 12:22AM -0800, Rob Beezer wrote:
> Excepting the above - I want to build matrices out of sets of vectors
> where the vectors become columns (as optional behavior).

Big thumbs up to being able to easily make matrices whose columns are
specified vectors.

This past semester, I taught a basic linear algebra course (the first
I've done that's *only* linear algebra, no differential equations, etc).
I didn't use Sage, but if -- uh, I mean, *when* -- I do so in the
future, building matrices using vectors as columns will be key.

There are a number of "basic moves" in linear algebra that you do all
the time when describing algorithms, doing proofs, and so on. The better
Sage supports those basic moves, the easier it will be to experiment
with basic linear algebra stuff.

Dan

--
--- Dan Drake
----- http://mathsci.kaist.ac.kr/~drake
-------

[sage-devel] Re: Adjoint of a matrix

On Dec 29, 10:31 pm, Jason Grout <jason-s...@creativetrax.com> wrote:
> Notice that there is an underlying ideology that vectors are rows:

Yes, I have noticed that. Ties go to rows:

sage: matrix( [vector(QQ, [1,2,3]), vector(QQ,[4,5,6])] )
[1 2 3]
[4 5 6]

But the above is the first example where I have been tempted to
suggest some optional keyword to cause columns to win the tie. In
other words, I am writing instructions for beginning students on how
to use Sage for linear algebra and I've been surprised at how little
trouble I have had maintaining a column-oriented development alongside
Sage's row-oriented preferences. Excepting the above - I want to
build matrices out of sets of vectors where the vectors become columns
(as optional behavior).

> sage: u=vector([1,2,3])
> sage: matrix(u)
> [1 2 3]
> sage: u.transpose()
> [1]
> [2]
> [3]

If I were BDFL I'd ban the above. ;-) It converts vectors to
matrices without warning. Implicitly says vectors are row vectors,
while for a 3x3 matrix A, the expressions u*A and A*u both compute
just fine and so there is no such preference here. Can't have your
cake and eat it too. If I were to "conjugate-transpose" a vector, I'd
want it to remain a vector, not get upgraded to an n x 1 matrix. Or
go entirely to a strict dichotomy between row vectors and column
vectors. I'd default to implementing the proposed .star() as
returning a vector.

> I'm not sure how I feel about .star() yet.  I do think the .H property
> should be implemented, which would be consistent with numpy.

+10 to having .H

-5 to having to explain to students why you don't write it as .H()

Not as belligerent as I sound,
Rob ;-)

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

วันพุธที่ 29 ธันวาคม พ.ศ. 2553

[sage-devel] SAGE64

Hi, all,

When I run, say, 4.6, I get this printout prior to the sage banner:

Detected SAGE64 flag
Building Sage on OS X in 64-bit mode

Is this necessary?  There's no build underway, and I imagine that it could be disconcerting to someone who is not comfortable with the development aspects of Sage.

Justin

--
Justin C. Walker, Curmudgeon at Large
Institute for the Absorption of Federal Funds
-----------
Like the ski resort full of girls hunting for husbands
and husbands hunting for girls, the situation is not
as symmetrical as it might seem.
  - Alan MacKay
--

[sage-devel] Re: Adjoint of a matrix

On 12/29/10 11:09 PM, Rob Beezer wrote:
> Whatever we use here for matrices, I'd like to do the same thing for
> vectors over CDF (see related post from a few minutes ago).
> "conjugate_transpose" is a bit odd for vectors, since Sage carries no
> notion of vectors being rows or columns. And it wouldn't make sense
> to me to use .adjoint() on a vector if we didn't use it on matrices.


Notice that there is an underlying ideology that vectors are rows:

sage: u=vector([1,2,3])
sage: matrix(u)
[1 2 3]
sage: u.transpose()
[1]
[2]
[3]

So if a vector had a conjugate method, the conjugate transpose would
make sense and would be a matrix.


> Proposal: How do folks feel about using .star() for matrices and
> vectors as a shorthand/alias for .conjugate_transpose()
> and .conjugate() (respectively)?
>
> Pros:
>
> 1) A star is a very common notation for this. It is not universal,
> but I think the variants (H, a dagger) are more common in other fields
> (like physics).
>
> 2) Short.
>
> 3) No ambiguity about its past.
>
> 4) It does not appear to be used elsewhere as a method or function
> name (and only a few places as a keyword).
>
> Cons:
>
> 1) Highly non-obvious.
>
> 2) Others?

I'm not sure how I feel about .star() yet. I do think the .H property
should be implemented, which would be consistent with numpy.

Jason


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

[sage-devel] Re: Adjoint of a matrix

Whatever we use here for matrices, I'd like to do the same thing for
vectors over CDF (see related post from a few minutes ago).
"conjugate_transpose" is a bit odd for vectors, since Sage carries no
notion of vectors being rows or columns. And it wouldn't make sense
to me to use .adjoint() on a vector if we didn't use it on matrices.

Proposal: How do folks feel about using .star() for matrices and
vectors as a shorthand/alias for .conjugate_transpose()
and .conjugate() (respectively)?

Pros:

1) A star is a very common notation for this. It is not universal,
but I think the variants (H, a dagger) are more common in other fields
(like physics).

2) Short.

3) No ambiguity about its past.

4) It does not appear to be used elsewhere as a method or function
name (and only a few places as a keyword).

Cons:

1) Highly non-obvious.

2) Others?

Rob

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

[sage-devel] Linear Algebra over CDF

I'd like to improve the current state of the linear algebra code over
CDF (and by extension, over RDF). The purpose would be to make Sage
more usable for teaching various topics involving matrices with
complex entries and orthogonal vectors (thus introducing square
roots). You can actually do quite a bit of this over the rationals,
where (to my surprise) the square roots get approximated by rationals,
and the accumulated errors are quite small. But it makes more sense
to me to actually work over CDF and liberally employ the .zero_at()
method when showing students how to interpret the results.

In any event, the goal would be to work up to things like QR
decompositions, unitary matrices, orthogonal projections, etc. A lot
of this is present, but not always documented well. I have not done a
comprehensive survey yet, but for example, everything about QR
decomposition talks about (and doctests) real matrices, even though
the calls to NumPy are doing the right thing with complex entries and
returning Q as unitary (not just orthogonal). But there needs to be
some prerequiste gaps filled for students to study these objects, the
algorithms, etc (such as there is not yet a function to take the
conjugate of a vector).

The inner product especially has me stumped. The following does not
seem to be what we want at all:

sage: v = vector(CDF, [I, I])
sage: v.inner_product(v)
-2.0

I'd like to have the "usual" version with a conjugate of one of the
vectors prior to the dot product (the sesquilinear form). I can't see
that setting a custom inner product matrix can make this happen, but
maybe I'm missing something. Should the inner product be over-ridden
for vector spaces over the complex numbers? Or, I hate to ask, should
there be something new, like .complex_inner_product(),
or .sesquilinear_inner_product()? (Just kidding about that last
one.) Or maybe this inner product is lurking somewhere and I'm not
noticing it.

I know Jason Grout has done a lot of work to integrate this with
NumPy. I'm trolling for anything else folks can send me that might
help: advice, informative Trac tickets, potential pitfalls, secret
desires. Thanks!

Rob

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

[sage-devel] Re: How is matrix action on vectors implemented?

Hi Robert,

On 29 Dez., 20:04, Robert Bradshaw <rober...@math.washington.edu>
wrote:
> On Tue, Dec 28, 2010 at 11:49 PM, Simon King <simon.k...@uni-jena.de> wrote:
> > ...
> >  sage: G = SymmetricGroup(5)
> >  sage: C = Groupoid(G)
> >  sage: G.random_element() in C.hom_category()
> >  False
>
> > Shouldn't the last line return "True"?
>
> Hmm... Groupoid is the wrong category here. Or, rather, the category
> we want is a groupoid, but not this one.

Yep, what I wrote was nonsense. See my post at sage-algebra,
http://groups.google.com/group/sage-algebra/browse_thread/thread/3e2ca2a8be1a3a23
(I think this discussion should be moved to sage-algebra):

If g is an element of G, then "g in C.hom_category()" should of
course return "False", since g is not a homset (but it is contained
in a homset).

Note that we currently have
sage: R.<x,y,z> = ZZ[]
sage: f = R.hom([x^2,y^2,z^2])
sage: C = R.category()
sage: f in C.hom_category()
True
which I think is a bug.

I think one *should* test the property of being a morphism by
"parent(g) in Groupoid(G).hom_category()" (which is not implemented
yet) resp. "parent(f) in C.hom_category()" (which works already).

> I'd say it would make sense to implement Actions as a mapping G x S ->
> S', which is essentially what the implementation is now. There should
> be functions provided to view this as a map G -> Hom(S, S') and as a
> functor, but the inheritance is certainly odd and wrong the way it is
> now.

OK, then let's make it so.

> Should containment be for morphisms, objects, or both?

See above: Not "g in C.hom_category()" but "parent(g) in
C.hom_category()".

Cheers,
Simon

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

Re: [sage-devel] Re: How is matrix action on vectors implemented?

On Tue, Dec 28, 2010 at 11:49 PM, Simon King <simon.king@uni-jena.de> wrote:
> Hi Robert,
>
> On 28 Dez., 23:41, Robert Bradshaw <rober...@math.washington.edu>
> wrote:
>> > According to your post, it should be "A group action G x S rightarrow
>> > S is a functor from G (considered as a category) to the category of
>> > Morphisms of Sets", and in the code it should be
>> > Functor.__init__(self, Groupoid(G), S.category().hom_category()).
>>
>> Not quite. It is G considered as a category where the elements of G
>> are the morphisms and there only one object, so it is actually a
>> functor to the categories of sets.
>
> I see. But is that category actually implemented in Sage? Apparently
> it is not Groupoid(G) (as one might expect from the code snippet
> above):
>  sage: G = SymmetricGroup(5)
>  sage: C = Groupoid(G)
>  sage: G.random_element() in C.hom_category()
>  False
>
> Shouldn't the last line return "True"?

Hmm... Groupoid is the wrong category here. Or, rather, the category
we want is a groupoid, but not this one.

> I'd like to provide both the categorical approach towards actions and
> the other approach: It would be up to the user what approach to use
> for a new action, and there should be a way to consider any action
> both as a functor and as a map, regardless how it was defined (see my
> post on sage-algebra).

I'd say it would make sense to implement Actions as a mapping G x S ->
S', which is essentially what the implementation is now. There should
be functions provided to view this as a map G -> Hom(S, S') and as a
functor, but the inheritance is certainly odd and wrong the way it is
now.

> But before that is possible, it seems that one needs to provide a
> proper HomCategory for groupoids with a __contains__ method that
> relies on containment in the underlying set.

Should containment be for morphisms, objects, or both?

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

Re: [sage-devel] patchbot+nagbot

On Wed, Dec 29, 2010 at 8:58 AM, Simon King <simon.king@uni-jena.de> wrote:
> Hi!
>
> I just noticed that my patch from #10296 (ready for review, improving
> the communication with singular via pexpect) had bit rotted.
>
> Of course, the patchbot knew  that the old patch did not apply to the
> current Sage version. Could the patchbot be modified à la "nagbot" and
> inform the author of a patch if it fails to apply?

That would be nice. I've been thinking about making it add a note to
trac, so every relevant person on trac would be notified. (Or I could
harvest the nagbot emails addresses, but that would be a pain to keep
up to date).

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

[sage-devel] Re: Mutability of echelon form result

Thanks, Robert. I'll dig deeper.

On Dec 28, 11:24 pm, Robert Bradshaw <rober...@math.washington.edu>
wrote:
> On Tue, Dec 28, 2010 at 8:38 PM, Rob Beezer <goo...@beezer.cotse.net> wrote:
> > sage: A=matrix(QQ,2,range(4))
> > sage: B=matrix(ZZ,2,range(4))
> > sage: C=A.echelon_form()
> > sage: D=B.echelon_form()
> > sage: C.is_mutable()
> > True
> > sage: D.is_mutable()
> > False
>
> > Should C and D be different with regard to mutability?  If not, should
> > both results be immutable?  (I'd rather not have to handle both
> > possibilities!)
>
> It's almost certain that mutability of C is an oversight.
>
> - 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+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] patchbot+nagbot

Hi!

I just noticed that my patch from #10296 (ready for review, improving
the communication with singular via pexpect) had bit rotted.

Of course, the patchbot knew that the old patch did not apply to the
current Sage version. Could the patchbot be modified à la "nagbot" and
inform the author of a patch if it fails to apply?

Cheers,
Simon

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

Re: [sage-devel] Re: Ideas for improvements in Mac app

On Dec 20, 2010, at 8:18 PM, David Joyner wrote:
> On Mon, Dec 20, 2010 at 12:13 PM, Ivan Andrus <darthandrus@gmail.com> wrote:
>> On Dec 20, 2010, at 5:48 PM, Jason Grout wrote:
>>> On 12/20/10 10:19 AM, Ivan Andrus wrote:
>>>> With the semester over, I'll have some time and I thought I'd work on
>>>> a few improvements to the Mac app. I have some improvements that I
>>>> would like to make, but I would very much like to know what others
>>>> think would be good/important to have. No suggestion is too big or
>>>> too small.
>>>
>>> What improvements are you thinking of doing?
>>
>> 1. Double click opening of sws (and maybe pdf files).
>
> +1

Okay, I have a patch up at #8473. It depends on #693 which I can give a positive review, except that I used the code, so I don't know if I'm allowed.

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

I don't know the notebook code very well, so someone with some expertise in that would be useful. Also testing of the Mac App would be nice. In particular there is a new option which may not be necessary.

Also please let me know if I should do anything differently to help the patchbot.

-Ivan

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

[sage-devel] Re: error compiling gnutls on suse 11.3

Install your distribution's lzo and lzo-devel packages.

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

[sage-devel] error compiling gnutls on suse 11.3

Hello:
We just got an error compiling sage (we tried versions 4.5.3 and 4.6)
in opensuse 11.3 32 bits. We took care of the readline problem that
other people reported recently, just in case, but even though all
reports regarding compile problems with suse 11 end up in a successful
compile, it didn't work for us. The error occurs very early, when
compiling gnutls. The first line says "gcc: /usr/lib/liblzo2.so: No such
file or directory", but that file is there!

Thanks

gcc: /usr/lib/liblzo2.so: No such file or directory
make[5]: *** [libgnutls-extra.la] Error 1
make[5]: Leaving directory
`/root/Downloads/sage-4.6/spkg/build/gnutls-2.2.1.p5/src/libextra'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory
`/root/Downloads/sage-4.6/spkg/build/gnutls-2.2.1.p5/src/libextra'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/root/Downloads/sage-4.6/spkg/build/gnutls-2.2.1.p5/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/root/Downloads/sage-4.6/spkg/build/gnutls-2.2.1.p5/src'
failed to build GNUTLS

real 0m43.460s
user 0m26.462s
sys 0m3.648s
sage: An error occurred while installing gnutls-2.2.1.p5
Please email sage-devel http://groups.google.com/group/sage-devel
explaining the problem and send the relevant part of
of /root/Downloads/sage-4.6/install.log. Describe your computer,
operating system, etc.
If you want to try to fix the problem yourself, *don't* just cd to
/root/Downloads/sage-4.6/spkg/build/gnutls-2.2.1.p5 and type 'make
check' or whatever is appropriate.
Instead, the following commands setup all environment variables
correctly and load a subshell for you to debug the error:
(cd '/root/Downloads/sage-4.6/spkg/build/gnutls-2.2.1.p5' &&
'/root/Downloads/sage-4.6/sage' -sh)
When you are done debugging, you can type "exit" to leave the
subshell.
make[1]: *** [installed/gnutls-2.2.1.p5] Error 1
make[1]: Leaving directory `/root/Downloads/sage-4.6/spkg'

real 2m58.532s
user 2m2.972s
sys 0m11.613s
Error building Sage.


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

[sage-devel] a bug in ./sage -upgrade?

Running ./sage --upgrade
without a parameter nuked the version (4.6.1.aplha3) I had, as it
started updating 4.6 instead....

I suppose this is a bug...

Dima

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

[sage-devel] Re: sage-4.6.1.rc0 released

Running ./sage --upgrade
without a parameter nuked the version (4.6.1.aplha3) I had, as it
started updating 4.6 instead....

I suppose this is a bug...

Dima


On Dec 27, 2:54 pm, leif <not.rea...@online.de> wrote:
> Justin C. Walker wrote:
>
> > On Dec 26, 2010, at 21:01 , John H Palmieri wrote:
>
> >> On Dec 24, 2:42 pm, "Justin C. Walker" <jus...@mac.com> wrote:
> >>> On Dec 24, 2010, at 07:55 , Jeroen Demeyer wrote:
> >>>> Upgrade path:
>
> >>>>http://sage.math.washington.edu/home/release/sage-4.6.1.rc0/sage-4.6....
>
> >>> Upgrade from 4.6.1.a3 failed with this complaint:
>
> >>> Failed to download 'http://sage.math.washington.edu/home/release/sage-4.6.1.rc0/sage-4.6.....
> >>> Abort.
>
> >> This is because of a bug in 4.6.1.alpha3 (or maybe alpha2?): in that
> >> alpha version, sage-update was changed so that it tries to download a
> >> nonexistent file.  Updating from any other version of Sage should work
> >> fine, and updating from rc0 to a later version I think should work
> >> too.
>
> > That will teach me to pay attention.  Well, maybe...
>
> > Thanks; I'll try an earlier version.
>
> Just hack your current local/bin/sage-update: ;-)
>
> @@ -351,7 +358,7 @@
>          version_file.close()
>      else:
>          old_version = ""
> -    download_file("VERSION.txt")
> +    download_file("standard/VERSION.txt")
>      version_file = open("VERSION.txt")
>      new_version = version_file.read()
>      new_version = new_version.strip()  # remove trailing newline
> @@ -364,11 +371,18 @@
>          version_file = open("VERSION.txt", 'w')
>          version_file.write("%s%s" % (new_version, old_version))
>          version_file.close()
> +    # shutil.copy raises an error if the destination already exists,
> +    # so remove SPKG_ROOT/standard/VERSION.txt.
> +    try:
> +        os.remove(os.path.join(SPKG_ROOT, "standard", "VERSION.txt"))
> +    except OSError:
> +        pass
> +    shutil.copy("VERSION.txt", os.path.join(SPKG_ROOT, "standard"))
>
> (The first hunk should suffice I think. Just an excerpt from the patches.)
>
> Cheers,
> -Leif

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

วันอังคารที่ 28 ธันวาคม พ.ศ. 2553

[sage-devel] Re: How is matrix action on vectors implemented?

Hi Robert,

On 28 Dez., 23:41, Robert Bradshaw <rober...@math.washington.edu>
wrote:
> > According to your post, it should be "A group action G x S rightarrow
> > S is a functor from G (considered as a category) to the category of
> > Morphisms of Sets", and in the code it should be
> > Functor.__init__(self, Groupoid(G), S.category().hom_category()).
>
> Not quite. It is G considered as a category where the elements of G
> are the morphisms and there only one object, so it is actually a
> functor to the categories of sets.

I see. But is that category actually implemented in Sage? Apparently
it is not Groupoid(G) (as one might expect from the code snippet
above):
sage: G = SymmetricGroup(5)
sage: C = Groupoid(G)
sage: G.random_element() in C.hom_category()
False

Shouldn't the last line return "True"?

I'd like to provide both the categorical approach towards actions and
the other approach: It would be up to the user what approach to use
for a new action, and there should be a way to consider any action
both as a functor and as a map, regardless how it was defined (see my
post on sage-algebra).

But before that is possible, it seems that one needs to provide a
proper HomCategory for groupoids with a __contains__ method that
relies on containment in the underlying set.

Cheers,
Simon

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

Re: [sage-devel] Re: Modular instead of monolithic

On Tue, Dec 28, 2010 at 6:46 PM, Aleksej Saushev <asau@inbox.ru> wrote:
> John H Palmieri <jhpalmieri64@gmail.com> writes:
>
>> On Dec 22, 5:34 am, Cedric <Man...@gmx.net> wrote:
>>> I love SAGE but then there is one flaw in it that I find one of the
>>> most severe in software-design of all. From my layman point of view
>>> (which I'm sure is wrong and unjustified) a software that bundles
>>> every single of its dozens dependencies has either a fundamental
>>> design flaw or is extremely badly managed.
>>
>> Please come up with a better system which will easily work on all of
>> the common linux platforms, Mac OS X, Solaris, and OpenSolaris.
>
> There exist package management systems that do that already.
> One of them is pkgsrc. If you work with Solaris, you should know it,
> it seems to popular choice there.

I've never heard of it, but if anyone wants to have a try you could
see how easy or hard it would be.

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

Re: [sage-devel] Mutability of echelon form result

On Tue, Dec 28, 2010 at 8:38 PM, Rob Beezer <google@beezer.cotse.net> wrote:
> sage: A=matrix(QQ,2,range(4))
> sage: B=matrix(ZZ,2,range(4))
> sage: C=A.echelon_form()
> sage: D=B.echelon_form()
> sage: C.is_mutable()
> True
> sage: D.is_mutable()
> False
>
> Should C and D be different with regard to mutability?  If not, should
> both results be immutable?  (I'd rather not have to handle both
> possibilities!)

It's almost certain that mutability of C is an oversight.

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

[sage-devel] Mutability of echelon form result

sage: A=matrix(QQ,2,range(4))
sage: B=matrix(ZZ,2,range(4))
sage: C=A.echelon_form()
sage: D=B.echelon_form()
sage: C.is_mutable()
True
sage: D.is_mutable()
False

Should C and D be different with regard to mutability? If not, should
both results be immutable? (I'd rather not have to handle both
possibilities!)

Thanks,
Rob

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

[sage-devel] Re: Modular instead of monolithic

John H Palmieri <jhpalmieri64@gmail.com> writes:

> On Dec 22, 5:34 am, Cedric <Man...@gmx.net> wrote:
>> I love SAGE but then there is one flaw in it that I find one of the
>> most severe in software-design of all. From my layman point of view
>> (which I'm sure is wrong and unjustified) a software that bundles
>> every single of its dozens dependencies has either a fundamental
>> design flaw or is extremely badly managed.
>
> Please come up with a better system which will easily work on all of
> the common linux platforms, Mac OS X, Solaris, and OpenSolaris.

There exist package management systems that do that already.
One of them is pkgsrc. If you work with Solaris, you should know it,
it seems to popular choice there.


--
HE CE3OH...

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

[sage-devel] Appengine based memoizing for python/sage

Hi,

Some long-running (~30 minutes) calculations I needed to do recently
in Sage working with a student inspired me to write a python
memoization library which uses Google App Engine to cache the output
of (decorated) functions. This means that if multiple people are
working on the same project they can all benefit from quick
calculations once one person has done the calculation. Also
memoization persists through stopping and starting python and
modifying other parts of the code (but obviously if the memoized
function is modified then the values have to be recalculated). The
target of my library is for calculations which take long enough to be
annoying, but no so long that it's worth writing file outputs etc.

The reason I am writing to this list is the hope that others might
find such a library useful also. The source code is available
https://github.com/jjh2/cloudm and is easily installed in sage
! easy_install decorator cloudm
will install the library.

Once setup adding this caching to a function done using a simple decorator
@cloudmemoize
def myfunc(params)

Calls to myfunc will now be cached on a global server and if the
result already exists in the cache myfunc won't be calculated again.

The library appears to work well enough for my needs but, of course,
it's still in very early development. Feel free to let me know if
anyone ends up finding it useful or has any improvements etc.

Regards,
Jonny

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

Re: [sage-devel] Re: How is matrix action on vectors implemented?

On Tue, Dec 28, 2010 at 12:46 AM, Simon King <simon.king@uni-jena.de> wrote:
> Hi Robert,
>
> On 28 Dez., 01:27, Robert Bradshaw <rober...@math.washington.edu>
> wrote:
>> ... You're working on
>> moving modules over to the new coercion framework, right?
>
> Yes.
>
>> > But how does one
>> > define an action? I guess that one is supposed to use
>> > sage.categories.action, but so far it has no example at all.
>>
>> http://hg.sagemath.org/sage-main/file/120c07be6358/sage/matrix/action...
>> is the most comprehensive example to date.
>
> Yes, I had looked at that example when I tried to understand how
> matrix action works. However, I couldn't see how it relates with
> functors, since it seems to me that it overrides all "typical" methods
> of functors.
>
>> > How are these two definitions related?
>>
>> Consider the category with a single object whose morphisms are the
>> element of G. Then the functor send the elements of G to morphisms in
>> Sets.
>
> That makes sense, but it does neither match the code nor the
> documentation.

I agree 100%. This is a case of someone (likely me) trying to map a
single mathematical view of an object onto an implementation. Even if
there is an "is a" relationship, it would probably make more sense for
Action to not inherit from Functor, as they behave and are used
completely differently.

> sage.categories.action.Action.__init__ is
> {{{
>    def __init__(self, G, S, bint is_left = 1, op=None):
>        from groupoid import Groupoid
>        Functor.__init__(self, Groupoid(G), S.category())
>        self.G = G
>        self.S = S
>        self._is_left = is_left
>        self.op = op
> }}}
> and sage.categories.action.__doc__ states "A group action G x S
> rightarrow S is a functor from G to Sets."
>
> According to your post, it should be "A group action G x S rightarrow
> S is a functor from G (considered as a category) to the category of
> Morphisms of Sets", and in the code it should be
> Functor.__init__(self, Groupoid(G), S.category().hom_category()).

Not quite. It is G considered as a category where the elements of G
are the morphisms and there only one object, so it is actually a
functor to the categories of sets. But, as I've stated above, this is
not the most useful perspective of an action (in our context at
least).

> Moreover, sage.matrix.action.MatrixMatrixAction is implemented by a
> _call_ method that has the signature
>   cpdef Element _call_(self, g, s)
> Hence, essentially it is a map (not a functor) from GxS to S -- so,
> the implementation uses the category-free definition of an action, but
> pretends to be categorical.
>
> One crucial question is, IMO:
> Would it really be wise to use a categorical approach towards actions?

I don't think so. Especially now that the category framework allows
attaching abstract mathematical structure to objects independent of
their inheritance and implementation.

> Using the categorical definition would mean: To any given element g of
> G, create a morphism from S to S (very slow!), and apply it to a given
> element s of S. I guess caching the morphism from S to S would not
> really be a solution. So, the current approach to think of an action
> as a map from GxS to S probably yields a better implementation (speed-
> wise).

It's often useful to be able to obtain the morphism corresponding to
any element (there is currently such a method on actions), but as
reflected in the current state of things and your comments this does
not yield a good implementation.

> But then, the question is what one should do with
> sage.categories.action? Should it be overhauled so that it really
> matches the categorical definition, just for completeness, even though
> it would not be used in Sage?
>
> Should there also be an "official" new framework for the non-
> categorical version of an action, say, in sage.structure.action? Then,
> actions that currently tacitly use the non-categorical definition
> (like MatrixMatrixAction) could finally be "officially non-
> categorical"?

Unless I'm mistaken, nearly every action that's used is in the context
of the coercion framework, which, though I want it to be
mathematically sound, I consider to be as much of a user interface
component as a mathematical one.

In fact, I just did a search through the sage sources and it looks
like there aren't any Actions other than the coercion one, so we could
probably just cut out the (weak) categorical ties.

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

[sage-devel] Re: How is matrix action on vectors implemented?

Hi!

I guess further discussion should be moved to sage-algebra. See
http://groups.google.com/group/sage-algebra/browse_thread/thread/1787794a7a42cfb5

Cheers,
Simon

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

[sage-devel] Re: new numerical developments in Sage ?

> well, soon one should be able to solve semidefinite programming
> programs in Sage
> (I have a an interface with cvxopt almost done)

And Linear Programming as well as Integer Linear Programming are
already heavily used by graphs !

This used to belong to the numerical section, though it nowhas a
section of its own on the TRAC server :-)

Nathann

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

[sage-devel] Re: new numerical developments in Sage ?

well, soon one should be able to solve semidefinite programming
programs in Sage
(I have a an interface with cvxopt almost done)

On Dec 28, 4:44 pm, Thierry Dumont <tdum...@math.univ-lyon1.fr> wrote:
> Hi,
>
> With some other French Colleagues, we organize a "mini-symposium"
> about Sage at the Congress of the French Mathematical Society in May
> (seehttp://smai.emath.fr/smai2011/). There will be some short talks (30
> mn) about Sage in different domains of Applied Maths, even in Industrial
> fields.
> I am supposed to speak about numerics in Sage. I'll speak about what
> exists nowadays, but I would like to know if there are  currently
> projects, developments (if any), in this field of Numerical methods.
>
> Yours,
> t.d.
>
>  tdumont.vcf
> < 1KViewDownload

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

[sage-devel] Re: How is matrix action on vectors implemented?

On 28 Dez., 09:46, Simon King <simon.k...@uni-jena.de> wrote:
> Moreover, sage.matrix.action.MatrixMatrixAction is implemented by a
> _call_ method that has the signature
>    cpdef Element _call_(self, g, s)
> Hence, essentially it is a map (not a functor) from GxS to S

... or actually from GxS to something into which S coerces. But that
doesn't change the fact that it makes no use of the functor framework.

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

[sage-devel] Re: How is matrix action on vectors implemented?

Hi Robert,

On 28 Dez., 01:27, Robert Bradshaw <rober...@math.washington.edu>
wrote:
> ... You're working on
> moving modules over to the new coercion framework, right?

Yes.

> > But how does one
> > define an action? I guess that one is supposed to use
> > sage.categories.action, but so far it has no example at all.
>
> http://hg.sagemath.org/sage-main/file/120c07be6358/sage/matrix/action...
> is the most comprehensive example to date.

Yes, I had looked at that example when I tried to understand how
matrix action works. However, I couldn't see how it relates with
functors, since it seems to me that it overrides all "typical" methods
of functors.

> > How are these two definitions related?
>
> Consider the category with a single object whose morphisms are the
> element of G. Then the functor send the elements of G to morphisms in
> Sets.

That makes sense, but it does neither match the code nor the
documentation.

sage.categories.action.Action.__init__ is
{{{
def __init__(self, G, S, bint is_left = 1, op=None):
from groupoid import Groupoid
Functor.__init__(self, Groupoid(G), S.category())
self.G = G
self.S = S
self._is_left = is_left
self.op = op
}}}
and sage.categories.action.__doc__ states "A group action G x S
rightarrow S is a functor from G to Sets."

According to your post, it should be "A group action G x S rightarrow
S is a functor from G (considered as a category) to the category of
Morphisms of Sets", and in the code it should be
Functor.__init__(self, Groupoid(G), S.category().hom_category()).

Moreover, sage.matrix.action.MatrixMatrixAction is implemented by a
_call_ method that has the signature
cpdef Element _call_(self, g, s)
Hence, essentially it is a map (not a functor) from GxS to S -- so,
the implementation uses the category-free definition of an action, but
pretends to be categorical.

One crucial question is, IMO:
Would it really be wise to use a categorical approach towards actions?

Using the categorical definition would mean: To any given element g of
G, create a morphism from S to S (very slow!), and apply it to a given
element s of S. I guess caching the morphism from S to S would not
really be a solution. So, the current approach to think of an action
as a map from GxS to S probably yields a better implementation (speed-
wise).

But then, the question is what one should do with
sage.categories.action? Should it be overhauled so that it really
matches the categorical definition, just for completeness, even though
it would not be used in Sage?

Should there also be an "official" new framework for the non-
categorical version of an action, say, in sage.structure.action? Then,
actions that currently tacitly use the non-categorical definition
(like MatrixMatrixAction) could finally be "officially non-
categorical"?

Cheers,
Simon

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