4 ms·
Every type-inference language I am aware of assumes that anything that looks like a float is a float. It would be un-pythonic to assume that everything that loo
by teilo 10y ago
Every type-inference language I am aware of assumes that anything that looks like a float is a float. It would be un-pythonic to assume that everything that looks like a float is a decimal. Imagine having to cast every damn float to a float.
- dragonwriter 10y agoSince when does an exact decimal literal "look like a float" more than it looks like a decimal?
- paulddraper 10y agoTradition. It was easier for computers and the rest is history.
- teilo 10y agoYeah, I was going to say, "Since computers."
- dragonwriter 10y agoSure, lots but not all (Scheme doesn't, for instance) programming languages treat things that look like decimals as floats as a popular performance-over-correctness optimization, but I don't think that makes an exact decimal representation look like anything but a decimal.
- teilo 10y agoThe Python Decimal class was introduced 10 years ago in version 2.4. That's after Python was 12 years old (from v. 1.0). It is a standard library module, not a first level type. This is not the least unusual. Even Swift, as modern as it gets, operates the same way. You are arguing against a convention that is as deep rooted as CPUs capable of floating point calculations. To this day, there ARE no "decimal" CPU operations. There are integer and float operations.
- dragonwriter 10y agoActually, I am arguing against describing exact decimal representation as something that "looks like a float" (particularly a binary float.) I'm not arguing against Python's behavior. I do think that, at a minimum, there are major and very common software domains where the common optimization is more harmful than beneficial, and that it's good that some languages buck the trend. But while I don't think it should be an unquestioned tradition in language design, I don't think it's categorically wrobg, either. > To this day, there ARE no "decimal" CPU operations First, this isn't true, there are CPUs that have decimal (still floating point, so only exact within a subset of their full range) operations. Second, it's irrelevant; many languages have types (including types for common literals) that don't map to a specialized class of operations in the CPU, where the language compiles operations down to aggregates of operations on some lower level type or types.
- zokier 10y agoSince about 1972 when C adopted that as a convention.
- kazagistar 10y agoIn Haskell: `2.3 :: Fractional t => t` In other words, it can be inferred to be any type that implements the Fractional typeclass, which includes Decimal types. Not that it is relevant here, because you basically need to have types for something like this to work, if you have proper type inference, then you don't need to assume any type, and can just interpret a literal as whatever is needed.