About groups.<tab>, designs.<tab>, and the brand-new codes.<tab>

[Nathann Cohen]

Hellooooooo everybody !

I just created ticket that adds a new codes.<tab> object to Sage gathering all codes that Sage can build, the same way that we already have such objects for groups/graphs/designs/matroids and perhaps others.

Basu wondered if it made sense to keep all constructors in the global namespace at the same time. Because right now, you can do both

    sage: HammingCode(3,GF(2))
    Linear code of length 7, dimension 4 over Finite Field of size 2

and 

    sage: codes.HammingCode(3,GF(2))
    Linear code of length 7, dimension 4 over Finite Field of size 2

So, well. Do we keep them, do we remove them ? I'm all for removing them from the global namespace too, as they can all be found through the codes.<tab> object anyway. What do you think ?

And I guess we can ask ourselves the same question for groups too. And designs.

Graphs behave well already :-P

Have fuuuuuuuuuuuuuuuuuuuuun !

Nathann

[John Cremona]

Backwards compatibility issues? I have a lot of code where I would
not want to change every NumberField(...) to fields.NumberField(...)
and similarly with QuadraticField() and CyclotomicField(). Is this
just a question of scale, i.e. those are almost all the special field
constructors while there are lots and lots of codes?

John

> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/groups/opt_out.

[Nathann Cohen]

Hellooooooo !!

> Backwards compatibility issues?

Well, we can deprecate stuff for a start. And the message could say "What you are looking for moved to a different place ! It's larger, there is a lot of light and a comfy couch. Come join us !"

> I have a lot of code where I would
> not want to change every NumberField(...) to fields.NumberField(...)
> and similarly with QuadraticField() and CyclotomicField().  Is this
> just a question of scale, i.e. those are almost all the special field
> constructors while there are lots and lots of codes?

Hmmm... There is no "fields.<tab>" object in the version of Sage I run, so I don't get your question O_o

You have around 32 entries in the groups.<tab> thing (more are being added), around 7 in the designs.<tab> thing (more are being added. At least 4-5). Around 7 entries in the matroids.<tab> thing, and the graphs.<tab> has 143 but they are not in the global namespace :-P

The goal is to have nice entry points for the mathematical structures that Sage can create. I posted here a couple of weeks ago just because I couldn't find Z/nZ in Sage, and it would have been easier if it had been available through groups.<tab>. Which is being done too (waiting for a review).

The only question that remains is : do we want to keep copies of the constructors in the global namespace too ? Why should we even import them when Sage starts ? Should we have 2 ways to access them ?

fields.Quadratic looks good in your case. Though there is no fields.<tab> thing at the moment it seems.

What do you think ?

Nathann

[John Cremona]

On 22 November 2013 13:31, Nathann Cohen <nathan...@gmail.com> wrote:
> Hellooooooo !!
>
>> Backwards compatibility issues?
>
> Well, we can deprecate stuff for a start. And the message could say "What
> you are looking for moved to a different place ! It's larger, there is a lot
> of light and a comfy couch. Come join us !"
>
>> I have a lot of code where I would
>> not want to change every NumberField(...) to fields.NumberField(...)
>> and similarly with QuadraticField() and CyclotomicField(). Is this
>> just a question of scale, i.e. those are almost all the special field
>> constructors while there are lots and lots of codes?
>
> Hmmm... There is no "fields.<tab>" object in the version of Sage I run, so I
> don't get your question O_o

You are right -- but I thought that your proposal was that there
should be, instead of what there is now.

John

>
> You have around 32 entries in the groups.<tab> thing (more are being added),
> around 7 in the designs.<tab> thing (more are being added. At least 4-5).
> Around 7 entries in the matroids.<tab> thing, and the graphs.<tab> has 143
> but they are not in the global namespace :-P
>
> The goal is to have nice entry points for the mathematical structures that
> Sage can create. I posted here a couple of weeks ago just because I couldn't
> find Z/nZ in Sage, and it would have been easier if it had been available
> through groups.<tab>. Which is being done too (waiting for a review).
>
> The only question that remains is : do we want to keep copies of the
> constructors in the global namespace too ? Why should we even import them
> when Sage starts ? Should we have 2 ways to access them ?
>
> fields.Quadratic looks good in your case. Though there is no fields.<tab>
> thing at the moment it seems.
>
> What do you think ?
>
> Nathann
>

[P Purkayastha]

