On Tuesday, October 28, 2014 10:02:11 PM UTC, Erik Massop wrote:
>
> P.S. Addition (concatenation) of sequences converts to lists. Is that
> the intended behavior?
I don't really want to hold up Sequence as the optimal implementation of a
"coercing container", its just the only one that we hav
On Tue, 28 Oct 2014 13:24:18 -0700 (PDT)
Volker Braun wrote:
> The language is explained here
>
> http://www.sagemath.org/doc/tutorial/tour_coercion.html#conversion-versus-
coercion
Thanks!
> On Tuesday, October 28, 2014 8:06:44 PM UTC, Erik Massop wrote:
> >
> > sage: s = Sequence([], QQ)
>
The language is explained here
http://www.sagemath.org/doc/tutorial/tour_coercion.html#conversion-versus-coercion
On Tuesday, October 28, 2014 8:06:44 PM UTC, Erik Massop wrote:
>
> sage: s = Sequence([], QQ)
> sage: s.append(QQ(3)) # no coercion or conversion
> sage: s.extend([int(1), ZZ(2)])
On Tue, 28 Oct 2014 10:41:16 -0700 (PDT)
Volker Braun wrote:
> On Tuesday, October 28, 2014 5:16:47 PM UTC, Erik Massop wrote:
> >
> > class CoercingDict:
> > def __init__(self, f):
> > self.f = f
> > self.data = dict()
> > def __setitem__(self,
On Tuesday, October 28, 2014 5:16:47 PM UTC, Erik Massop wrote:
>
> class CoercingDict:
> def __init__(self, f):
> self.f = f
> self.data = dict()
> def __setitem__(self, key, value):
> self.data[self.f(key)] = value
Thats manua
On Tue, 28 Oct 2014 05:42:52 -0700 (PDT)
Volker Braun wrote:
> But the most important thing is that caching must be 100% reliable, and
> that means input must be really equal (at most up to some unique
> isomorphism), and not just "equal enough". So either we make __eq__ much
> stricter, or we
On Monday, October 27, 2014 10:45:40 PM UTC, Nils Bruin wrote:
>
> 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
> c
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
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
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
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, trivia
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 b
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
> preprocessin
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 co
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
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 associat
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
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
> 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.
>
Perhaps we could follow suit with other parts o
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 wit
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
Hi Travis,
On 2014-10-26, Travis Scrimshaw wrote:
> We need to get away from the __cmp__ to make the transition easier. Plus I
> would think most parents are not totally ordered.
Just for clarification: What exactly do you mean by "get away from
the __cmp__"? Are you saying we should use __rich
Am Sonntag, 26. Oktober 2014 18:59:10 UTC+1 schrieb Eric Gourgoulhon:
>
>
>
> Le dimanche 26 octobre 2014 16:02:30 UTC+1, Travis Scrimshaw a écrit :
>>
>> We need to get away from the __cmp__ to make the transition easier. Plus
>> I would think most parents are not totally ordered.
>>
>> Yes mos
Le dimanche 26 octobre 2014 16:02:30 UTC+1, Travis Scrimshaw a écrit :
>
> We need to get away from the __cmp__ to make the transition easier. Plus I
> would think most parents are not totally ordered.
>
> Yes most probably.
The task looks quite heavy: in src/sage:
find -name "*.py*" | xargs gre
Le dimanche 26 octobre 2014 11:08:15 UTC+1, Volker Braun a écrit :
>
> Right now: only implement __cmp__ following what is written in
> sage/structure/element.pyx, and not __eq__ and friends. You can play some
> tricks with the __richcmp__ hook but its probably best to stick to a single
> kind
We need to get away from the __cmp__ to make the transition easier. Plus I
would think most parents are not totally ordered.
Best,
Travis
On Sunday, October 26, 2014 3:08:15 AM UTC-7, Volker Braun wrote:
>
> Right now: only implement __cmp__ following what is written in
> sage/structure/elemen
Right now: only implement __cmp__ following what is written in
sage/structure/element.pyx, and not __eq__ and friends. You can play some
tricks with the __richcmp__ hook but its probably best to stick to a single
kind of comparison if you want your stuff to transition easily to python3.
On Sun
27 matches
Mail list logo
