Re: [sage-devel] Oneliners

[Jori Mantysalo]

On Wed, 3 Dec 2014, Vincent Delecroix wrote:

By "one line function" I meant "one line function that anybody can 
reproduce after one hour of Python".


To give two specific examples: on posets there are is_connected() and 
minimal_elements(). First is just a direct wrapper to graph function with 
same name. Second wraps sources() and gives meaningful name for poset.


So should we get rid of at least first one? I think no, but how about 
others?


--
Jori Mäntysalo

[sage-devel] PyClaw

[Thierry Dumont]

I would like to know if anybody tried to install PyClaw in Sage.

http://www.clawpack.org/doc/pyclaw/

I am interested, and I propose to make an spkg.

Yours

t.d.

-- 
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 Graph.to_partition and Poset.to_graph

[Nathann Cohen]

Hello !

> I have used it, although I wasn't using the fact it returned a Partition
> instance.

Oh. So what you needed was actually map(len, G.connected_components()).
Well, this functon has been added in order to return a partition (this the
name _to_partition), and this is one thing I find no good explanation for.

> I'd be okay with that (although it is somewhat long).

It is somewhat long and uncomfortable. I would prefer to remove it myself,
but if this is the only middle ground then let it be.

>> I do not understand what you mean by 'similar'. I tried to explain in my
>> first post how the behaviour of this function was not clear from its
name,
>> and how renaming it would make it almost a copy of a function that
already
>> exist. Also, if you want the graph corresponding to the hasse diagram,
it is
>> perfectly natural to do Graph(P.hasse_diagram()).
>
> You're saying remove the method because you can replace it with a short
> 1-line statement with that last sentence.

While it can indeed be rewritten with a short 1-line, and while I gave this
1-line repeatedly, please do not reduce my whole argumentation to that. The
reason why I believe that this function should be removed is that I find
its name unclear, as I explained in my first post on the subject.

In order to fix this problem, I believe that the name this function could
be renamed to should contain both ('undirected' or 'Graph') as well as
Hasse Diagram. This would give something like
Poset.undirected_hasse_diagram; or Poset.hasse_diagram_undirected; or
Poset.hasse_diagram_graph, none of which offers any simplification with
respect to the already available alternatives, i.e.:

- Graph(Poset.hasse_diagram())
- Poset.hasse_diagram().to_undirected()

Because it needs to be renamed, and because all names I can think of offer
no advantage over already available alternatives, I believe that this
function should be removed.

> It depends on how you think of posets. I don't naturally think of them as
> directed graphs, so I wouldn't a priori know that I could plug it into
> Graph.

This is the key point: there is indeed no unique Graph associated to a
Poset, which is probably the reason why the two of them are not 'naturally
associated' for you. Indeed, I oppose both Graph(Poset) and
Poset.to_graph(), as equally unclear.

While there is no 'uniquely determined' poset associated to a Poset, there
is a notion of Hasse Diagram, which is directed. To this directed graph we
can naturally associate an undirected graph, and this I believe is the best
way to obtain the desired result. It is faithfully represented by the two
commands I mentionned.

> I think we can only hope for so much with the names themselves as certain
> words are often overloaded from different areas of math and we don't want
> 40+ character function names.

We are not as desperate as you say. Besides, the problem with to_graph has
nothing to do with long names.

> Again, if you can think of a better, go ahead
> and change it.

I do not have one. I still defend that Poset.to_graph should be removed for
the reasons I gave above. Do you find them unfair on some respect ?

I am eager to see this matter solved.

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 Graph.to_partition and Poset.to_graph

[Travis Scrimshaw]

>
>
> I would be interested to know how. Do you use it yourself ?
>
> I have used it, although I wasn't using the fact it returned a Partition 
instance.
 

> > but I'm not opposed to renaming it to something
> > like connected_components_partition.
>
> As Vincent said, 'connected_components_partition' sounds like it will 
> return a partition of the vertex set into connected components, i.e. what 
> 'connected_components' already does. If you do not like the 
> 'connected_components_sizes_partition' I proposed, could you give us an 
> other possible name for this method that would more explicit than 
> 'to_partition' ?
>

