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 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
13 matches
Mail list logo