Steven D'Aprano writes:
> What key combination do I need to type to get ≜ in the following editors
> please? I tried typing \triangleq but all I got was \triangleq.
Your implied point is correct IMO, but all of the editors and
applications mentioned that I've used are perfectly happy with any
[Serhiy]
>> Isn't everyone expect that x*2 == x + x? Isn't this the definition of
>> multiplication?
[Steven D'Aprano ]
> I can't think of any counter-examples, but it wouldn't surprise me even
> a tiny bit to learn of some.
Sure you can: explain -3.1 * -2.7 = 8.37 in terms of repeated addition
On Wed, Apr 18, 2018 at 11:24:13PM +0300, Serhiy Storchaka wrote:
> Isn't everyone expect that x*2 == x + x? Isn't this the definition of
> multiplication?
I can't think of any counter-examples, but it wouldn't surprise me even
a tiny bit to learn of some.
> And when we have a multiplication,
[Serhiy]
> Isn't everyone expect that x*2 == x + x? Isn't this the definition of
> multiplication?
Note: in my first message in this thread, I made the same objection.
And that, e.g., it would also be weird if x*-1 is not the same as -x.
Obviously, I don't care enough about those to make up a me
[Tim]
>> (*) The obvious implementation:
>>
>> def __mul__(self, other):
>> if isinstance(other, Sized):
>> raise TypeError("cannot multiply Counter by Sized type %s" %
>> type(other))
[Serhiy]
> Wouldn't be better to return NotImplemented here?
Probably, but that's up t
[Tim]
>> Counter supports a wonderfully weird mix of methods driven by use
>> cases, not by ideology.
>>
>> + (binary)
>> - (binary)
>> |
>> &
>>
>> have semantics driven by viewing a Counter as a multiset
>> implementation. That's why they discard values <= 0. They
>> corresp
18.04.18 21:45, Tim Peters пише:
(*) The obvious implementation:
def __mul__(self, other):
if isinstance(other, Sized):
raise TypeError("cannot multiply Counter by Sized type %s"
% type(other))
Wouldn't be better to return NotImplemented here?
result = Count
18.04.18 22:34, Tim Peters пише:
Counter supports a wonderfully weird mix of methods driven by use
cases, not by ideology.
+ (binary)
- (binary)
|
&
have semantics driven by viewing a Counter as a multiset
implementation. That's why they discard values <= 0. They
correspon
[Wes Turner ]
> The use cases these TypeErrors would exclude include weightings (whether
> from a generator without an intermediate tuple/list or from a dict) where
> the need is to do elementwise multiplication:
Yes. That's exactly what I had in mind when I wrote:
>> What we're trying to stop i
The use cases these TypeErrors would exclude include weightings (whether
from a generator without an intermediate tuple/list or from a dict) where
the need is to do elementwise multiplication:
if len(self) != len(other):
raise ValueError("tensors are multiplicable")
if self.keys() != other.key
[Serhiy Storchaka ]
> There are methods update() and subtract() which are similar to operators "+"
> and "-", but don't discard non-positive values.
Yup.
> I expect that "*" and "/" discard non-positive values for consistency with
> "+" and "-". And a new method should be added which does multip
[Raymond]
>> I've started working on an implementation and several choices arise:
>>
>> 1) Reject scalar with a TypeError if scalar is a Counter
>> 2) Reject scalar with a TypeError if scalar is a Mapping
>> 3) Reject scalar with a TypeError if scalar is a Collection
>> 4) Reject scalar with a Type
16.04.18 08:07, Tim Peters пише:
Adding Counter * integer doesn't bother me a bit, but the definition
of what that should compute isn't obvious. In particular, that
implementation doesn't preserve that `x+x == 2*x` if x has any
negative values:
x = Counter(a=-1)
x
Counter({'a': -1})
x+x
Cou
On 04/18/18 17:33, Raymond Hettinger wrote:
On Apr 16, 2018, at 5:43 PM, Tim Peters wrote:
BTW, if _`Counter * scalar` is added, we should think more about
oddball cases. While everyone knows what _they_ mean by "scalar",
Python doesn't.
I've started working on an implementation and sev
[Raymond]
> I've started working on an implementation and several choices arise:
>
> 1) Reject scalar with a TypeError if scalar is a Counter
> 2) Reject scalar with a TypeError if scalar is a Mapping
> 3) Reject scalar with a TypeError if scalar is a Collection
> 4) Reject scalar with a TypeError
> On Apr 16, 2018, at 5:43 PM, Tim Peters wrote:
>
> BTW, if _`Counter * scalar` is added, we should think more about
> oddball cases. While everyone knows what _they_ mean by "scalar",
> Python doesn't.
I've started working on an implementation and several choices arise:
1) Reject scalar wi
16 matches
Mail list logo