I'd be okay with that (although it is somewhat long).

>
> > Similar for to_graph.
>
> I do not understand what you mean by 'similar'. I tried to explain in my 
> first post how the behaviour of this function was not clear from its name, 
> and how renaming it would make it almost a copy of a function that already 
> exist. Also, if you want the graph corresponding to the hasse diagram, it 
> is perfectly natural to do Graph(P.hasse_diagram()).
>

You're saying remove the method because you can replace it with a short 
1-line statement with that last sentence.

>
> If you believe that this function should be renamed instead of removed, 
> could you say how ? I am especially interested in understanding why you 
> believe that it is useful as a function of its own, when 
> Graph(P.hasse_diagram()) or P.hasse_diagram().to_undirected() seem both 
> natural and concise.
>

It depends on how you think of posets. I don't naturally think of them as 
directed graphs, so I wouldn't a priori know that I could plug it into 
Graph. IMO putting descriptions in the docstrings is sufficient. So I don't 
think a different name is needed, but I'm not opposed to renaming it.

>
> What I want to avoid, however, is that the name of functions might be 
> confusing to graph theorists. The same way that I hope that the name of 
> graph functions is not confusing to non graph theorists.
>
> I think we can only hope for so much with the names themselves as certain 
words are often overloaded from different areas of math and we don't want 
40+ character function names. Again, if you can think of a better, go ahead 
and change it.

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 Graph.to_partition and Poset.to_graph

[Nathann Cohen]

Hello !

>I strongly object to removing the function to_partition as it is useful
> to people (beyond FindStat),

I would be interested to know how. Do you use it yourself ?

> but I'm not opposed to renaming it to something
> like connected_components_partition.

As Vincent said, 'connected_components_partition' sounds like it will
return a partition of the vertex set into connected components, i.e. what
'connected_components' already does. If you do not like the
'connected_components_sizes_partition' I proposed, could you give us an
other possible name for this method that would more explicit than
'to_partition' ?

> Similar for to_graph.

I do not understand what you mean by 'similar'. I tried to explain in my
first post how the behaviour of this function was not clear from its name,
and how renaming it would make it almost a copy of a function that already
exist. Also, if you want the graph corresponding to the hasse diagram, it
is perfectly natural to do Graph(P.hasse_diagram()).

If you believe that this function should be renamed instead of removed,
could you say how ? I am especially interested in understanding why you
believe that it is useful as a function of its own, when
Graph(P.hasse_diagram()) or P.hasse_diagram().to_undirected() seem both
natural and concise.

> Although if you
> want to argue about removing "one-line" functions, we should also remove
> add_edges, add_vertices, delete_edges, delete_vertices, subdivide_edges,
> average_degree, average_distance, etc.

Sorry if there was a misunderstanding, I did not ask that they be removed
for the only reason that they can be written in one line. I tried to make
it my main point that their name was unclear.

> Also I cannot emphasize sufficiently
> that not all Sage users who use the graph code are graph theorists.

Indeed, and for fixing all bugs related to multiple edges and edge labels
you must be convinced that I am aware of that. Frédéric Chapoton added some
functions which compute polynomials associated to graph (polynomials I
never heard of), and some of these tickets I reviewed myself.

What I want to avoid, however, is that the name of functions might be
confusing to graph theorists. The same way that I hope that the name of
graph functions is not confusing to non graph theorists.

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] Sage.app binary problems

[Ivan Andrus]

The 6.4.1 download _does_ give the app.

-Ivan

On Dec 1, 2014, at 12:03 PM, Volker Braun  wrote:

