Re: [sage-devel] Re: patchbot help
Sorry not to have responded today, I have been otherwise occupied. There is nothing customised at all. I don't have time to track this down in the near future so I will just give up for now. John On 17 June 2015 at 13:22, Frédéric Chapoton fchapot...@gmail.com wrote: Do you have a custom matplotlibrc ? Le mercredi 17 juin 2015 12:35:59 UTC+2, Frédéric Chapoton a écrit : Maybe ticket #12114 is relevant.. Le mercredi 17 juin 2015 12:22:13 UTC+2, Frédéric Chapoton a écrit : The plot failures are correlated exactly to the files where pylab is imported.. Le mercredi 17 juin 2015 12:07:17 UTC+2, Frédéric Chapoton a écrit : Maybe this page is relevant about the matplotlib failures ? http://stackoverflow.com/questions/2443702/problem-running-python-matplotlib-in-background-after-ending-ssh-session Le mercredi 17 juin 2015 12:04:58 UTC+2, Frédéric Chapoton a écrit : Hello, Indeed, the patchbot stops if he fails to run the 0 ticket (i.e. latest develop) without failures. Otherwise it would send many bad reports.. Have you many installed optional packages ? Could you please - run yourself sage -t --long --warn-long 58.6 src/sage/plot/plot.py - post here the first 10 lines of the result ? Frederic Le mardi 16 juin 2015 20:27:10 UTC+2, John Cremona a écrit : On 16 June 2015 at 17:27, Jeroen Demeyer jdem...@cage.ugent.be wrote: John, Occam's Razor would suggest that those timeouts are because the machine is too much loaded. If you are using many parallel threads (MAKE=make -jN for a high value of N) or somebody is running other things on that machine, that might explain the timeouts. Almost nothing is running -- the madhone has 64 cores and I chose it as it was idle: load average essentially 0. Can you send the log file on one of those timed out make ptestlong runs? http://homepages.warwick.ac.uk/staff/J.E.Cremona/ptestlong.log.bz2 Thanks! John Jeroen. -- 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/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. -- 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] problem posting on trac
Hi all, I seem to have trouble posting on trac. I successfully updated a ticket 3 hours ago and since then I have tried posting on http://trac.sagemath.org/ticket/17618 but it just times out on me after I hit the submit change button. I can see tickets just fine. Francois -- 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: patchbot help
Do you have a custom matplotlibrc ? Le mercredi 17 juin 2015 12:35:59 UTC+2, Frédéric Chapoton a écrit : Maybe ticket #12114 is relevant.. Le mercredi 17 juin 2015 12:22:13 UTC+2, Frédéric Chapoton a écrit : The plot failures are correlated exactly to the files where pylab is imported.. Le mercredi 17 juin 2015 12:07:17 UTC+2, Frédéric Chapoton a écrit : Maybe this page is relevant about the matplotlib failures ? http://stackoverflow.com/questions/2443702/problem-running-python-matplotlib-in-background-after-ending-ssh-session Le mercredi 17 juin 2015 12:04:58 UTC+2, Frédéric Chapoton a écrit : Hello, Indeed, the patchbot stops if he fails to run the 0 ticket (i.e. latest develop) without failures. Otherwise it would send many bad reports.. Have you many installed optional packages ? Could you please - run yourself sage -t --long --warn-long 58.6 src/sage/plot/plot.py - post here the first 10 lines of the result ? Frederic Le mardi 16 juin 2015 20:27:10 UTC+2, John Cremona a écrit : On 16 June 2015 at 17:27, Jeroen Demeyer jdem...@cage.ugent.be wrote: John, Occam's Razor would suggest that those timeouts are because the machine is too much loaded. If you are using many parallel threads (MAKE=make -jN for a high value of N) or somebody is running other things on that machine, that might explain the timeouts. Almost nothing is running -- the madhone has 64 cores and I chose it as it was idle: load average essentially 0. Can you send the log file on one of those timed out make ptestlong runs? http://homepages.warwick.ac.uk/staff/J.E.Cremona/ptestlong.log.bz2 Thanks! John Jeroen. -- 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/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.
[sage-devel] load_ipython_extension()
Do we really need this line in src/sage/__init__.py from sage.repl.ipython_extension import load_ipython_extension This line forces *every use of Sage* to import IPython. In particular, it makes sage-download-file depend on IPython which is annoying since a broken IPython means no more downloads... -- 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: patchbot help
Maybe this page is relevant about the matplotlib failures ? http://stackoverflow.com/questions/2443702/problem-running-python-matplotlib-in-background-after-ending-ssh-session Le mercredi 17 juin 2015 12:04:58 UTC+2, Frédéric Chapoton a écrit : Hello, Indeed, the patchbot stops if he fails to run the 0 ticket (i.e. latest develop) without failures. Otherwise it would send many bad reports.. Have you many installed optional packages ? Could you please - run yourself sage -t --long --warn-long 58.6 src/sage/plot/plot.py - post here the first 10 lines of the result ? Frederic Le mardi 16 juin 2015 20:27:10 UTC+2, John Cremona a écrit : On 16 June 2015 at 17:27, Jeroen Demeyer jdem...@cage.ugent.be wrote: John, Occam's Razor would suggest that those timeouts are because the machine is too much loaded. If you are using many parallel threads (MAKE=make -jN for a high value of N) or somebody is running other things on that machine, that might explain the timeouts. Almost nothing is running -- the madhone has 64 cores and I chose it as it was idle: load average essentially 0. Can you send the log file on one of those timed out make ptestlong runs? http://homepages.warwick.ac.uk/staff/J.E.Cremona/ptestlong.log.bz2 Thanks! John Jeroen. -- 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/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: patchbot help
The plot failures are correlated exactly to the files where pylab is imported.. Le mercredi 17 juin 2015 12:07:17 UTC+2, Frédéric Chapoton a écrit : Maybe this page is relevant about the matplotlib failures ? http://stackoverflow.com/questions/2443702/problem-running-python-matplotlib-in-background-after-ending-ssh-session Le mercredi 17 juin 2015 12:04:58 UTC+2, Frédéric Chapoton a écrit : Hello, Indeed, the patchbot stops if he fails to run the 0 ticket (i.e. latest develop) without failures. Otherwise it would send many bad reports.. Have you many installed optional packages ? Could you please - run yourself sage -t --long --warn-long 58.6 src/sage/plot/plot.py - post here the first 10 lines of the result ? Frederic Le mardi 16 juin 2015 20:27:10 UTC+2, John Cremona a écrit : On 16 June 2015 at 17:27, Jeroen Demeyer jdem...@cage.ugent.be wrote: John, Occam's Razor would suggest that those timeouts are because the machine is too much loaded. If you are using many parallel threads (MAKE=make -jN for a high value of N) or somebody is running other things on that machine, that might explain the timeouts. Almost nothing is running -- the madhone has 64 cores and I chose it as it was idle: load average essentially 0. Can you send the log file on one of those timed out make ptestlong runs? http://homepages.warwick.ac.uk/staff/J.E.Cremona/ptestlong.log.bz2 Thanks! John Jeroen. -- 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/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: patchbot help
Hello, Indeed, the patchbot stops if he fails to run the 0 ticket (i.e. latest develop) without failures. Otherwise it would send many bad reports.. Have you many installed optional packages ? Could you please - run yourself sage -t --long --warn-long 58.6 src/sage/plot/plot.py - post here the first 10 lines of the result ? Frederic Le mardi 16 juin 2015 20:27:10 UTC+2, John Cremona a écrit : On 16 June 2015 at 17:27, Jeroen Demeyer jdem...@cage.ugent.be javascript: wrote: John, Occam's Razor would suggest that those timeouts are because the machine is too much loaded. If you are using many parallel threads (MAKE=make -jN for a high value of N) or somebody is running other things on that machine, that might explain the timeouts. Almost nothing is running -- the madhone has 64 cores and I chose it as it was idle: load average essentially 0. Can you send the log file on one of those timed out make ptestlong runs? http://homepages.warwick.ac.uk/staff/J.E.Cremona/ptestlong.log.bz2 Thanks! John Jeroen. -- 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 javascript:. To post to this group, send email to sage-...@googlegroups.com javascript:. 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: patchbot help
Maybe ticket #12114 is relevant.. Le mercredi 17 juin 2015 12:22:13 UTC+2, Frédéric Chapoton a écrit : The plot failures are correlated exactly to the files where pylab is imported.. Le mercredi 17 juin 2015 12:07:17 UTC+2, Frédéric Chapoton a écrit : Maybe this page is relevant about the matplotlib failures ? http://stackoverflow.com/questions/2443702/problem-running-python-matplotlib-in-background-after-ending-ssh-session Le mercredi 17 juin 2015 12:04:58 UTC+2, Frédéric Chapoton a écrit : Hello, Indeed, the patchbot stops if he fails to run the 0 ticket (i.e. latest develop) without failures. Otherwise it would send many bad reports.. Have you many installed optional packages ? Could you please - run yourself sage -t --long --warn-long 58.6 src/sage/plot/plot.py - post here the first 10 lines of the result ? Frederic Le mardi 16 juin 2015 20:27:10 UTC+2, John Cremona a écrit : On 16 June 2015 at 17:27, Jeroen Demeyer jdem...@cage.ugent.be wrote: John, Occam's Razor would suggest that those timeouts are because the machine is too much loaded. If you are using many parallel threads (MAKE=make -jN for a high value of N) or somebody is running other things on that machine, that might explain the timeouts. Almost nothing is running -- the madhone has 64 cores and I chose it as it was idle: load average essentially 0. Can you send the log file on one of those timed out make ptestlong runs? http://homepages.warwick.ac.uk/staff/J.E.Cremona/ptestlong.log.bz2 Thanks! John Jeroen. -- 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/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.
[sage-devel] functionality request on recursively enumerated sets
I have a question about the code of recursively enumerated sets inside sets/recursively_enumerated_sets.pyx. Such recursive structures contain the extra information about a path from the seeds to a given node (which is indeed a shortest path for breadth first search). Since the successor function is an iterable, one can keep track of which next a yields a given element. Example: sage: succ = lambda a:[a+2,a+3] sage: C = RecursivelyEnumeratedSet([0], succ) sage: C A recursively enumerated set (breadth first search) sage: it = C.breadth_first_search_iterator() sage: [next(it) for _ in range(10)] [0, 2, 3, 4, 5, 6, 8, 9, 7, 10] But one could also keep track of how one of these ints is obtained: sage: it = C.breadth_first_search_iterator() sage: [next(it) for _ in range(10)] [ (0, []), (2, [0]), (3, [1]), (4, [0,0]), (5, [2,3]), (6, [3,3]), (8, [2,3,3]), (9, [3,3,3]), (7, [3,2,2], (10, [3,3,2,2])] Actually, one problem is already apparent there: the order does depend on the iterator through a set (and so would the word if succ returns a set), so I don't think this is stable among different machines. But if succ returns a determined iterator (contrary to a pseudo-random iterator), the word makes prefect sense. Reason for me to want that: I want to use this iterator for reflection groups generated by simple reflections, and I want to keep track of the used reduced word of the elements. Do you think that's reasonable? Do you see a problem with this implementation speedwise? Thanks, Christian -- 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: matrix constructor signature clash
Hi, On Tuesday, 16 June 2015 20:10:05 UTC+2, Nils Bruin wrote: Tiebreaker needed: We have a whole bunch of ways in which a matrix can be constructed. Some of the possible signatures we support according to the documentation: A) matrix(n,m, callable f) which constructs the n x m matrix with entries f(i,j), where i,j run throw the row and column indices. B) matrix(n,n, c) which produces c times the n x n identity matrix. Does kill the whole thing with fire count as a tiebreaker? I remember fighting against the matrix constructor and init (a matrix apparently has to go through several circles of ducktyping hell before being instantiated: first the matrix(...) constructor, then MatrixSpace(...).matrix(), then the MatrixSpace(...).__matrix_class constructor) half a year ago ( http://trac.sagemath.org/ticket/17124 ), and the reason was rather similar: What was meant as an entry was misunderstood to be a vector due to it belonging to a free module (the ground ring was a free module). I fixed it by adding yet another special case to the Frankensteinian mess of a code, not unlike what Jeroen suggested yesterday. The good ideas in Jeroen's pseudocode notwithstanding (I 100% agree on deprecating matrix(n, n, c), by the way), I am wondering whether the fixes of today won't become the bugs of tomorrow. This is not to belittle the work done by those who have been improving these constructors for years -- they have been bravely cutting heads off a hydra... What, at least to me, seems to be the underlying problem is our pattern of ducktyping input because we can. Polymorphism is certainly a good idea, but this goes far beyond any reasonable notion of polymorphism; it seems to be an attempt to save the user some typing time by implementing various different constructors all in the __init__ (or classcall, depending on the object). Needless to say, checking that these different constructors have disjoint domains of definitions is not a viable option: Whoever does this would have to have a bird's eye view of the whole Sage landscape (present and future). I am not blaming the authors of the matrix classes for not expecting that a matrix could be defined over a ring which itself is a free module; nor do I expect them to have tested it on the symbolic ring (I don't test things on the symbolic ring either) or on a ring R whose zero is not R(0) (brace yourself, these bugreports will be coming). Ducktyping has its limits when the pond is bottomless and has frogs, chameleons, kraken, dead things and horrors unknown. It appears that whoever wrote the doc of the matrix constructor (Calling matrix() with a Sage object may return something that makes sense.) was aware of its ability to produce deterministic chaos, but several places in the Sage code are using the matrix constructor either assuming that it is a reliable piece of code with predictable output, or writing their own hacky workarounds to avoid its pitfalls. I don't know which is worse. I have a feeling that at least one reply to this message will try to justify the status quo by claiming that users cannot be expected to go search the doc for the right constructor, that the current syntax is the simplest / most intuitive and is what people are used to; etc. I think we are at the point where the downsides outweigh all of these arguments. Not having to look up how to build an identity matrix doesn't help if what comes out is a TypeError instead of an identity matrix; those aren't very user-friendly either. And the matrix(n, n, c) syntax makes no sense: Being a special syntax for scalar matrices, why does it require the user entering the size of the matrix twice? (It throws an error when you try to feed it different dimensions.) More importantly, why should one *expect* such a syntax? Why shouldn't it instead return the rank-1 matrix filled with c's? Or having a single c in cell (1,1) and 0's everywhere else? Sure, it's said in the doc, but the doc could just as well refer to Matrix.scalar(n, c, ring=R) for a scalar matrix (no, we don't have this method, and yes, we should have it). It appears that we are assuming that people learn Sage by trial and error, experimenting with various syntaxes until they find one that works. Apart from this being a great way to pick up bad habits, is this any faster than reading the doc? Best regards and sorry for more than the usual snark, Darij -- 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: Map, Morphism and PoorManMap
Hi Martin, On 2015-06-16, 'Martin R' via sage-devel sage-devel@googlegroups.com wrote: Generally, attributes of morphisms will carry a certain semantics that is related with the category. So, if your morphism class M1 has a method __call__, and M2 inherits from M1, then M2 has a __call__ method as well, and thus both M1 and M2 are morphisms in the category of SetsWithPartialMaps(). Or: If M1 has an attribute .tensor(), then M2 inherits it, and thus both categories are supposed to provide a tensor product. Somehow that appears strange to me. I wouldn't expect that the instances of some class are morphisms in, say, SetsWithPartialMaps() just because they are callable. (But maybe that's the python way.) What I stated was not about python (since it doesn't know about categories) and I guess also not about Sage, since I don't think that there is any automatism implemented. What I stated was about the semantics. If it is callable, then you want to call it on *something*, namely on elements. It may be that the callable throws an error on some elements, thus, we have a partial map, and where there are elements there are sets. Hence, SetsWithPartialMaps(). Anyway, I think it would be great to have this implemented. Do you think you can recycle your branch on trac? I'll see what I can do in the next few weeks. Best regards, Simon -- 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: matrix constructor signature clash
On Wednesday, June 17, 2015 at 5:52:20 AM UTC-7, Darij Grinberg wrote: I have a feeling that at least one reply to this message will try to justify the status quo by claiming that users cannot be expected to go search the doc for the right constructor, that the current syntax is the simplest / most intuitive and is what people are used to; etc. Here is that response then. For the most part, matrix does work nicely and I really appreciate the typing it saves. I think a good interface design pattern here is: - provide the basic object constructors, with a very rigid, unambiguous input structure. When you use these, you know exactly what is going to happen because the system doesn't have to guess at all. For matrices, this should probably be the constructors belonging to the various matrix spaces. - provide on top of that convenience constructors that do make some effort to try and understand what you mean. That would be matrix. A corollary is that this routine will occasionally get it wrong and sometimes necessarily so. I would not want to do away with the convenience of matrix because it doesn't work for some more complicated constructions. In those cases the users should be smart enough to go and read the documentation and look up the right constructor. The matrix doc would ideally have some pointers. The problem with matrix(n,n,c) is that it's actually coming from matrix rings! Scalars should probably coerce in there to make A - 1 work. It's something supported on a level below. Oddly enough, it's matrix(n,m,callable) that's the hard signature to recognize there. It seems we have the following signatures. [1] matrix([ring],n,n,scalar) [2] matrix([ring],n,m,callable) [3] matrix([ring],[n,[m]],iterable) [4] matrix([ring],[n,[m]],iterable producing iterables) The last one includes matrix(ZZ,n,m,[[1,2],[3,4]]) which I think is completely unambiguous, so that input should not be mistaken for something else. In particular, the following element matches all four: sage: R.x=QQ[] sage: S.y=R[] sage: F=x*y*x sage: F=x*y+x sage: F(1,1) ##callable, with the right arity sage: list(F) ##iterable [x, x] sage: map(list,list(F)) ##iterable producing iterables [[0, 1], [0, 1]] We end up with sage choosing option [1]: sage: matrix(2,2,F) [x*y + x 0] [ 0 x*y + x] but the other ones would work too: sage: matrix(2,2,lambda i,j: F(i,j)) #sage doesn't actually check callable but looks for specific types [0 1] [0 2] sage: matrix(list(F)) #we're not actually looking for iterables: they need to be lists or tuples [x x] sage: matrix(map(list,list(F))) [0 1] [0 1] so ... yeah ... with our current rules, taken with appropriate ducktyping interpretation, we have input that could specify 4 (different!) matrices. -- 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: matrix constructor signature clash
Quote of the day :-) On 2015-06-17 14:52, Darij Grinberg wrote: Ducktyping has its limits when the pond is bottomless and has frogs, chameleons, kraken, dead things and horrors unknown. -- 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: matrix constructor signature clash
Hi Nils, On Wed, Jun 17, 2015 at 4:37 PM, Nils Bruin nbr...@sfu.ca wrote: On Wednesday, June 17, 2015 at 5:52:20 AM UTC-7, Darij Grinberg wrote: Here is that response then. For the most part, matrix does work nicely and I really appreciate the typing it saves. I think a good interface design pattern here is: - provide the basic object constructors, with a very rigid, unambiguous input structure. When you use these, you know exactly what is going to happen because the system doesn't have to guess at all. For matrices, this should probably be the constructors belonging to the various matrix spaces. +1. Ducktyping as a convenience option is OK, but ducktyping as the only public interface is plain wrong. Unfortunately, currently the ducktyping is not just in the matrix constructor; it is split across the three stations I mentioned (matrix constructor, matrix space, matrix class). Apparently every single of our matrix classes has its own way of recognizing scalar matrix input (that very matrix(n, n, c) syntax that has caused the present discussion), apparently written by different people (since the error messages differ). I suspect there is no way for sufficiently generic code to sidestep all of the ducktyping at the present time, and this is just bad. - provide on top of that convenience constructors that do make some effort to try and understand what you mean. That would be matrix. A corollary is that this routine will occasionally get it wrong and sometimes necessarily so. I would not want to do away with the convenience of matrix because it doesn't work for some more complicated constructions. In those cases the users should be smart enough to go and read the documentation and look up the right constructor. The matrix doc would ideally have some pointers. The problem with matrix(n,n,c) is that it's actually coming from matrix rings! Scalars should probably coerce in there to make A - 1 work. It's something supported on a level below. Oddly enough, it's matrix(n,m,callable) that's the hard signature to recognize there. It is the harder one, but it is also the saner one in my opinion. Nevertheless, there is nothing wrong with making it explicit as Matrix.from_callable(n, m, callable) (or from_function or from_family, depending on how we want to call it). Once the basic constructors have been implemented, is there a way to discourage people from using the ducktyped matrix constructor *in the Sage library*? Some kind of warnings that appear only in doctest mode and tell you what basic constructors should be used? It seems we have the following signatures. [1] matrix([ring],n,n,scalar) [2] matrix([ring],n,m,callable) [3] matrix([ring],[n,[m]],iterable) [4] matrix([ring],[n,[m]],iterable producing iterables) Also matrix([ring], n[, m]]) to return a zero matrix, and matrix(various kinds of objects). And [3] involves some case analysis, since the iterable can be a dictionary but can also be a flattened list of entries. The last one includes matrix(ZZ,n,m,[[1,2],[3,4]]) which I think is completely unambiguous, so that input should not be mistaken for something else. In particular, the following element matches all four: sage: R.x=QQ[] sage: S.y=R[] sage: F=x*y*x sage: F=x*y+x sage: F(1,1) ##callable, with the right arity sage: list(F) ##iterable [x, x] sage: map(list,list(F)) ##iterable producing iterables [[0, 1], [0, 1]] We end up with sage choosing option [1]: sage: matrix(2,2,F) [x*y + x 0] [ 0 x*y + x] but the other ones would work too: sage: matrix(2,2,lambda i,j: F(i,j)) #sage doesn't actually check callable but looks for specific types [0 1] [0 2] sage: matrix(list(F)) #we're not actually looking for iterables: they need to be lists or tuples [x x] sage: matrix(map(list,list(F))) [0 1] [0 1] so ... yeah ... with our current rules, taken with appropriate ducktyping interpretation, we have input that could specify 4 (different!) matrices. Ouch. It is a good thing matrix currently tests for specific kinds of iterables rather than generally for iterability; but this is not a very good pattern to follow. Best regards, Darij -- 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] load_ipython_extension()
On Wed, Jun 17, 2015 at 12:55 AM, Jeroen Demeyer jdeme...@cage.ugent.be wrote: Do we really need this line in src/sage/__init__.py from sage.repl.ipython_extension import load_ipython_extension This line forces *every use of Sage* to import IPython. In particular, it makes sage-download-file depend on IPython which is annoying since a broken IPython means no more downloads... Also IPython is large and takes a long time to load. In the past I've often tried to keep IPython from loading by default if it isn't needed, to reduce the startup time (similar to not importing numpy by default). William -- 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. -- William (http://wstein.org) -- 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.
