Re: [sage-devel] Re: About docs (and code) of poset

[Nathann Cohen]

> took about 10 second. Of course this would be faster if we can integrate code 
> more directly; propably only milliseconds if glued together with 
> static_sparse_graph.pyx.

If would be very cool to have such timings in Sage indeed, though even
there knowing that most of the computation time is due to the creation
of posets in Sage is not acceptable either -_-

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+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: About docs (and code) of poset

[Jori Mantysalo]

On Thu, 28 Aug 2014, Nicolas M. Thiery wrote:


Posets(5)

which internally does something like

[x for x in GenerateAllDirectedGrapsh(5) if x.is_poset()]



Semantically, this is correct. Luckily the implementation is more
clever than this: it only runs through digraphs that are actually
Hasse diagrams. For details, see the section "Graphs up to
isomorphism" in sage.combinat.tutorial?


OK. However, I did a quick test:

%timeit
x=0
for P in Posets(7):
if P.has_top():
x=x+1
print x

took (in quite old computer) 128 seconds. I modified the code written by 
Gunnar Brinkmann to output dicts. It took milliseconds to create a file 
containing dicts for posets of size 7. After that


%timeit
x=0
with open('/tmp/7.tosage') as myfile:
for line in myfile:
if Poset(eval(line)).has_top():
x=x+1
print x

took about 10 second. Of course this would be faster if we can integrate 
code more directly; propably only milliseconds if glued together with 
static_sparse_graph.pyx.


--
Jori Mäntysalo

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

Re: [sage-devel] Re: About docs (and code) of poset

[Jori Mantysalo]

On Tue, 2 Sep 2014, Nathann Cohen wrote:

Because it is (mostly) irrelevant. Just as users should not be bothered 
by things like "There is a SSD disk in this computer" or "Calculations 
are actually executed on cloud" or "This mail was delivered with SMTP 
protocol".



It's a point of faith, I believe. I feel that we owe users a good and
simple interface, but our code contains bugs and we do fix them, and
letting them know that is not a sin. There was a recent thread,
however, were some developpers raised the same points and wanted the
"TESTS" field (the place where we store those checks) to be hidden
from the final doc. Either way, we (as developpers) should keep those
things along, and independently of whether users should see them or
not, it should not leave Sage's source code.


+1 to TESTS.

In the ideal world there would be different levels of documentation. 
Something like


"Use Matrix(...) to create matrix. For example Matrix([[1,2],[3,4]]). 
Click here for more options."


and after clicking user would find for example sparce-option. But of 
course developers time is finite resource, so I don't except this kind of 
stuff to be done within several years.


--
Jori Mäntysalo

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

Re: [sage-devel] Re: About docs (and code) of poset

[Nathann Cohen]

> Because it is (mostly) irrelevant. Just as users should not be bothered by 
> things like "There is a SSD disk in this computer" or "Calculations are 
> actually executed on cloud" or "This mail was delivered with SMTP protocol".

It's a point of faith, I believe. I feel that we owe users a good and
simple interface, but our code contains bugs and we do fix them, and
letting them know that is not a sin. There was a recent thread,
however, were some developpers raised the same points and wanted the
"TESTS" field (the place where we store those checks) to be hidden
from the final doc. Either way, we (as developpers) should keep those
things along, and independently of whether users should see them or
not, it should not leave Sage's source code.

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+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: About docs (and code) of poset

[Jori Mantysalo]

On Tue, 2 Sep 2014, Nathann Cohen wrote:

But at least user should not see details like "There was an error in 
code three years ago. We show that it is corrected by...".



Why shouldn't we see it ?


Because it is (mostly) irrelevant. Just as users should not be bothered by 
things like "There is a SSD disk in this computer" or "Calculations are 
actually executed on cloud" or "This mail was delivered with SMTP 
protocol".


--
Jori Mäntysalo

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

Re: [sage-devel] Re: About docs (and code) of poset

[Nathann Cohen]

Y !

> I think that this is bad from user viewpoint.
>
> In the ideal world things would "just work". For a software like this it
is
> not possible --- there will always be notes of implemtation details and
> limits of algorithms somewhere. But at least user should not see details
> like "There was an error in code three years ago. We show that it is
> corrected by...".

Why shouldn't we see it ?

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+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: About docs (and code) of poset

[Jori Mantysalo]

On Tue, 2 Sep 2014, Nathann Cohen wrote:

I would say that it should be the union of the two. Some examples are 
meant to the users, some are meant to test past bugs that we fixed, and 
we do not want to lose that.