On 11/22/2013 09:34 PM, John Cremona wrote:
> On 22 November 2013 13:31, Nathann Cohen <nathan...@gmail.com> wrote:
>> Hellooooooo !!
>>
>>> Backwards compatibility issues?
>>
>> Well, we can deprecate stuff for a start. And the message could say "What
>> you are looking for moved to a different place ! It's larger, there is a lot
>> of light and a comfy couch. Come join us !"
>>
>>> I have a lot of code where I would
>>> not want to change every NumberField(...) to fields.NumberField(...)
>>> and similarly with QuadraticField() and CyclotomicField(). Is this
>>> just a question of scale, i.e. those are almost all the special field
>>> constructors while there are lots and lots of codes?
>>
>> Hmmm... There is no "fields.<tab>" object in the version of Sage I run, so I
>> don't get your question O_o
>
> You are right -- but I thought that your proposal was that there
> should be, instead of what there is now.
>

My reason for suggesting this change (at least for the sage/coding) is
so that the codes are more easily discoverable.

Right now, if I want a specific code, say Hamming code, I have to
remember "oh.. the name of the code is Hamming, so it probably starts
with Hamming in Sage too. Oh great! That works! Hamming<tab> gives
HammingCode. Let's try LDPC<tab>.. nothing, ok.. maybe.. ldp<tab>, nope.
Low<tab>, nope." And then I will have to go around searching through the
documentation and realize that ldpc codes are not there in Sage.

With the codes.<code> introduced by Nathann, it can easily be checked
what codes are there - by simply doing a codes.<tab>. Once this ticket
is in place, it would be in fact nice to not have all these codes also
in the global namespace. Having them in both places is a duplication,
and might even be confusing to a new user. It is not for now, but rather
for later - as the components inside Sage themselves grow in size with
new constructions they will be better organized if they are under the
general names and discoverable via tab completion beyond that.
Temporarily, one's programs may not run or may give deprecation errors.
Over the long term everyone should benefit from a neatly organized
namespace.

Just my opinion. :)

- basu.

[Harald Schilly]

I really like these collections of similar constructors. Having more of them would make Sage - as you said - much more discoverable. Is there a plots.* ? For example, list_plot is never seen, if you do plot[tab].

On Friday, November 22, 2013 2:21:32 PM UTC+1, John Cremona wrote:

Backwards compatibility issues?  I have a lot of code where I would
not want to change every NumberField(...) to fields.NumberField(...)

Yes, there must be a deprecation period if some of them are removed.
Additionally, in your case I'm pretty sure you can fix this easily by adding
from fields import *
at the top.

Harald

[Stefan]

+1 to removing them from the main namespace (with appropriate deprecation period).

When we designed the matroid code, keeping the namespace clean was an important goal for me. So we only have "Matroid" and "matroids" in there, and I expect it'll stay that way.

I can see no reason to have individual codes and designs litter the namespace. Groups, rings and fields are a muddier issue, because they're so widely used.

--Stefan.

[Volker Braun]

There is some value to have often-used things in the global namespace; Sage integers should always be ZZ and not just rings.Integers. 

* In the future, do not add new factory functions to the global namespace if there is a better place

* Remove obscure constructors from globals at some later time, err on the safe side for what is "obscure"...

[William Stein]

On Fri, Nov 22, 2013 at 10:23 AM, Volker Braun <vbrau...@gmail.com> wrote:
> There is some value to have often-used things in the global namespace; Sage
> integers should always be ZZ and not just rings.Integers.

+1

This was in particular one of the things I changed from the design of
Magma, where you *have* to type out IntegerRing() or Integers(),
unless you have a custom startup file. Not having common shortcuts
like ZZ in the global namespace of Magma was a conscious design choice
they made, which I didn't agree with. In retrospect, I think it's
fine having ZZ.

> * Remove obscure constructors from globals at some later time, err on the
> safe side for what is "obscure"...

Maybe we could have a criterion to decide what "obscure" is and some
examples? For example, if a typical ending first year pure math
*graduate student* is unlikely to have heard of the object, then it is
obscure. Thus

RationalField(), QQ, matrix, Graph, primes,

are clearly not obscure, whereas

dimension_cusp_forms

which I put in the global namespace, when I was the only user of Sage,
is definitely obscure, as (sadly) is

ModularSymbols,

which is also "obscure". A more interesting edge case is

EllipticCurve,

which I would argue should remain in the global namespaces...

