Re: Why float('Nan') == float('Nan') is False
Le 13/02/2019 à 14:21, ast a écrit :
Hello
>>> float('Nan') == float('Nan')
False
Why ?
Regards
Thank you for answers.
If you wonder how I was trapped with it, here
is the failing program.
r = float('Nan')
while r==float('Nan'):
inp = input("Enter a number\n")
try:
r = float(inp)
except ValueError:
r = float('Nan')
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why float('Nan') == float('Nan') is False
u...@speedy.net writes: > There are more integers than odd numbers, and more odd numbers than prime > numbers. An infinite set may be a subset of another infinite set although > they may both have the same cardinality. Or in other words, the number of > elements in each set is not equal. One has more elements than the other. > AND, by induction you can also prove that the other one has more elements > than the first one. So the number of elements in two infinite sets can't be > equal. Even, if you compare the same set to itself. You would expect that to be true, but it is not. There are in fact the same number of odd integers as integers, and the same number of primes as integers. Counterintuitive but true. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why float('Nan') == float('Nan') is False
songbird writes: > Chris Angelico wrote: >> On Thu, Feb 14, 2019 at 7:12 AM Test Bot wrote: >>> >>> This definition of NaN is much better in mentally visualizing all the so >>> called bizarreness of IEEE. This also makes intuitive that no 2 NaN will be >>> equal just as no 2 infinities would be equal. I believe in a hypothesis(of >>> my own creation) that any arithmetic on a data type of NaN would be similar >>> to any set of operations on the set of Infinities. >>> >> >> Why would no two infinities be equal? In mathematics, there's one >> best-known infinity (aleph null, aka the number of counting numbers), >> and many many infinities are provably equal to it. (Others are >> provably NOT equal to it, like the number of real numbers.) There's >> nothing wrong with saying "there are as many prime numbers as there >> are odd numbers", or equivalently that "the size/cardinality of the >> set of primes is equal to the size of the set of odd numbers" [1]. And >> both Python and IEEE agree: > ... >> [1] I'm sure someone will point out something pedantically wrong in >> what I said, but certainly the sets have the same cardinality. > > all such proofs i have ever seen are based upon the > assumptions that there are infinite numbers of such > things like primes. > > this only makes sense in theory. > > alas, we don't really know if the universe is infinitely > subdivisible (as the reals seem to represent) or infinitely > large (even if it isn't infinitely subdivisible)... so to > me every one of those proofs is conditional upon assumptions > (which also drags the p = np question into such assumptions). > > it's fun to think about. :) It doesn't depend upon assumptions, it depends on definitions and logic. You don't need to assume there are an infinite number of primes, it's been proven. It doesn't matter whether the universe is infinitely subdivisible or infinitely large, the set of real number is (assuming I'm interpreting your "subdivisible" correctly). I've got no idea what P and NP have to do with this. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why float('Nan') == float('Nan') is False
On Thu, Feb 14, 2019 at 11:01 AM songbird wrote: > all such proofs i have ever seen are based upon the > assumptions that there are infinite numbers of such > things like primes. I posted an abbreviated proof of that in a footnote. It's a proof by contradiction. First, assume that there are, in fact, a finite number of primes. If that's the case, then all primes must be integers between 2 and some number p, the highest prime. Take the product of all primes - call it x. When you take the product of positive integers, the result must always be at least as large as any of the factors, so x >= p. Also, x must be a multiple of every prime, which in turn means that x+1 cannot possibly be a multiple of any such prime. Thus the value x+1 must either be prime, or be the product of prime numbers that aren't in your collection of primes; therefore the collection of primes cannot possibly be complete. Therefore there are indeed an infinite number of primes. So it's not an assumption; it's a proven point. The subdividability of the universe is actually irrelevant. Perhaps the universe, at some level, becomes indivisible; but numbers don't. For any two non-equal real numbers, it is always possible to find another number in between them. (This is NOT true of floating-point numbers or any other fixed-size representation.) Numbers are actually extremely convenient like that. This is largely off-topic for Python, but do consider: thanks to bignum integers and the Fraction type, we can represent any rational number, assuming we have enough storage space. Or do we. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Best way to remove unused pip installed modules/module dependencies from a virtual env?
[Reformatted as original post got mangled] Looking for advice on the best way to remove unused modules from a Python virtual environment. My setup is Python 3.6.6 running on macOS although I believe my use case is OS independent. Background: Long running project that, over the course of time, pip installed modules that are no longer used by the code. I'm looking for a way to identity unused modules and remove them. Here's my back-of-napkin strategy to do this. Wondering if there are holes in this approach or if there's an off-the-shelf solution for my use case? 1. pip freeze > modules.txt 2. build a list of all import statements, extract out module names 3. remove these module names from modules.txt and add to used-modules.txt 4. modules that remain in modules.txt are either module dependencies of directly imported modules or no longer used 5. remove my virtual env and recreate it again to start with a fresh env 6. reinstall each directly imported module (from list in used-modules.txt); this will pull in dependencies again 7. pip freeze > requirements.txt <--- this should be the exact modules used by our code Thank you, Malcolm -- https://mail.python.org/mailman/listinfo/python-list
Best way to remove unused pip installed modules/module dependencies from a virtual env?
Looking for advice on the best way to remove unused modules from a Python virtual environment. My setup is Python 3.6.6 running on macOS although I believe my use case is OS independent. Background: Long running project that, over the course of time, pip installed modules that are no longer used by the code. I'm looking for a way to identity unused modules and remove them. Here's my back-of-napkin strategy to do this. Wondering if there are holes in this approach or if there's an off-the-shelf solution for my use case? 1. pip freeze > modules.txt 2. build a list of all import statements, extract out module names 3. remove these module names from modules.txt and add to used- modules.txt4. modules that remain in modules.txt are either module dependencies of directly imported modules or no longer used5. remove my virtual env and recreate it again to start with a fresh env6. reinstall each directly imported module (from list in used- modules.txt); this will pull in dependencies again7. pip freeze > requirements.txt <--- this should be the exact modules used by our code Thank you, Malcolm -- https://mail.python.org/mailman/listinfo/python-list
Re: Why float('Nan') == float('Nan') is False
Chris Angelico wrote: > On Thu, Feb 14, 2019 at 7:12 AM Test Bot wrote: >> >> This definition of NaN is much better in mentally visualizing all the so >> called bizarreness of IEEE. This also makes intuitive that no 2 NaN will be >> equal just as no 2 infinities would be equal. I believe in a hypothesis(of >> my own creation) that any arithmetic on a data type of NaN would be similar >> to any set of operations on the set of Infinities. >> > > Why would no two infinities be equal? In mathematics, there's one > best-known infinity (aleph null, aka the number of counting numbers), > and many many infinities are provably equal to it. (Others are > provably NOT equal to it, like the number of real numbers.) There's > nothing wrong with saying "there are as many prime numbers as there > are odd numbers", or equivalently that "the size/cardinality of the > set of primes is equal to the size of the set of odd numbers" [1]. And > both Python and IEEE agree: ... > [1] I'm sure someone will point out something pedantically wrong in > what I said, but certainly the sets have the same cardinality. all such proofs i have ever seen are based upon the assumptions that there are infinite numbers of such things like primes. this only makes sense in theory. alas, we don't really know if the universe is infinitely subdivisible (as the reals seem to represent) or infinitely large (even if it isn't infinitely subdivisible)... so to me every one of those proofs is conditional upon assumptions (which also drags the p = np question into such assumptions). it's fun to think about. :) songbird -- https://mail.python.org/mailman/listinfo/python-list
What's up with Activestate Python?
For many, many years I've always installed ActiveState's ActivePython Community edition when forced to use Windows. It has always included all of the "extra" libraries that I didn't wan't to install (or couldn't because I didn't have a C compiler for Windows). I recently decided to upgrade my Win7 machine from ActivePython 3.5.4 to 3.6. ... and all of apps stopped working. ActivePython 3.6 appears to be a minimal install that includes nothing but CPython. Comparing the download sizes makes this obvious: -rw-r--r-- 1 grante users 223056832 Mar 26 2018 ActivePython-2.7.14.2717-win64-x64-404905.exe -rw-r--r-- 1 grante users 225065576 May 29 2018 ActivePython-3.5.4.3504-win64-x64-404899.exe -rw-r--r-- 1 grante users 30297136 Feb 13 16:28 ActivePython-3.6.0.3600-win64-x64-401834.exe I've searched the ActiveState web site, and the fact that they've stopped including "extra" libraries doesn't seem to be documented anywhere. I guess it's time to switch to Anaconda or ??? -- Grant Edwards grant.b.edwardsYow! Is this going to at involve RAW human ecstasy? gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Why float('Nan') == float('Nan') is False
On Thu, Feb 14, 2019 at 9:07 AM Avi Gross wrote: > But that means that normal mathematics is warped. Well yes. Yes, it is. That's why people think "Alice's Adventures in Wonderland" is the result of a drug-induced dream - in actual fact, it's the result of the Dean of Mathematics telling stories to young children. Of course mathematics is warped. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why float('Nan') == float('Nan') is False
I think we should realize that Nan and NA and so on are human constructs people
Define in programming languages. Some have subdivisions as in not an int as
compared to not a float.
Python also has an Inf as well as a -Inf that are abstractions and not a real,
so to speak. Number.
Mathematics is arguably a human discovery when it comes to infinities since
Cantor but the rules are not the same. CARDINALITY is not a number. It is a
logical range of partitions. There obviously are more integers than prime
numbers as you count upwards to a thousand or a billion. BUT in the context of
infinity, at the Aleph Null level, they sort of map into the same category. So
the primes or squares or odd numbers are not equal but in the limit as you
approach whatever infinity means, they seem effectively equal as there is
always another. You can sort of make a 1:1 correspondence or mapping.
But that means that normal mathematics is warped. Double it and/or add a
quadrillion and it remains in the same bucket. But there are other buckets and
everything in them is not so much the same as in some sense larger than the
previous bucket but smaller than the next higher bucket.
The continuum hypothesis remains open as to whether there is an intermediate
bucket you can describe between Aleph Null and Aleph one. Meaning there is no
reasonable definition of a bucket the new infinite construct fits in while not
fitting existing ones.
Back to python. Or is it IEEE? In type int the number can be arbitrarily large
as long as you have enough computer memory and resources. Yet the special
concepts of Inf and negative Inf can be compared with other ints but not
fruitfully with Nan, right? There are helper functions you can call to ask if a
variable is an Inf or a Nan. Doubles have size limits so anything big enough
might as well be an Inf. I note some things like numpy use a fixed size int as
well.
Some of the confusion may come when a language uses a concept in many ways. In
R all an NA can mean is Not Available. Some data structures, just like a numpy
array in python, insist on holding objects of one unified type and NA normally
matches any such type as a placeholder. Sort of a NULL. You normally do not
want to include an NA in calculations as it infects everything. So you often
filter it out implicitly or explicitly. It is not necessarily an error but if
you use it in calculating a mean, then the result is sort of an error.
You can ask if a variable is an NA as in is.na(x) which returns a Boolean. So
to test if x and y are both NA or have the same status by both not being NA,
use the functions. Python has similar functionality. Just don't compare the
naked singularities to each other!
Sent from AOL Mobile Mail
On Wednesday, February 13, 2019 Chris Angelico wrote:
On Thu, Feb 14, 2019 at 7:12 AM Test Bot wrote:
>
> This definition of NaN is much better in mentally visualizing all the so
> called bizarreness of IEEE. This also makes intuitive that no 2 NaN will be
> equal just as no 2 infinities would be equal. I believe in a hypothesis(of
> my own creation) that any arithmetic on a data type of NaN would be similar
> to any set of operations on the set of Infinities.
>
Why would no two infinities be equal? In mathematics, there's one
best-known infinity (aleph null, aka the number of counting numbers),
and many many infinities are provably equal to it. (Others are
provably NOT equal to it, like the number of real numbers.) There's
nothing wrong with saying "there are as many prime numbers as there
are odd numbers", or equivalently that "the size/cardinality of the
set of primes is equal to the size of the set of odd numbers" [1]. And
both Python and IEEE agree:
>>> float("inf") == float("inf")
True
NaN and infinity are quite different concepts, and they behave very differently.
ChrisA
[1] I'm sure someone will point out something pedantically wrong in
what I said, but certainly the sets have the same cardinality.
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why float('Nan') == float('Nan') is False
On Thu, Feb 14, 2019 at 8:24 AM אורי wrote: > On Wed, Feb 13, 2019 at 10:20 PM Chris Angelico wrote: >> >> Why would no two infinities be equal? In mathematics, there's one >> best-known infinity (aleph null, aka the number of counting numbers), >> and many many infinities are provably equal to it. (Others are >> provably NOT equal to it, like the number of real numbers.) There's >> nothing wrong with saying "there are as many prime numbers as there >> are odd numbers", or equivalently that "the size/cardinality of the >> set of primes is equal to the size of the set of odd numbers" [1]. And >> both Python and IEEE agree: > > > There are more integers than odd numbers, and more odd numbers than prime > numbers. An infinite set may be a subset of another infinite set although > they may both have the same cardinality. Or in other words, the number of > elements in each set is not equal. One has more elements than the other. AND, > by induction you can also prove that the other one has more elements than the > first one. So the number of elements in two infinite sets can't be equal. > Even, if you compare the same set to itself. > You can enumerate the odd numbers easily. The first odd number is 1, the second odd number is 3, the third is 5, the fourth is 7, etc, etc. Or if you want to include negative odd numbers, the first is 1, the second is -1, the third is 3, the fourth is -3, the fifth is 5, the sixth is -5, etc. Thus there is a clear and easy bijection between odd numbers and counting numbers. You aren't going to run out of counting numbers before you run out of odd numbers or vice versa. The same is true of prime numbers. The first prime number is 2, the second is 3, the third is 5, the fourth 7, the fifth 11, the sixth 13. You can never "run out" of prime numbers [1], so you can enumerate them all. Thus there's the same bijection between prime numbers and counting numbers, and thus there are equally many. Therefore, since you can take any odd number and find its position in the list, and then find the same position in the list of primes, it would be possible (albeit computationally impractical) to find the corresponding prime number for any odd number. There are just as many prime numbers as odd numbers. ChrisA [1] Proof by contradiction: if there were finitely many primes, you could multiply them all together and add one. The result is greater than any number on your list, and can't be a multiple of any of the primes, ergo it's either prime, or a product of primes not on your list. QED. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why float('Nan') == float('Nan') is False
אורי
u...@speedy.net
On Wed, Feb 13, 2019 at 10:20 PM Chris Angelico wrote:
> On Thu, Feb 14, 2019 at 7:12 AM Test Bot wrote:
> >
> > This definition of NaN is much better in mentally visualizing all the so
> > called bizarreness of IEEE. This also makes intuitive that no 2 NaN will
> be
> > equal just as no 2 infinities would be equal. I believe in a
> hypothesis(of
> > my own creation) that any arithmetic on a data type of NaN would be
> similar
> > to any set of operations on the set of Infinities.
> >
>
> Why would no two infinities be equal? In mathematics, there's one
> best-known infinity (aleph null, aka the number of counting numbers),
> and many many infinities are provably equal to it. (Others are
> provably NOT equal to it, like the number of real numbers.) There's
> nothing wrong with saying "there are as many prime numbers as there
> are odd numbers", or equivalently that "the size/cardinality of the
> set of primes is equal to the size of the set of odd numbers" [1]. And
> both Python and IEEE agree:
>
There are more integers than odd numbers, and more odd numbers than prime
numbers. An infinite set may be a subset of another infinite set although
they may both have the same cardinality. Or in other words, the number of
elements in each set is not equal. One has more elements than the other.
AND, by induction you can also prove that the other one has more elements
than the first one. So the number of elements in two infinite sets can't be
equal. Even, if you compare the same set to itself.
>
> >>> float("inf") == float("inf")
> True
>
> NaN and infinity are quite different concepts, and they behave very
> differently.
>
> ChrisA
>
> [1] I'm sure someone will point out something pedantically wrong in
> what I said, but certainly the sets have the same cardinality.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
How do/can I generate a PKCS#12 file the cryptography module?
I’m using the cryptography module (https://cryptography.io/en/latest/) to try and generate some cert/key/identities. It's pretty easy using said module to generate the contents of .pem file for a private key: keyPEMBytes = privateKey.private_bytes( encoding=serialization.Encoding.PEM, format=serialization.PrivateFormat.TraditionalOpenSSL, encryption_algorithm=serialization.NoEncryption()) It’s also easy to generate the contents of a .cer/.pem file for an associated cert: certBytes = certificate.public_bytes(encoding=serialization.Encoding.PEM) But I need them (and their chain) balled up on a single .p12 (PKCS12) file. Said module documents how to parse/consume PKCS12 formats, but nothing (that I can find) about how one can generate them. My understanding of PKI stuff is hit and miss though, so maybe I'm just not searching the right keyword in the documentation? I can create the .p12 file at the command line on Linux using openssl pkcs12 -export -out myIdentity.p12 -inkey myPrivKey.pem -in myCert.crt -certfile myCertChain.crt So I could just wrap calls like this with subprocess/cmd and mess with tempfiles/pipes. I was hoping to keep it all in memory/python though. Is there a different python TLS library that I should be considering, that can do this? (stack overflow version if you’re into the points and all that: https://stackoverflow.com/questions/54677841/how-do-can-i-generate-a-pkcs12-file-using-python-and-the-cryptography-module) -- https://mail.python.org/mailman/listinfo/python-list
Re: Why float('Nan') == float('Nan') is False
On 2/13/19 12:32 PM, Marko Rauhamaa wrote:
"Avi Gross" :
A NaN is a bit like a black hole. Anything thrown in disappears and
that is about all we know about it. No two black holes are the same
even if they seem to have the same mass, spin and charge. All they
share is that we don't know what is in them.
Then, how do you explain:
>>> float("nan") != float("nan")
True
Why's that not False?
Marko
Because IEEE-754 decided that it was non-optional that (x != y) was
equal to not (x == y). Which is not the case for the ordering
operators, since ordering is inherently undefined.
In part, these decisions were made to make it possible to detect a NaN
in C in the absence of an isnan() function. If (x != x), then x must be
a NaN.
--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why float('Nan') == float('Nan') is False
"Avi Gross" :
> A NaN is a bit like a black hole. Anything thrown in disappears and
> that is about all we know about it. No two black holes are the same
> even if they seem to have the same mass, spin and charge. All they
> share is that we don't know what is in them.
Then, how do you explain:
>>> float("nan") != float("nan")
True
Why's that not False?
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why float('Nan') == float('Nan') is False
On Thu, Feb 14, 2019 at 7:12 AM Test Bot wrote:
>
> This definition of NaN is much better in mentally visualizing all the so
> called bizarreness of IEEE. This also makes intuitive that no 2 NaN will be
> equal just as no 2 infinities would be equal. I believe in a hypothesis(of
> my own creation) that any arithmetic on a data type of NaN would be similar
> to any set of operations on the set of Infinities.
>
Why would no two infinities be equal? In mathematics, there's one
best-known infinity (aleph null, aka the number of counting numbers),
and many many infinities are provably equal to it. (Others are
provably NOT equal to it, like the number of real numbers.) There's
nothing wrong with saying "there are as many prime numbers as there
are odd numbers", or equivalently that "the size/cardinality of the
set of primes is equal to the size of the set of odd numbers" [1]. And
both Python and IEEE agree:
>>> float("inf") == float("inf")
True
NaN and infinity are quite different concepts, and they behave very differently.
ChrisA
[1] I'm sure someone will point out something pedantically wrong in
what I said, but certainly the sets have the same cardinality.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why float('Nan') == float('Nan') is False
This definition of NaN is much better in mentally visualizing all the so
called bizarreness of IEEE. This also makes intuitive that no 2 NaN will be
equal just as no 2 infinities would be equal. I believe in a hypothesis(of
my own creation) that any arithmetic on a data type of NaN would be similar
to any set of operations on the set of Infinities.
On Thu, Feb 14, 2019, 12:33 AM Avi Gross I won't speak for the IEEE but NOT A NUMBER does not tell you what
> something
> IS.
>
> If "Hello, World!" is not a number as in an int or a float and we throw
> away
> the content and simply call it a NaN or something and then we notice that
> an
> object that is a list of fruits is also not a number so we call it a NaN
> too, then should they be equal?
>
> A NaN is a bit like a black hole. Anything thrown in disappears and that is
> about all we know about it. No two black holes are the same even if they
> seem to have the same mass, spin and charge. All they share is that we
> don't
> know what is in them.
>
> When variable "a" is a Nan then it is sort of a pointer to a concept. The
> pointer IS itself but the concepts may not be.
>
> -Original Message-
> From: Python-list On
> Behalf Of Grant Edwards
> Sent: Wednesday, February 13, 2019 1:03 PM
> To: python-list@python.org
> Subject: Re: Why float('Nan') == float('Nan') is False
>
> On 2019-02-13, ast wrote:
> > Hello
> >
> > >>> float('Nan') == float('Nan')
> > False
>
> If you think that's odd, how about this?
>
> >>> n = float('nan')
> >>> n
> nan
> >>> n is n
> True
> >>> n == n
> False
> >>>
>
> > Why ?
>
> IEEE says so.
>
> --
> Grant Edwards grant.b.edwardsYow! Like I always say
> at -- nothing can beat
> gmail.comthe BRATWURST here in
>DUSSELDORF!!
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why float('Nan') == float('Nan') is False
On 2/13/19 1:53 PM, Grant Edwards wrote: Floating point is sort of the quantum mechanics of computer science. At first glance, it seems sort of weird. But after you work with it a while, it gets even worse. Yep! :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Why float('Nan') == float('Nan') is False
On Thu, Feb 14, 2019 at 6:55 AM Grant Edwards wrote: > > On 2019-02-13, Schachner, Joseph wrote: > > > This makes some sense because NAN is Not A Number, so any comparison > > to a number fails. > > Ah, but you now seem to be conflating "comparison fails" with > "comparison has a boolean value of False". > > The alternative to (nan == nan) => False is probably not (nan == nan) > => True: it's (nan == nan) => exception. Or (nan == nan) => nan, which is what "infections nan" would be like. (Compare NULL.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why float('Nan') == float('Nan') is False
On Thu, Feb 14, 2019 at 6:40 AM Schachner, Joseph
wrote:
>
> Because all comparisons with NAN return false, that's the spec.
Apart from !=, because it would be insane (I mean, even more insane
than it is) to have nan == nan be false AND nan != nan.
IEEE NAN has several purposes, including representing the concept of
"could be any number but we have no idea what", and also the concept
of "there is truly no value here". And sometimes both at once -
imagine getting per-capita statistics partitioned by age group and
postal code, and having nobody in a particular age/postcode, so you
end up with both "there is no value here" and "what do you get when
you divide zero by zero" (zero whatevers divided by zero people). So
there ARE some operations involving nan that produce real results:
>>> 1 ** nan
1.0
but as a general rule, you have to assume that nan truly isn't a number.
Oh, and if you want TRULY mind-melty fun, look into the SQL "NULL"
value, which is a value, except when it isn't. Comparisons with NULL
don't return false, they return NULL. Most of the time, if you take a
column function over a nullable column (say, taking the sum or average
of the values in a field), you just ignore any rows that are NULL; but
if *every* value is NULL, the sum is not 0, but NULL.
Now try mapping SQL's NULL to Python's float("nan"), and performing
operations on both sides.
Endless fun.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why float('Nan') == float('Nan') is False
On 2019-02-13, Schachner, Joseph wrote: > This makes some sense because NAN is Not A Number, so any comparison > to a number fails. Ah, but you now seem to be conflating "comparison fails" with "comparison has a boolean value of False". The alternative to (nan == nan) => False is probably not (nan == nan) => True: it's (nan == nan) => exception. Towards that end, the IEEE standard provides for something called a "signalling NaN". I'm not aware of any Python implementations that support signalling NaNs. Floating point is sort of the quantum mechanics of computer science. At first glance, it seems sort of weird. But after you work with it a while, it gets even worse. -- Grant Edwards grant.b.edwardsYow! Jesuit priests are at DATING CAREER DIPLOMATS!! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
RE: Why float('Nan') == float('Nan') is False
Because all comparisons with NAN return false, that's the spec. is NAN > 0?
False. Is NAN< 0? False. Is NAN == 0? False. Is NAN == ? False.
So: Is NAN == NAN? False. And one more: Is NAN < 1.0e18? False
This makes some sense because NAN is Not A Number, so any comparison to a
number fails.
--- Joseph S.
-Original Message-
From: ast
Sent: Wednesday, February 13, 2019 8:21 AM
To: python-list@python.org
Subject: Why float('Nan') == float('Nan') is False
Hello
>>> float('Nan') == float('Nan')
False
Why ?
Regards
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why float('Nan') == float('Nan') is False
ast writes:
> Hello
>
float('Nan') == float('Nan')
> False
>
> Why ?
>
> Regards
Others have given the real answer -- IEEE says so, and the people who
wrote the standard are smarter than me. All the same, this is my take
on the reason for it: NaN is specifically a representation for "this
has no value". The == operator compares the values of its operands;
something that has no value can't == anything, including itself.
--
https://mail.python.org/mailman/listinfo/python-list
RE: Why float('Nan') == float('Nan') is False
I won't speak for the IEEE but NOT A NUMBER does not tell you what something
IS.
If "Hello, World!" is not a number as in an int or a float and we throw away
the content and simply call it a NaN or something and then we notice that an
object that is a list of fruits is also not a number so we call it a NaN
too, then should they be equal?
A NaN is a bit like a black hole. Anything thrown in disappears and that is
about all we know about it. No two black holes are the same even if they
seem to have the same mass, spin and charge. All they share is that we don't
know what is in them.
When variable "a" is a Nan then it is sort of a pointer to a concept. The
pointer IS itself but the concepts may not be.
-Original Message-
From: Python-list On
Behalf Of Grant Edwards
Sent: Wednesday, February 13, 2019 1:03 PM
To: python-list@python.org
Subject: Re: Why float('Nan') == float('Nan') is False
On 2019-02-13, ast wrote:
> Hello
>
> >>> float('Nan') == float('Nan')
> False
If you think that's odd, how about this?
>>> n = float('nan')
>>> n
nan
>>> n is n
True
>>> n == n
False
>>>
> Why ?
IEEE says so.
--
Grant Edwards grant.b.edwardsYow! Like I always say
at -- nothing can beat
gmail.comthe BRATWURST here in
DUSSELDORF!!
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why float('Nan') == float('Nan') is False
On 2019-02-13, ast wrote:
> Hello
>
> >>> float('Nan') == float('Nan')
> False
If you think that's odd, how about this?
>>> n = float('nan')
>>> n
nan
>>> n is n
True
>>> n == n
False
>>>
> Why ?
IEEE says so.
--
Grant Edwards grant.b.edwardsYow! Like I always say
at -- nothing can beat
gmail.comthe BRATWURST here in
DUSSELDORF!!
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why float('Nan') == float('Nan') is False
On 2/13/19 7:21 AM, ast wrote:
Hello
>>> float('Nan') == float('Nan')
False
Why ?
Because the IEEE-754 Standard demands it, and people smarter
than I worked on the IEEE-754 Standard.
is a quick starting
point for a deeper dive.
--
https://mail.python.org/mailman/listinfo/python-list
Why float('Nan') == float('Nan') is False
Hello
>>> float('Nan') == float('Nan')
False
Why ?
Regards
--
https://mail.python.org/mailman/listinfo/python-list
Re: A limit to writing to a file from a loop?
Steve wrote:
> My program reads from a text file (A), modifies the data, and writes to
> another file (B). This works until I reach about 300 writes and no more
> lines are written to file (B).
>
> I had to create a Counter and increment it to 250 when it gets reset.
>
> Upon reset, I close the file (B) being written and reopen it for append.
>
> Then it accepts the entire list of lines of data.
>
>
>
> Bizarre?
Maybe a misdiagnosis. If you are reading the file contents while it is still
open some output may reside in a buffer that is invisible to the reading
file object.
> CycleCounter += 1
>
> if CycleCounter > 250:
>
> CycleCounter = 1
Try replacing the following two lines
> DateReadings.close()
> DateReadings=open("Date-ReadingsAndDoses.txt", "a")
with
DateReadings.flush()
If that has the same effect as the close()/open() dance remove the flush(),
too, and ensure that the file is closed before you check its contents. The
with statement is the established way to achieve that. Instead of
file = open(...)
do_stuff_with(file)
file.close() # not called if there is an exception
write
with open(...) as file:
do_stuff_with(file)
# at this point the file is guaranteed to be closed.
>
> DateReadings.write("{0:15} {1:>8} {2:>8} {3:>8} {4:<2}
> {5:>8} {6:>8} {7:>10}".format
>
> (ThisTimeDate, ThisReading, ThisDose1,
> ThisSensor, ThisTrend,
>
>ThisTS, ThisPercent, SensorNumberDay2) +
>"\n")
--
https://mail.python.org/mailman/listinfo/python-list
