Re: [Python-Dev] Mixing float and Decimal -- thread reboot
Sorry to intervene out of the blue, but I find the suggested rule for fractional to decimal conversion not as clean as I'd expect. If fractions are converted to decimals when doing arithmetics, would it be worthwhile to at least provide a minimum of fractional conversion integrity? What I have in mind is the following rule: When doing conversion from fraction to decimal, always generate a whole number of repeating digits, always at least twice. Examples, with a precision of 5 in Decimal: 1/2 -> 0.5 1/3 -> 0.3 1/11 -> 0.090909 # Note that we produced 6 digits, because # the repeating pattern contains 2 digits. 1/7 -> 0.142857142857 # Always at least two full patterns. The benefits I see are that: 1. If a number can be represented exactly it will be converted exactly. 2. The minimum precision requested is respected. 3. The conversion yields something that will convert back more precisely. Not perfectly, but see the next point. 4. Since the repeating pattern is present at least twice at the end, one can augment the precision of the conversion by detecting the repetition and adding more. This detection is trivial. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mixing float and Decimal -- thread reboot
Pierre B. hotmail.com> writes: > > 4. Since the repeating pattern is present at least twice at the end, > one can augment the precision of the conversion by detecting the > repetition and adding more. This detection is trivial. Wrong of me. This point is acutally invalid, since it is impossible to generally differentiate where the pattern ends. The counter example is: 0.177177177177... vs 0.177.1777... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is nan != nan?
Mark Dickinson gmail.com> writes: > > On Thu, Mar 25, 2010 at 12:39 PM, Jesus Cea jcea.es> wrote: > > > > But IEEE 754 was created by pretty clever guys and sure they had a > > reason for define things in the way they are. Probably we are missing > > something. > > Well, if we are, then nobody seems to know what! See the Bertrand > Meyer blog post that was linked to up-thread. The missing part, IMO, is that allowing a given NaN value to compare equal to itself only pushes the problem up one level. Any single operation yielding a NaN will still be unequal to itself. That is, under what is being proposed, with a function func() returning the same result of some calculation: x = func() s1 = (x) print x in s1 print func() in s1 This would print True and False, even though func() is perfoming the same calculation and thus logically returning the same NaN. I think the IEEE NaN represent the fact that you have a number of an undefined set, but it doesn't specify which. The only way out, IMO, is to make *all* NaN comparisons yield False, but identity yield true. No interning necessary. At most, you could make the identity function return False for the different types of NaN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