>
> * In the future, do not add new factory functions to the global namespace if
> there is a better place
>
>
>
>
>

> On Friday, November 22, 2013 8:09:18 AM UTC-5, Nathann Cohen wrote:
>>
>> Hellooooooo everybody !
>>
>> I just created ticket that adds a new codes.<tab> object to Sage gathering
>> all codes that Sage can build, the same way that we already have such
>> objects for groups/graphs/designs/matroids and perhaps others.
>>
>> Basu wondered if it made sense to keep all constructors in the global
>> namespace at the same time. Because right now, you can do both
>>
>> sage: HammingCode(3,GF(2))
>> Linear code of length 7, dimension 4 over Finite Field of size 2
>>
>> and
>>
>> sage: codes.HammingCode(3,GF(2))
>> Linear code of length 7, dimension 4 over Finite Field of size 2
>>
>> So, well. Do we keep them, do we remove them ? I'm all for removing them
>> from the global namespace too, as they can all be found through the
>> codes.<tab> object anyway. What do you think ?
>>
>> And I guess we can ask ourselves the same question for groups too. And
>> designs.
>>
>> Graphs behave well already :-P
>>
>> Have fuuuuuuuuuuuuuuuuuuuuun !
>>
>> Nathann
>>

> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/groups/opt_out.

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

[Harald Schilly]

On Fri, Nov 22, 2013 at 7:39 PM, William Stein <wst...@gmail.com> wrote:
> Maybe we could have a criterion to decide what "obscure" is and some
> examples?

Well, there are also other measurements you can take and mix together.
e.g. how broadly the given constructor is developed, I mean, how many
features are implemented or possible in general.
Also, some time ago I created this statistical overview of the
sagemath.org/doc pages. This is also some kind of indicator, which
areas of Sage are of interest.
http://sagemath.org/doc_stats.html
(e.g. check out the "constructions" box)

>
> EllipticCurve,
>
> which I would argue should remain in the global namespaces...

That sounds fine, also given that there are a lot of featurs for
Elliptic curves, right?

Harald

[Nathann Cohen]

Okayyyyyyyyy... I just updated #15445 and the constructors exported
into the global namespace are now deprecated.

I hope that the git releases will begin soon, because a lot of git
patches are already waiting to be merged, and a lot of git patches are
waiting for a review too :-P

Nathann

> --
> You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/9dInETcNfgE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.

[David Joyner]

On Fri, Nov 22, 2013 at 8:09 AM, Nathann Cohen <nathan...@gmail.com> wrote:
> Hellooooooo everybody !
>
> I just created ticket that adds a new codes.<tab> object to Sage gathering
> all codes that Sage can build, the same way that we already have such
> objects for groups/graphs/designs/matroids and perhaps others.
>
> Basu wondered if it made sense to keep all constructors in the global
> namespace at the same time. Because right now, you can do both
>
> sage: HammingCode(3,GF(2))
> Linear code of length 7, dimension 4 over Finite Field of size 2
>
> and
>
> sage: codes.HammingCode(3,GF(2))
> Linear code of length 7, dimension 4 over Finite Field of size 2

Very cool, thanks Nathann!

Now, how about plot.<tab> ? :-)

>
> So, well. Do we keep them, do we remove them ? I'm all for removing them
> from the global namespace too, as they can all be found through the
> codes.<tab> object anyway. What do you think ?
>
> And I guess we can ask ourselves the same question for groups too. And
> designs.
>
> Graphs behave well already :-P
>
> Have fuuuuuuuuuuuuuuuuuuuuun !
>
> Nathann
>

> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an

[Nathann Cohen]

> Very cool, thanks Nathann!
>
> Now, how about plot.<tab> ? :-)

I feel home in somes places of Sage's code, and at others I feel like
I'm treading on somebody else's property. Aaaaaaand I definitely don't
feel home with plots :-P

Nathann

[Volker Braun]

You can already review git branches *hint* *hint*

Sage-5.13 should be the last "old-style" release...

[William Stein]

On Sat, Nov 23, 2013 at 5:09 AM, Nathann Cohen <nathan...@gmail.com> wrote:
>> Very cool, thanks Nathann!
>>
>> Now, how about plot.<tab> ? :-)

(1) plot is already a specific command that means something, and is
not obscure by any definition.

(2) one already has sage.plot.[tab], which does this:

sage: sage.plot.
sage.plot.all sage.plot.circle
sage.plot.graphics sage.plot.plot
sage.plot.scatter_plot
sage.plot.animate sage.plot.colors
sage.plot.hyperbolic_arc sage.plot.plot3d
sage.plot.step
sage.plot.arc sage.plot.contour_plot
sage.plot.hyperbolic_triangle sage.plot.plot_field
sage.plot.text
sage.plot.arrow sage.plot.density_plot
sage.plot.line sage.plot.point
sage.plot.bar_chart sage.plot.disk
sage.plot.matrix_plot sage.plot.polygon
sage.plot.bezier_path sage.plot.ellipse
sage.plot.misc sage.plot.primitive

>
> I feel home in somes places of Sage's code, and at others I feel like
> I'm treading on somebody else's property. Aaaaaaand I definitely don't
> feel home with plots :-P
>
> Nathann
>

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/groups/opt_out.

[Harald Schilly]

On Sat, Nov 23, 2013 at 4:11 PM, William Stein <wst...@gmail.com> wrote:
>>> Now, how about plot.<tab> ? :-)
>
> (1) plot is already a specific command that means something, and is
> not obscure by any definition.

I proposed "plots." (for me quite logical, since there is also
"groups."), sage.plot.* is also very good but not quite that ;-)

Harald

[William Stein]

Yes, plots is good; its also like "graphs".

And it would be nice to gather together all these namespaces in some
root namespace.

stuff.[tab]
stuff.plots.[tab]

and have a t-shirt and quickref card with a nice plot of the resulting tree.

William

> Harald

[David Joyner]

On Sat, Nov 23, 2013 at 10:33 AM, William Stein <wst...@gmail.com> wrote:
> On Sat, Nov 23, 2013 at 7:30 AM, Harald Schilly
> <harald....@gmail.com> wrote:
>> On Sat, Nov 23, 2013 at 4:11 PM, William Stein <wst...@gmail.com> wrote:
>>>>> Now, how about plot.<tab> ? :-)
>>>
>>> (1) plot is already a specific command that means something, and is
>>> not obscure by any definition.
>>
>>
>> I proposed "plots." (for me quite logical, since there is also
>> "groups."), sage.plot.* is also very good but not quite that ;-)
>>
>
> Yes, plots is good; its also like "graphs".
>
> And it would be nice to gather together all these namespaces in some
> root namespace.
>
> stuff.[tab]
> stuff.plots.[tab]
>
> and have a t-shirt and quickref card with a nice plot of the resulting tree.

If they are made, I will definitely buy one of those t-shirts!

[Thierry]

Hi,

On Sat, Nov 23, 2013 at 04:30:04PM +0100, Harald Schilly wrote:
> > (1) plot is already a specific command that means something, and is
> > not obscure by any definition.
>
> I proposed "plots." (for me quite logical, since there is also
> "groups."), sage.plot.* is also very good but not quite that ;-)

+1 for "plots.", though "graphics." could also make sense (wrt Graphics()
constructor).

Currently, none of plot<TAB> or sage.plot.<TAB> allows to discover
implicit_plot, which i discovered by reading ask.sagemath.org.

+1 also for "rings." and "fields.", even if we keep ZZ, QQ, AA,... in the
global namespace as well, since they correspond to very standard objects.
As well as with "plots.implicit", those will help the user to discover
what is available in Sage.

Having a unified naming scheme for constructors and related examples will
ease teaching Sage. A single mechanism you can explain in 5 minutes is
much better for the user's autonomy than a lot of shortcuts that maintain
the user in manipulating magic recipes, even if those recipes seem
appealing in a first discovery (for example the icosahedron() method plots
an object that can not be manipulated further than having a fancy picture,
but polytopes.icosahedron().plot() makes much more sense ; the same holds
for circle() that returns a picture, not the plot of something that comes
from a Curve() construction).

I agree that it is somehow cool to be able to show some fancy things that
work out of the box in Sage, so perhaps should we move those in a "demo."
namespace ?

We have a partial "Object()" "objects." correspondance for constructors
and examples, that should be generalised:
- Graph() graphs.
- Matroid() matroids.
- Word() words.
- CubicalComplex() cubical_complexes.
- Poset() posets.
- ToricVariety() toric_varieties.
- ... (the list is not exhaustive, i may have missed some)

Some are less consistent and should be fixed:

