On Tuesday, July 19, 2016 at 9:12:57 AM UTC+5:30, Steven D'Aprano wrote: > On Mon, 18 Jul 2016 08:15 pm, Chris Angelico wrote: > > > On Mon, Jul 18, 2016 at 8:00 PM, Marko Rauhamaa wrote: > >> Python programmers (among others) frequently run into issues with > >> surprising results in floating-point arithmetics. For better or worse, > >> Scheme has tried to abstract the concept. You don't need to explain the > >> ideas of IEEE 64-bit floating-point numbers or tie the hands of the > >> implementation. Instead, what you have is "reliable" arithmetics and > >> "best-effort" arithmetics, a bit like TCP is "reliable" and UDP is > >> "best-effort". > > > > The problem with that is that failing to explain IEEE floating point > > and just calling it "inexact" scares people off unnecessarily. I've > > seen a lot of very intelligent people who think that you should never > > compare floats with the == operator, because floats randomly introduce > > "inaccuracy". > > Yes, this. "Never compare floats for equality" is a pernicious myth that > won't die.
In this context, I asked Chris: > I dont know what point you are trying to make > Here is behavior. Should one use == ?? As often happens between me and Chris I ask a ‘why’ (in this case ‘what’) question. And he gives a ‘how’ answer So I again ask: You say «"Never compare floats for equality" is a pernicious myth» Given that for Chris’ is_equal we get is_equal(.1+.1+.1, .3) is True whereas for python builtin == its False What (non)myth do you suggest for replacement? [Note I am not arguing for the goodness of his is_equal] Analogy: Mutable default parameters are a source of problem and confusion. No A says. One can use them to simulate statics No B says No problem as long as you make sure there is no mutation to the mutable, either inside or outside the function. Sure thats all true. However "Module-globals” is a simpler answer than A And “DON’T” is simpler than B So awaiting your preferred myth-ology… -- https://mail.python.org/mailman/listinfo/python-list