> Can somebody tell me for sure that the current osx binary is wrong? The app 
> and dmg have different sizes.
> 
> 
> 
> On Monday, December 1, 2014 6:54:29 PM UTC, kcrisman wrote:
> 
> I, just downloaded the Sage.app (OSX 10.9) from 2 different server and the 
> resulting downloads didn't give the Sage.app, but simply the src
> Maybe theres a problems?
> 
> It's conceivable that the mirrors were still updating, though in that case I 
> thought there would be no link at all.  Is this still a problem?
> 
> Hi kcrisman,
> 
> I think the original poster means "binary" instead of "src".
> 
> What may have happened at some point is that the script to
> produce sage-osx.dmg and sage-osx-app.dmg was producing
> sage-osx.dmg properly, but then producing the same again
> and calling it sage-osx-app.dmg, because of some missing
> setting of an environment variable. We should check if this
> is fixed now, ie, does the sage-osx-app.dmg available for
> download really contain the -app version?
> 
> 
> Ah, this is probably it -  Volker reported something similar happening with 
> the 10.10 binary last time, I believe.  Maybe the same thing happened here?
> 
> -- 
> 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.

-- 
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: possible issue with DiGraph in interval fields

[Nathann Cohen]

> sage: a = CIF(RIF(0, 1), RIF(0, 1))
> sage: a is a
> True
> sage: a == a
> False
>
> So equality is not even reflexive.

Okay. Please never define a graph with these things as vertices :-D

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 Graph.to_partition and Poset.to_graph

[Vincent Delecroix]

Hello Travis,

2014-12-03 0:24 UTC+01:00, Travis Scrimshaw :
>I strongly object to removing the function to_partition as it is useful
> to people (beyond FindStat), but I'm not opposed to renaming it to
> something like connected_components_partition.

I find your proposition too ambiguous. For me, I would expect that
such function returns the (set) partition induced on the set of
vertices... (which is just what connected_components does).

> Similar for to_graph.
> Although if you want to argue about removing "one-line" functions, we
> should also remove add_edges, add_vertices, delete_edges, delete_vertices,
> subdivide_edges, average_degree, average_distance, etc.

No. I am sorry if that was misinterpreted. One line methods like

map(len, self.connected_components())

or equivalently

[len(cc) for cc in self.connected_components()]

which are just standard Python are very different from

self._backend.add_edge(u, v, label, self._directed)

which strongly depends on the implementation of graphs in Sage. By
"one line function" I meant "one line function that anybody can
reproduce after one hour of Python".

> Also I cannot
> emphasize sufficiently that not all Sage users who use the graph code are
> graph theorists.

True. But I am not sure it helps to decide here (or I misunderstood
something hidden in your sentence)

Vincent

-- 
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 Graph.to_partition and Poset.to_graph

[Travis Scrimshaw]

   I strongly object to removing the function to_partition as it is useful 
to people (beyond FindStat), but I'm not opposed to renaming it to 
something like connected_components_partition. Similar for to_graph. 
Although if you want to argue about removing "one-line" functions, we 
should also remove add_edges, add_vertices, delete_edges, delete_vertices, 
subdivide_edges, average_degree, average_distance, etc. Also I cannot 
emphasize sufficiently that not all Sage users who use the graph code are 
graph theorists.

Travis
 

On Tuesday, December 2, 2014 2:12:07 AM UTC-8, vdelecroix wrote:
>
> Hello, 
>
> For Graph I would remove the one line functions 
>
>  - remove Graph.to_partition 
>  - remove Graph.connected_components_number 
>
> or as a second choice 
>
>  - rename Graph.to_partition -> Graph.connected_components_sizes (with 
> an argument `multiplicity` if you need to emphasize that you will 
> repeat the numbers several time) 
>
> Vincent 
>

-- 
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: Maple versus Mathematica

[Harald Schilly]

On Tue, Dec 2, 2014 at 10:43 PM, maldun  wrote:
> Has someone more examples why he/she uses Sage instead of one of the 4Ms?


in such a list, vendor lock-in is also a good point. imagine mathworks
closes its doors …

-- harald

-- 
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: Maple versus Mathematica

[maldun]

