On Sat, 12 Jul 2014 20:14:32 +0200, Johannes Bauer wrote:
> On 12.07.2014 18:35, Steven D'Aprano wrote:
>
>> If you said, "for many purposes, one should not compare floats for
>> equality, but should use some sort of fuzzy comparison instead" then I
>> would agree with you. But your insistence th
On Sun, Jul 13, 2014 at 9:06 AM, Roy Smith wrote:
> But, you can still have:
>
print x
> 1.0
print y
> 1.0
print x == y
> False
>
>
> which, I know, isn't really what you were talking about, but it is part
> of the general confusion of using floats.
This is partly because of the oh
In article ,
Chris Angelico wrote:
> On Sun, Jul 13, 2014 at 4:14 AM, Johannes Bauer wrote:
> > Bullshit. Comparing floats by their representation is *generally* a bad
> > idea because of portability issues. You don't know if IEEE754 is used to
> > represent floats on the systems that your code
On Sun, Jul 13, 2014 at 4:14 AM, Johannes Bauer wrote:
> Bullshit. Comparing floats by their representation is *generally* a bad
> idea because of portability issues. You don't know if IEEE754 is used to
> represent floats on the systems that your code is used on.
No, you don't, but I think you c
In article ,
Chris Angelico wrote:
> And there are plenty of other laws of real numbers that floats violate
> (or, let's be generous, "approximate to rather than following
> perfectly"). For instance, adding two positive (non-zero) numbers
> should result in a number which is greater than eithe
On 12.07.2014 18:35, Steven D'Aprano wrote:
> If you said, "for many purposes, one should not compare floats for
> equality, but should use some sort of fuzzy comparison instead" then I
> would agree with you. But your insistence that equality "always" is wrong
> takes it out of good advice int
On Sun, Jul 13, 2014 at 2:35 AM, Steven D'Aprano
wrote:
> You're not going to hear me arguing that the non-reflexivity of NANs and
> SQL NULL is a bad idea, although some very smart people have:
>
> http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/
>
> Mathematical
On Sat, 12 Jul 2014 13:54:07 +0200, Johannes Bauer wrote:
> On 09.07.2014 11:17, Steven D'Aprano wrote:
>
>> People are already having problems, just listen to Anders. He's
>> (apparently) not doing NAN-aware computations on his data, he just
>> wants to be able to do something like
>>
>> this_l
On 09.07.2014 11:17, Steven D'Aprano wrote:
> People are already having problems, just listen to Anders. He's
> (apparently) not doing NAN-aware computations on his data, he just wants
> to be able to do something like
>
> this_list_of_floats == that_list_of_floats
This is a horrible example.
On Sat, 12 Jul 2014 01:07:28 -0400, Alan Bawden wrote:
> Steven D'Aprano writes:
>
>> But perhaps we only care about changes in value, not type. NAN or no
>> NAN, list equality works fine:
>>
>> py> data = [1.0, 2.0, float('nan'), 4.0]
>> py> old = data[:]
>> py> old == data # No changes made
On Sat, Jul 12, 2014 at 4:53 PM, Ethan Furman wrote:
> Because I'm tired, and it seemed like a good excuse to show else with for,
> and because I'm tired. :)
Excellent justification. I withdraw the criticism. :)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
On 07/11/2014 11:39 PM, Chris Angelico wrote:
On Sat, Jul 12, 2014 at 4:11 PM, Ethan Furman wrote:
class list:
def __eq__(self, other):
if len(self) != len(other):
return False
for this, that in zip(self, other):
if this is that or this == that:
Chris Angelico :
> On Sat, Jul 12, 2014 at 4:11 PM, Ethan Furman wrote:
>> class list:
>> def __eq__(self, other):
>> if len(self) != len(other):
>> return False
>> for this, that in zip(self, other):
>> if this is that or this == that:
>>
On Sat, Jul 12, 2014 at 4:11 PM, Ethan Furman wrote:
> class list:
> def __eq__(self, other):
> if len(self) != len(other):
> return False
> for this, that in zip(self, other):
> if this is that or this == that:
> continue
>
On 07/11/2014 10:07 PM, Alan Bawden wrote:
Steven D'Aprano writes:
But perhaps we only care about changes in value, not type. NAN or no NAN,
list equality works fine:
py> data = [1.0, 2.0, float('nan'), 4.0]
py> old = data[:]
py> old == data # No changes made yet, should return True
True
Y
Hallöchen!
Torsten Bronger writes:
> Alan Bawden writes:
>
>> [...]
>>
>> You lost me right here. If list equality is determined by
>> comparing lists element-by-element, and the second element of old
>> is _not_ equal to the second element of data, then why should old
>> and data be equal?
>
>
Hallöchen!
Alan Bawden writes:
> [...]
>
> You lost me right here. If list equality is determined by
> comparing lists element-by-element, and the second element of old
> is _not_ equal to the second element of data, then why should old
> and data be equal?
I think Python first tests for identi
On Sat, Jul 12, 2014 at 3:07 PM, Alan Bawden
wrote:
> Steven D'Aprano writes:
>
>> But perhaps we only care about changes in value, not type. NAN or no NAN,
>> list equality works fine:
>>
>> py> data = [1.0, 2.0, float('nan'), 4.0]
>> py> old = data[:]
>> py> old == data # No changes made yet,
Steven D'Aprano writes:
> But perhaps we only care about changes in value, not type. NAN or no NAN,
> list equality works fine:
>
> py> data = [1.0, 2.0, float('nan'), 4.0]
> py> old = data[:]
> py> old == data # No changes made yet, should return True
> True
You lost me right here. If list e
Thanks to everyone who has commented. Some responses:
* I was completely mistaken about == enforcing the rule
that __eq__ returns True or False. I have no idea where
I got that idea from, sorry for the noise.
* I disagree that having two equals operators, == and ===,
would be confusing. T
On 9 July 2014 09:00, Steven D'Aprano wrote:
> At the moment, Python has two (in)equality operators, == and != which
> call __eq__ and __ne__ methods. Some problems with those:
>
>
> * Many people expect == to always be reflexive (that is, x == x for
> every x) but classes which customise __eq__
On Wed, 09 Jul 2014 13:05:22 -0500, Tim Chase wrote:
> If you want to compare things in a NaN-aware way, you can either spell
> it out explicitly:
>
> if x == y or (math.isnan(x) and math.isnan(y)):
> do_stuff()
But do we really want any arbitrary NAN to compare equal-ish with every
other
TL;DR: I've got an alternative proposal at the bottom of this message.
On 09Jul2014 09:17, Steven D'Aprano wrote:
On Wed, 09 Jul 2014 17:21:20 +1000, Chris Angelico wrote:
First thought: It will just add confusion. Currently, there are small
pockets of confusion surrounding the few cases where
In article <53bd3a1d$0$29995$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> On Wed, 09 Jul 2014 08:27:28 -0400, Roy Smith wrote:
>
> > We would have *three* ways to compare for equality (==, ===, and is).
>
> `is` does not, never has, and never will, be a test for equality.
>
>
On Wed, Jul 9, 2014 at 12:05 PM, Tim Chase
wrote:
> def equalish(x, y):
>return x == y or (math.isnan(x) and math.isnan(y))
With more generality:
def nan_type(x):
if isinstance(x, numbers.Complex):
if cmath.isnan(x): return 'qnan'
elif isinstance(x, decimal.Decimal):
On 2014-07-09 12:48, Steven D'Aprano wrote:
> On Wed, 09 Jul 2014 08:27:28 -0400, Roy Smith wrote:
>
> > We would have *three* ways to compare for equality (==, ===, and
> > is).
>
> `is` does not, never has, and never will, be a test for equality.
>
> py> x = []
> py> y = []
> py> x is y
> Fals
On Wed, Jul 9, 2014 at 3:17 AM, Steven D'Aprano wrote:
> People are already having problems, just listen to Anders. He's
> (apparently) not doing NAN-aware computations on his data, he just wants
> to be able to do something like
>
> this_list_of_floats == that_list_of_floats
>
> without NANs scre
On Wednesday, July 9, 2014 2:47:40 PM UTC+5:30, Steven D'Aprano wrote:
> On Wed, 09 Jul 2014 17:21:20 +1000, Chris Angelico wrote:
> > wrote:
> >> Thoughts? Comments?
> > First thought: It will just add confusion. Currently, there are small
> > pockets of confusion surrounding the few cases where
On 2014-07-09 08:00, Steven D'Aprano wrote:
At the moment, Python has two (in)equality operators, == and != which
call __eq__ and __ne__ methods. Some problems with those:
* Many people expect == to always be reflexive (that is, x == x for
every x) but classes which customise __eq__ may not
On 07/09/2014 12:00 AM, Steven D'Aprano wrote:
I propose:
[adding new operators]
-1
Too much added confusion, too little gain.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On Wed, 09 Jul 2014 08:27:28 -0400, Roy Smith wrote:
> We would have *three* ways to compare for equality (==, ===, and is).
`is` does not, never has, and never will, be a test for equality.
py> x = []
py> y = []
py> x is y
False
--
Steven
--
https://mail.python.org/mailman/listinfo/python-
to enable it
> using "from __future__ import equals" in Python 3.5, and then to
> become the default behaviour in 3.6.
>
> * To support non-reflexive types, allow === and !=== operators, which
> are like == and != except they don't call `is` first.
>
>
On Wed, Jul 9, 2014 at 12:00 AM, Steven D'Aprano wrote:
> At the moment, Python has two (in)equality operators, == and != which
> call __eq__ and __ne__ methods. Some problems with those:
>
>
> * Many people expect == to always be reflexive (that is, x == x for
> every x) but classes which custo
On Wed, Jul 9, 2014 at 7:02 PM, Steven D'Aprano wrote:
> If you can tell the difference between x=y and x==y you should be able to
> also distinguish x===y. But I accept that it's a little sub-optimal.
I'm not bothered so much by the "which one is this" confusion as the
"which should this be" con
On Wed, 09 Jul 2014 17:21:20 +1000, Chris Angelico wrote:
> On Wed, Jul 9, 2014 at 5:00 PM, Steven D'Aprano
> wrote:
>> Thoughts? Comments?
>
> First thought: It will just add confusion. Currently, there are small
> pockets of confusion surrounding the few cases where something's
> non-reflexive
cost of
looking up __eq__ and calling it, the extra cost will be insignificant,
and since many objects (small ints, certain strings, etc.) are cached,
the over-all result will probably be to speed up the average == test.
>>* That's a backwards-incompatible change, so you need to enable it
you describe.
I propose:
* The == operator be redefined to *always* assume reflexivity, that
is, it first compares the two arguments using `is` before calling
the __eq__ methods.
Won't this slow down every == test?
* That's a backwards-incompatible change, so you need to enable it
On Wed, Jul 9, 2014 at 5:00 PM, Steven D'Aprano wrote:
> Thoughts? Comments?
First thought: It will just add confusion. Currently, there are small
pockets of confusion surrounding the few cases where something's
non-reflexive, and there are occasional threads on the subject, like
we have now. Add
efore calling
the __eq__ methods.
* That's a backwards-incompatible change, so you need to enable it
using "from __future__ import equals" in Python 3.5, and then to
become the default behaviour in 3.6.
* To support non-reflexive types, allow === and !=== operators, whi
On Aug 22, 5:43 pm, "Medardo Rodriguez (Merchise Group)"
<[EMAIL PROTECTED]> wrote:
> On Fri, Aug 22, 2008 at 6:30 PM, defn noob <[EMAIL PROTECTED]> wrote:
> > What does >> and << do?
>
> Normally they are bitwise operators:>> Shifts bits right
>
> << Shifts bits left
>
> print 1 << 3
> 8
>
> becau
On Fri, Aug 22, 2008 at 6:30 PM, defn noob <[EMAIL PROTECTED]> wrote:
> What does >> and << do?
Normally they are bitwise operators:
>> Shifts bits right
<< Shifts bits left
print 1 << 3
8
because 8 = 1000 in binary
Regards
--
http://mail.python.org/mailman/listinfo/python-list
On Fri, Aug 22, 2008 at 6:30 PM, defn noob <[EMAIL PROTECTED]> wrote:
> What does >> and << do?
>
> Googling on them and they are just ignored...
>
> --
>
http://docs.python.org/lib/bitstring-ops.html
>
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/l
What does >> and << do?
Googling on them and they are just ignored...
--
http://mail.python.org/mailman/listinfo/python-list
> ... I noticed it complains
> about the use of the += and -= assignment operators. The fix is
> obviously pretty trivial. I didn't notice any mention in the Pyrex
> docs as a difference between Python and Pyrex though. Was I mistaken?
Never mind. I missed the bit where it said they haven't ye
I'm experimenting a bit with Pyrex and like it pretty well so far.
While converting a module from Python to Pyrex I noticed it complains
about the use of the += and -= assignment operators. The fix is
obviously pretty trivial. I didn't notice any mention in the Pyrex
docs as a difference between
Hi list
I'm trying to implement a new type in a C extension and it must support
some binary operators, like &, |, ^, << and >>. With &, | and ^, the
method must receive another object of the same type, perform the
operation with an attribute of both, create a new object with the result
as the at
46 matches
Mail list logo
