12 views

Skip to first unread message

Nov 30, 2008, 12:22:46 PM11/30/08

to sage-...@googlegroups.com, sage-comb...@googlegroups.com

Michael Abshoff wrote in the comments to trac ticket #4653:

> one issue that might be worth considering now before merging is

> "name space pollution", i.e. there was some discussion at SD 11

> that it would be better to have most of the functionality of certain

> packages like quadratic forms not in the global namespace.

> I am not sure what the situation with words is (sorry, no time to

> apply the patch and play :)), but it would be nice if most of the

> functionality would be in

>

> words.$FOO

>

> Sooner or later things will start colliding in the global namespace,

> so the time to fix this would be pre-merge :)

I like this idea for several reasons, but it is something that needs

to be discussed since there should be a consistent way to do this

across all Sage packages/libraries. So let's discuss it. What is the

best way to do this? (I wasn't at Sage Days 11, so I don't know what

was decided.)

One thing that comes to mind, from a user's perspective, is that there

should be a consistent way to load all functions from a given package

into the global name space. Something like:

LoadPackage(words)

or

from words import *

I prefer the latter, actually.

Another related issue, perhaps this should be a different thread, is

pre-defined examples of objects. I am going to use graphs to

illustrate what I mean here. One can write, for example,

sage: graphs.CompleteGraph(5)

Complete graph: Graph on 3 vertices

But there are other objects lying around in the global name space

which should probably be access by such interface. And this should

also be consistent across Sage. Is graphs a suitable name for this?

Should it be something like GraphExamples or GraphConstructor or

something else instead? One problem with the name graphs is that some

sage-combinat developer is going to come along and define the

combinatorial class of all graphs and name it Graphs. Then graphs and

Graphs might have different behaviour unless one allows something like

this:

sage: Graphs(3)

Graphs on 3 vertices

sage: Graphs.CompleteGraph(5)

Complete graph: Graph on 3 vertices

Thoughts/comments?

Franco

--

Nov 30, 2008, 5:07:45 PM11/30/08

to sage-...@googlegroups.com, sage-comb...@googlegroups.com

I really like

sage: finance.[tab]

I don't like explicitly forcing people to import stuff before they can use it

at all. Thus I much prefer

$ sage

....

sage: finance.[tab]

and I don't like

$ sage

...

sage: import sage.finance as finance

sage: finace.[tab]

I do like various domains with lots of functions to have their

functionality gathered together under

a namespace. That said, I'm not for some massive reorganization of

the current global namespace, since that wold break a huge amount of

existing code -- both in Sage and out (e.g., the examples at

wiki.sagemath.org/interact).

And it's not the end of the world that len(globals()) is large. It's

only a problem to me when there are specific reasons it is a problem.

-- William

Nov 30, 2008, 5:11:58 PM11/30/08

to sage-devel

<SNIP>

> I really like

>

> sage: finance.[tab]

>

> I don't like explicitly forcing people to import stuff before they can use it

> at all. Thus I much prefer

>

> $ sage

> ....

> sage: finance.[tab]

>

> and I don't like

>

> $ sage

> ...

> sage: import sage.finance as finance

> sage: finace.[tab]

>

> I do like various domains with lots of functions to have their

> functionality gathered together under

> a namespace. That said, I'm not for some massive reorganization of

> the current global namespace, since that wold break a huge amount of

> existing code -- both in Sage and out (e.g., the examples at

> wiki.sagemath.org/interact).

>

> And it's not the end of the world that len(globals()) is large. It's

> only a problem to me when there are specific reasons it is a problem.

>

> -- William

Ok, that is pretty much what I wanted to express, i.e. having most

things of a given subsystem gathered under $SUBSYSTEM.[tab]. I did not

mean that one would have to import things, so my use of "global

namespace" was not in the pythonic way.

Cheers,

Michael

> I really like

>

> sage: finance.[tab]

>

> I don't like explicitly forcing people to import stuff before they can use it

> at all. Thus I much prefer

>

> $ sage

> ....

> sage: finance.[tab]

>

> and I don't like

>

> $ sage

> ...

> sage: import sage.finance as finance

> sage: finace.[tab]

>

> I do like various domains with lots of functions to have their

> functionality gathered together under

> a namespace. That said, I'm not for some massive reorganization of

> the current global namespace, since that wold break a huge amount of

> existing code -- both in Sage and out (e.g., the examples at

> wiki.sagemath.org/interact).

>

> And it's not the end of the world that len(globals()) is large. It's

> only a problem to me when there are specific reasons it is a problem.

>

> -- William