The emphasis lies on 'trying' Concerning image processing and control 
theory matlab is prefered by most with good reason (for reference: I come 
from these areas)
Since numpy/scipy/matplotlib is on board with Sage, it can easily challenge 
Mathematica in these areas, since the scipy packages can compare quite good 
with
Matlab. And I dare say that sage can easily outsmart the symbolic toolbox 
of Matlab.

On another note: Sage comes with Cython (and of course other possibilities) 
which is much smarter than MEX from matlab concerning low level programming 
for fast code.
And I remember well that a colleague of mine switched very fast to 
Numpy/Cython, because he got sick of MEX files.
A comparison between MEX and Cython would also be a good point.

I suppose some direct use cases where Sage is directly compared to the 
other 4Ms and shows why it is better suited, would be important to such a 
comparison.
Some of the formentioned things above are some reasons why at least I 
prefer Sage over Matlab and Mathematica. 
Maybe it would be a good Idea to collect some more concrete examples?

A short list of other strong points besides the one from above


   1.  The price: Of course
   2. Open
   3. Covers broad functionality
   4. Expandable: It is easy to build Sage packages and expand it's 
   functionality.
   5. The Notebook: It is easy to use, and has very nice typesetting 
   (compared to Mathematica it is far better I think; this could also be in a 
   comparison)
   6. Python: One could always argue about the language itself, but in 
   contrast to the others Sage uses a general purpose language. So it easy to 
   combine Sage with other programs (Ever build standalone Programs with the 
   others?)
   7. Most important Python packages for Math ready to go
   8. A nice community
   9. The price!
   10. ...

Has someone more examples why he/she uses Sage instead of one of the 4Ms? 

Maybe a survey along the users would be also good Idea? This could extend 
the list,
and maybe would at least be a start.


On Monday, December 1, 2014 6:27:56 AM UTC+1, Dr. David Kirkby (Kirkby 
Microwave Ltd) wrote:
>
> On 27 Nov 2014 20:51, "maldun" > wrote:
>
> > I personally a comparison of sage with the other Systems is quite hard, 
> since all of the other 4Ms concentrate more or less
> > on particular fields of mathematic (e.g. Matlab focus on numerics, 
> Mathematica more on Calculus etc.)
> > Sage is far from perfect but tries to cover all fields at once.
>
> Although I have never tested it myself,  several sources say Mathematica 
> is the best program for symbolic maths.  
>
> But to me at least Mathematica covers a very wide area of mathematics. 
> Inage processing,  control theory,  number theory, numerics, financial etc. 
> I think it tries to cover pretty much everything.  
>
> I believe any attempt to compare the packages would be very difficult and 
> I doubt it is possible to remove personal bias. 
>
> It is totally objective to say Sage is free, whereas neither Mathematica 
> or MATLAB are. But just about other comparison else is going to be 
> subjective. 
>
> Dave.
>

-- 
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] matplotlib compile error

[Stefan]

Success again. I don't know what was different the first time. Sorry for 
the noise.

--Stefan

On Tuesday, December 2, 2014 10:35:15 PM UTC+13, Stefan wrote:
>
> Single-threaded build after "make distclean" was successful. Currently 
> trying
>
> export MAKE="make -j4"
> make distclean
> make
>
> Will report back tomorrow.
>
> --Stefan.
>
> On Tuesday, December 2, 2014 5:00:06 PM UTC+13, Stefan wrote:
>>
>>
>>
>> On Tuesday, December 2, 2014 2:22:28 PM UTC+13, François wrote:
>>>
>>> It looks like pkg-config has not been installed or the dependencies for 
>>> matplotlib aren't there yet. freetype and png should be discovered 
>>> through 
>>> pkg-config and they aren't in your case. Did you "make distclean" before 
>>> starting to build again? 
>>>
>>
>> I'm fairly sure I did so before the build that broke above. I had 
>> MAKE="make -j4". I'm currently trying it with MAKE="make", it's still 
>> running. 
>>
>

