Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue11734>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Wiebe added the comment:
Taking a look at the patch, I see you're using the single -> half conversion
routine from NumPy. This has the double rounding problem when converting double
-> float -> half, so it would be better to use the double -> half routine. I
implement
Mark Wiebe added the comment:
I think this won't work on Windows since there the 64-bit int is generally
__int64. If you look at the long long and unsigned long long support in
_struct.c you can see a better way to do this: "#ifdef HAVE_LONG_LONG" and
"unsigned PY_LON
Mark Hammond added the comment:
As Tim Roberts says on the python-win32 list:
> Actually, on closer examination, it may be a bit difficult to sell this. The
> Microsoft compilers do not define this symbol at all. The SDK defines
> SSIZE_T (as a long). Nothing defines ssize_
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 Wiebe added the comment:
The patch currently assumes IEEE 754 with byte-order matching the integer type.
I see that pyconfig.h defines three possible cases when IEEE 754 doubles are
supported, DOUBLE_IS_LITTLE_ENDIAN_IEEE754, DOUBLE_IS_BIG_ENDIAN_IEEE754, and
Mark Wiebe added the comment:
There's no disagreement, since they're different cases. Taking an arbitrary
double, rounding to float, then rounding to half definitely has double-rounding
issues. (And I would recommend constructing an example to add to the test case
to make sure you
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 Wiebe added the comment:
Just a few small tweaks.
I think you meant to subtract the second term here:
+#('>e', b'\x80\x01', -2.0**-25 + 2.0**-35), # Rounds to minimum subnormal
Isn't the "x < 0" part unnecessary? Maybe a comment explain
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 Roddy added the comment:
Adding patch for py3k which implements Raymond's suggested fix which utilizes
collections.Counter.
Have not changed the name of the assertion method as this seems as though it
may be outside the scope of this issue, but I can produce another patch with
Mark Roddy added the comment:
Adding patch for release27-maint branch which implements Raymond's suggested
fix which utilizes collections.Counter.
Has the same issues addressed with the py3k patch.
--
Added file: http://bugs.python.org/file19721/py27.10242.
Mark Roddy added the comment:
Current patch has grown stale. Attaching a newer one.
--
nosy: +MarkRoddy
Added file: http://bugs.python.org/file19724/py3k.7911.patch
___
Python tracker
<http://bugs.python.org/issue7
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,
Mark Dickinson added the comment:
Ah yes; good point about __float__. I'll revise.
Ezio Melotti also suggested (on #python-dev) that it would be useful to have
some examples here.
--
nosy: +ezio.melotti
___
Python tracker
<http://bugs.py
Mark Dickinson added the comment:
Ezio: can you suggest a better place for a specification of what float
accepts? I think it's necessary (especially for people working on alternative
implementations) to have the information *some
Mark Dickinson added the comment:
Updated patch:
- add some examples
- mention __float__
- mention that large numeric arguments can result in an OverflowError
--
Added file: http://bugs.python.org/file19744/float_builtin_doc_v2.patch
___
Python
Mark Dickinson added the comment:
I haven't done a full review, but this looks good at first glance.
For '#g' formatting on the Decimal type, I wonder whether the patch gives the
right semantics. E.g., should
format(Decimal('1.23'), '#.6g')
give '
Mark Dickinson added the comment:
I think the change below is sufficient if we decide that the '#g' formatting
should always have the given number of significant digits.
--- Lib/decimal.py (revision 86635)
+++ Lib/decimal.py (working copy)
@@ -3701,7 +3701,8 @@
Mark Dickinson added the comment:
Gah. That doesn't work for zeros, though.
Apart from this, the rest of the patch looks good, and all tests pass on my
machine. (Well, except for test_urllib2_localnet, but I'm pretty sure that
failure is unrelated.)
I hadn'
Mark Dickinson added the comment:
> As you make progress on the patch, you will face more questions.
Well, if all that's wanted is for hour==24 to be legal on input, with the
datetime object itself being automatically normalized at creation time, then
the choices seem simple: e.g.
Mark Dickinson added the comment:
> What about time objects? If we take the "normalized at creation time"
> approach, time(24) may still be disallowed.
Yes, I guess that would follow. That wouldn't bother me too much. :-)
--
_
Mark Dickinson added the comment:
r86648.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10488>
___
___
Python-bugs-list mai
Mark Dickinson added the comment:
Doug: thanks. I think I may just be being stupid here. One thing you might
try is replacing the line
extern double round(double);
in Include/pymath.h, with:
PyAPI_FUNC(double) round(double);
and see if that helps
Mark Dickinson added the comment:
Hmm. That's puzzling indeed.
I made a claim earlier that 'round' is already used in Objects/floatobject.c,
but it occurs to me now that that's not true if PY_NO_SHORT_FLOAT_REPR is
#defined.
Could you attach the pyconfig.h file p
Mark Dickinson added the comment:
Thanks. I'm still stuck, though. Since I'm pretty much at the wild guesses
stage, here's one:
Perhaps the pymath.o object file isn't being included in the Python
executable at all, because none of its functions are needed. Now that d
Mark Dickinson added the comment:
> I *do* get a math module... but it does *not* have a round function.
Not a problem: the math module isn't supposed to have a round function. :-)
The round function is used as part of the calculations that produce the gamma
function. So if t
Changes by Mark Dickinson :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue9915>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
I think that's expected behaviour. Note that int vs float behaves in the same
way as float vs complex:
>>> class xint(int):
... def __radd__(self, other):
... print "__radd__"
... return 42
...
>>> 3 + x
Mark Dickinson added the comment:
> In my opinion, 2.6.6 was faulty in the float + xint case, for the same
> reasons as above, and 2.7 is faulty in both float + xint and complex +
> xint.
Well, I disagree: Python is behaving as designed and documented in these
cases. If you want
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file19832/unnamed
___
Python tracker
<http://bugs.python.org/issue5211>
___
___
Python-bugs-list mailin
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file19828/unnamed
___
Python tracker
<http://bugs.python.org/issue5211>
___
___
Python-bugs-list mailin
Changes by Mark Dickinson :
Removed file: http://bugs.python.org/file19820/unnamed
___
Python tracker
<http://bugs.python.org/issue5211>
___
___
Python-bugs-list mailin
Mark Dickinson added the comment:
Glad to oblige. :-)
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Mark Dickinson added the comment:
Just to add my own thoughts: 'j' for *a* (not *the* ) square root
of -1 has, as Michael points out, a history of use in engineering (particularly
electrical engineering) and physics. Personally, I would have preferred 'i' to
'j&#
1201 - 1300 of 12223 matches
Mail list logo
