Re: Proposal: === and !=== operators
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: >> continue >> break >> else: >> return True >> return False > > Seems a little elaborate. Why not just return straight from the loop, > instead of breaking and using else? :) But look at that keyword density! That single function demonstrates 80% of Python syntax making it a great educational tool. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
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: continue break else: return True return False Seems a little elaborate. Why not just return straight from the loop, instead of breaking and using else? :) Because I'm tired, and it seemed like a good excuse to show else with for, and because I'm tired. :) -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
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
We are looking for talented and motivated PYTHON Developers for our office in Bandung, West Java.
http://www.voxteneo.com/jobs/#job-indonesia *PYTHON Developers #12* We are looking for talented and motivated PYTHON Developers for our office in Bandung, West Java. We offer a permanent contract with a competitive salary package You will join our team to take charge of analysis and development of ambitious projects within a growing company You will be part of a skilled, dynamic team in a friendly environment As developer, you will translate companies’ needs into functional specifications and develop new applications. Skills Mini. 2 year of significant software development experience Must have delivered production level code (Python) in a commercial environment Excellent analytical and decision making skills Server-side Python coding, both in Django and straight WSGI Client-side development with HTML, JS/JQuery, and CSS SQL database design and coding Experience with AWS Degree in Computer Science a plus http://www.voxteneo.com/jobs/#job-indonesia -- View this message in context: http://python.6.x6.nabble.com/We-are-looking-for-talented-and-motivated-PYTHON-Developers-for-our-office-in-Bandung-West-Java-tp5063819.html Sent from the Python - python-list mailing list archive at Nabble.com. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
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 yet, should return True True
>
> 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?
Because practicality beats purity.
Outside of the specialist areas of IEEE-754 floating point NANs, and SQL
NUL, it is a basic property of *nearly everything* that x equals itself,
for any x. This property is called "reflexivity", and is considered by
some (although not me) to be absolutely fundamental, never to be violated
under any circumstances.
(To be clear, I'm talking about reflexivity of *equality* specifically,
not of every operator. We wouldn't expect x > x, for example -- the
"greater than" operator is not reflexive.)
While IEEE-754, and SQL, have good reasons for violating the reflexivity
of equals, that upsets a lot of people. Given:
data = [1.0, 2.0, 3.0]
data == data
it would be surprising, and annoying, more often than useful if the
equality test returned False. Replace any of the floats with a NAN, and
the same surprise and annoyance applies.
In the case of Python, lists and other builtin containers partially
violate the specialist rules of IEEE-754 NAN handling, by using "is"
identity test as a shortcut for equality. Effectively, they assume that
equality is always reflexive. This was introduced as an optimization,
since == can be quite expensive in Python, whereas "is" requires only a
fast pointer comparison and is very cheap.
I support this optimization, even if it violates the non-reflexivity of
NANs. NANs are specialised values, and outside of the narrow confines of
IEEE-754 arithmetic, their non-reflexivity is more of a nuisance than
anything else.
(Some would argue that *even within* IEEE-754 arithmetic, non-reflexivity
is a nuisance. For now, I prefer to remain neutral in that argument.)
> In fact, I find myself puzzled about exactly how list equality is
> actually defined.
You'd have to check the C source code, but I would expect something like
this (only written in C):
class list:
def __eq__(self, other):
if self is other:
return True
elif isinstance(other, list):
if len(self) != len(other):
return False
for a, b in zip(self, other):
if not (a is b or a == b):
return False
return True
else:
return NotImplemented # Let other decide.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
[ANN] pyspread 0.3.1
== pyspread 0.3.1 == Pyspread 0.3.1 is released. This is a bugfix release that removes an annoying warning on the console. About pyspread == Pyspread is a non-traditional spreadsheet application that is based on and written in the programming language Python. The goal of pyspread is to be the most pythonic spreadsheet application. Pyspread is free software. It is released under the GPL v3. Project website: http://manns.github.com/pyspread/ Download page: https://pypi.python.org/pypi/pyspread What is new in 0.3.1 + Bugfix + Updated German localization + Updated Ukrainian localization Enjoy Martin -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
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. There's no pretty way of saying this: Comparing floats using equals operators has always and will always be an incredibly dumb idea. The same applies obviously to containers containing floats. I also agree with Chris that I think an additional operator will make things worse than better. It'll add confusion with no tangible benefit. The current operators might have the deficiency that they're not relexive, but then again: Why should == be always reflexive while the other operators aren't? Why should I be able to assume that x == x -> True but not when x < x -> False If you're arguing from a mathematical/logical standpoint then if you want the former you'll also have to want the latter. Cheers, Johannes -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa -- https://mail.python.org/mailman/listinfo/python-list
Rest WebService Testing using Python
Hi folks, This is Neeraj , I want to develop some standalone python Scripts to Test Rest Webservices i.e. WADL services with endpoints. Particularly I need "A script for logging in would pass the xml to the rest api with variables for all the payload fields python" So Can Anyone please provide me some sample scripts or tutorials or package that can help me in above Scenario for automating the Rest WebService Testing for me I am new to python.So please bear with me..:) Thanks in advance -- https://mail.python.org/mailman/listinfo/python-list
Re: Rest WebService Testing using Python
In article , neeraj.bakht...@gmail.com wrote: > Hi folks, > This is Neeraj , I want to develop some standalone python Scripts to Test > Rest Webservices i.e. WADL services with endpoints. > > Particularly I need "A script for logging in would pass the xml to the rest > api with variables for all the payload fields python" > > > So Can Anyone please provide me some sample scripts or tutorials or package > that can help me in above Scenario for automating the Rest WebService Testing > for me > > I am new to python.So please bear with me..:) > > Thanks in advance The question you are asking is broad, so I can only make some general suggestions. You've really got two needs here. One is you need some kind of test framework, the other is that you need some way to talk to an HTTP server. Let's attack those one at a time. Test framework. Testing is all about writing down a list of things you believe to be true, and then exercising the code to verify that they are indeed true. When I do X, I expect Y to happen. If it does, the test passes. If not, the test fails. Generally you write a large number of these tests, and run them all. A lot of this is boilerplate. You need some way to organize all the individual tests. Run them (or perhaps run subsets of them). Record which ones passed or not. Set up the right environment for each test to run, and possibly clean up after each one. The idea of a test framework is that it takes care of most of this for you automatically, letting you concentrate on the test logic. There's a couple of choices for test frameworks. The standard one that comes packaged with Python is unittest (https://docs.python.org/2/library/unittest.html). I used to use it a lot, but I've come to regard it as somewhat klunky. Still, it's the standard. If you've used JUnit, it has the advantage that it will feel very familiar. A newer alternative is nose (https://nose.readthedocs.org/), which is what I mostly use now. Nose simplifies some things, but sometimes can be a bit difficult to understand (the docs can be a bit obtuse in places). The big advantage of nose is it has some very powerful tools for running tests in parallel. If you have a lot of tests that are I/O bound, this can seriously reduce the time to run your test suite. There's also doctest (https://docs.python.org/2/library/doctest.html), but for the kind of testing you want to do, it's probably not the right tool. I include it only for completeness. OK, so now, how to talk to your HTTP service. That's easy. You want to use requests (http://docs.python-requests.org). If your web service involves persisting state on the client side with cookies, you'll want to explore requests' session functionality. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
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_list_of_floats == that_list_of_floats > > This is a horrible example. > > There's no pretty way of saying this: Comparing floats using equals > operators has always and will always be an incredibly dumb idea. The > same applies obviously to containers containing floats. That's a myth. It simply is not true that you should never compare floats with the equals operator, it comes from the dark ages of numeric computing prior to IEEE-754. 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 into the realm of superstition. Quoting Professor William Kahan from the foreword to the "Apple Numerics Manual", second edition: [B]ecause so many computers in the 1960s and 1970's possessed so many different arithmetic anomalies, computational lore has become encumbered with a vast body of superstition purporting to cope with them. One such superstitious rule is "*Never* ask whether floating-point numbers are exactly equal." That was written in 1987, just two years after the introduction of the IEEE-754 standard. It is heart-breaking that 26 years later this bogus "rule" is still being treated as gospel. Bruce Dawson has written an awesome series of blog posts dealing with floating point issues. In this post: https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/ he discusses some of the issues with comparing two C floats or doubles for equality. If you read the entire post, he emphasises how hard it is to compare floats, and gives three methods: - test whether they differ by an absolute error - test whether they differ by a relative error - test whether they differ by a certain number of Units In Last Place (one method he misses is the one used by Python unittest module, which rounds the values before comparing them) and describes some of the weaknesses of each. In a reply to a comment, he warns about using == to compare a float (single precision) and a double. But if you keep reading all the way down to this comment: https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/#comment-9989 he says: [T]he default equality comparison absolutely should be true equality. To do otherwise risks madness. I have a post almost ready that uses exact floating-point comparisons to validate math, thus proving that exact comparisons are valid. [...] So, standard fuzzy comparison functions would be nice, but the default should remain exact comparisons. There's one obvious use-case for exact comparison: "Has this value changed to some other value?" old = x x = function(x) if x != old: print "changed!" is fine. Changing the inequality to some fuzzy comparison is bogus, because that means that *some changes will not be detected*. > I also agree with Chris that I think an additional operator will make > things worse than better. It'll add confusion with no tangible benefit. > The current operators might have the deficiency that they're not > relexive, but then again: Why should == be always reflexive while the > other operators aren't? 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 equality is reflexive. It is fundamental to the nature of numbers and equality that a number is always equal to itself. To the degree that floats are supposed to model real numbers, they should obey the same laws of real numbers. However, they already fail to obey them, so the failure of reflexivity is just one more problem that makes floating point such a hard problem. Compared to floating point arithmetic, calculus is easy. > Why should I be able to assume that > > x == x -> True > > but not > > when x < x -> False Because not all types are ordered: py> x = 1+3j py> x < x Traceback (most recent call last): File "", line 1, in TypeError: unorderable types: complex() < complex() -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
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 equality is reflexive. It is fundamental to the nature of > numbers and equality that a number is always equal to itself. To the > degree that floats are supposed to model real numbers, they should obey > the same laws of real numbers. However, they already fail to obey them, > so the failure of reflexivity is just one more problem that makes > floating point such a hard problem. Compared to floating point > arithmetic, calculus is easy. > 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 either, but thanks to rounding, that's not always true. (Not to mention that "infinity" isn't a number, but it is a floating-point value.) The problem is not equality comparisons, the problem is the expectation that the rules of reals apply to floats. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
Steve Hayes on Sun, 01 Jun 2014 05:05:05 +0200 typed in comp.lang.python the following: >On Sat, 31 May 2014 15:44:46 +0300, Marko Rauhamaa wrote: > >>Steve Hayes : >> >>> I'll leave Python 3.2 on my computer, but 2.7.5 will be the one I'm >>> installing now. Even if I could *find* a book that deals with Python >>> 3.x, couldn't afford to but yet another Python book. >> >>Unfortunately, in the computer field, if there's a book written on a >>topic, it will most likely be out of date. >> >>In the 1990's, I used to buy computer books on various topics. I don't >>think I have bought one for ten years. Either it is online or it doesn't >>exist. >> >>There's enough Python material online to become a pro in it: > >I hate reading stuff online, and find it diffucult to learn anything with that >method. I use MS Word 97 in preference to Libre Office wor Word 2010 (both of >which I have) because I have a book on the first, but not on the others. I >can't read online books in the bath or in bed. Hear, hear! -- pyotr filipivich The fears of one class of men are not the measure of the rights of another. -- George Bancroft -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
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 into the realm of superstition.
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.
You're hairsplitting: when I'd have said "in 99.9% of cases" you'd agree
with me but since I said "always" you disagree. Don't lawyer out.
Comparing binary representation of floats is a crappy idea.
Even more so in the age of cloud computing where your code is executed
on who knows which architecture where the exact same high level
interpretation might lead to vastly different results. Not to mention
high performance computing, where specialized FPUs can numerously be
found which don't give a shit about IEEE754.
Another thing why it's good to NEVER compare floats with regards to
their binary representation: Do you exactly know how your FPU is
configured by your operating system. Do you know that your FPUs on a
multiprocessor system are configured all identically with regards to
754? Rounding modes, etc?
Just don't fall in the pit. Don't compare floats via equals.
>> when x < x -> False
>
> Because not all types are ordered:
>
> py> x = 1+3j
> py> x < x
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: unorderable types: complex() < complex()
Oh, so then you also don't want refelexivity of equals, I think.
Because, obviously, not all types support comparison for equality:
#!/usr/bin/python3
class Yeah(object):
def __eq__(self, other):
raise TypeError("Booya")
Yeah() == Yeah()
You cherrypick your logic and hairsplit in your reasoning. It's not
consistent.
Cheers,
Johannes
--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Wed, May 28, 2014 at 12:23 PM, Larry Martell wrote: > Somthing I came across in my travels through the ether: > > https://medium.com/@deliciousrobots/5d2ad703365d/ Hey kids, maybe if we all chant this enough times, we can make it true! Wouldn't that be fun? -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
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 either, but thanks to > rounding, that's not always true. Not to mention that whole "sum of all the positive integers" thing :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
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 can safely assume that 1.0 == 1.0 on any system that Python runs on. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
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 is used on. > > No, you don't, but I think you can safely assume that 1.0 == 1.0 on > any system that Python runs on. > > ChrisA 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. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
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-so-handy magic of Python's float reprs, rounding them off. Can you do the same trick in Python 3, where the repr rules changed? If so, I would say this is a potential flaw in the display, although not really a serious one. But in terms of the OP's complaint, this is still fine, as the state must have changed for it to be unequal. If you care about equality differences and NOT about the above change, well, I think I've found your solution: instead of "x == y", you should use "repr(x) == repr(y)" :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
codingbat question broken?
I'm working on the following problem set from codingbat.com http://codingbat.com/prob/p107863 Given 3 int values, a b c, return their sum. However, if one of the values is 13 then it does not count towards the sum and values to its right do not count. So for example, if b is 13, then both b and c do not count. lucky_sum(1, 2, 3) → 6 lucky_sum(1, 2, 13) → 3 lucky_sum(1, 13, 3) → 1 The solution I came up with was - def lucky_sum(a, b, c): t = 0 for ints in (a, b, c): if a == 13: t = b + c elif b == 13: t = a elif c == 13: t = a + b else: t = a + b + c return t However the following tests fail lucky_sum(13, 2, 3) → 05X lucky_sum(13, 2, 13) → 015Xlucky_sum(13, 13, 2) → 015X Can anyone show me an example where all test are success? -- https://mail.python.org/mailman/listinfo/python-list
Re: codingbat question broken?
On Sun, Jul 13, 2014 at 12:05 PM, Rodrick Brown wrote: > > Can anyone show me an example where all test are success? No, because that's asking for the answer :) What you need to do is look at the failing test cases, and figure out why your function is giving the wrong result. Do you see what's true of all the failing cases and is not true of any others? That might give you a clue as to what's wrong. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: codingbat question broken?
This runs on 2.7 or 3.4, unmodified (other than the #!):
#!/usr/local/cpython-2.7/bin/python
#!/usr/local/cpython-3.4/bin/python
def lucky_sum(*list_):
lucky_total = 0
for element in list_:
if element == 13:
break
lucky_total += element
return lucky_total
if __name__ == '__main__':
print('starting tests')
assert lucky_sum(1, 2, 3) == 6
assert lucky_sum(1, 2, 13) == 3
assert lucky_sum(1, 13, 3) == 1
print('ending tests')
On Sat, Jul 12, 2014 at 7:05 PM, Rodrick Brown
wrote:
> I'm working on the following problem set from codingbat.com
>
> http://codingbat.com/prob/p107863
>
> Given 3 int values, a b c, return their sum. However, if one of the values
> is 13 then it does not count towards the sum and values to its right do not
> count. So for example, if b is 13, then both b and c do not count.
>
> lucky_sum(1, 2, 3) → 6
> lucky_sum(1, 2, 13) → 3
> lucky_sum(1, 13, 3) → 1
>
> The solution I came up with was -
>
> def lucky_sum(a, b, c):
> t = 0
> for ints in (a, b, c):
> if a == 13:
> t = b + c
> elif b == 13:
> t = a
> elif c == 13:
> t = a + b
> else:
> t = a + b + c
> return t
>
> However the following tests fail
>
> lucky_sum(13, 2, 3) → 05X lucky_sum(13, 2, 13) → 015Xlucky_sum(13,
> 13, 2) → 015X
>
> Can anyone show me an example where all test are success?
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: codingbat question broken?
On Sat, Jul 12, 2014 at 8:05 PM, Rodrick Brown wrote: > if a == 13: > t = b + c This looks incorrect. So no, I don't think the problem is with codingbat. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: === and !=== operators
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 that equality "always" is >> wrong takes it out of good advice into the realm of superstition. > > 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. How many systems do you know of are there that support Python but don't support IEEE-754? Here's a thread from 2008 which discusses this: https://mail.python.org/pipermail/python-dev/2008-February/076680.html If you're running my code on an implementation of Python without IEEE-754 floats, then I'm quite happy to say "Sorry guys, that's not my problem, you're on your own." And if you're running an implementation of Python where 1.0 != 1.0, well, your system is so broken that there is no hope for it. None what so ever. > You're hairsplitting: when I'd have said "in 99.9% of cases" you'd agree > with me I never said that. I would not put a percentage to it, because it depends on the context and what you are trying to do. For some uses, exact equality is the right solution. For others, an absolute epsilon comparison is better. For yet others still, a relative error, or a ULP comparison, are better solutions. There's no way of putting a percentage to those. You have to understand what you are doing, and not just mindlessly follow some superstition. When you mindlessly follow superstition, you end up with bogus warnings like this: https://gcc.gnu.org/ml/gcc/2001-08/msg00853.html > but since I said "always" you disagree. Don't lawyer out. > Comparing binary representation of floats is a crappy idea. Yes. And *not* comparing floats with == is a crappy idea too. *EVERY* method of comparing two floats to see if they are the same can break under some circumstances. Everything about floats is crappy, except that avoiding floats completely is *worse*. Nevertheless, floats are not magically cursed. They are deterministic, for any fixed combination of CPU (or FPU) + machine code, and if you understand how floats work, then you can understand when to use exact equality and when not to: http://randomascii.wordpress.com/2012/06/26/doubles-are-not-floats-so- dont-compare-them/ Using any sort of fuzzy comparison means that you lose transitivity: if x == y and y == z then x == z This holds for any sane floating point system, but it doesn't hold with fuzzy comparisons. By default, APL uses fuzzy comparisons instead of exact equality. Out of the thousands of programming languages ever designed, APL is unique, or at most one of a tiny handful of languages, which eschews exact float equality. Why do you think that is? The idea of tolerant comparisons and fuzzy functions is a fundamental design feature of APL: http://www.jsoftware.com/papers/satn23.htm nevertheless even in APL there are uses for setting the tolerance to zero (i.e. to get exact equality). Robert Bernecky gives one such example, and writes "In such a search exact comparison is absolutely necessary." [Aside: I note that despite providing fuzzy comparison functions, and a system variable that controls the amount of fuzz, APL merely pushes the decision of how much fuzz is appropriate onto the user: "In general, ⎕ct should be chosen to be the smallest value which is large enough to mask common arithmetic errors." And what about uncommon arithmetic errors, I wonder? But I digress.] > Even more so in the age of cloud computing where your code is executed > on who knows which architecture where the exact same high level > interpretation might lead to vastly different results. If so, then that is a bug in the cloud computing platform. Not my problem. Complain to the provider. > Not to mention > high performance computing, where specialized FPUs can numerously be > found which don't give a shit about IEEE754. Why should I support such broken platforms? If I run Python code on some horrible platform which only checks the first 8 characters of a string for equality "for performance reasons": if "monumentless" == "monumental": print "Your Python is broken" we'd all agree that the implementation was broken. Failure to meet at least the semantics of CPython floats is likewise broken. > Another thing why it's good to NEVER compare floats with regards to > their binary representation: Do you exactly know how your FPU is > configured by your operating system. Do you know that your FPUs on a > multiprocessor system are configured all identically with regards to > 754? Rounding modes, etc? > > Just don't fall in the pit. Don't compare floats via equals. And this is why that advise is purest superstition. If you don't
