[Python-ideas] Python Float Update

[David Mertz]

Decimal literals are far from as obvious as suggested.  We *have* the
`decimal` module after all, and it defines all sorts of parameters on
precision, rounding rules, etc. that one can provide context for.
 decimal.ROUND_HALF_DOWN is "the obvious way" for some users,
while decimal.ROUND_CEILING is "the obvious way" for others.

I like decimals, but they don't simply make all the mathematical answers
result in what all users would would consider "do what I mean" either.

On Sun, May 31, 2015 at 11:27 PM, Nicholas Chammas <
nicholas.chammas at gmail.com> wrote:

> I don’t know. Personally, I’d be willing to pay a performance penalty
> to avoid reasoning about floating-point arithmetic most of the time,
> then “drop into” floats when I need the speed.
>
> This is perhaps a bit off topic for the thread, but +9000 for this.
>
> Having decimal literals or something similar by default, though perhaps
> problematic from a backwards compatibility standpoint, is a) user friendly,
> b) easily understandable, and c) not surprising to beginners. None of these
> qualities apply to float literals.
>
> I always assumed that float literals were mostly an artifact of history or
> of some performance limitations. Free of those, why would a language choose
> them over decimal literals? When does someone ever expect floating-point
> madness, unless they are doing something that is almost certainly not
> common, or unless they have been burned in the past?
>
> Every day another programmer gets bitten by floating point stupidities
> like this one <http://stackoverflow.com/q/588004/877069>. It would be a
> big win to kill this lame “programmer rite of passage” and give people
> numbers that work more like how they learned them in school.
>
> The competing proposal is to treat decimal literals as decimal.Decimal
> values.
>
> I’m interested in learning more about such a proposal.
>
> Nick
> ​
>
> On Mon, Jun 1, 2015 at 2:03 AM Jim Witschey <jim.witschey at gmail.com>
> wrote:
>
>> On Sun, May 31, 2015 at 11:46 PM, Matthias Bussonnier
>> <bussonniermatthias at gmail.com> wrote:
>> > IIRC (during | after) the language submit at PyCon this year, it was
>> said that maybe the stdlib should get
>> > less features, not more.
>>
>> Rationals (and Decimals) already exist in the standard library. The
>> original proposal (as I read it, anyway) is more about the default
>> interpretation of, e.g., integer division and decimal-number literals.
>>
>> > Side note, Sympy as a IPython ast-hook that will wrap all your integers
>> into SymPy Integers and hence
>> > give you rationals of whatever you like, if you want to SymPy-plify
>> your life.
>>
>> Thank you for the pointer -- that's really cool.
>>
>> > But for majority of use will it be useful ?
>>
>> I believe interpreting "0.1" as 1/10 is more ergonomic than
>> representing it as 1.600000023841858 * (2^-4). I see it as being more
>> useful -- a better fit -- in most use cases because it's simpler, more
>> precise, and more understandable.
>>
>> > What would be the performance costs ?
>>
>> I don't know. Personally, I'd be willing to pay a performance penalty
>> to avoid reasoning about floating-point arithmetic most of the time,
>> then "drop into" floats when I need the speed.
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150601/cbbee853/attachment-0001.html>