-- 
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: possible issue with DiGraph in interval fields

[Clemens Heuberger]

Am 2014-12-01 um 19:37 schrieb Nils Bruin:
> Interval fields apparently hide this (intervals are "equal" if they have
> non-empty intersection?), but of course hash cannot respect this, because this

ComplexIntervalFieldElement.__richcmp__ says:

As with the real interval fields this never returns false positives.
Thus, `a == b` is ``True`` iff both `a` and `b` represent the same
one-point interval. Likewise `a != b` is ``True`` iff `x != y` for all
`x \in a, y \in b`.

Note the "one-point interval". Therefore,

sage: a = CIF(RIF(0, 1), RIF(0, 1))
sage: a is a
True
sage: a == a
False

So equality is not even reflexive.

Regards, CH


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

[sage-devel] Re: Sage.app binary problems

[Volker Braun]

The 6.4 binary did not build the app version, but we fixed that for 6.4.1. 
The latter are different.



On Tuesday, December 2, 2014 4:17:30 PM UTC, kcrisman wrote:
>
> I can't do that since I don't have a recent enough OS X, *but* the MD5 
> hashes are the same, according to the download page.
>
> *sage-6.4-x86_64-Darwin-OSX_10.9_x86_64.dmg* 
> 
> torrent 
> MD5:
>  
> 4230f47747ca48a43ae13ced9580bb37
> *sage-6.4-x86_64-Darwin-OSX_10.9_x86_64-app.dmg* 
> 
> torrent 
> MD5:
>  
> 4230f47747ca48a43ae13ced9580bb37
>
>  
>

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

[sage-devel] Re: Sage.app binary problems

[kcrisman]

On Monday, December 1, 2014 2:04:00 PM UTC-5, Volker Braun wrote:
>
> Can somebody tell me for sure that the current osx binary is wrong? The 
> app and dmg have different sizes.
>
>
>>
I can't do that since I don't have a recent enough OS X, *but* the MD5 
hashes are the same, according to the download page.

*sage-6.4-x86_64-Darwin-OSX_10.9_x86_64.dmg* 

torrent 
MD5:
 
4230f47747ca48a43ae13ced9580bb37
*sage-6.4-x86_64-Darwin-OSX_10.9_x86_64-app.dmg* 

torrent 
MD5:
 
4230f47747ca48a43ae13ced9580bb37

 

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

[sage-devel] Re: Maple versus Mathematica

[mmarco]

That is great!. Where are those plugins available?

On a slightly unrelated subject, i could be interested in some way to 
automatically convert sage worksheets into wiki pages.

El martes, 2 de diciembre de 2014 03:04:53 UTC+1, jason escribió:
>
> On 12/1/14, 6:00, mmarco wrote: 
>
> > P.S. 2: Is there some easy way to embed sagecell code in a wiki? 
> > 
>
> Yes, we have plugins for MoinMoin, Dokuwiki, and Drupal.  See the 
> interact pages at http://wiki.sagemath.org/interact/ for examples of how 
> to do this on the Sage wiki. 
>
> Jason 
>
>
>
>

-- 
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 Graph.to_partition and Poset.to_graph

[Vincent Delecroix]

Hello,

For Graph I would remove the one line functions

 - remove Graph.to_partition
 - remove Graph.connected_components_number

or as a second choice

 - rename Graph.to_partition -> Graph.connected_components_sizes (with
an argument `multiplicity` if you need to emphasize that you will
repeat the numbers several time)

Vincent

-- 
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] matplotlib compile error

[Stefan]

Single-threaded build after "make distclean" was successful. Currently 
trying

export MAKE="make -j4"
make distclean
make

Will report back tomorrow.

--Stefan.

