10 ms·
CPython, C standards, and IEEE 754
- stephencanon 5y agoNit: > 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.
- mirekrusin 5y agoMultiplying infinity by negative number (including negative infinity) gives -Infinity, no?
- scatters 5y agoWell, other than negative zero.
- mirekrusin 5y agoTrue :)
- stephencanon 5y agoCorrect, hence "an infinity" (also, infinity * -0 is NaN).
- chipsa 5y agoInfinity is a special type of NaN where the fraction component is all 0.
- Dylan16807 5y agoI'm pretty sure that's just a storage optimization and not one being a subset of the other.
- quietbritishjim 5y agoFor example: nan==nan is false but inf==inf is true
- klodolph 5y agoIt's not actually a storage optimization. A number is either NaN (mantissa != 0) or Inf (mantissa == 0).
- quietbritishjim 5y agoI think they meant that having the same exponent, even though they are logically different numbers, is a storage optimisation.
- Dylan16807 5y agoWhat's your definition of storage optimization, where zero and nonzero mantissas meaning completely different things doesn't qualify?
- klodolph 5y agoZero and nonzero mantissas always mean different things, no matter what the exponent is. I guess I am not sure how this could be described as an optimization... an optimization relative to what? Some hypothetical floating-point format which has extra bits?
- Dylan16807 5y ago> Zero and nonzero mantissas always mean different things, no matter what the exponent is. They don't normally mean different types of value. 4.0000000 and 4.0000001 are just different adjacent numbers. > I guess I am not sure how this could be described as an optimization... an optimization relative to what? Some hypothetical floating-point format which has extra bits? Using the exponent to distinguish, like the format uses for normal/subnormal/nonfinite. Or using extra bits, sure. They took a bit pattern that would have been a NaN if not for Infinity, and used it to store Infinity.
- stephencanon 5y agoInfinity is not a special type of NaN. Infinity and NaN are encoded with the same exponent, but they are distinct numerical data.
- klodolph 5y agoYou 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.
- mananaysiempre 5y agoFurther 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.)
- WalterBright 5y agoI appreciate a guy who knows his NaNs!
- wheelerof4te 5y agoI 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.
- SoylentOrange 5y agoI would stay away from writing any program in C unless it is absolutely 100% necessary for your use case. For example, if you’re working on a large existing C code base like the Linux kernel. There are much better modern alternatives to get comparable speed for new projects. Many projects that used to be written in C are being rewritten in either C++ or Rust for better memory safety and reasoning about the memory model. Disclaimer: I did my PhD (several years ago) in a systems and networking lab and most of the code I wrote was in C. Now for example modern kernel modules tend to be written in Rust if possible, while such an option was not available while I was working there
- pjmlp 5y agoAnd when using C++, for 99% of the use cases it is perfectly fine to leave bounds checking and iterator validation enabled in release code as well.
- eternityforest 5y agoI kinda hate writing real programs in C. The only time it's vaugely enjoyable is with sub 100 line embedded stuff. Otherwise, it's near the bottom of my list of languages I'd like to use. Not actually at the bottom, I'd choose it over Forth and ASM, but.... I haven't written it for anything but a microcontroller in years. I don't really do much outside of Python and JS in general these days. Python's performance is basically the same as C, because... There's already a C extension for everything! I'm really not even a fan of compiled languages in general especially not for open source work. Things like plugin architectures are a lot easier in dynamic everything is a dict type languages. But C sure is good at being ubiquitous! I appreciate the heavy standardization.
- morelisp 5y ago
- jVinc 5y agoWhat 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 5y ago> 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 5y agoLeaving 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.
- DrewRWx 5y agoThis is a very good point. At my workplace we haven't had a 2->3 level project event, but our discussions _are_ always shaped and influenced by not only how previous agreements have worked in practice, but also how previous discussions (and arguments) leading up to those agreements played out. It is to the point that a sizable amount of my value is derived from being having been around long enough with my ear to the ground to be able to recount the logic behind arguments from each side and giving recommendations on how to broach remaining tensions.
- tzot 5y agoAt work we had a very-late-technical-debt-move from “Python 2.7/Django 1.7” to “Python 3.8/Django 3.2” (with lots of associated libraries moving forward too) and we managed to reach a point where our codebase was common and functioning in either environment; the process was… bloody, to say the least, and obviously I wouldn't wish for others to ever have to go through a similar ordeal, but it was feasible. In any case, I don't think that in the Python ecosystem there will ever be another jump of the same magnitude as 2 to 3.
- dec0dedab0de 5y agoI 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.
- Spivak 5y agoI 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 5y agoIn 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.
- mistrial9 5y ago> In CPython 2, a `str` was bytes -- like old C language, a str is really bytes, no encoding is enforced.
- amanzi 5y agoThat would suit me too, but not sure of the wider implications.
- creata 5y agoWhy 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.
- snnn 5y agoI 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 5y agoHuh. Could Python switch to Alpine instead of Ubuntu?
- LukeShu 5y agoThe "manylinux" platform tag definition means GNU libc. musl libc systems are not within the "manylinux" Python platform, they are a separate "musllinux" platform tag. See: PEP 600, PEP 656. While the manylinux infrastructure project may use Alpine to produce "musllinux" binaries, Alpine will never be usable to produce "manylinux" binaries. So Alpine would only be useful in addition to another distro, not instead of another distro.
- snnn 5y agoSee: https://github.com/pypa/manylinux/pull/1135 https://github.com/pypa/manylinux/pull/1135 . Alpine is a supplement. It can't replace the others. It hasn't been widely accepted by the community yet. I believe many python projects are not afforded to replace libc.
- AceJohnny2 5y agoGlad to see Havelock Vetinari, ruler of Ankh-Morpock on Discworld, is such a renaissance man as to contribute insight into standards support of compilers. (see also other prolific pseudonymous Linux contributor "George Spelvin <linux@horizon.net>")
- jart 5y agoI can't believe Python is reluctant to mandate floating-point when they require threads. I'm still on Python 3.6 because there's no simple consistent cross-platform way to do threads via system interfaces.