On Sun, Oct 18, 2009 at 11:46 PM, Antoine Pitrou wrote:
> Sure, but it's no different than doing, e.g.:
> list(range(1)).sort()
>
> (don't try this, it just made by computer slow down to a crawl and I had to
> kill
> -9 the Python interpreter)
Maybe you were running out of RAM? On a
On Sun, Oct 18, 2009 at 9:01 PM, Antoine Pitrou wrote:
> Can we remove this check, or are there people doing million-digits
> calculations
> they want to interrupt using Control-C ?
By the way, here's an example of an *almost* real-life use of million digit
calculations.
For an elementary numb
On Mon, Oct 19, 2009 at 9:58 PM, Tim Peters wrote:
> Don't want to hijack this thread, but this is the kind of use case
> justifying keeping the 3-argument pow in the decimal module. People
> "playing" with number theory questions can learn a bag of tricks to
> worm around that non-decimal arithm
On Tue, Oct 20, 2009 at 11:49 AM, Nick Coghlan wrote:
> Mark Dickinson wrote:
>> This high-precision inefficiency could easily be fixed by
>> using a dedicated 'decimal natural number' extension
>> type for the Decimal coefficient, stored internally in
On Tue, Oct 20, 2009 at 3:50 PM, Eric Smith wrote:
>> The code was working a few months ago (with all Decimal tests
>> passing), but there have been some changes and bugfixes since
>> then. I might try to resurrect that code, dropping the _Decimal type and
>> just concentrating on Deccoeff.
>
> M
On Tue, Oct 20, 2009 at 2:15 PM, Stefan Krah wrote:
> 1. Are you generally in favour of a C decimal module in Python?
I'm certainly interested in the general idea; whether I'd be in favour
of replacing decimal.py with a particular C version would depend on
a lot of factors, with code quality, in
On Wed, Oct 21, 2009 at 11:37 AM, Nick Coghlan wrote:
> As far as decimal.py in particular goes, there are significant
> maintenance gains in keeping a lot of the non-performance critical
> context management code in pure Python. So we're likely to wait and see
> how much speed Mark can wring out
On Wed, Oct 21, 2009 at 4:05 PM, Antoine Pitrou wrote:
> Mark Dickinson gmail.com> writes:
>> BTW, does anyone know the current SLOC count for py3k?
>
> Here you are, generated using David A. Wheeler's 'SLOCCount':
> [...]
Thanks, Antoine! With SLOCCount
Would it be worth spending some time discussing the buildbot situation
at the PyCon 2010 language summit? In the past, I've found the
buildbots to be an incredibly valuable resource; especially when
working with aspects of Python or C that tend to vary significantly
from platform to platform (for
On Mon, Oct 26, 2009 at 7:56 PM, Guido van Rossum wrote:
> I'm beginning to think maybe adding a method to a built-in object type
> *should* fall under the moratorium.
Another possible test case for this decision is the int.from_bytes and
int.to_bytes methods, proposed a while ago, and implemente
On Sat, Oct 31, 2009 at 9:47 PM, Brett Cannon wrote:
> Just wanted to publicly thank everyone who has been causing all the
> checkins to fix and stabilize the test suite (I think it's mostly
> Antoine and Mark, but I could be missing somebody; I'm under a
> deadline so only have marginal higher br
On Fri, Nov 6, 2009 at 3:53 AM, R. David Murray wrote:
> (1) issue 3864: FreeBSD testing hangs consistently. According to the
> ticket this is a FreeBSD bug fixed in 6.4, so an OS upgrade
> on the buildslave would probably solve it.
I think the particular issue mentioned in 386
On Mon, Nov 9, 2009 at 12:21 PM, Stefan Krah wrote:
> I see the point, but Decimal("NaN") does not hash:
>
hash(Decimal("NaN"))
> Traceback (most recent call last):
> File "", line 1, in
> File "/usr/lib/python2.7/decimal.py", line 937, in __hash__
> raise TypeError('Cannot hash a NaN v
On Sun, Nov 8, 2009 at 4:26 PM, Stefan Krah wrote:
> Hi,
>
> in a (misguided) bugreport (http://bugs.python.org/issue7279) I was
> questioning the reasons for allowing NaN comparisons with == and !=
> rather than raising InvalidOperation.
Some quick recent history:
For reference, the current beh
On Mon, Nov 9, 2009 at 10:42 AM, Stefan Krah wrote:
> I can also give a decimal use case where the current behavior is problematic
> A variable initialized to a signaling NaN should always cause an exception.
>
> But this doesn't:
>
> salary = Decimal("sNaN")
> minimum_wage = 1000
> if (salary ==
On Mon, Nov 9, 2009 at 1:01 PM, Mark Dickinson wrote:
> current behaviour comes from the IEEE 854 standard; given the
> absence of helpful information in the Decimal standard, IEEE 854
> is an obvious next place to look. There's an unofficial copy of the
> standard avail
On Mon, Nov 9, 2009 at 1:21 PM, Stefan Krah wrote:
> Antoine Pitrou wrote:
>> (NB: interestingly, float("nan") does hash)
>
>
> I wonder if it should:
>
d = {float('nan'): 10, 0: 20}
0 in d
> True
float('nan') in d
> False
d[float('nan')]
> Traceback (most recent call last):
>
On Mon, Nov 9, 2009 at 5:26 PM, Jasper Lievisse Adriaanse
wrote:
> Hi,
>
> while trying to get Python 2.6 working on OpenBSD/sgi (64-bit port)
> I ran into the following during build:
>
> OverflowError: signed integer is greater than maximum
>
> I ran the command that triggered this by hand with -
On Fri, Nov 13, 2009 at 6:18 PM, Adam Olsen wrote:
> On Mon, Nov 9, 2009 at 06:01, Mark Dickinson wrote:
>> Well, when running in some form of 'non-stop' mode, where (quiet) NaN
>> results are supposed to be propagated to the end of a computation, you
>> certainly
On Fri, Nov 13, 2009 at 9:50 PM, Mark Dickinson wrote:
> And they do: nan != 0 returns False. Maybe I'm missing your point
> here?
Aargh! True! I meant to say True!
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
On Mon, Nov 23, 2009 at 10:44 AM, M.-A. Lemburg wrote:
> Thanks for pointing me to the that ticket.
>
> Looks like Guido already commented on this, so intobject.h could
> be revived in some form.
I'm wondering how a resurrected intobject.h should be used: would
Linux distributors (for example) p
On Sun, Nov 29, 2009 at 6:36 PM, C. Titus Brown wrote:
> On Sun, Nov 29, 2009 at 07:28:50PM +0100, "Martin v. L?wis" wrote:
>> That's not true, see
>>
>> http://www.python.org/dev/buildbot/builders/x86 osx.5 trunk
>
> Ahh! Sorry, was searching for 'mac' somewhere in the string.
>
> Those tests ar
Question: should the CPython source compile cleanly and work
correctly on (mostly ancient or hypothetical) machines that use
ones' complement or sign-and-magnitude to represent signed integers?
I'd like to explicitly document and make use of the following assumptions
about the underlying C implem
On Tue, Dec 1, 2009 at 1:46 PM, "Martin v. Löwis" wrote:
> Mark Dickinson wrote:
>> Question: should the CPython source compile cleanly and work
>> correctly on (mostly ancient or hypothetical) machines that use
>> ones' complement or sign-and-magnitude to re
On Tue, Dec 1, 2009 at 3:32 PM, "Martin v. Löwis" wrote:
>> No, the original question really was the question that I meant to ask. :)
>
> Ok. Then the reference to issue 7406 is really confusing, as this is
> about undefined behavior - why does the answer to your question affect
> the resolution
On Tue, Dec 1, 2009 at 4:08 PM, "Martin v. Löwis" wrote:
>>> I'd rather prefer to explicitly list what CPython assumes about the
>>> outcome of specific operations. If this is just about &, |, ^, and ~,
>>> then its fine with me.
>>
>> I'm not even interested in going this far:
>
> I still am: wit
On Tue, Dec 1, 2009 at 4:17 PM, James Y Knight wrote:
> I think all that needs to be defined is that conversion from unsigned to
> signed, and (negative) signed to unsigned integers have 2's complement
> wrapping semantics, and does not affect the bit pattern in memory.
Yes, I think everything
On Tue, Dec 1, 2009 at 4:47 PM, Alexander Belopolsky
wrote:
>> On Tue, Dec 1, 2009 at 4:17 PM, James Y Knight wrote:
>>> I think all that needs to be defined is that conversion from unsigned to
>>> signed, and (negative) signed to
>>> unsigned integers have 2's complement wrapping semantics, an
On Tue, Dec 1, 2009 at 5:22 PM, Mark Dickinson wrote:
> or a workaround. E.g., for an unsigned long x,
>
> ((x) >= 0 ? (long)(x) : ~(long)~(x))
>
> always gives the appropriate wraparound semantics (I think), assuming
Sorry; should have tested. Try:
((x) <= LONG_MAX ? (
[Mark]
> I'm not sure how to decide which particular consequences
> should be listed, but those for &, |, ^ and ~ could certainly
> be included.
[Martin]
> It should give the CPython contributors an indication what kind
> of code would be ok, and which would not. Perhaps it should include
> both a
On Thu, Dec 3, 2009 at 11:33 AM, Antoine Pitrou wrote:
> Eric Smith trueblade.com> writes:
>>
>> But in trunk, the value is just used as-is. So when formating a decimal,
>> for example, '\xc2\xa0' is just inserted into the result, such as:
>> >>> format(Decimal('1000'), 'n')
>> '1\xc2\xa'
>>
On Sat, Dec 5, 2009 at 11:18 AM, Stefan Krah wrote:
> Hi,
>
> I'm in the process of implementing formatting in my C-decimal module.
> Since testing is quite time consuming, I would appreciate a binding
> decision on how the following should be formatted:
>
from decimal import *
format(fl
On Sat, Dec 5, 2009 at 1:18 PM, wrote:
>
> >>> format(Decimal(1234), '020,g')
> '0,000,000,000,001,234'
> >>> format(Decimal(1234), '0=20,g')
> '0001,234'
>
> Why in the world would you ever want to insert commas as separators and not
> use them consistently?
So should co
I'd like to request that Stefan Krah be granted commit privileges to the Python
svn repository, for the sole purpose of working on a (yet to be created)
py3k-decimal-in-c branch.
Stefan has produced a C library 'libmpdec' implementing (fast!) arbitrary
precision decimal arithmetic, together with a
On Mon, Dec 14, 2009 at 8:20 PM, Antoine Pitrou wrote:
> Mark Dickinson gmail.com> writes:
>> I'd like to request that Stefan Krah be granted commit privileges to the
>> Python
>> svn repository, for the sole purpose of working on a (yet to be created
In Python 2.7, PyArg_ParseTuple and friends currently accept a float
argument where an integer is expected, but produce a
DeprecationWarning in this case. This can be seen in various places
in Python proper:
>>> itertools.combinations(range(5), 2.0)
__main__:1: DeprecationWarning: integer argumen
What are the current plans for PEP 328 (the absolute imports PEP) in Python 2.x?
The PEP says:
"""In Python 2.6, any import statement that results in an
intra-package import will raise DeprecationWarning (this also applies
to from <> import that fails to use the relative import syntax). In
Python
On Tue, Feb 2, 2010 at 1:20 PM, Eric Smith wrote:
> Mark Dickinson wrote:
>>
>> What are the current plans for PEP 328 (the absolute imports PEP) in
>> Python 2.x?
> Not sure about the decision one way or the other. But if there's not going
> to be a 2.8, and i
On Tue, Feb 16, 2010 at 9:19 PM, David DiCato wrote:
> I have a minor concern about certain corner cases with math.hypot and
> complex.__abs__, namely when one component is infinite and one is not a
> number.
> as well, and FWIW, I personally agree with this convention. However, the
> math modu
On Tue, Feb 16, 2010 at 10:46 PM, Steven D'Aprano
> What's the justification for that convention? It seems wrong to me.
It's difficult to do better than to point to Kahan's writings. See
http://www.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
and particularly the discussion on page 8 t
On Tue, Feb 16, 2010 at 11:06 PM, Mark Dickinson wrote:
> and particularly the discussion on page 8 that starts "Were there no
> way to get rid of NaNs ...". I don't think it covers hypot, but the
Whoops. I should have reread that article myself. The behaviour of
hypot *i
[With apologies for Steven for the duplicate email.]
On Wed, Feb 17, 2010 at 12:22 PM, Steven D'Aprano wrote:
> Well, who am I to question Kahan?
Yes, there I go with the argument from authority. But while we
shouldn't instantly accept Kahan's arguments just because he's Kahan,
it would be equa
On Fri, Feb 26, 2010 at 4:51 AM, Meador Inge wrote:
>
> Recently some discussion began in the issue 3132 thread
> (http://bugs.python.org/issue3132) regarding
> implementation of the new struct string syntax for PEP 3118. Mark Dickinson
> suggested that I bring the discussion on
On Sun, Feb 28, 2010 at 1:39 AM, Greg Ewing wrote:
> Meador Inge wrote:
>
>> Even with the user-defined precision capabilities of the 'Decimal' class?
>> In other words, can I create an instance of a 'Decimal' that behaves (in
>> all operations: arithmetic, comparison, etc...) exactly as the exte
Hello all,
Currently in Python 2.x, Decimal-to-float comparisons behave as follows:
>>> Decimal(1) < float(4)
False
>>> Decimal(4) < float(1)
False
That is, any Decimal sorts before any float (though this is arbitrary:
it's possible that on some implementations any float sorts before any
Decima
On Tue, Mar 16, 2010 at 2:58 PM, Facundo Batista
wrote:
> On Tue, Mar 16, 2010 at 9:41 AM, Mark Dickinson wrote:
>
>> On the one hand there's something to be said for maintaining a clean
>> separation between the float and Decimal types, allowing only explicit
>>
On Tue, Mar 16, 2010 at 3:58 PM, P.J. Eby wrote:
> At 09:58 AM 3/16/2010 -0500, Facundo Batista wrote:
>>
>> I'm +0 to allow these comparisons, being "Decimal(1) < .3" the same as
>> "Decimal(1) < Decimal.from_float(.3)"
>
> Does Decimal.from_float() use the "shortest decimal representation"
> app
On Tue, Mar 16, 2010 at 4:11 PM, Mark Dickinson wrote:
[...]
>>>> Decimal.from_float(1.1) == 1.1
> False
Whoops. To clarify, this is the pre-patch behaviour; post-patch,
this gives True.
Mark
___
Python-Dev mailing list
Python-Dev@
On Tue, Mar 16, 2010 at 4:18 PM, Victor Stinner
wrote:
> If comparaison of Decimal and float can have "unpredictable" result, I would
> suggest the same behaviour (raise an error).
Well, it's not really `unpredictable': the new behaviour is perfectly
predictable and sane, provided only that you
On Tue, Mar 16, 2010 at 4:41 PM, Guido van Rossum wrote:
> I'd say if you're not going to forward-port this to Python 3, it
> shouldn't go into Python 2 -- in that case it would make more sense to
> me to back-port the exception-raising behavior.
That's also a possible solution, and the one that
On Tue, Mar 16, 2010 at 10:16 PM, Greg Ewing
wrote:
> Mark Dickinson wrote:
>>
>> On Tue, Mar 16, 2010 at 3:58 PM, P.J. Eby wrote:
>>
>>> If not, it might be confusing if a number that prints as '.1' compares
>>> unequal to Decimal('.1&#x
On Tue, Mar 16, 2010 at 10:32 PM, Steven D'Aprano wrote:
> On Wed, 17 Mar 2010 03:23:30 am Mark Dickinson wrote:
>> On Tue, Mar 16, 2010 at 4:11 PM, Mark Dickinson
>> wrote: [...]
>>
>> >>>> Decimal.from_float(1.1) == 1.1
>> >
>> > Fa
On Wed, Mar 17, 2010 at 12:36 AM, Raymond Hettinger
wrote:
>
> On Mar 16, 2010, at 9:41 AM, Guido van Rossum wrote:
>>
>> Also supporting comparisons but not other mixed operations is going to
>> be confusing. If you are sticking to that behavior I think mixed
>> comparisons should also be ruled o
On Wed, Mar 17, 2010 at 11:43 AM, Steven D'Aprano wrote:
> Having said all that, I've just re-read the PEP, and spotted a fly in
> the ointment... hash.
>
> If we allow Decimals to compare equal to floats, that presumably implies
> that they need to hash equal. That may be simple enough for intege
On Tue, Mar 16, 2010 at 5:15 PM, Guido van Rossum wrote:
> Definitely some. Stricter comparison rules are a frequent cause of
> problems when code is first ported to 3.x. While you'd think that code
> comparing a float and a Decimal is *already* broken, there's a
> surprising number of situations
On Thu, Mar 18, 2010 at 5:55 PM, Raymond Hettinger
wrote:
> My thought is that intentional mixed compares of float and decimal
> are very rare relative to unintentional cases. IOW, most of the
> time that x (or the user simply doesn't understand what his or her code is
> actually doing). That us
On Thu, Mar 18, 2010 at 9:48 PM, Nick Coghlan wrote:
> Note that even in Py3k there are some fairly serious weirdnesses kicking
> around due to the intransitive nature of numeric equality though:
Yep. My personal favourite is:
>>> from decimal import Decimal as dec
>>> set((1, 1.0, dec(1))) ==
On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson wrote:
> Making hashes of int,
> float, Decimal *and* Fraction all compatible with one another,
> efficient for ints and floats, and not grossly inefficient for
> Fractions and Decimals, is kinda hairy, though I have a couple of
>
On Fri, Mar 19, 2010 at 12:46 PM, Alex A. Naanou wrote:
> A friend of mine stumbled upon the following behavior:
>
>
> ---cut---
>
class A(object): pass
> ...
class B(object):
> ... def __add__(self, other):
> ... print 'B: adding B and %s objects.' % other.__class__.__name__
On Fri, Mar 19, 2010 at 6:43 PM, Terry Reedy wrote:
> On 3/19/2010 2:11 PM, Antoine Pitrou wrote:
>>
>> Raymond Hettinger gmail.com> writes:
>>>
>>> The reason to prefer an exception is that decimal/float comparisons
>>> are more likely to be a programmer error than an intended behavior.
>
> If
On Fri, Mar 19, 2010 at 7:50 PM, Mark Dickinson wrote:
> So the patch
> I've put on the issue tracker is wrong, since it does raise TypeError ...
s/I've put/I have yet to put/
I really shouldn't admit to errors in things that I haven't even been
Just a couple of quick side comments on this; I haven't got my head
around the whole mixed-operations idea yet.
On Fri, Mar 19, 2010 at 9:50 PM, Guido van Rossum wrote:
> There is one choice which I'm not sure about. Should a mixed
> float/Decimal operation return a float or a Decimal?
I'll jus
On Fri, Mar 19, 2010 at 1:17 PM, Case Vanhorsen wrote:
> On Fri, Mar 19, 2010 at 3:07 AM, Mark Dickinson wrote:
>> On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson wrote:
>>> Making hashes of int,
>>> float, Decimal *and* Fraction all compatible with one another,
On Sat, Mar 20, 2010 at 12:10 AM, Greg Ewing
wrote:
> Nick Coghlan wrote:
>>
>> Mark Dickinson wrote:
>
>> It seems to me that given the existing conflation of numeric equivalence
>> and containment testing, going the whole hog and fixing the set
>> member
On Sat, Mar 20, 2010 at 11:41 AM, Paul Moore wrote:
> On 20 March 2010 04:20, Nick Coghlan wrote:
>> In the case of floats and Decimals, there's no ambiguity here that
>> creates any temptation to guess - to determine a true/false result for a
>> comparison, floats can be converted explicitly to
On Sat, Mar 20, 2010 at 3:17 PM, Case Vanhorsen wrote:
> On Sat, Mar 20, 2010 at 4:06 AM, Mark Dickinson wrote:
>> What external modules are there that rely on existing hash behaviour?
>
> I'm only aware of gmpy and SAGE.
>
>> And exactly what behaviour do
On Sat, Mar 20, 2010 at 7:56 PM, Guido van Rossum wrote:
> I propose to reduce all hashes to the hash of a normalized fraction,
> which we can define as a combination of the hashes for the numerator
> and the denominator. Then all we have to do is figure fairly efficient
> ways to convert floats a
On Sat, Mar 20, 2010 at 11:20 PM, Greg Ewing
wrote:
> * Decimal and float really belong side-by-side in the
> tower, rather than one above the other. Neither of them is
> inherently any more precise or exact than the other.
Except that float is fixed-width (typically 53 bits of precision),
while
On Sun, Mar 21, 2010 at 10:50 PM, Greg Ewing
wrote:
> Raymond Hettinger wrote:
>
>> Since decimal also allows arbitrary sizes, all long ints can be
>> exactly represented (this was even one of the design goals
>> for the decimal module).
>
> There may be something we need to clarify here. I've bee
On Mon, Mar 22, 2010 at 5:56 PM, Raymond Hettinger
wrote:
>
> On Mar 22, 2010, at 10:00 AM, Guido van Rossum wrote:
>
> Decimal + float --> Decimal
>
> If everybody associated with the Decimal implementation wants this I
> won't stop you; as I repeatedly said my intuition about this one (as
> op
On Mon, Mar 22, 2010 at 7:00 PM, Raymond Hettinger
wrote:
>
> On Mar 22, 2010, at 11:26 AM, Mark Dickinson wrote:
>>
>> Just for the record, I'd also prefer Decimal + Fraction -> Decimal.
>
>
> Guido was persuasive on why float + Fraction --> float,
>
On Mon, Mar 22, 2010 at 8:02 PM, Pierre B. wrote:
> 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
On Mon, Mar 22, 2010 at 8:33 PM, Raymond Hettinger
wrote:
> While we're on the topic, I think you should consider allowing the Fraction()
> constructor to accept a decimal input.
>
> This corresponds to common schoolbook problems and simple client requests:
> "Express 3.5 as a fraction".
>
>
On Mon, Mar 22, 2010 at 8:44 PM, Guido van Rossum wrote:
> On Mon, Mar 22, 2010 at 12:33 PM, Raymond Hettinger
> wrote:
>> While we're on the topic, I think you should consider allowing the Fraction()
>> constructor to accept a decimal input.
>>
>> This corresponds to common schoolbook problems a
On Tue, Mar 23, 2010 at 12:33 AM, Greg Ewing
wrote:
> Mark Dickinson wrote:
>>
>> It might make sense for
>> Decimal + complex mixed-type operations to be disallowed, for example.
>
> As long as you're allowing Decimal-float comparisons,
> Decimal-complex com
On Tue, Mar 23, 2010 at 12:09 PM, Stefan Krah wrote:
> Facundo Batista wrote:
>> On Fri, Mar 19, 2010 at 5:50 PM, Guido van Rossum wrote:
>>
>> > As a downside, there is the worry that inadvertent mixing of Decimal
>> > and float can compromise the correctness of programs in a way that is
>> > h
On Tue, Mar 23, 2010 at 3:09 PM, Stefan Krah wrote:
> Mark Dickinson wrote:
>> [Stefan]
>> >
>> > strictness 2: current py3k behaviour + pure equality comparisons
>>
>> Can you explain what you mean by "+ pure equality comparisons" here?
>>
On Tue, Mar 23, 2010 at 5:48 PM, Adam Olsen wrote:
> a = Decimal('nan')
> a != a
>
> They don't follow the behaviour required for being hashable.
What's this required behaviour? The only rule I'm aware of is that if
a == b then hash(a) == hash(b). That's not violated here.
Note that containmen
On Tue, Mar 23, 2010 at 6:07 PM, Adam Olsen wrote:
> On Tue, Mar 23, 2010 at 12:04, Mark Dickinson wrote:
>> Note that containment tests check identity before equality, so there's
>> no problem with putting (float) nans in sets or dicts:
>>
>>>>> x
On Wed, Mar 24, 2010 at 5:36 AM, Stephen J. Turnbull wrote:
> Steven D'Aprano writes:
>
> > As usual though, NANs are unintuitive:
> >
> > >>> d = {float('nan'): 1}
> > >>> d[float('nan')] = 2
> > >>> d
> > {nan: 1, nan: 2}
> >
> >
> > I suspect that's a feature, not a bug.
Right: disti
On Wed, Mar 24, 2010 at 11:47 AM, Nick Coghlan
> Interning NaN certainly seems like it should be sufficient to eliminate
> the set/dict membership weirdness.
>
> That is, make it so that the first two lines of the following return
> True, while the latter two lines continue to return False:
>
On Wed, Mar 24, 2010 at 6:26 PM, Alexander Belopolsky
wrote:
> Mark, I wonder if you could describe an algorithm off the top of your
> head that relies on NaN == NaN being false.
>
No, I certainly couldn't! And I often wonder if the original IEEE 754
committee, given 20/20 foresight, would have
[Changing the subject line, since we're way off the original topic]
On Wed, Mar 24, 2010 at 7:04 PM, Alexander Belopolsky
wrote:
> On Wed, Mar 24, 2010 at 2:50 PM, Mark Dickinson wrote:
> ..
>> If Python were to do something different then a naively translated
>>
Slight change of topic. I've been implementing the extra comparisons
required for the Decimal type and found an anomaly while testing.
Currently in py3k, order comparisons (but not ==, !=) between a
complex number and another complex, float or int raise TypeError:
>>> z = complex(0, 0)
>>> z < in
On Wed, Mar 24, 2010 at 8:56 PM, Raymond Hettinger
wrote:
> FWIW, my viewpoint on this is softening over time
> and I no longer feel a need to push for a new context flag.
>
> It is probably simplest for users if implicit coercions didn't come
> with control knobs. We already have Fraction+float-
On Wed, Mar 24, 2010 at 10:30 PM, Alexander Belopolsky
wrote:
> On Wed, Mar 24, 2010 at 6:21 PM, Raymond Hettinger
> wrote:
> ..
>> If we want to be able to reason about our programs,
>> then we need to rely on equality relations being
>> reflexsive, symmetric, and transitive. Otherwise,
>> cont
On Wed, Mar 24, 2010 at 10:36 PM, Alexander Belopolsky
wrote:
> On Wed, Mar 24, 2010 at 6:31 PM, Mark Dickinson wrote:
> ..
>> Neither is necessary, because Python doesn't actually use == as the
>> equivalence relation for containment testing: the actual equival
On Wed, Mar 24, 2010 at 10:52 PM, Alexander Belopolsky
wrote:
> On Wed, Mar 24, 2010 at 6:47 PM, Mark Dickinson wrote:
> ..
>> There's no ideal solution here; IMO, the compromise that currently
>> exists is an acceptable one.
>
> I don't see a compromise.
On Wed, Mar 24, 2010 at 11:11 PM, Alexander Belopolsky
wrote:
> On Wed, Mar 24, 2010 at 7:02 PM, Mark Dickinson wrote:
> ..
>>
>> So if I understand correctly, you propose that float('nan') ==
>> float('nan') return True. Would you also suggest
On Thu, Mar 25, 2010 at 11:22 AM, Nick Coghlan wrote:
> Mark Dickinson wrote:
>> Here's an interesting recent blog post on this subject, from the
>> creator of Eiffel:
>>
>> http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/
>
On Thu, Mar 25, 2010 at 11:22 AM, Nick Coghlan wrote:
> So, I'm specifically putting that proposal on the table for both float
> and Decimal NaNs in Python:
>
> "Not a Number" is not a single floating point value. Instead each
> instance is a distinct value representing the precise conditions th
On Thu, Mar 25, 2010 at 12:36 PM, Jesus Cea wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/25/2010 07:54 AM, Georg Brandl wrote:
>>> float('nan') in [float('nan')]
False
>>>
>>> Sure, but just think of it as having two different nans there. (You
>>> could imagine thin
On Thu, Mar 25, 2010 at 12:39 PM, Jesus Cea 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 wa
On Thu, Mar 25, 2010 at 2:08 PM, Nick Coghlan wrote:
> Jesus Cea 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.
>
> Yes, this is where their "implementable in a hardware circuit" fo
On Thu, Mar 25, 2010 at 2:26 PM, Antoine Pitrou wrote:
> Le Thu, 25 Mar 2010 07:19:24 -0700, Curt Hagenlocher a écrit :
>> Wait, what? I haven't been paying much attention, but this is backwards.
>> There are multiple representations of NaN in the IEEE encoding; that's
>> actually part of the prob
On Thu, Mar 25, 2010 at 2:42 PM, Mark Dickinson wrote:
> On Thu, Mar 25, 2010 at 2:26 PM, Antoine Pitrou wrote:
>> This sounds a bit sophistic, if the (Python) user doesn't have access to
>> the payload anyway.
>
> Well, you can get at the payload using the struct mo
On Thu, Mar 25, 2010 at 3:01 PM, Curt Hagenlocher wrote:
> On Thu, Mar 25, 2010 at 7:54 AM, Mark Dickinson wrote:
>>
>> Hmm. I take it back. I was being confused by the fact that sqrt(nan)
>> returns a nan with a new identity; but it does apparently preserve
>> the
On Thu, Mar 25, 2010 at 3:05 PM, Nick Coghlan wrote:
> Mark Dickinson wrote:
>> On Thu, Mar 25, 2010 at 2:08 PM, Nick Coghlan wrote:
>>> Jesus Cea wrote:
>>>> But IEEE 754 was created by pretty clever guys and sure they had a
>>>> reason for define t
On Thu, Mar 25, 2010 at 1:15 AM, Jeffrey Yasskin wrote:
> On Wed, Mar 24, 2010 at 2:09 PM, Mark Dickinson wrote:
>> Slight change of topic. I've been implementing the extra comparisons
>> required for the Decimal type and found an anomaly while testing.
>> Currently
On Fri, Mar 26, 2010 at 11:16 PM, Raymond Hettinger
wrote:
> Of the ideas I've seen in this thread, only two look reasonable:
> * Do nothing. This is attractive because it doesn't break anything.
> * Have float.__eq__(x, y) return True whenever x and y are
> the same NaN object. This is attra
101 - 200 of 388 matches
Mail list logo
