[HN Gopher] CPython, C standards, and IEEE 754
___________________________________________________________________
CPython, C standards, and IEEE 754
Author : jwilk
Score : 61 points
Date : 2022-03-03 19:21 UTC (3 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| wheelerof4te wrote:
| I love the compatibility between C and Python.
|
| Maybe off-topic, but in which language of theese two do you find
| a joy to program in?
|
| As for me, Python's features are godsend. Only, sometimes I want
| that procedural simplicity of C.
|
| I feel dirty trying to emulate C coding style in Python, even
| when it makes sense.
| morelisp wrote:
| jVinc wrote:
| What exactly is the bikeshed here? Naturally Python doesn't use
| the newest standards the second they are released because that
| would be chaos. So they need to consider when they use newer
| standards. In this case they found bugs and had a discussion
| that ended in everyone supporting adopting a newer standard.
|
| What exactly do you feel is the "which color should the shed
| be" point of this discussion?
| morelisp wrote:
| > What exactly do you feel is the "which color should the
| shed be" point of this discussion?
|
| I thought it was extremely clear from my comment. "Will
| requiring IEEE 754 make Python less appealing?"
| troutwine wrote:
| Leaving aside whether this is a bikeshed or not, I'm not at
| all surprised that a community that passed through the 2->3
| project would subsequently be concerned about even the
| barest repeat of that.
| tzot wrote:
| The quote was:
|
| > "The more 'it's-only-Python-if-it-has-X' restrictions we
| have, the less appealing we become."
|
| We the Python language?
| [deleted]
| dec0dedab0de wrote:
| I just wish python would switch float and Decimal.
|
| Most of the time float is just an implementation detail when you
| really want a decimal. I think the literals should be a decimal,
| and you could explicitly cast float when you actually need to do
| floating point math, or as an optimization. But I know it's too
| late for that.
| creata wrote:
| Why do you say that "most of the time... you really want a
| decimal"? I can't think of any situation where I'd prefer a
| decimal.Decimal over an ordinary float, except for the textbook
| example of dollars and cents. In most situations, I'm pretty
| sure decimal.Decimals would be unacceptably slower.
| tomrod wrote:
| In data science, this can be an issue.
| samwillis wrote:
| Even with currency now it seems more common to just use ints
| of the currency's lowest denomination/subunit (cents, pence
| etc)
| amanzi wrote:
| That would suit me too, but not sure of the wider implications.
| Spivak wrote:
| I mean they switched from strings being bytes of UTF-8 to
| unicode, never say never for Python 4! It would be a downright
| Pythonic move.
| tzot wrote:
| In CPython 2, a `str` was bytes _period_ ; no encoding was
| enforced, these bytes were not _necessarily_ valid UTF-8, and
| a `unicode` had either UTF-16 or UTF-32 in-memory
| representation (decided at compilation time). In CPython 3, a
| `bytes` is bytes and a `str` has ASCII /UTF-16/UTF-32 in-
| memory representation (decided at runtime). So CPython 2
| strings were not "bytes of UTF-8", and that is why strings
| `'\xfc\xf7\xe9'` worked fine, they even printed fine in the
| proper environments.
| snnn wrote:
| I don't know why GCC-12 was in the picture, but I hope all of you
| can understand one thing: python's source code must be compatible
| with GCC 6. And no so called "Threading [Optional]" features. It
| is all because CentOS is dead. CentOS has been sold to IBM. There
| is no CentOS 8 anymore. The free lunch is ended. And there
| wouldn't be another OSS project to replace it.
|
| Linux kernel developers want to use C11. CPython developers want
| to use C11. But does your compiler support it? If you were a C++
| developer, would you request C++17/C++20 also?
|
| CPython must be aligned with the manylinux project. manylinux
| build every python minor release from source. Historically
| manylinux only use CentOS. CentOS has devtoolset, which allows
| you use the latest GCC in an very old Linux release. Red hat has
| spent much time on it. Now you can't get it for free because
| CentOS is dead. So the manylinux community is switching to
| Ubuntu. Ubuntu can only provide GCC 6 to them. If anycode in
| CPython is not compatible with GCC6, then manylinux will have to
| drop ubuntu too. And they don't have any other alternative. As I
| said, for now Red Hat devtoolset is the only solution. When IBM
| discontinued the CentOS project, most people do not understand
| what it means to the OSS community.
|
| (I work for Microsoft. It doesn't stop me to love Linux.)
| tomrod wrote:
| Huh. Could Python switch to Alpine instead of Ubuntu?
| stephencanon wrote:
| Nit:
|
| > Multiplying infinity by any number is defined to be a NaN for
| IEEE 754
|
| No, multiplying infinity by any number other than zero or NaN
| produces an infinity. Multiplying infinity by zero produces a
| NaN.
| mananaysiempre wrote:
| Further nit:
|
| > The calculation was using the HUGE_VAL constant, which is
| defined as an ISO C constant with a value of positive infinity
| [...].
|
| Only if the floating point implementation has infinities, which
| ISO C does not require. C99 also defines INFINITY, but that
| one's also not required to actually be an infinity,
| unfortunately.
|
| More seriously:
|
| > "Nowadays, outside museums, it's hard to find computers which
| don't implement IEEE 754."
|
| AFAIU there are plenty of implementations that either run
| faster without or outright refuse to implement the "gradual
| underflow" semantics, which 754 technically requires with no
| equivocation. (Wikipedia tells me the Intel compiler turns on
| SSE "denormals as zeros" when optimizations are on, for
| example.)
| chipsa wrote:
| Infinity is a special type of NaN where the fraction component
| is all 0.
| stephencanon wrote:
| Infinity is not a special type of NaN. Infinity and NaN are
| encoded with the same exponent, but they are distinct
| numerical data.
| Dylan16807 wrote:
| I'm pretty sure that's just a storage optimization and not
| one being a subset of the other.
| klodolph wrote:
| It's not actually a storage optimization. A number is
| either NaN (mantissa != 0) or Inf (mantissa == 0).
| Dylan16807 wrote:
| What's your definition of storage optimization, where
| zero and nonzero mantissas meaning completely different
| things doesn't qualify?
| quietbritishjim wrote:
| I think they meant that having the same exponent, even
| though they are logically different numbers, is a storage
| optimisation.
| quietbritishjim wrote:
| For example: nan==nan is false but inf==inf is true
| klodolph wrote:
| You might think of floating-point numbers coming in five
| varieties:
|
| - normal (exponent not minimum or maximum)
|
| - zero (minimum exponent, mantissa == 0)
|
| - subnormal (minimum exponent, mantissa != 0)
|
| - infinity (maximum exponent, mantissa == 0)
|
| - nan (maxmimum exponent, mantissa != 0)
|
| NaN is only the last category, strictly. Finite is everything
| except infinity and nan. Subnormal and zero are collectively
| denormal. The distinction between "subnormal" and "denormal"
| is a bit esoteric.
| mirekrusin wrote:
| Multiplying infinity by negative number (including negative
| infinity) gives -Infinity, no?
| scatters wrote:
| Well, other than negative zero.
| stephencanon wrote:
| Correct, hence "an infinity" (also, infinity * -0 is NaN).
___________________________________________________________________
(page generated 2022-03-03 23:00 UTC)