I think that this is bad from user viewpoint.

In the ideal world things would "just work". For a software like this it 
is not possible --- there will always be notes of implemtation details and 
limits of algorithms somewhere. But at least user should not see details 
like "There was an error in code three years ago. We show that it is 
corrected by...".


--
Jori Mäntysalo

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

Re: [sage-devel] Re: About docs (and code) of poset

[Nathann Cohen]

Hello !

> And how is documentation supposed to be?
>
> As I said, has_top() has same examples. mobius_function(x, y) has one common 
> example. mobius_function_matrix() has totally different examples. 
> open_interval() has basically same example.

I would say that it should be the union of the two. Some examples are
meant to the users, some are meant to test past bugs that we fixed,
and we do not want to lose that. So if only one function remains, all
examples should stay in Sage.

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+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: About docs (and code) of poset

[Jori Mantysalo]

On Tue, 2 Sep 2014, Nathann Cohen wrote:


If there is a Poset function which is an exact copy of the HasseDiagram
function, is there any reason for not removing the HasseDiagram one ?


And how is documentation supposed to be?

As I said, has_top() has same examples. mobius_function(x, y) has one 
common example. mobius_function_matrix() has totally different examples. 
open_interval() has basically same example.


--
Jori Mäntysalo

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

Re: [sage-devel] Re: About docs (and code) of poset

[Nathann Cohen]

>
> My understanding is Hasse diagram is the back-end digraph for the poset 
>> and many of the methods don't want to be inherited/exposed. However I'm not 
>> completely sure why that particular the design decision was made.
>>
>
If there is a Poset function which is an exact copy of the HasseDiagram 
function, is there any reason for not removing the HasseDiagram one ?

This class does not seem to be instanciated on its own.

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+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: About docs (and code) of poset

[Travis Scrimshaw]

>
>
> For example view(Poset( ([1,2,3,4,5], [[1,2],[1,3],[3,4],[2,5],[4,5]]) ), 
> tightpage=True) does nothing. 
>

It takes a few seconds to feed it to my pdf viewer, but it works for me 
(and I have installed the dot2tex optional spkg). 

>
> OK, maybe I understood a little of that. 
>
> But then going back to tode. For example posets.py has 
>
>  def has_top(self): 
>  return self._hasse_diagram.has_top() 
>
> and documentation and two examples. hasse_diagrams.py contains 
>
>  def has_top(self): 
>  if not self.top() is None: return True 
>  return False 

 
>
and almost same documentation and exactly same examples. Why isn't that 
> code put directly to posets.py? 
>
> My understanding is Hasse diagram is the back-end digraph for the poset 
and many of the methods don't want to be inherited/exposed. However I'm not 
completely sure why that particular the design decision was made.

Best,
Travis

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

Re: [sage-devel] Re: About docs (and code) of poset

[Jori Mantysalo]

On Mon, 25 Aug 2014, Travis Scrimshaw wrote:

IIRC most of the doc is in the header of some module... just use view(P, 
tightpage=True), it uses dot2tex if you install the optional spkg (with 
sage -i dot2tex). IMO the output is much prettier.


For example view(Poset( ([1,2,3,4,5], [[1,2],[1,3],[3,4],[2,5],[4,5]]) ), 
tightpage=True) does nothing.



But how come categories to this picture?


As I stated, they can act like ABC's (abstract base classes), but can be 
set at runtime based on inputs (see MatrixSpace(R, m, n) with m = n and 
with m != n). Here's also a nice tutorial on the subject. Although they 
carry more information with them which is used for the morphisms.


OK, maybe I understood a little of that.

But then going back to tode. For example posets.py has

def has_top(self):
return self._hasse_diagram.has_top()

and documentation and two examples. hasse_diagrams.py contains

def has_top(self):
if not self.top() is None: return True
return False

and almost same documentation and exactly same examples. Why isn't that 
code put directly to posets.py?


--
Jori Mäntysalo

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

Re: [sage-devel] Re: About docs (and code) of poset

[Nicolas M. Thiery]

On Mon, Aug 25, 2014 at 11:14:09AM +0300, Jori Mantysalo wrote:
> Posets(5)
> 
> which internally does something like
> 
> [x for x in GenerateAllDirectedGrapsh(5) if x.is_poset()]

Semantically, this is correct. Luckily the implementation is more
clever than this: it only runs through digraphs that are actually
Hasse diagrams. For details, see the section "Graphs up to
isomorphism" in sage.combinat.tutorial?

