Re: [sage-devel] Re: Tell me how the design of the Poset class is not flawed
Hi Nathann, Whoo hoo. First of all, you put my wrong e-mail address and I am not reading sage-devel all the time. Second of all, I did not write the poset code. As far as I know, it was written by Peter Jipsen and Franco Saliola. I used the poset code in the new class LinearExtensions in combinat/posets/linear_extensions.py Anne On Tuesday, September 30, 2014 4:45:28 AM UTC-7, Nathann Cohen wrote: > > Hello, > > > Let's for sanity's sake suppose that == among all vertex labels of > > FinitePosets is an equivalence relation. Let's moreover suppose that > > hashing respects this equivalence relation. > > Thanks, > > > Then the problem seems to be that in the unique representation > > (an_integer_labelled_hasse_diagram, list_of_vertex_labels) > > of FinitePoset the internal mapping from vertex labels to integers is > > exposed. > > > > It seems to me that this can be fixed by > > A) getting rid of the exposure of the internal mapping, > > or > > B) by making the internal mapping unique given the Hasse diagram > > labelled using the actual vertex labels. > > > > Option A probably involves using a vertex label labelled Hasse diagram > > in the unique representation. The issue then becomes implementing that. > > I will rewrite it by making Poset.__init__ only depend on a hasse diagram > represented by a labelled digraph (which will then be translated internally > into an integer-labelled HasseDiagram). This way the key is the labelled > hasse diagram, which is the only thing that makes sense. > > Nicolas told me that this "_elements" thing was only used by Anne > Schilling in her markov-related code. So I will create some > AnneSchillingPoset class with list of elements, keys and everything she > needs and get us a real Poset class. And I hope everything will hold > together afterwards. > > Thank you for your message, though. Asking a design question only earned > me answers about "what is equality", and "can you provide a bug report > which is not the bug report you provided". > > Now, all I have to do is write somebody else's 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.
[sage-devel] Re: Regina 3-manifold software
kcrisman: > > I think we have a SnapPy (or whatever it is called now) interface, but do > we have one for this? (Well, no. But *should* we?) > > http://regina.sourceforge.net/ > > It uses Python for scripting... and has been around for quite a while. > Just curious. Feel free to open a ticket if you would use this! > http://trac.sagemath.org/ticket/17077 -- 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: problems with hypergeometric and maxima_calculus.hgfpoly
On Friday, September 26, 2014 4:25:58 PM UTC+2, Nils Bruin wrote: > > It would be good if mpmath used a different approach when it's known a > hypergeometric function is a polynomial, but it's a little orthogonal to > what happens in sage. By the time we hit mpmath, we're doing multiprecision > float computation. Polynomial hypergeometric functions can easily be > evaluated at arbitrary inputs (rational, algebraic, symbolic). We should > not be bothering with multiprecision floats if we don't have to, or at > least only do so if there's a benefit and we can control precision issues. > In most symbolic special functions we check for special values and, if found, evaluate immediately. This is not so in hypergeometric.py but would be trivial to add. I can only speculate that the reason was the then forced call of maxima. Since this doesn't seem a problem with commenters please review http://trac.sagemath.org/ticket/17066 and this can be simply emulated until inclusion of the ticket by saying sage: hypergeometric([-2,-1],[2],-1).simplify_hypergeometric() 0 No need to explicitly call Maxima here. Regards, -- 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: Tell me how the design of the Poset class is not flawed
> Otherwise, maybe it can be fixed on the relabel function level (once > again, > > I don't know how it works). > > I don't see how. I tried many times, and each time I was sent back to > this design problem: the default value of the list of vertices is not > properly defined, and good a good reason (i.e. the question I asked). > > Perhaps a dumb question, because I am not surprised that totally rewriting is challenging... Could you in the interim use internally (for your purposes now) a new is_isomorphic (or perhaps is_really_actually_equal) method as Volker suggests, that could be easily replaced by (or replace) == once that works correctly? Or would that run into the infinite loop problem you mention at the ticket (though it seems like that issue has since been resolved/hacked around). I apologize if you have already answered this, but I didn't see exactly this question answered - perhaps because you are right that it's not just isomorphism. I agree this is not optimal. But I also can see that probably it is just too much work for any one person to completely restructure this, nor can this kind of thing happening be easily resolved without imposing a far more stringent structure on Sage development itself, which is already at times quite onerous (yes, I know I am sometimes one of the ones imposing that!). Anyway, unless you are exposing the (wrong) behavior directly in what you are working on, maybe this is better than nothing happening, both for you and the originator(s) of FinitePosets. If this is not a useful suggestion, again my apologies :( - kcrisman -- 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: Tell me how the design of the Poset class is not flawed
> Now, all I have to do is write somebody else's code. I will not. I spent many hours on this yesterday, went back home just to sleep, and continued today. it is too much work, and it is not my job. I cannot do that. I do not know the code. I am stuck here just cause somebody put some badly designed code in Sage, and now all I can do is rewrite it all from scratch just to solve a bug, while rebasing all her work above. Hours and hours of work which is totally pointless to me. It would not be fair. It would not be fair if by writing bad code she gets me to rewrite it all, only because it is now "sage code". It is too much work. I can't do that. 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.
[sage-devel] Regina 3-manifold software
I think we have a SnapPy (or whatever it is called now) interface, but do we have one for this? (Well, no. But *should* we?) http://regina.sourceforge.net/ It uses Python for scripting... and has been around for quite a while. Just curious. Feel free to open a ticket if you would use this! -- 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: Tell me how the design of the Poset class is not flawed
Hello, > Let's for sanity's sake suppose that == among all vertex labels of > FinitePosets is an equivalence relation. Let's moreover suppose that > hashing respects this equivalence relation. Thanks, > Then the problem seems to be that in the unique representation > (an_integer_labelled_hasse_diagram, list_of_vertex_labels) > of FinitePoset the internal mapping from vertex labels to integers is > exposed. > > It seems to me that this can be fixed by > A) getting rid of the exposure of the internal mapping, > or > B) by making the internal mapping unique given the Hasse diagram > labelled using the actual vertex labels. > > Option A probably involves using a vertex label labelled Hasse diagram > in the unique representation. The issue then becomes implementing that. I will rewrite it by making Poset.__init__ only depend on a hasse diagram represented by a labelled digraph (which will then be translated internally into an integer-labelled HasseDiagram). This way the key is the labelled hasse diagram, which is the only thing that makes sense. Nicolas told me that this "_elements" thing was only used by Anne Schilling in her markov-related code. So I will create some AnneSchillingPoset class with list of elements, keys and everything she needs and get us a real Poset class. And I hope everything will hold together afterwards. Thank you for your message, though. Asking a design question only earned me answers about "what is equality", and "can you provide a bug report which is not the bug report you provided". Now, all I have to do is write somebody else's 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] Proposal: remove SAGE_UPGRADING
On Tuesday, September 30, 2014 10:51:05 AM UTC+2, Jeroen Demeyer wrote: > > On 2014-09-30 08:24, Jeroen Demeyer wrote: > > I certainly agree with this, but it should be said that "make" will take > > a longer time when changing packages. For example, you will see ATLAS > > being rebuilt very frequently (it has many dependencies and if one of > > those changes, ATLAS will get rebuilt). > On the other hand, using the "order only dependency" feature of GNU make > would solve this problem. > http://www.gnu.org/software/make/manual/make.html#Prerequisite-Types > Sounds like a good idea to try. Maybe include it in the trac ticket for removal? Or open a new one and try to merge both at the same time? -- 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] Proposal: remove SAGE_UPGRADING
On 2014-09-30 08:24, Jeroen Demeyer wrote: I certainly agree with this, but it should be said that "make" will take a longer time when changing packages. For example, you will see ATLAS being rebuilt very frequently (it has many dependencies and if one of those changes, ATLAS will get rebuilt). On the other hand, using the "order only dependency" feature of GNU make would solve this problem. http://www.gnu.org/software/make/manual/make.html#Prerequisite-Types -- 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: Proposal: remove SAGE_UPGRADING
+1. I have had export SAGE_UPGRADING='yes' in my .bashrc for a long time now. John On 30 September 2014 00:02, William A Stein wrote: > On Mon, Sep 29, 2014 at 3:01 PM, Dima Pasechnik wrote: >> On 2014-09-29, Volker Braun wrote: >>> I propose to remove the SAGE_UPGRADING variable and make it act like it >>> would be always "yes" (instead of "no", which is the current default). >>> Right now, we sabotage "make" to not rebuild dependencies of rebuilt >>> packages. So you don't have to wait long for your broken Sage installation. >>> >>> The only sane alternative would be to have it default to "yes", but I don't >>> really think that we really need something with such a narrow use case. You >>> can of course always only individual packages (sage -f) and only the sage >>> library (sage -b) if you are feeling lucky. But "make" should really >>> produce something that works IMHO. >> >> +1 >> >> (just got bitten by that, again :-)) > > +1 -- that's how I had naively hoped it already worked, and I don't > want to get bit by this ever, and I have a fast enough computer > > > > -- > William Stein > Professor of Mathematics > University of Washington > http://wstein.org > wst...@uw.edu > > -- > 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] Proposal: remove SAGE_UPGRADING
It is certainly on "intel" and making strides on arm. It covers a few other archs through inheritance from gotoblas2 but it doesn't support power7, never mind power8. I can discuss those more in details for anyone interested. François On 30/09/2014, at 21:15, Jean-Pierre Flori wrote: > I also agree with the removal, with the issue of ATLAS. > Maybe we should switch to openblas (IIRC Clément Pernet said it is more state > of the art nowadays) :) > > On Tuesday, September 30, 2014 9:15:59 AM UTC+2, Jeroen Demeyer wrote: > See http://trac.sagemath.org/ticket/17072 > > -- > 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. This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments. Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more information. -- 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] Proposal: remove SAGE_UPGRADING
I also agree with the removal, with the issue of ATLAS. Maybe we should switch to openblas (IIRC Clément Pernet said it is more state of the art nowadays) :) On Tuesday, September 30, 2014 9:15:59 AM UTC+2, Jeroen Demeyer wrote: > > See http://trac.sagemath.org/ticket/17072 > -- 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] Proposal: remove SAGE_UPGRADING
See http://trac.sagemath.org/ticket/17072 -- 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.
