nformation.
>>> 0.1 + 0.2
0.30004
>>> 1.23 * 4.64
5.7071999
>>> str(0.1 + 0.2)
'0.3'
>>> str(1.23 * 4.64)
'5.7072'
I don't know whether this makes it worth keeping str different from repr.
Mark
_
On Mon, Oct 12, 2009 at 7:48 PM, Guido van Rossum wrote:
> On Mon, Oct 12, 2009 at 11:41 AM, Mark Dickinson wrote:
>> But str still has some value in py3k: it protects users from
>> accumulated rounded errors produced by arithmetic operations:
> [...]
>
> I kno
ython/compile.c:937: error: ‘z’ undeclared (first use in this function)
Python/compile.c:937: warning: implicit declaration of function
‘PyComplex_AsCComplex’
make: *** [Python/compile.o] Error 1
Mark
Postscript: the above compilation failure is easily fixed. The next
failure is:
gcc -DWITHO
complex type there.
+1 for removing the WITHOUT_COMPLEX define from py3k.
-0 for removing it from trunk.
Mark
___
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
ce of
being correctly rounded (and making it correctly rounded would likely
be prohibitively expensive in terms of code size and complexity). It's
using something like x**y = exp(y*log(x)) behind the scenes, at least
for computing the argument of the result.
For square roots, cm
don't need millions of digits for a single
operation to take a noticeable amount of time: try str(10**10),
for example.
Is there a benefit to removing the check?
Mark
___
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
: O(n) rather than O(n log n)?)
So I'd say that it *is* different. A million digit integer takes less
than half a megabyte of RAM, so a single operation can be
horribly slow long before memory limitations are reached.
I'd prefer to keep the SIGCHECK unless there's a really
compe
first 100 digits takes a good few seconds; the
other operations are faster.
But if you (not unreasonably) try to compute str(p),
you'll find it's impossibly slow, and it's very handy
that it's possible to interrupt that calculation, attempt
to understand *why* it's slow, and t
gt;
Right. Low precision Decimal operations should be fine. I don't
really see the advantage of the second operation over a simple
pow(2, 43112609, 10**100)
though.
By the way, despite the above use-case, and despite the fact
that I use it frequently, I still don't believe 3-argumen
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
coeff type is very simple, though. It would be easy to create
a pure Python version of it, and then do something like:
try:
from _decimal import Deccoeff # try to get C version
except ImportError:
from deccoeff import Deccoeff # else use Python fallback code.
Mark
_
e reason or another? Stefan, do you see yourself
having time to spend on maintenance of this code for the
forseeable future?
BTW, does anyone know the current SLOC count for py3k?
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
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 M
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
back to r7713
(1997-04-02). The original implementation checked by Guido and
attributed to Mark Hammond. So, we should ask Mark why he did that.
The thread seems to be at
http://groups.google.com/group/comp.lang.python/browse_frm/thread/be32478a4b8e77b6/816d6228119a3474
(although I do seem to
my flawed reasoning.
For reference:
#if defined(MS_WINDOWS) && !defined(__BORLANDC__)
/* Due to Mark Hammond and Tim Peters */
static PyObject *
time_clock(PyObject *self, PyObject *unused)
{
static LARGE_INTEGER ctrStart;
static double divisor = 0.0;
LARGE_INTEGER n
On 22/10/2009 3:45 PM, Robert Collins wrote:
On Thu, 2009-10-22 at 15:21 +1100, Mark Hammond wrote:
I'd be very surprised if any applications rely on
the fact that each process starts counting at zero, so if someone can
come up with a high-res counter which avoids that artifact I'd
her projects do?
These are probably the wrong questions; I'm hoping that a discussion
would help produce the right questions, and possibly some answers.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
le ago, and implemented
by Alexandre Vassalotti. See:
http://bugs.python.org/issue1023290
Mark
___
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/arc
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 onl
On 4/11/2009 4:35 AM, Guido van Rossum wrote:
I've checked draft (!) PEP 3003, "Python Language Moratorium", into
SVN. As authors I've listed Jesse, Brett and myself.
Good move, +1.
Cheers,
Mark
___
Python-Dev mailing list
P
7;d really love to see more time devoted to improving the standard
library.
My 2c:-)
--
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy
"Advanced Qt Programming" - ISBN 0321635906
___
en on the buildbots but that doesn't
> seem to be showing up right now (is it fixed?) is issue 7251, which
> Mark is working on.
It's not fixed, but I hope to have time to fix it this weekend. It's just
not showing up on some runs because test_multiprocessing kills the
build
uot;, line 937, in __hash__
> raise TypeError('Cannot hash a NaN value.')
> TypeError: Cannot hash a NaN value.
I think that may represent an excess of caution. float nans do hash quite
happily, and I can't see a good reason for preventing Decimal nans from
having a hash.
issues emerge from the brief discussion:
>
> 1. Should the comparison operators follow the 'compare' function
> from the standard?
That's a possibility. But see below.
> 2. What is the use of == and != outside the decimal scope?
>
> Mark mentions that Python use
gt; minimum_wage = 1000
> if (salary == minimum_wage):
> print "do stuff"
> else:
> print "do other stuff"
Hmm. This does look suspicious. It's possible we should be raising
for signalling nans here. For most of what I wrote above I was thinking
of qui
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
14:47:39)
[GCC 4.2.1 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> nan = float('nan')
>>> d = {nan: 10, 0: 20}
>>> nan in d
True
>>> d[nan]
10
Mark
___
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
--with-pydebug configure
option for this.)
Mark
___
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
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
to hold corresponding
> C code, e.g. to provide compatibility wrappers of new APIs that
> implement different semantics in 3.x.
This is also an interesting idea.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
since there are significant differences: most obviously, the
default build on 10.6 is an LP64 build.
I'm not seeing the test_distutils failure you report on my own
10.5 machine, for some reason.
Mark
___
Python-Dev mailing list
Python-Dev@python.
' complement
and sign-and-magnitude machines in mind. That's certainly feasible,
but it seems silly to do such a rewrite without a good reason.
Python-dev agreement that ones' complement machines should be
supported would, of course, be a good reason.
Mark
__
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
ot a trap representation
- conversion from an unsigned type to a signed type wraps modulo
2**(width of unsigned type).
(Though I think these assumptions do in fact completely determine
the behaviour of &, |, ^, ~.)
As far as I know these are almost universally satisfied for curren
ist of assumptions is easier to check
directly for any given implementation: it corresponds
exactly to items 2 and 4 in C99 J.3.5, and any conforming
C implementation is required to explicitly document how it
behaves with regard to these items.
I'm not sure how to decide which particular conseque
is the
> operation of the cast operators, and it seems to me that it implies the other
> requirements.
Agreed.
Thanks,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail
either used a direct cast
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
two's complement with no trap representation.
Mark
___
Pyth
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
t
I can see:
format(Decimal('1000'), '06n').decode('utf-8') gives a string of length 5
format(Decimal('1000'), u'06n') fails with a UnicodeDecodeError.
Mark
___
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
are inserted:
Python 3.2a0 (py3k:76671, Dec 4 2009, 18:55:54)
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> format(float(1234), '0=20,g')
'0,000,00
020,g'. Why would you use '0=20,g' instead? I'm not sure
that the 'X=...' notation was intended to be used for zero padding.
Mark
___
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
fully integrated into the branch, and we have some timings
and benchmarks to show the performance benefit. There are also various
other questions about a C version of decimal that will eventually need to
addressed, but I don't want to distract from the main point of this message.)
Mark
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
really looking for properties specific
to the operating system (eg, the location of the start menu, desktop,
appdata folders etc) I don't think they belong in this PEP; they are a
property of the OS install/version, not of the specific Python
install/vers
On 15/12/2009 2:42 PM, David Lyon wrote:
On Tue, 15 Dec 2009 14:40:56 +1100, Mark Hammond
wrote:
I think it is fine. If you are really looking for properties specific
to the operating system (eg, the location of the start menu, desktop,
appdata folders etc)
But under windows, an application
On 15/12/2009 3:09 PM, David Lyon wrote:
On Tue, 15 Dec 2009 15:05:18 +1100, Mark Hammond
wrote:
But under windows, an application developer might (as in probably
would) like to install an application in \Program Files\someapp
rather than hidden in the bowels of the python interpretor.
I
porting from
2.x to 3.x. There's a patch at http://bugs.python.org/issue5080
There's one fly in the ointment: the deprecation warning is produced
for all integer codes except for one---the 'L' code. The patch adds a
deprecation warning for this code.
Mark
ble to find anything by searching the archives), or whether
the DeprecationWarning just got forgotten about.
If the latter, should the DeprecationWarning be introduced in 2.7?
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.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
ifficult for them to help resolve that.
Cheers,
Mark
___
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
s the
> documentation should be updated to reflect this.
Yes, it should. Thanks!
Mark
___
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
ut since then, the standards (well, at
least C99 and IEEE 754-2008) have come out in favour of 1**nan == 1.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mai
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
t;> 1e300 ** 2
Traceback (most recent call last):
File "", line 1, in
OverflowError: (34, 'Result too large')
>>> 1e300 * 1e300
inf
Here I'd argue that the ideal Python behaviour would be to produce an
OverflowError in both cases; more generally, arithm
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
can't be
> represented exactly are rounded.
>
> I would be very surprised if there is a way of configuring
> the Decimal type so that it gives identical results to that
> of any IEEE binary floating point type, including rounding
> behaviour, denormalisation, etc.
I'd b
solution to
require an unnecessary amount of work to implement. After exploring
it a bit in the course of those discussions I hope that test-resources
(or something similar, maybe something like junit rules which was also
brought up) makes it into the stdlib at some point as some of the more
l back to the more general add_argument() call, the
wrapper could just handle the usual case (default false, presence of option
sets flag to True). So the signature would be pretty simple - something like:
def add_bool_argument(self, help=None, dest=No
l instances are going to cause similar difficulties to those
above. In practice I think this is much less of an issue than the
float/Decimal problem, since the chance of accidentally combining
Fraction and Decimal types in a calculation seems significantly
smaller than the chance of accidentally combining float and Decimal
types.
--
Mark
___
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
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
>>
social means (e.g., educating the programmer). Any
technical solution that made "Decimal('1.1') == float('1.1')" evaluate
to True would, I suspect, be a cure worse than the original disease.
Mark
___
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
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@
ne, provided only that you remember the basic fact
that float("0.1") is not exactly 0.1.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailm
ut.
Confusing, yes, but at least not bug-prone. The current 2.x behaviour
has provoked complaints from a number of different people in various
different fora (I recently saw this come up on StackOverflow), and
after initially being skeptical I'm now convinced that it w
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
is feature to 2.x if it's
not going to go into 3.x; but I'm convinced enough that the 2.x
behaviour should change that I'd prefer to add it to both 2.x and 3.x
than to neither.
The other option would be to leave 3.x alone and just add a py3k
wa
ore intrusive) alternative would be to come up with
a single sane hash function defined for all rational numbers (plus
infinities and nans), and use this function for int, long, float,
Decimal and Fraction types. I have a candidate function in mind...
Mark
_
ble cause of subtle bugs,
and again would be fixed by the proposed change in behaviour. On the
other hand, I've not seen any reports of anyone encountering this in
real life.
Mark
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
ise an exception, or allow
comparisons) would be an improvement on the current 2.7 behaviour.
Could everyone live with making float<->Decimal comparisons raise an
exception in 2.7?
Mark
[1] http://bugs.python.org/issue2531#msg83691
[2] http://bugs.python.org/issue2531#msg83818
[3] http://bugs
o we really want to preserve strange, unintuitive behaviour like the above?
No. Not really, no. :)
Mark
___
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
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
>
to get a TypeError here, as ints indeed
> have an __add__ method, and they do not know anything about C objects
> (obviously :) ).
Yes: the int.__add__ method is tried first. Since it doesn't know
anything about C objects it returns NotImplemented, and then
C.__radd__ is given a chance to
solution to the original problem that still has 0.0 ==
Decimal(0) evaluating to False isn't much of a solution.
This puts me firmly in the 'make numeric comparisons give the right
answer' camp.
Thanks,
Mark
___
Python-Dev mailing list
Pyth
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
;s working for ints, floats and
Decimals; still need to implement it for Fractions and complex
numbers) and it seems to work just fine, with essentially no more code
than was there before. I'll post a proof-of-concept patch when I've
filled in the missing bits.
Mark
__
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
ng. Was there a discussion on this?
There's PEP 3141 (http://www.python.org/dev/peps/pep-3141/), which was
the motivation for adding the fractions module in the first place, and
there's the issue tracker item for the fractions module
(http://bugs.python.org/issue1682).
Mark
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
compatibly for all numeric types, even large Decimals like the above.
It needs a little tidying up, but it works.
Mark
___
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
n),
while Decimal allows a user-specified, arbitrarily large, precision;
so in that sense the two floating-point types aren't on an equal
footing.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-d
comaprisons exact as well),
else the rule that x == y implies hash(x) == hash(y) would become
untenable. Again, this is the pattern that already exists for
int<->float and Fraction<->float interactions: comparisons are exact,
but arithmetic operations involve a lossy conversion.
Mark
_
intuition about this one (as
> opposed to the other two above) is very weak.
>
> That's my vote.
> I believe Nick chimed-in in agreement.
> Mark, do you concur?
Yes; Decimal + float -> Decimal works for me; the greater flexibility
of the Decimal type is the main plus for me. I
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,
>
ecimal expansion of this fraction has a
period of over 15 million!
Sorry, but this doesn't seem like a feasible or desirable strategy.
Mark
___
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
is both useful and unsurprising.
Sounds fine to me. Fraction already accepts decimal floating-point
strings, so the implementation of this would be trivial (convert to
string, then call the Fraction constructor).
Mark
___
Python-Dev mailing list
Py
7;d failed to notice that! So decimal -> fraction
conversion is implemented twice in the Fractions module---once in
__new__ and once in from_decimal. Hmm.
Mark
___
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
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
'nan') should return False rather than raising an exception.
And the decimal module provides compare and compare_signal for those
who want complete standards-backed control here. Besides, this seems
to me to be an orthogonal issue to the issue of mixing Decimal with
other numeric types.
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?
>>
That's not violated here.
Note that containment tests check identity before equality, so there's
no problem with putting (float) nans in sets or dicts:
>>> x = float('nan')
>>> s = {x}
>>> x in s
True
Mark
___
P
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
So there have to be some
compromises somewhere.
The current compromise at least has the virtue that it doesn't require
special-casing nans anywhere in the general containment-testing and
hashing machinery.
One alternative would be to prohibit putting nans into sets and dicts
by
loats would be to put
the interning code into PyFloat_FromDouble. I'm not sure whether this
would be worth the cost in terms of added code (and possibly reduced
performance, since the nan check would be done every time a float was
returned), but I'd be willing to review a patch.
Mar
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 foresig
[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
>>
601 - 700 of 1370 matches
Mail list logo
