[sage-devel] BooleanLattice(n) with n=0 and n=1
for i in [3,2,1,0]: print Posets.BooleanLattice(i)
prints
Finite lattice containing 8 elements
Finite lattice containing 4 elements
Finite lattice containing 1 elements
Traceback (click to the left of this block for traceback)
It sounds natural to have BooleanLattice(0) be 1-element lattice, but is
it normal mathematical definition? And to check, shouldn't
BooleanLattice(2) return the 2-element chain?
Btw, Posets.BooleanLattice('cat-says-meow') says "unsupported operand
type(s) for ** or pow(): 'int' and 'str'"... I have already open a ticket
for 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.
[sage-devel] Re: Sage on OSX 10.10
bump On Friday, October 24, 2014 2:39:45 PM UTC+1, Volker Braun wrote: > > I have a working Sage on OSX 10.10. I suggest to release that shortly, in > case anybody else made the mistake of upgrading soon after the initial > Yosemite release ;-) Please review > > http://trac.sagemath.org/query?status=needs_review&keywords=~yosemite > > and any outstanding blocker bugs... > -- 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: __cmp__ vs. __eq__ in element class
Also, this might be a good idea to revisit our abuse of hashing vs. equality. I'm still very unhappy with us breaking python associative containers, which really hurts padics and/or caching. We should at least think about having separate _identical_ vs. _isomorphic_ methods, say, where only the latter involves coercion and possibly non-unique isomorphism. On the command line we could bind == to _isomorphic_, but use _identical_ in library code. Then we would have intuitive comparison and could still work with associative containers. On Sunday, October 26, 2014 9:50:20 PM UTC, Nils Bruin wrote: > > On Sunday, October 26, 2014 2:08:27 PM UTC-7, Volker Braun wrote: >> >> Python 3 only uses __eq__, __lt__, . Python also provides >> functools.partial_ordering to synthesizing the remaining methods just from >> __eq__ and __lt__. We either use that or write a similar decorator to also >> deal with coercion. >> >> The __richcmp__ method is a Cython convention and doesn't exist in plain >> Python 3 (or 2 for that matter). >> > > A little more elaborately: On C-API level PyTypeObject has a > tp_richcompare slot with the interface that cython's __richcompare__ has. > Cython puts that special method in that slot for a cdef class. Python's > "python" classes inherit a tp_richcompare that dispatches to __eq__ and > __lt__ methods, probably because the constants Py_EQ etc. were deemed > unappetizing to expose on python level. > > This also means that on cython level, we should stick with __richcompare__ > by default, because dispatching to __eq__ python functions would be slow. > > >> -- 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: Poset/lattice, join and join_matrix
On Thu, 23 Oct 2014, Nathann Cohen wrote: sage: gcd([5]) 5 sage: gcd([5,7]) 1 This is good argument to support (only) []-style argument for several elements. Be consistent within same program. Or in Sage terms, "Build a car, don't let it look like bicycle combined to tractor." :=) Btw, why gcd([]) returns zero? At least there is inconsistency with lcm([]) returning one. I guess they should both return one or raise an exception. -- 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: Poset/lattice, join and join_matrix
Yo ! > This is good argument to support (only) []-style argument for several > elements. Be consistent within same program. Or in Sage terms, "Build a car, > don't let it look like bicycle combined to tractor." :=) > > Btw, why gcd([]) returns zero? At least there is inconsistency with lcm([]) > returning one. I guess they should both return one or raise an exception. I would say that it is because for guys doing number theory Z/2Z is associated with 2 and Z is associated with 0. Think of 0 like the infinity, or the product of all integers. 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: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
On 10/25/14, 21:38, William Stein wrote: On Sat, Oct 25, 2014 at 6:34 PM, William Stein wrote: On Oct 25, 2014 5:53 PM, "Jason Grout" wrote: On 10/25/14, 15:04, William Stein wrote: On Sat, Oct 25, 2014 at 6:37 AM, Jason Grout wrote: On 10/25/14, 0:07, William Stein wrote: They are fun aren't they -- no login required. It seems that often, though, the login page or the project settings page flashes up for a second or less, which is confusing. Do you know why the signup page or settings page might come up first, then be replaced with the worksheet? It's fixed now. Not for me. There's a blank white page, then a page that says Sage and something like "loading", then the settings page for a project, then the published worksheet. Each page flashes up for maybe 1/2 second or so. I've made sure my cache is disabled when I reloaded. This is with this page: https://cloud.sagemath.com/projects/4a5f0542-5873-4eed-a85c-a18c706e8bcd/files/support/ams-article-mathematica-bugs.sagews Try it when you are not logged in, eg in a new private browsing session. Disregard my message -- I would guess you already are using private browsing mode for testing. I was going back and forth. Let me be more precise. Using incognito, it does indeed appear that (now) the flashes of setting screen, etc., are gone---all I see is a blank screen, then a header, then the page. When I am logged in, I still see the flashes of the settings page, etc. Thanks, 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: Poset/lattice, join and join_matrix
On 27 October 2014 12:37, Nathann Cohen wrote: > Yo ! > >> This is good argument to support (only) []-style argument for several >> elements. Be consistent within same program. Or in Sage terms, "Build a car, >> don't let it look like bicycle combined to tractor." :=) >> >> Btw, why gcd([]) returns zero? At least there is inconsistency with lcm([]) >> returning one. I guess they should both return one or raise an exception. > It is not inconsistent, any more than this is: sage: sum([]) 0 sage: prod([]) 1 and the reason is essentially the same. > I would say that it is because for guys doing number theory Z/2Z is > associated with 2 and Z is associated with 0. Think of 0 like the > infinity, or the product of all integers. I don't quite follow that but as a number theorist here is how I would explain it. If you write a loop to read in integers and output their sum, you just add each new one to the runing total, after initializing this total to: 0 Same but for products: you have to initialize to 1. Same but for gcd: each updated result is the gcd of the running "total" and the new input. Must be initialised to: 0. Same for lcm: each time you take the lcm with the new input. To get the right answer you must initialize to: 1. In every vase this tells you what f([]) should be! John > > 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. -- 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: Poset/lattice, join and join_matrix
Nathann Cohen wrote: > > Yo ! > > > This is good argument to support (only) []-style argument for several > > elements. Be consistent within same program. Or in Sage terms, "Build a > car, > > don't let it look like bicycle combined to tractor." :=) > > > > Btw, why gcd([]) returns zero? At least there is inconsistency with > lcm([]) > > returning one. I guess they should both return one or raise an > exception. > > I would say that it is because for guys doing number theory Z/2Z is > associated with 2 and Z is associated with 0. Think of 0 like the > infinity, or the product of all integers. > Here is how I would put it: - sum([]) is zero because zero is the identity element for addition (for any x, the sum 0 + x equals x), therefore you can initialize a sum to 0, then add summands one by one, and this gets you the sum; so an empty sum is just the initial 0. - prod([]) is one because one is the identity element for multiplication (for any x, the product 1*x equals x); therefore you can initialize a product to 1, then multiply by the multiplicands one by one, and this gets you the product; so an empty product is just the initial 1. - gcd([]) is zero because zero is the identity element for gcd (for any x, gcd(0,x) equals x); therefore you can initialize a gcd to 0, then take gcd with the list elements one by one, and this gets you the gcd; so an empty gcd is just the initial 0. - lcm([]) is one because one is the identity element for lcm (for any x, lcm(1,x) equals x); therefore you can initialize an lcm to 1, then take lcm with the list elements one by one, and this gets you the lcm; so an empty lcm is just the initial 1. -- 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: Poset/lattice, join and join_matrix
On Mon, 27 Oct 2014, Samuel Lelievre wrote: Here is how I would put it: - gcd([]) is zero because zero is the identity element for gcd (for any x, gcd(0,x) equals x); Understood. Thanks. -- 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: Poset/lattice, join and join_matrix
On Mon, Oct 27, 2014 at 5:55 AM, John Cremona wrote: > On 27 October 2014 12:37, Nathann Cohen wrote: >> Yo ! >> >>> This is good argument to support (only) []-style argument for several >>> elements. Be consistent within same program. Or in Sage terms, "Build a car, >>> don't let it look like bicycle combined to tractor." :=) >>> >>> Btw, why gcd([]) returns zero? At least there is inconsistency with lcm([]) >>> returning one. I guess they should both return one or raise an exception. >> > > It is not inconsistent, any more than this is: > > sage: sum([]) > 0 > sage: prod([]) > 1 > > and the reason is essentially the same. > >> I would say that it is because for guys doing number theory Z/2Z is >> associated with 2 and Z is associated with 0. Think of 0 like the >> infinity, or the product of all integers. > > I don't quite follow that but as a number theorist here is how I would > explain it. If you write a loop to read in integers and output their > sum, you just add each new one to the runing total, after initializing > this total to: 0 > > Same but for products: you have to initialize to 1. > > Same but for gcd: each updated result is the gcd of the running > "total" and the new input. Must be initialised to: 0. Here's another number theorist's perspective. I think of the gcd(X) as a canonical generator for the ideal generated by X, when defined. The ideal generated by a set X is the smallest ideal that contains it. In case X is the empty set, that ideal is the 0 ideal (not the unit ideal). -- William -- William Stein Professor of Mathematics University of Washington 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.
[sage-devel] Re: BooleanLattice(n) with n=0 and n=1
Hello ! It sounds natural to have BooleanLattice(0) be 1-element lattice, but is > it normal mathematical definition? > Well, I would indeed expect BooleanLattice(0) to have 1 element, but also expect BooleanLattice(1) to have exactly 2 (against 1 at the moment) O_o 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: __cmp__ vs. __eq__ in element class
On Monday, October 27, 2014 5:03:00 AM UTC-7, Volker Braun wrote: > > On the command line we could bind == to _isomorphic_, but use _identical_ > in library code. Then we would have intuitive comparison and could still > work with associative containers. > I don't think this would be easy to do with the current preparser. Since "==" is an infix operator, you need to fully parse the expression to substitute the called operation reliably. Our current preparser only does regex. It is of course entirely feasible to rewrite the REPL to first use python's parser to give us an AST and do substitutions on that prior to fully compiling and executing the statements. Furthermore, I think it is a strength of computer algebra systems such as sage, magma, maple that their interface language is also used for large parts of their libraries. This already doesn't quite hold true for sage, but apart from "1/2" and "2^3" it's confined to syntax that produces errors in straight python. I suspect that changing the semantics of "==" between interface and library will be much more subtle and hence more problematic (because casual testing may well not find differences). I see where your desire for "different parents means not equal" comes from (I don't think we have to go all the way to is_identical: for p-adic elements just insisting that precision also agrees should be sufficient), but I don't quite see a way to implement it that won't lead to bigger problems elsewhere. -- 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: __cmp__ vs. __eq__ in element class
On Mon, Oct 27, 2014 at 10:32 AM, Nils Bruin wrote: > On Monday, October 27, 2014 5:03:00 AM UTC-7, Volker Braun wrote: >> >> On the command line we could bind == to _isomorphic_, but use _identical_ >> in library code. Then we would have intuitive comparison and could still >> work with associative containers. >> > > I don't think this would be easy to do with the current preparser. Since > "==" is an infix operator, you need to fully parse the expression to > substitute the called operation reliably. Our current preparser only does > regex. It is of course entirely feasible to rewrite the REPL to first use > python's parser to give us an AST and do substitutions on that prior to > fully compiling and executing the statements. > > Furthermore, I think it is a strength of computer algebra systems such as > sage, magma, maple that their interface language is also used for large > parts of their libraries. This already doesn't quite hold true for sage, > but apart from "1/2" and "2^3" it's confined to syntax that produces errors > in straight python. I suspect that changing the semantics of "==" between > interface and library will be much more subtle and hence more problematic > (because casual testing may well not find differences). > +1 > I see where your desire for "different parents means not equal" comes from > (I don't think we have to go all the way to is_identical: for p-adic > elements just insisting that precision also agrees should be sufficient), > but I don't quite see a way to implement it that won't lead to bigger > problems elsewhere. > I think this would be too constraining, even in library code. Either that or we'd have to make a bunch of exceptions (e.g. comparison to the int and Integer 1 and 0, ...) -- 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: __cmp__ vs. __eq__ in element class
On Sun, Oct 26, 2014 at 2:50 PM, Nils Bruin wrote: > On Sunday, October 26, 2014 2:08:27 PM UTC-7, Volker Braun wrote: >> >> Python 3 only uses __eq__, __lt__, . Python also provides >> functools.partial_ordering to synthesizing the remaining methods just from >> __eq__ and __lt__. We either use that or write a similar decorator to also >> deal with coercion. >> >> The __richcmp__ method is a Cython convention and doesn't exist in plain >> Python 3 (or 2 for that matter). >> > > A little more elaborately: On C-API level PyTypeObject has a > tp_richcompare slot with the interface that cython's __richcompare__ has. > Cython puts that special method in that slot for a cdef class. Python's > "python" classes inherit a tp_richcompare that dispatches to __eq__ and > __lt__ methods, probably because the constants Py_EQ etc. were deemed > unappetizing to expose on python level. > > This also means that on cython level, we should stick with __richcompare__ > by default, because dispatching to __eq__ python functions would be slow. > I've been toying with the idea of letting (the default) __richcmp__ delegate to (c-level) __eq__, etc. if defined in Cython to further minimize the differences between Cython and Python. For elements, it'd be nice to have a them work with coercion by default, with an _eq_ (and possibly _lt_) method that is guaranteed to get elements of the same parent. There's the wrinkle that __richcmp__ and __hash__ must be inherited together in the C API. -- 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: __cmp__ vs. __eq__ in element class
On Monday, October 27, 2014 5:32:12 PM UTC, Nils Bruin wrote: > > I don't think this would be easy to do with the current preparser. > As you said, we'll need to look at the AST. That is part of IPython's preprocessing framework, trivial to implement. Furthermore, I think it is a strength of computer algebra systems such as > sage, magma, maple that their interface language is also used for large > parts of their libraries. This already doesn't quite hold true for sage, > but apart from "1/2" and "2^3" it's confined to syntax that produces errors > in straight python. I suspect that changing the semantics of "==" between > interface and library will be much more subtle and hence more problematic > (because casual testing may well not find differences). I don't think its that difficult. Library generally works with elements of the same type, so you'll probably get away with not coercing in a lot of places. It is mostly useful for handling user input, where you might want to convert anyways. And if you don't then it will be rather obvious, if Integer(1) works but int(1) doesn't then your comparison was too strict. Doctesting can check that. Really its just a matter of replacing a == b in the library code with is_isomorphic(a, b) in the right places. If we are smart about the transition (supporting both old- and new-style comparison for a while) then we could add that pretty gradually. The alternative is to not have caching and associative containers for padics. That means you can never write Buchberger's algorithm for polynomials with padic coefficients, say. I find that much more worrisome. -- 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: __cmp__ vs. __eq__ in element class
On Monday, October 27, 2014 10:57:58 AM UTC-7, Volker Braun wrote: > > On Monday, October 27, 2014 5:32:12 PM UTC, Nils Bruin wrote: >> >> I don't think this would be easy to do with the current preparser. >> > > As you said, we'll need to look at the AST. That is part of IPython's > preprocessing framework, trivial to implement. > Yay! That could clean up quite a bit of preparsing. > The alternative is to not have caching and associative containers for > padics. That means you can never write Buchberger's algorithm for > polynomials with padic coefficients, say. I find that much more worrisome. > Your main example has been p-adics, which is a little different case than the "comparison between arbitrary objects and coercion". Perhaps the problem there is just that where currently we say that 1+O(5^1) == 1+ O(5^2) we should in actuality say that they are *not* equal. In fact, just as with any numerical algorithm, your first guess when you are comparing p-adics is that you're doing something wrong and should be checking, e.g., that the difference has relative precision 0, so I would expect that for most mathematical applications it doesn't matter too much what "==" means on p-adics, since anybody seriously working with them has to explicitly choose between different notions anyway, just as floats tend to not get compared for equality. Floats also don't tend to end up as keys in associative arrays. Are you sure that implementing Buchberger's algorithm would require coefficients to occur as *keys*? I would expect things to be keyed on exponent vector, but perhaps you're thinking of some optimization that works the other way around. -- 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: __cmp__ vs. __eq__ in element class
On Monday, October 27, 2014 6:24:44 PM UTC, Nils Bruin wrote: > > Are you sure that implementing Buchberger's algorithm would require > coefficients to occur as *keys*? > You need to put the S-polynomials in a hash table for any kind of reasonable performance. I agree that this could be fixed by moving the comparison away from "isomorphic" and more towards "identical". That is of course always true if you just tighten equality enough. Completely unrelated to padics is the issue of caching. It seems unlikely that a function will give the same answer on Integer(3) and GF(5)(3), but with caching it does. Really, once we declare them == we just can't trust associative containers any more since they don't have a hook to use a different comparison than ==. And many (most) fast algorithms depend on associative containers. And even worse, if you have __eq__ elements with different hashes as dict keys then what happens depends on an unlikely hash collision. And the more parent/elements with coercion rules we implement, the more likely is it that we trip over that. -- 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: __cmp__ vs. __eq__ in element class
On Mon, Oct 27, 2014 at 10:57 AM, Volker Braun wrote: > On Monday, October 27, 2014 5:32:12 PM UTC, Nils Bruin wrote: >> >> I don't think this would be easy to do with the current preparser. > > As you said, we'll need to look at the AST. That is part of IPython's > preprocessing framework, trivial to implement. It's not a question of ease, it's a question of desirability. Ideally most pre-parsing shouldn't change a valid Python AST. >> Furthermore, I think it is a strength of computer algebra systems such as >> sage, magma, maple that their interface language is also used for large >> parts of their libraries. This already doesn't quite hold true for sage, but >> apart from "1/2" and "2^3" it's confined to syntax that produces errors in >> straight python. I suspect that changing the semantics of "==" between >> interface and library will be much more subtle and hence more problematic >> (because casual testing may well not find differences). > > I don't think its that difficult. Library generally works with elements of > the same type, so you'll probably get away with not coercing in a lot of > places. It is mostly useful for handling user input, where you might want to > convert anyways. And if you don't then it will be rather obvious, if > Integer(1) works but int(1) doesn't then your comparison was too strict. > Doctesting can check that. > > Really its just a matter of replacing a == b in the library code with > is_isomorphic(a, b) in the right places. If we are smart about the > transition (supporting both old- and new-style comparison for a while) then > we could add that pretty gradually. Currently, the only place preparsing modifies valid code is for literals, which is surprising enough but at least easy to explain. Changing the meaning of == depending on the context is a really scary proposition to me. I would also argue that equality "across parents" is the Pythonic choice: sage: int(1) == float(1) True > The alternative is to not have caching and associative containers for > padics. That means you can never write Buchberger's algorithm for > polynomials with padic coefficients, say. I find that much more worrisome. We should make it easier to have associative containers with this notion of comparison if that's the crux of the issue, e.g. compare on (parent(a), a) rather than just a. I would even consider making elements by default unhashable by default, and one would have to write cache[a.key()] or cache[a.isomorphic_key()] to use them as keys. You have to be careful anyways storing things like p-adics or reals... - Robert -- 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: __cmp__ vs. __eq__ in element class
On Monday, October 27, 2014 1:13:29 PM UTC-7, Robert Bradshaw wrote: > Currently, the only place preparsing modifies valid code is for > literals, which is surprising enough but at least easy to explain. > There is one more: the "^" -> "**" substitution. Without it I think many mathematicians would find sage's interface unacceptable, though. Changing the meaning of == depending on the context is a really scary > proposition to me. I would also argue that equality "across parents" > is the Pythonic choice: > > sage: int(1) == float(1) > True > I don't think you can extrapolate sensible behaviour for a computer algebra system out of python's standard numerical stack. For one thing, for Python, numerical parents always more or less "inject" into a common parent, so that one hash function always does the trick. In fact, since any numerical type in python is represented by (a tuple of) rational numbers, a single function defined on the rationals suffices, and this is indeed what cpython does: https://docs.python.org/3/library/stdtypes.html#hashing-of-numeric-types (I wasn't able to find a ref for Python2 on this, so I hope Python 2 does the same). As we know by allowing equality across coercion via non-injective maps we are in a fundamentally different situation for ZZ in sage already. > We should make it easier to have associative containers with this > notion of comparison if that's the crux of the issue. Most of the time I expect it would be a matter of fixing the parent/structure of keys beforehand and do any required coercions on the keys before lookup. Then the task gets reduced to ensuring that equality/hash are compatible within parents (and possibly closely affiliated structures). , e.g. compare on (parent(a), a) rather than just a. I would even consider > making > elements by default unhashable by default, and one would have to write > cache[a.key()] or cache[a.isomorphic_key()] to use them as keys. That's just horrible! the same would apply to sets of elements! Your suggestion would mean that we cannot even get the elements of ZZ/5ZZ as a set any more. I think the main thing we're finding with p-adics is that hashing/equality are mismatched *within* the parent. I think that's going too far. We'll just have to go with an equality notion in the p-adics that is consistent with a sufficiently faithful hash, and if that means that O(5^1) != O(5^3) then we'll have to live with that. I think a base line is that we should be able to have a "subset of " type that works reliably, i.e., a finite enumerated set that knows where its elements live. In practice people will probably just use python's "set" and enforce the parents themselves (or not). -- 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: __cmp__ vs. __eq__ in element class
On Monday, October 27, 2014 8:13:29 PM UTC, Robert Bradshaw wrote: > > (parent(a), a) rather than just a. I would even consider making > elements by default unhashable by default, and one would have to write > cache[a.key()] or cache[a.isomorphic_key()] to use them as keys. The you can just as well get rid of @cached_method, that of course also solves the problem. But as far as I know all the big Ms cache aggressively. If we make elements not hashable by default then we will always be slow by comparison. IMHO every immutable element ought to be hashable. -- 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: __cmp__ vs. __eq__ in element class
On Monday, October 27, 2014 2:33:34 PM UTC-7, Volker Braun wrote: > > The you can just as well get rid of @cached_method, that of course also > solves the problem. > Note quite, thanks to http://trac.sagemath.org/ticket/16316 , which basically implements the scheme Robert proposes and uses that automatically if a normal "hash" is not available. In general I expect that cached_methods should preprocess their arguments a bit before doing a key lookup anyway (such as do the required coercions on arguments). Most of the time, functions with arguments should *not* be cached, because their cache quickly becomes a memory leak. The most important place where caching happens is UniqueFactory/UniqueRepresentation. These are mostly parent constructors, so tend to be very lenient in their input specifications. So their input should probably be uniformized quite agressively before using as a key. The current interface doesn't make that particularly easy. > IMHO every immutable element ought to be hashable. > I agree with that. With the understanding that "a==b" => "hash(a) == hash(b)" is only guaranteed to apply when "parent(a) is parent(b)", hopefully extending a little beyond. -- 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] sagenb 0.11.0 ready for review
Dear sage-devel, http://trac.sagemath.org/ticket/16004 is ready for review. Please test! This update for Sage notebook includes * javascript default graphics! * snapshots working again! Thanks especially to Volker B. and Jonathan G. for a lot of work making the jsmol work inside of Sage, lots of semi-documented things to figure out. Prereqs include http://trac.sagemath.org/ticket/17020 and you'll probably want http://trac.sagemath.org/ticket/17170 so that graphics show up easily; see also http://trac.sagemath.org/ticket/16911 although that will presumably be in whatever the next beta is since it and the Sphinx ticket are now merged. Thanks, - 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.
