[sage-devel] Re: name space pollution

[Nicolas M. Thiery]

Hi!

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

On Tue, Dec 02, 2008 at 01:22:30AM -0800, Craig Citro wrote:
 
  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).
 
 
 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

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?



 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 

[sage-devel] Re: name space pollution

[Nicolas M. Thiery]

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])

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

Cheers,
Nicolas
--
Nicolas M. Thiéry Isil nthi...@users.sf.net
http://Nicolas.Thiery.name/

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

[sage-devel] Re: name space pollution

[koffie]

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

[sage-devel] Re: name space pollution

[Craig Citro]

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


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 STAB, 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 

[sage-devel] Re: name space pollution

[Dan Drake]

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.

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 [EMAIL PROTECTED]
-  KAIST Department of Mathematical Sciences
---  http://mathsci.kaist.ac.kr/~drake


signature.asc
Description: Digital signature

[sage-devel] Re: name space pollution

[koffie]

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
On Nov 30, 11:11 pm, mabshoff [EMAIL PROTECTED] wrote:
 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
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: name space pollution

[William Stein]

On Sun, Nov 30, 2008 at 9:22 AM, Franco Saliola [EMAIL PROTECTED] wrote:

 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?

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

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

[sage-devel] Re: name space pollution

[mabshoff]

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