things of a given subsystem gathered under $SUBSYSTEM.[tab]. I did not

mean that one would have to import things, so my use of "global

namespace" was not in the pythonic way.

Cheers,

Michael

Dec 1, 2008, 8:49:05 AM12/1/08

to sage-devel

Are there some general guidelines on how to use the namespaces in

sage. Like: which function's should be accesible from which namespace

(global v.s. local and maybe some hierachical structure in the local

namespace).

I think some guidelines on this would improve the userfriendliness of

sage a big deal in the long run.

I personally find the polution of the global namespace and some local

namespace's to get already a bit annoying and making the [tab]

funtionality a whole less usefull then it could be for when quickly

trying to find some funtion.

Here are just some random ideas on what might be in these guidlines (I

don't claim them all to be good so be happy to comment at them, or

propose your own, or just shoot me ;))

1 A packege should, without a good reason (like almost every

mathematician need the package almost all of the time), not use more

then X names in the global namespace. (You could ofcourse do import

Foo to get more things in the global namespace when using a certain

package very heavely).

2 All functionallity related to a package should always be accessible

by Packagename.[tab] or Packagename.Subpackage.[tab] or

Packagename.Subpackage.SubSubPackage.[tab] e.t.c.

3 Names of Subpackages should start with a capitalized letter, while

names of atributes and functions should not (or any other convenient

way to make an easy distinction between packages and functions)

4 Maybe some guidelines to encourage nice hierachical namespace

design.

5 Some sort of template hierachy to make the user interface

(espesially the [tab]) in sage feel the same through all packages.

5.1 For example categorical constructions like (fibred) sum, (firbred)

product, etc occur in all area's of mathematics, and could be grouped

in PackageName.CategoricalStuff (sorry for the lame name).

5.2 Another one is to make all object initialisation commands

available through something like PackageName.Init. using the current

graph implementation this addition would make the following two

statements equivalent

sage: graphs.CompleteGraph(6)

sage: Graph.Init.CompleteGraph(6)

Hope you don't mind the long tekst.

Maarten

sage. Like: which function's should be accesible from which namespace

(global v.s. local and maybe some hierachical structure in the local

namespace).

I think some guidelines on this would improve the userfriendliness of

sage a big deal in the long run.

I personally find the polution of the global namespace and some local

namespace's to get already a bit annoying and making the [tab]

funtionality a whole less usefull then it could be for when quickly

trying to find some funtion.

Here are just some random ideas on what might be in these guidlines (I

don't claim them all to be good so be happy to comment at them, or

propose your own, or just shoot me ;))

1 A packege should, without a good reason (like almost every

mathematician need the package almost all of the time), not use more

then X names in the global namespace. (You could ofcourse do import

Foo to get more things in the global namespace when using a certain

package very heavely).

2 All functionallity related to a package should always be accessible

by Packagename.[tab] or Packagename.Subpackage.[tab] or

Packagename.Subpackage.SubSubPackage.[tab] e.t.c.

3 Names of Subpackages should start with a capitalized letter, while

names of atributes and functions should not (or any other convenient

way to make an easy distinction between packages and functions)

4 Maybe some guidelines to encourage nice hierachical namespace

design.

5 Some sort of template hierachy to make the user interface

(espesially the [tab]) in sage feel the same through all packages.

5.1 For example categorical constructions like (fibred) sum, (firbred)

product, etc occur in all area's of mathematics, and could be grouped

in PackageName.CategoricalStuff (sorry for the lame name).

5.2 Another one is to make all object initialisation commands

available through something like PackageName.Init. using the current

graph implementation this addition would make the following two

statements equivalent

sage: graphs.CompleteGraph(6)

sage: Graph.Init.CompleteGraph(6)

Hope you don't mind the long tekst.

Maarten

Dec 2, 2008, 4:22:30 AM12/2/08

to sage-...@googlegroups.com

> That said, I'm not for some massive reorganization of

> the current global namespace, since that wold break a huge amount of

> existing code -- both in Sage and out (e.g., the examples at

> wiki.sagemath.org/interact).

>

> the current global namespace, since that wold break a huge amount of

> existing code -- both in Sage and out (e.g., the examples at

> wiki.sagemath.org/interact).

>

I definitely agree that reorganizing and/or massively reducing the

global namespace would be a silly thing to do. However, I do think

things could be cleaned up a bit, and that certain things would

actually be *easier* to find if they were gathered into some

namespaces. Here are some thoughts:

1. I think a massively useful namespace would be databases.<tab>. As

it stands, we have various databases scattered throughout the global

namespace ... here are a few I found at random:

ConwayPolynomials