- Polyhedron() polytopes. (i prefer "Polytope() polytopes." over
"Polyhedron() polyhedrons." since polyhedron is usually specific to
dimension 3).

- BlockDesign()/IncidenceStructure() designs. (note that "Design" is
unused).

- Matrix() matrix. (not matrices.). The other issue here is that
"Matrix.<TAB>" gives you examples (as should "matrices." do). Also,
matrix is equal to Matrix, so there is a useless redundancy which does
not help. Moreover, it is incomplete, for example cartan_matrix or
hadamard_matrix or coxeter_matrix are provided by a function, but not
by Matrix.<TAB>. I propose to deprecate matrix and create matrices.
with cartan, hadamard, coxeter...

- SetSpecies/PartitionSpecies/SubsetSpecies/CombinatorialSpecies/
CharacteristicSpecies/SingletonSpecies/EmptySetSpecies/CycleSpecies/
LinearOrderSpecies/PermutationSpecies/EmptySpecies/SumSpecies/
ProductSpecies/CompositionSpecies/FunctorialCompositionSpecies species.
Perhaps should there be a Species() overlay to all those ?

That said, i understand the CamelCase/lowercase convention, but what
explains the singular/plural one?

Ciao,
Thierry

[Volker Braun]

On Friday, January 3, 2014 2:11:30 PM UTC-10, Thierry (sage-googlesucks@xxx) wrote:

 - Polyhedron() polytopes. (i prefer "Polytope() polytopes." over
   "Polyhedron() polyhedrons." since polyhedron is usually specific to
   dimension 3).

That is not the usual notation, most authors define a polytope to be a compact polyhedron. The dimension is arbitray. So the constructor should always be "Polyhedron". Historically, all canned examples are actually compact so it is polytopes.<example>. Though for consistency it should probably be changed to polyhedra.<example>

[Simon King]

Hi Volker,

On 2014-01-04, Volker Braun <vbrau...@gmail.com> wrote:
> On Friday, January 3, 2014 2:11:30 PM UTC-10, Thierry
> (sage-googlesucks@xxx) wrote:
>>
>> - Polyhedron() polytopes. (i prefer "Polytope() polytopes." over
>> "Polyhedron() polyhedrons." since polyhedron is usually specific to
>> dimension 3).
>
> That is not the usual notation, most authors define a polytope to be a
> compact polyhedron. The dimension is arbitray. So the constructor should
> always be "Polyhedron".

Much to my surprise, I found that the English Wikipedia defines a polyhedron
as "a solid in three dimensions with flat faces and straight edges". The
French Wikipedia also just states that a polyhedron is a geometric form in
three dimensions. The German Wikipedia states that in a narrower sense a
polyhedron is as in the English and French Wikipedia, but at least it mentions
that in the broader sense the mathematical notion is different.

I believe that English and French Wikipedia are totally and German Wikipedia
almost totally wrong here. Around my PhD thesis, the theory of polyhedra and
(convex) polytopes was part of my field of expertise, and I totally agree with
Volker that polyhedra are defined in arbitrary dimension and polytopes are
compact polyhedra.

Now we have to decide: Shall Sage adopt a notion that is surprisingly
widespread but is refused by experts of the field? I believe Sage is a
maths software and thus should use notions that are backed up by text
books in the relevant fields, and should not rely on folklore.

Best regards,
Simon

[Nathann Cohen]

Yooooooooooo !!!

> +1 also for "rings." and "fields.", even if we keep ZZ, QQ, AA,... in the
> global namespace as well, since they correspond to very standard objects.
> As well as with "plots.implicit", those will help the user to discover
> what is available in Sage.

Ahahahah.. Less talk, more tickets in needs_review :-P

> Some are less consistent and should be fixed:
>

>  - BlockDesign()/IncidenceStructure() designs. (note that "Design" is
>    unused).

"should be fixed" ? Hey, I like it as it is right now. Plus I need help to review actual new features in this folder. Not only for cosmetics :-P
https://groups.google.com/d/topic/sage-combinat-devel/yYtZI0xdt5o/discussion

Heeeeeeeeeeeeeeeeeeeeeeeeeeeeelp ! This stuff is great, and it's rotting at the moment :-P

Nathann

[Volker Braun]

Common language notions generally don't include higher than 3-dimensional objects, it should be clear that Sage is using the term "polytope" in its mathematical sense. 

Also, a manifold is not a "chamber or pipe with a number of inlets or outlets used to collect or distribute a fluid" in Sage.