On Tuesday, December 2, 2014 5:00:06 PM UTC+13, Stefan wrote:
>
>
>
> On Tuesday, December 2, 2014 2:22:28 PM UTC+13, François wrote:
>>
>> It looks like pkg-config has not been installed or the dependencies for 
>> matplotlib aren't there yet. freetype and png should be discovered 
>> through 
>> pkg-config and they aren't in your case. Did you "make distclean" before 
>> starting to build again? 
>>
>
> I'm fairly sure I did so before the build that broke above. I had 
> MAKE="make -j4". I'm currently trying it with MAKE="make", it's still 
> running. 
>

-- 
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 Graph.to_partition and Poset.to_graph

[Jori Mantysalo]

On Tue, 2 Dec 2014, Nathann Cohen wrote:


Could there be just Graph(Poset) and maybe even DiGraph(Poset)?


Same problem, we would not know "which graph" or "which digraph" it 
represents. With P.hasse_diagram() or P.comparability_graph() we know.


True. Then I think we should just remove .to_graph(). (Good name could be 
coverings_digraph(), but we already has hasse_diagram().)


--
Jori Mäntysalo

Re: [sage-devel] Re: About Graph.to_partition and Poset.to_graph

[Nathann Cohen]

> I would have guessed that P.to_graph() returns a digraph.

Then you expected either P.hasse_diagram() or
P.hasse_diagram().transitive_closure().

> Could there be just Graph(Poset) and maybe even DiGraph(Poset)?

Same problem, we would not know "which graph" or "which digraph" it
represents. With P.hasse_diagram() or P.comparability_graph() we know.
[1]

> What is actually a Hasse diagram? A graph with vertices labeled as
> integers from 0 to n-1, some positioning information used for plot(), what
> else?

Sage contains a HasseDiagram class that is not meant for users (many
unchecked assumptions, like the 0..n-1 labelling). When you execute
P.hasse_diagram() you get a digraph whose vertices are list(P).

More information there: http://en.wikipedia.org/wiki/Hasse_diagram

Also, if you have an acyclic digraph D, then Poset(D).hasse_diagram()
== D.transitive_reduction()

Nathann

[1] We could even have an exception raised in case of Graph(P) that
mention those methods.

-- 
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: Slow Poset creation and UniqueRepresentation

[Jori Mantysalo]

On Mon, 1 Dec 2014, Nils Bruin wrote:

The easy solution for Nathann and Jori for now is just to write their 
high-performance code in terms of primitives: a tuple consisting of the 
base set and some suitable description of the PO


I can use plain Hasse diagram.

A simple example of timings: If I create posets with Posets(7) it takes 
about half a minute. If I use #14110 I can create posets of size 8 with 
about same amount of time --- this is where UniqueRepresentation comes to 
bottleneck. And if I use #14110 and create Hasse diagrams instead of 
posets it takes about half a minute to generate posets of size 9 --- now 
bottleneck is on using posets, not creating them.


--
Jori Mäntysalo

[sage-devel] Re: About Graph.to_partition and Poset.to_graph

[Jori Mantysalo]

On Tue, 2 Dec 2014, Nathann Cohen wrote:


Poset.to_graph)
  There are three graphs that I know which can be associated to a
Poset. Its comparability graph [1], its incomparability graph, and the
undirected version of its Hasse Diagram [2]. When I see
"Poset.to_graph" I cannot guess which one it may be. Turns out that
P.to_graph is actually Graph(P.hasse_diagram()) or
P.hasse_diagram().to_undirected() which is rather explicit.



I would not see the point of a Poset.hasse_diagram_undirected() or
Poset.undirected_hasse_diagram() when it can already be obtained as
Graph(Poset.hasse_diagram()).


I would have guessed that P.to_graph() returns a digraph.

Could there be just Graph(Poset) and maybe even DiGraph(Poset)?

What is actually a Hasse diagram? A graph with vertices labeled as 
integers from 0 to n-1, some positioning information used for plot(), what 
else?


--
Jori Mäntysalo

[sage-devel] Re: About Graph.to_partition and Poset.to_graph

[Nathann Cohen]

I forgot an important part: could you tell me if you agree with the removal 
of such functions ? If you object, can you say why ?

Thanks,

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.