Mark Dickinson added the comment:
Eugene's new patch looks good to me; +1 on applying it.
Raymond, do you happen to remember why it was necessary to add the zero-check
in the first place?
--
___
Python tracker
<http://bugs.python.org/is
Mark Dickinson added the comment:
Fixed in 2.7, 3.1, 3.2, 3.3. Closing.
--
resolution: -> fixed
status: open -> closed
versions: +Python 3.1
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
Yes, there's interest (at least here). I've just been really short on
Python-time recently, so haven't found time to review your patch.
--
___
Python tracker
<http://bugs.py
Mark Dickinson added the comment:
I'm going to unassign for now; I still hope to look at this at some point, but
can't see a time in the near future when it's going to happen.
--
assignee: mark.dickinson ->
___
Pyt
Mark Dickinson added the comment:
See:
http://docs.python.org/tutorial/floatingpoint.html
--
nosy: +mark.dickinson
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
I don't think this needs to be documented beyond the limitations of
floating-point that are already documented in the tutorial. It's the obvious
behaviour: double to float (when packing) converts to the nearest float; the
float to double con
Mark Dickinson added the comment:
[Robert]
> I have to disagree. It seems entirely reasonable to expect that
> unpack should return the same value passed to pack.
Robert: notice that a *Python* float (a *64-bit* C double internally) is here
being stored as a *32-bit* float, losing pre
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue11549>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
Fixed in 'default' branch. Note that the regression still exists in 3.2; I'm
not sure that it's worth backporting the two fixes.
--
status: open -> closed
___
Python tracker
<http://
Mark Dickinson added the comment:
I don't see a real problem here: both cmath.sqrt(-1) and (-1)**0.5 are
producing good approximations to the correct result, which is about as much as
you can hope for in general with floating-point algorithms.
I wouldn't want to start special-
New submission from Mark Dickinson :
[From a problem encountered by an EPD user, analyzed by Robert Kern]
There appears to be an
if isinstance(size_or_initializer, (int, long)):
check in the Python 2.x source for multiprocessing.RawArray. As a result, the
following works (as expected
Mark Dickinson added the comment:
Duplicate of issue 11673 :-)
--
resolution: -> duplicate
superseder: -> RawArray does not accept long
___
Python tracker
<http://bugs.python.org/i
Changes by Mark Dickinson :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11672>
___
___
Python-bugs-list mailing list
Unsubscri
Mark Dickinson added the comment:
Thanks for the patch.
Are there practical cases where the operator.index check is more useful that
the isinstance(..., (int, long)) check that you originally proposed
(off-tracker)? While I agree that it's the right fix in principle, the
operator.
Changes by Mark Dickinson :
--
assignee: -> mark.dickinson
stage: -> commit review
___
Python tracker
<http://bugs.python.org/issue11673>
___
___
Pyth
Changes by Mark Dickinson :
--
nosy: +jnoller
___
Python tracker
<http://bugs.python.org/issue11673>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Mark Dickinson :
The documentation for the multiprocessing module says:
"If size_or_initializer is an integer, then it determines the length of the
array, and the array will be initially zeroed. "
But the part about the array being zeroed doesn't seem to b
Mark Dickinson added the comment:
Since this behaviour seems to have been present since at least Python 2.6, it's
tempting to call this a documentation bug.
--
___
Python tracker
<http://bugs.python.org/is
Mark Dickinson added the comment:
Here's a patch that adds zeroing.
--
keywords: +patch
Added file: http://bugs.python.org/file21400/issue11675.patch
___
Python tracker
<http://bugs.python.org/is
Mark Dickinson added the comment:
> The practical case I was thinking of was numpy integer scalar types
Hmm, true. But at least numpy.int instances pass an isinstance(..., int)
check, right? But that still leaves numpy.int as a
problem on 32-bit systems and Windows, and similarly for
Mark Dickinson added the comment:
As Daniel says, from_float expects a float object, not a Decimal instance.
What did you want to achieve in the following line:
self.from_float(value * decimal.Decimal(1.0))/decimal.Decimal(1.0)
?
By the way: in all current versions of Python, from_float
Changes by Mark Dickinson :
--
assignee: -> mark.dickinson
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python
Changes by Mark Dickinson :
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Mark Dickinson :
--
title: Remove unneeded "context" pointer from getters and setters ->
test___all__
___
Python tracker
<http://bugs.pyth
Changes by Mark Dickinson :
--
title: test___all__ -> Remove unneeded "context" pointer from getters and
setters
___
Python tracker
<http://bugs.pyth
Changes by Mark Dickinson :
--
assignee: -> mark.dickinson
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: -> behavior
___
Python tracker
<http://bugs.pyt
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue1446619>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
Patch looks good to me. Thanks!
--
assignee: -> mark.dickinson
___
Python tracker
<http://bugs.python.org/issue9696>
___
_
Mark Dickinson added the comment:
Patience! I'm getting there...
--
___
Python tracker
<http://bugs.python.org/issue9696>
___
___
Python-bugs-list m
Mark Dickinson added the comment:
> I'm sorry, I wasn't hurrying you. Just wanted to make sure you know.
No problem :-). Thanks for the fix!
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue11734>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
I've only glanced at the patch, but a couple of things:
(1) It looks as though the patch assumes that a C double is IEEE 754 binary64
format, and that a C float is IEEE 754 binary32 format. Is that correct?
If so, that's a significant break with
Mark Dickinson added the comment:
> There's no disagreement, since they're different cases. [...]
What he said.
> Should I change the _PyFloat_Pack4 implementation while I'm in there?
No; let's keep the patch as simple as possible. We can open a separate i
Mark Dickinson added the comment:
> Is the failure to round-to-even only for legacy formats, or is it for
> IEEE formats as well?
Ah; I see it's just for the non-IEEE formats, so not really an issue. When
the float format is known, the code just depends on a (float) cast doing
Mark Dickinson added the comment:
> I'd also suggest adding some more to the test suite here to verify that >
> ties are rounding to the nearest even properly.
And I second this suggestion.
--
___
Python tracker
<http://bugs.pyth
Mark Dickinson added the comment:
See also issue 3724.
I'm -0 on this: between log(x, 2) and int.bit_length, there's not much need
for log2. log(x, 2) should be plenty accurate enough for most numerical needs;
the exception is when you're taking log base 2 of an int
Mark Dickinson added the comment:
Raymond: just curious---why do you ask? Did this fix break something?
--
___
Python tracker
<http://bugs.python.org/issue10
Mark Dickinson added the comment:
> We can provide log2() only if the C library has this function.
Big -1 from me: I'd hate to see working Python scripts written on Unix fail on
Windows because of a missing log2.
--
___
Python tracke
Mark Dickinson added the comment:
Rather than reinventing the wheel, it may be worth looking at what numpy does
here.
--
___
Python tracker
<http://bugs.python.org/issue11
Mark Dickinson added the comment:
> it may be worth looking at what numpy does here.
... or it may not. NumPy just uses (approximation to 1/log(2)) * log(x) when
log2 doesn't already exist. And indeed, on Windows:
Python 2.7.1 |EPD 7.0-2 (64-bit)| (r271:86832, Dec 2 2010, 10:23:
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue11892>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue11945>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue11949>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
> sqrt(-0.0) to return -0.0. Does anyone know what the relevant standard says?
sqrt(-0.0) should indeed be -0.0, according to IEEE 754.
--
___
Python tracker
<http://bugs.python.org/issu
Mark Dickinson added the comment:
Alexander,
There are lots of almost-equality tests in the test-suite already, between
test_math, test_float, test_cmath and test_complex. Do you need to implement
another one here, or can you reuse one of the existing ones
Mark Dickinson added the comment:
Would you want x >> 2 to be equivalent to x / 4.0 or x // 4.0?
--
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
> The only way to do that now is t=frexp(x) and y=ldexp(t[0],t[1]+2).
What's wrong with the more direct ldexp(x, 2)?
N.B. There *are* edge cases where Martin's suggested alternative won't work.
E.g., to compute 1e-300 * 2**1500:
>
Mark Dickinson added the comment:
Here's a patch implementing log2. Still to do: use the system log2 where
available.
--
keywords: +patch
Added file: http://bugs.python.org/file21861/issue11888.patch
___
Python tracker
<http://bugs.py
Mark Dickinson added the comment:
I was thinking of something like the rAssertAlmostEqual method in test_cmath.
--
___
Python tracker
<http://bugs.python.org/issue11
Mark Dickinson added the comment:
I believe that this was a deliberate design decision, though now that I look it
seems it's not well documented. That should probably be fixed, so I see this
as a documentation issue.
More details:
The specification on which the decimal module is
Mark Dickinson added the comment:
The doc change should also note that // and divmod suffer from a similar
mismatch:
>>> Decimal(-2) // Decimal(3)
Decimal('-0')
>>> -2 // 3
-1
>>> -2.0 // 3
-1.0
However, the invariant that x = x // y * y
Changes by Mark Dickinson :
--
nosy: +eric.smith, mark.dickinson
___
Python tracker
<http://bugs.python.org/issue12014>
___
___
Python-bugs-list mailing list
Unsub
Mark Dickinson added the comment:
Thanks, Victor. I suspect we're going to need to be a bit more careful,
though: when the extra tests were added for math.log, it turned out that it
had all sorts of strange special-case behaviour on various platforms.
So I suspect that even on plat
Mark Dickinson added the comment:
Thanks, Victor. You caught me by surprise a bit: I had some more minor
changes to that patch pending, so I've committed those separately.
Any news from the buildbots?
--
___
Python tracker
Mark Dickinson added the comment:
> You know what? Mac OS X log2 is less accurate than Python log2!
That doesn't surprise me much. Though it's probably still true that log2 from
OS X is more accurate than our log2 for some other values. It's just that
getting the answer
Mark Dickinson added the comment:
One other thought: we should check that it's not pow that's at fault here,
rather than log2. The test uses math.log2(2.0**n). It would probably be
better off using math.log2(ldexp(1.0, n)), or similar: the libm pow operation
is also not
Mark Dickinson added the comment:
Okay, thanks. We should still be using ldexp rather than 2.0**... in the
tests, though; I've fixed this, and also fixed the incorrect (too small) range
for those tests, so that all representable powers of 2 are now co
Mark Dickinson added the comment:
Grr. Got the issue number wrong in the commit message; see msg135584.
New changeset 1f23d63b578c by Mark Dickinson in branch 'default':
Issue #11188: In log2 tests, create powers of 2 using ldexp(1, n) instead of
the less reliable 2.
Changes by Mark Dickinson :
--
Removed message: http://bugs.python.org/msg135584
___
Python tracker
<http://bugs.python.org/issue11188>
___
___
Python-bugs-list m
Mark Dickinson added the comment:
Please upgrade: this issue is already fixed in current versions of Python.
--
nosy: +mark.dickinson
resolution: -> out of date
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
(Duplicate of issue 7070.)
--
___
Python tracker
<http://bugs.python.org/issue12052>
___
___
Python-bugs-list mailing list
Unsub
Mark Dickinson added the comment:
Thanks, Roumen. Fixed.
--
___
Python tracker
<http://bugs.python.org/issue11888>
___
___
Python-bugs-list mailing list
Unsub
Mark Dickinson added the comment:
Victor, what do you think about simply #undefining HAVE_LOG2 on Tiger (e.g. in
pyport.h), so that the fallback log2 version is used there instead of the
system version?
Does anyone know the appropriate preprocessor check for OS X <= 10.4? I can
get as
Mark Dickinson added the comment:
Thanks, Victor.
--
___
Python tracker
<http://bugs.python.org/issue11888>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
[Docs]
"If both are numbers, they are converted to a common type."
[Terry]
"In any case, I think it is only true for built-in number types,"
It's not even true for built-in number types. When comparing an int with a
float, it&#x
Changes by Mark Dickinson :
--
superseder: -> except-as in Py3 eats variables
___
Python tracker
<http://bugs.python.org/issue12064>
___
___
Python-bugs-lis
Changes by Mark Dickinson :
--
assignee: mark.dickinson ->
___
Python tracker
<http://bugs.python.org/issue5231>
___
___
Python-bugs-list mailing list
Un
Mark Dickinson added the comment:
Unassigning. Sorry; no time for this at the moment.
--
___
Python tracker
<http://bugs.python.org/issue5231>
___
___
Pytho
Mark Dickinson added the comment:
> I find it convenient to use int(), float() etc. for data validation.
Me too. This is why I'd still be happiest with int and float not accepting
non-ASCII digits at all. (And also why the recent suggestions to allow extra
underscores in int a
Mark Dickinson added the comment:
It seems we're getting a bit off-topic for the issue title; the discussion
about cleaning up test_math (which I agree would be a good thing to do) should
probably go into another issue.
On the issue itself, I'm -1 on making comparisons with
Mark Dickinson added the comment:
> Therefore making <, >, etc. raise on NaN while keeping the
> status quo for != and == would bring Python floats closer to
> compliance with IEEE 754.
Not so. Either way, Python would be providing exactly 10 of the 22 required
IEEE 754 compar
Mark Dickinson added the comment:
Yes, I agree. Do you have a patch? I guess the only mildly tricky part here
is making sure that the patch doesn't cause fma(2, 3, snan) (for example) to
raise.
--
___
Python tracker
<http://bugs.py
Mark Dickinson added the comment:
> cause fma(2, 3, snan) ...
Gah! That was nonsense. Please ignore.
--
___
Python tracker
<http://bugs.python.org/issu
Mark Dickinson added the comment:
Thanks for the report; I'll try to find some time to look at this.
This isn't the first time that I've thought that it might be better just to
abandon the aim of getting correctly-rounded results for pow.
--
assignee: -&
Changes by Mark Dickinson :
--
type: compile error -> feature request
versions: +Python 3.3 -Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issu
Mark Dickinson added the comment:
I think this is something that should be brought up for wider discussion on the
python-dev mailing list. It may be that people are ready to allow those
leading zeros for Python 3.3 or 3.4.
--
nosy: +mark.dickinson
Mark Dickinson added the comment:
Well, I'd personally like to see those leading zeros accepted at some point in
Python's future, for the sake of cleanliness and consistency. Not just
consistency with int(), but also e.g. with float literals:
>>> 0050.
50.0
>>
Mark Dickinson added the comment:
> Table 5.2 referenced above lists 10 operations, four of which (>, <,
> >=, and <=) are given spellings that are identical to the spellings of
> Python comparison operators.
Yep, those are included amongst the "various ad-hoc
Mark Dickinson added the comment:
> Prof. Kahan states that nan < x must signal.
Would that be the sentence that starts "In the syntax of C ..." ?
--
___
Python tracker
<http://bugs.py
Mark Dickinson added the comment:
> keep naive implementation of builtin max()
Agreed.
> provide symmetric float.max such that nan.max(x) = x.max(nan) = x (nan
> result would be a valid but less useful alternative.)
That might be viable (a math module function might also make s
Mark Dickinson added the comment:
> What is the reason to make them quiet for floats other
> than backward compatibility?
For me, none. I'll happily agree that, all other things being equal, it's more
natural (and more consistent with other languages) to have < correspon
Mark Dickinson added the comment:
On the idea of a warning, I don't really see the point; I find it hard to
imagine it's really going to catch many real errors.
--
___
Python tracker
<http://bugs.python.o
Mark Dickinson added the comment:
> This is just sophistry. If Python was more popular than C at the
> time Prof. Kahan wrote this, he would write "in the syntax of Python."
I doubt it. C has a standard that explicitly states that < must signal on
comparison with Na
Mark Dickinson added the comment:
Hmm, okay. Call me +0 on the warning.
--
___
Python tracker
<http://bugs.python.org/issue11949>
___
___
Python-bugs-list mailin
Mark Dickinson added the comment:
> and it's dishonest to claim it is.
This language was going too far, and I apologise for it. I think I need one of
those 'wait 5 minutes before allowing you to post' controls.
--
keywords: +gsoc
Mark Dickinson added the comment:
It does look as though all the arguments were pretty thoroughly hashed out on
the python-3000 list when this was first proposed. See e.g., the thread
starting at:
http://mail.python.org/pipermail/python-3000/2007-March/006262.html
and various follow-on
Mark Dickinson added the comment:
It turns out that this is as simple as moving the _convert_other call to the
top of the Decimal.fma method. (For some reason I was confusing this with the
subtleties involved in making sure that an InvalidOperation arising from the
multiplication part of
Mark Dickinson added the comment:
I wouldn't risk changing the exception type in 2.7. It's fine for 3.2.
--
___
Python tracker
<http://bugs.python.o
Mark Dickinson added the comment:
Hmm. Does anyone remember the reason for making sNaNs unhashable in the first
place. I recall there was a discussion about this, but can't remember which
issue.
--
___
Python tracker
<http://bugs.py
Mark Dickinson added the comment:
Ah, now I remember: making sNaNs hashable has the potential to introduce
seemingly random exceptions with set and dict operations. The logic went
something like:
(1) if sNaNs are hashable, you can put them in dicts,
(2) operations on dicts make equality
Mark Dickinson added the comment:
[Stefan]
> ... a direct request to raise an exception...
Understood; the issue is that this conflicts with the general expectation that
equality (and inequality) comparisons always work (at least, for objects that
are perceived as immutable). I think th
Mark Dickinson added the comment:
Grr. Horrible formatting on that last comment.
Sorry about that.
Anyway, I'd be interested to hear other people's opinions.
--
___
Python tracker
<http://bugs.python.o
Mark Dickinson added the comment:
> Force it to export that 'round' symbol in the core, perhaps?
Sure. That might involve first understanding why it's not being exported.
That's where I'm a bit stuck, especially without a Solaris system to test on.
If someone c
Mark Dickinson added the comment:
Fixed in r86552. Thanks!
--
assignee: -> mark.dickinson
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python
Mark Dickinson added the comment:
This should now be fixed in r86553. If you have a chance to test and report
back, that would be great!
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> pending
___
Python track
Mark Dickinson added the comment:
Questions:
(1) Did you run the unittests on Windows? I think there are stronger
requirements for pickleability there.
(2) What specific security issues do you anticipate from pickling the
authentication key?
--
nosy: +mark.dickinson
Mark Dickinson added the comment:
Here's a patch (targeting 3.3) for allowing whitespace around the central
binary operator; it implements the grammar suggested in msg115163.
--
assignee: -> mark.dickinson
Added file: http://bugs.python.org/file19733/issue95
Mark Dickinson added the comment:
Grr. Some unintended cut-and-paste duplication there.
--
Added file: http://bugs.python.org/file19740/float_builtin_doc.patch
___
Python tracker
<http://bugs.python.org/issue10
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file19739/float_builtin_doc.patch
___
Python tracker
<http://bugs.python.org/issue10488>
___
___
Pytho
New submission from Mark Dickinson :
The docs for 'float' are outdated, and also not entirely written in English. :-)
Here's a patch.
--
assignee: d...@python
components: Documentation
files: float_builtin_doc.patch
keywords: patch
messages: 121910
nosy: d...@python,
401 - 500 of 6463 matches
Mail list logo