ClassicalModularPolynomialDatabase

zeta_zeros

cm_j_invariants

I've picked these somewhat at random, but I wanted to point out that

(1) the naming is (for good reason!) not at all uniform, and (2)

"Database" doesn't necessarily occur anywhere in the names. It would

be really interesting to be able to see all of the databases we have

at one fell swoop, I think. Also, it would be extremely helpful for

the person who wanted to see a database of modular polynomials, but

didn't realize that we labeled them ClassicalModularPolynomials.

2. I also think that there are cases where the global namespace is

getting a little polluted. Again, I was "tabbing around" at random, so

I don't think that these are necessarily the best examples, but I

think they're both good examples of places where we could probably

trim down the global namespace without losing anything serious.

First: David Joyner has done a lot of work to wrap various

functionality for computing special functions in Maxima & Pari in

sage. Tab completing, one finds things like:

sage: elliptic_<TAB>

elliptic_curves elliptic_ec elliptic_f elliptic_pi

elliptic_e elliptic_eu elliptic_kc

sage: spherical_<TAB>

spherical_bessel_J spherical_hankel1 spherical_harmonic

spherical_bessel_Y spherical_hankel2

Now, I have to admit, I had no idea what a lot of these were -- so I

went and read the source file sage/functions/special.py. At the top,

David has written an excellent description of what all these functions

are, and how they're all related. But you can only see it if you

happen to look at the comments at the top of the file! Maybe other

people disagree with me, but I would much rather have

elliptic_integrals.<TAB> give me a list, and have the nice

documentation that David wrote be the docstring for that module, so

that elliptic_integrals? would show these comments.

Second: I wonder if the constructors for some of the combinatorics

functions couldn't be given a common interface. For instance:

sage: SetPartitions

SetPartitions SetPartitionsIk SetPartitionsRk

SetPartitionsAk SetPartitionsPRk SetPartitionsSk

SetPartitionsBk SetPartitionsPk SetPartitionsTk

sage: Ja

JackPolynomialsJ JackPolynomialsP JackPolynomialsQ JackPolynomialsQp

Now, I've never really looked at/used the combinatorics code at all,

so if what I'm about to say is totally off-base, just ignore me. But

looking at the constructors for the SetPartitions*, for instance, seem

to have the same signature. Would it be possible to replace them with

a single "SetPartitionsOfType" and take an extra argument that

specifies what type of partitions you're taking? This is similar to

what happens in the case of modular forms, where we essentially have

ModularFormsGamma0, ModularFormsGamma1, ModularFormsGammaH,

ModularFormsGamma0Eps, etc., all of which take similar inputs -- but

we have a global constructor (ModularForms) which takes the input and

calls off to the appropriate constructor.

3. Also, I think that moving a handful of things into namespaces, and

reducing the global namespace a little bit, could have two big

advantages for new users.

First, it's an easy starting point for a new user who wants to know

some of what Sage can do in a specific area. For instance, if I sit

down having never used Sage before, and I hit finance.<TAB>, I get a

sense for some of the things that might interest me, without having to

guess what I might get lucky with via tab completion, or what

something might be called.

Second, I think that a large global namespace is much more

disorienting to a new Sage user, *particularly* one who isn't an

experienced programmer, than many of us remember. For instance, the

SetPartitions* functions I pointed out before don't bother me

personally at all -- if I hit S<TAB>, they're visually grouped, and my

brain "knows" to ignore them if they're not the type of thing I'm

looking for. However, for the novice user who tries the same thing

(looking for, say, some Statistics functionality) is going to be

bombarded by a long list of functions, many of which seem to be about

something combinatorics-related. I'm not trying to say that we should

start severely pruning the global namespace, by any means -- I'm just

saying that a silghtly tidier global namespace is more approachable to

the novice user. (I'm not just hypothesizing here -- I know someone

who had exactly this experience, specifically with the case of

Statistics.)

-cc

Dec 2, 2008, 7:23:12 AM12/2/08

to sage-devel

+1 on craig, especially the 3th point.

ow I forgot to mention before, I also think that a massive

reorganization would be a bad thing to do since this would be big load

of work, and there are much better things that could get done in that

time. But motivating people to have the newly added stuff to be

organized in some sort of way, wich is uniform across all of sage, is

just a small effort, which could highly improve the user friendliness

of sage.

-Maarten

ow I forgot to mention before, I also think that a massive

reorganization would be a bad thing to do since this would be big load

of work, and there are much better things that could get done in that

time. But motivating people to have the newly added stuff to be

organized in some sort of way, wich is uniform across all of sage, is