> To get lattices of size 5 one says
> 
> [sage.combinat.posets.lattices.FiniteLatticePoset(x) for x in
> Posets(5) if x.is_lattice()]
> 
> Because a) FiniteLatticePoset is not available on global namespace
> and b) there is no ready method to get lattices of given size.
> 
> Am I right on this?

Alas, yes.

In theory, the orderly generation technique should be applicable for
lattices too, doing an augmentation by vertices (see also the
tutorial). However this would require some basic control on how
vertices are added (the meet-semi lattice property is stable upon
removing largest elements only). Tom Denton had given it a quick shot
back in 2010, but it seemed like the orderly generation code did not
make it easy to gain such control. I'd love to be proven wrong :-)

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

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

Re: [sage-devel] Re: About docs (and code) of poset

[Travis Scrimshaw]

Hey Jori,

>
> OK. I have used to using html docs, but this of course varies. 
>

Of course (although I should be a little more honest and state that my 
viewpoint comes primarily from people who I've told to use the `?`).

>
> Neither way, at least .show() function for poset does not tell about 
> figsize-option etc. 
>

Well, I've never really been able to understand the graph plotting. IIRC 
most of the doc is in the header of some module... just use view(P, 
tightpage=True), it uses dot2tex if you install the optional spkg (with 
sage -i dot2tex). IMO the output is much prettier.

>
> Trying to understand... mathematically there is kind of diamond inclusion 
> of classes: 
>
> finite lattices \subset lattices 
> finite lattices \subset finite posets 
> lattices \subset posets 
> finite posets \subset posets 
>
> Which means that, for example, every function for finite lattice is 
> available for finite poset, but not necessarily other way. On C++ 
> this could be modelled with multiple inheritance. 
>

Otherway around, any methods for finite posets is also for finite lattices, 
but you're right, it's basically multiple inheritance.

>
> But how come categories to this picture? 
>

As I stated, they can act like ABC's (abstract base classes), but can be 
set at runtime based on inputs (see MatrixSpace(R, m, n) with m = n and 
with m != n). Here's also a nice tutorial on the subject 
. 
Although they carry more information with them which is used for the 
morphisms.

>
> This is still quite confusing (or I am dumb, or both). To get posets of 
> size 5 one can say 
>
> Posets(5) 
>
> which internally does something like 
>
> [x for x in GenerateAllDirectedGrapsh(5) if x.is_poset()] 
>
> To get lattices of size 5 one says 
>
> [sage.combinat.posets.lattices.FiniteLatticePoset(x) for x in Posets(5) if 
> x.is_lattice()] 
>
> Because a) FiniteLatticePoset is not available on global namespace and b) 
> there is no ready method to get lattices of given size. 
>
> Am I right on this? 
>

`Posets` is special; it's not the actual category object, like say Groups 
is. It's somewhat of an abuse here IMO, but it's minor. Although I don't 
think we have methods to get all lattices of a given rank yet in Sage...IDK 
off-hand for sure.

Best,
Travis

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

Re: [sage-devel] Re: About docs (and code) of poset

[Jori Mantysalo]

On Mon, 25 Aug 2014, Travis Scrimshaw wrote:


In my experience, most people read the documentation in Sage using `?`
rather than the reference manual. So it's not a matter of where the method
is defined (you can think of the category like an ABC in this case).


OK. I have used to using html docs, but this of course varies.

Neither way, at least .show() function for poset does not tell about 
figsize-option etc.



 The short version why is_lattice is in the category is that
*every* finite poset can check if is a lattice (if it has implementations to
check if it's a join and meet semilattice). In fact, I would argue that
there are many methods of the current implementation of FinitePoset (with no
's', i.e., not the category) that could be moved into the category because
all objects of the category of finite posets should have them.


Trying to understand... mathematically there is kind of diamond inclusion 
of classes:


finite lattices \subset lattices
finite lattices \subset finite posets
lattices \subset posets
finite posets \subset posets

Which means that, for example, every function for finite lattice is 
available for finite poset, but not necessarily other way. On C++ 
this could be modelled with multiple inheritance.


But how come categories to this picture?

This is still quite confusing (or I am dumb, or both). To get posets of 
size 5 one can say


Posets(5)

which internally does something like

[x for x in GenerateAllDirectedGrapsh(5) if x.is_poset()]

To get lattices of size 5 one says

[sage.combinat.posets.lattices.FiniteLatticePoset(x) for x in Posets(5) if 
x.is_lattice()]


Because a) FiniteLatticePoset is not available on global namespace and b) 
there is no ready method to get lattices of given size.


Am I right on this?

--
Jori Mäntysalo

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