just a small effort, which could highly improve the user friendliness

of sage.

-Maarten

Dec 2, 2008, 6:24:13 PM12/2/08

to sage-...@googlegroups.com

On Tue, 02 Dec 2008 at 01:22AM -0800, Craig Citro wrote:

> Second: I wonder if the constructors for some of the combinatorics

> functions couldn't be given a common interface. For instance:

>

> sage: SetPartitions

> SetPartitions SetPartitionsIk SetPartitionsRk

> SetPartitionsAk SetPartitionsPRk SetPartitionsSk

> SetPartitionsBk SetPartitionsPk SetPartitionsTk

>

> sage: Ja

> JackPolynomialsJ JackPolynomialsP JackPolynomialsQ JackPolynomialsQp

>

> Now, I've never really looked at/used the combinatorics code at all,

> so if what I'm about to say is totally off-base, just ignore me.

> Second: I wonder if the constructors for some of the combinatorics

> functions couldn't be given a common interface. For instance:

>

> sage: SetPartitions

> SetPartitions SetPartitionsIk SetPartitionsRk

> SetPartitionsAk SetPartitionsPRk SetPartitionsSk

> SetPartitionsBk SetPartitionsPk SetPartitionsTk

>

> sage: Ja

> JackPolynomialsJ JackPolynomialsP JackPolynomialsQ JackPolynomialsQp

>

> Now, I've never really looked at/used the combinatorics code at all,

> so if what I'm about to say is totally off-base, just ignore me.

I use the combinatorics code, and the SetPartitions* stuff bothers me. I

only use the regular SetPartitions code, and think the other ones can be

"put away". I like the "SetPartitionsOfType" idea.

Dan

--

--- Dan Drake <dr...@kaist.edu>

----- KAIST Department of Mathematical Sciences

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

Mar 8, 2009, 4:32:05 PM3/8/09

to sage-...@googlegroups.com

Hi!

Browsing back through my old e-mail, I just wanted to add a couple

notes.

Yes, as you suggest below, this indeed definitely should be reduced to

something like:

SetPartitions(..., type=["A",3])

> sage: Ja

> JackPolynomialsJ JackPolynomialsP JackPolynomialsQ JackPolynomialsQp

This one (together with SFA*, Macdonald*, kSchur*, ...) will be fixed

as soon as someone steps up to reorganize the symmetric functions

stuff as it is in MuPAD-Combinat. There, we had a single entry point:

S = SymmetricFunctions(field)

S.schur

S.jack(t).P

S.macdonald(t,q).Q

S.kSchur(3)

Volunteers?

And to answer another e-mail, the category framework could allow to

group a lot of the categorical constructions within a single entry

point: the category itself. For example, all the hom and much of the

tensor product code is there, and to start with:

FreeModules(QQ).hom_category()

FreeModules(QQ).tensor_category()

Cheers,

Nicolas

--

Nicolas M. Thiéry "Isil" <nth...@users.sf.net>

http://Nicolas.Thiery.name/

Mar 8, 2009, 5:06:50 PM3/8/09

to sage-...@googlegroups.com

On Sun, Mar 08, 2009 at 09:32:05PM +0100, Nicolas Thiéry wrote:

> > sage: SetPartitions

> > SetPartitions SetPartitionsIk SetPartitionsRk

> > SetPartitionsAk SetPartitionsPRk SetPartitionsSk

> > SetPartitionsBk SetPartitionsPk SetPartitionsTk

>

> Yes, as you suggest below, this indeed definitely should be reduced to

> something like:

> SetPartitions(..., type=["A",3])

> > sage: SetPartitions

> > SetPartitions SetPartitionsIk SetPartitionsRk

> > SetPartitionsAk SetPartitionsPRk SetPartitionsSk

> > SetPartitionsBk SetPartitionsPk SetPartitionsTk

>

> Yes, as you suggest below, this indeed definitely should be reduced to

> something like:

> SetPartitions(..., type=["A",3])

Now: http://sagetrac.org/sage_trac/ticket/5458

> > sage: Ja

> > JackPolynomialsJ JackPolynomialsP JackPolynomialsQ JackPolynomialsQp

> This one (together with SFA*, Macdonald*, kSchur*, ...) will be fixed

> as soon as someone steps up to reorganize the symmetric functions

> stuff as it is in MuPAD-Combinat. There, we had a single entry point:

>

> S = SymmetricFunctions(field)

> S.schur

> S.jack(t).P

> S.macdonald(t,q).Q

> S.kSchur(3)

>

> Volunteers?

Now: http://sagetrac.org/sage_trac/ticket/5457

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu