Mark Veldhuis <[EMAIL PROTECTED]> added the comment:
I think this solves my problem, I took away the -n from the launcher so
the command is just "/usr/bin/idle-python2.5". Now Idle does not show
the No subprocesses text, and when I press F5 the Python shell displays
a line
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's (msum.py) an example in Python of one fairly straightforward way of
dealing with overflow correctly, without needing more than one pass
through the data, and without significant slowdown in the normal case.
(The Pyt
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I agree that having lines >= 80 characters long is ugly (and violates PEP
7). But I think this particular case falls under the 'rules are made to
be broken' comment at the start of PEP 7.
I like the fact that if you s
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Test 11 failed: 9007199254740992.0 vs 9007199254740991.0 expected for
> [9007199254740992.0, -0.5, -5.5511151231257827e-17].
Yes: that's the lack of correct rounding rearing its ugly head...
> Test 12 failed: inf vs
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Ensuring correct rounding isn't as onerous as I expected it to be.
crsum.py is a snippet of Python code showing how to add nonadjacent floats
and get the correctly rounded result.
Added file: http://bugs.python.org/file103
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
This is fine. copysign isn't supposed to propagate NaNs---it's just
supposed to silently transfer the sign bit from the second argument to the
first. So I think this is correct behaviour.
Incidentally, on OS X:
>
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Okay, just to show it's possible:
Here (msum4.py) is a modified version of Raymond's recipe that deals
correctly with:
(1) intermediate overflows
(2) special values (infs and nans) in the input, and
(3) always gives c
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Closing this; I'm 99.72% sure the current behaviour is okay. :-)
Christian, please feel free to reopen if you think further discussion is
needed.
--
resolution: -> invalid
status:
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's a patch that fixes the rounding of integer division. It includes a
fast path for the case where both integers are small (less than about
3.5e12).
--
keywords: +patch
Added file: http://bugs.python.or
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
In Py30a5 idlelib/EditorWindow.py line 292 uses xrange() when it should
use range().
--
components: IDLE
messages: 67060
nosy: mark
severity: normal
status: open
title: idlelib/EditorWindow.py uses xrange()
versions: Pyth
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
The latest mathmodule patch (file 10371) looks pretty good to me. I
haven't looked at the complex version yet. A few comments:
- for setting _do_sum_pow_2 I think you should use ldexp instead of pow;
there's a much g
Mark Veldhuis <[EMAIL PROTECTED]> added the comment:
Sure, and thank you for your efforts. It will be interesting to see if
it really is the package. If there is anything I can do to test, just
drop a note.
__
Tracker <[EMAIL PROTECTED]>
<http://
Changes by Mark Blakeney <[EMAIL PROTECTED]>:
--
nosy: +markb
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1641>
__
___
Python-bugs-list mailin
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I'm working on issue 2873 (remove htmllib dependency from pydoc).
--
nosy: +marketdickinson
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
This issue is at least partially dependent on issue #1883 (adapting pydoc
to new doc system), in that it's a little awkward to test pydoc before
#1883 is complete.
--
dependencies: +Adapt pydoc to new doc
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
On some older Intel 32-bit hardware, under Linux, floating-point
operations don't always give correctly rounded results. Here's an
example involving addition, on SuSE Linux 10.2/Xeon.
Python 2.6a3+ (trunk:63521, May 2
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Okay; so this is definitely not a Python bug---it's a well-known
and well-documented problem with IA32 floating-point. And I accept
that it's really not Python's responsibility to document this, either.
Nevertheless, it
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
math module patch committed, r63542.
I'm still working on converting the tests to the unittest framework.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Tests committed in r63543
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2819>
__
___
Python-bugs
Mark Summerfield <[EMAIL PROTECTED]> added the comment:
AFAIK if you have a regex with named capture groups there is no direct
way to relate them to the capture group numbers.
You could do (untested; Python 3 syntax):
d = {v: k for k, v in match.groupdict()}
for i in
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
>>> help(str.replace)
Help on method_descriptor:
replace(...)
S.replace (old, new[, maxsplit]) -> unicode
Return a copy of S with all occurrences of substring
old replaced by new. If the optional ar
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
Py30a5
2to3 currently does not cope correctly with this:
print whatever; print
which it converts to:
print(whatever); print
This is a subtle error since "print" on its own is valid.
Nor does it replace the d
New submission from Mark Veldhuis <[EMAIL PROTECTED]>:
I am using IDLE on Ubuntu Hardy (8.04) and all in all very content to
use it. Today I got an AttributeError using sys.stdin.fileno(). A closer
look revealed this:
in IDLE:
Python 2.5.2 (r252:60911, Apr 21 2008, 11:12:42)
[GCC
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Contrary to what I said above, I'm not going to find time for this
before the beta. Anyone else want to have a go at producing a patch?
A simple implementation would be fine---the algorithm could be tweaked
for
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
assignee: -> marketdickinson
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2138>
___
_
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's a patch that fixes the problems with math.sum on x86 machines that
aren't using SSE2.
On these machines, the patched version of math.sum does almost the entire
calculation using long doubles instead of doubles. T
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I agree that those -1s should really be 0s.
Do you have any examples of real-life code
that's affected by this bug? It doesn't seem
like something that would be a problem in
practice.
--
nosy: +marketdickinson
prio
Mark Hammond <[EMAIL PROTECTED]> added the comment:
pywin32 has a 'winerror' module, which is (basically) a h2py generated
module from the same header (although initially generated roughly a
decade ago and hand-tweaked since then). Its unfortunate pywin32 still
hasn't adopt
Mark Hammond <[EMAIL PROTECTED]> added the comment:
What should struct.calcsize() do with a 'p' format string?
--
nosy: +mhammond
___
Python tracker <[EMAIL PROTECTED]>
<http://
New submission from Mark English <[EMAIL PROTECTED]>:
*Problem*
The directory structure of PCBuild8 differs from PCBuild in that each
project has its own subdirectory.
There is no subdirectory for _ssl, and the files that would belong in it
are also omitted.
*Solution*
The attached files,
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I suspect that what's happening is that errno is being set to ERANGE
on a subnormal results; this is somewhat ... um ... unorthodox.
In that case, the fix would be to raise OverflowError when errno is set to
ERANGE and the func
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I further suspect that no-one with access to ia64 is monitoring this
issue. :-)
So maybe this should just be checked in, and then reverted if it either
causes other buildbots to fail or doesn't help with Ubuntu/ia64.
Benjamin,
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Could you provide some tests for the fixed behaviour?
I'll try to check this in (with appropriate tests) after the beta.
--
assignee: -> marketdickinson
___
Python tracker <
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Committed, r64349. I'm watching the buildbots.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
It looks like there's a refcounting bug in the code: if the call to
PyNumber_Multiply fails then iobj gets DECREF'd twice. This means that a
keyboard interrupt of factorial() can exit the interpreter:
Python 2.6a3+ (trun
Mark Summerfield <[EMAIL PROTECTED]> added the comment:
[snip]
> 13) Implement a grouptuples(...) method as per Mark Summerfield's
> suggest on 2008-05-28 09:38. grouptuples would take the same filtering
> parameters as the other group* functions, and would return a list of
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
Python 30b1
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "en_US.UTF-8")
'en_US.UTF-8'
>>> for x in
(1234,12345,123456,1234567,12345678,123456789,1234567
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
When you build 30b1 on Linux (I tried Fedora 8 and Xubuntu 8) you get a
message that make failed to find the bits to build "_gestalt", which I
think is a Mac-thing not a Linux thing.
Anyway, Barry asked me to a
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
Py30b1
The module renaming of urllib's modules (and the getting rid of urllib2)
has been done---but this isn't reflected in the docs.
--
assignee: georg.brandl
components: Documentation
messages: 68406
nosy: ge
Mark Summerfield <[EMAIL PROTECTED]> added the comment:
[snip]
It seems to me that both using a special prefix or adding an option are
adding a lot of baggage and will increase the learning curve.
The nice thing about (3) (even without slicing) is that it seems a v.
natural extension.
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Reopening this; I'd like to have a second go at implementing the 'n'
format specifier for the Decimal type.
See issue 2802 for hints about how to go about this.
--
assignee: facundobatis
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
On Wed, Jun 18, 2008 at 4:56 PM, Arnaud Bergeron <[EMAIL PROTECTED]>
wrote:
>
> Arnaud Bergeron <[EMAIL PROTECTED]> added the comment:
>
> Would these do?
>
> self.assertEqual(slice(None
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10669/unnamed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Sorry: looks like I messed up that last post. The example should be:
>>> slice(10, 10, -1).indices(10) # expect (9, 9, -1)
(9, 10, -1)
___
Python tracker <[EMAIL PROTECTED]>
&l
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's a new patch that incorporates Arnaud's fix and tests, together with
a few extra tests.
While I expect that this change will affect very little code, I think it's
the right thing to do, because:
- start and s
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> 0 <= start <= stop <= lengthif step is positive, and
> length-1 >= start >= stop >= -1 if step is negative.
That should be:
0 <= start <= length and 0 <= stop <= length (step > 0), and
le
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
The patch looks good to me.
It's a bit unfortunate that -0.0 doesn't round-trip correctly (the sign
of the zero gets lost):
>>> eval(bin(-0.0))
0.0
I don't know whether it's worth special-casing this;
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Mark, I added tests for Inf/Nan. Will this work on all platforms?
I think the tests should work on all common to semicommon platforms,
including on all the buildbots. They won't work on non IEEE 754 platforms
(float(&#x
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Committed, r64426.
Thanks for the report, Arnaud.
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
If n is a Python long, then one might expect float(n) to return the
closest float to n. Currently it doesn't do this. For example (with
Python 2.6, on OS X 10.5.2/Intel):
>>> n = 295147905179352891391L
The closest
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I'll take a look.
--
assignee: -> marketdickinson
nosy: +marketdickinson
___
Python tracker <[EMAIL PROTECTED]>
<http://bu
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
assignee: -> marketdickinson
nosy: +marketdickinson
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Could you tell me what
>>> import math
>>> math.log(float('-inf'))
gives instead of the expected ValueError?
___
Python tracker <[EMAIL PROTECTE
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
I built Python 30b1 from the tarball on Fedora 8 and Xubuntu 8.
My only configure switch was --prefix to get a local build.
On both systems the only build error I got was:
Failed to find the necessary bits to build these m
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Judging by the information at
http://docs.sun.com/app/docs/doc/802-1930-03/6i5u95u0i?
l=en&a=view&q=matherr
this behaviour is intentional. It looks like log(-inf)
sets errno = EDOM and returns -inf. An IEEE 754
conformin
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
On second thoughts, forget about matherr---looks like it's
outdated technology.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
In Python 2.6, for a long n, hex(n) and oct(n) have a trailing 'L', while
bin(n) does not:
>>> hex(1L)
'0x1L'
>>> oct(1L)
'01L'
>>> bin(1L)
'0b1'
I'm guessi
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
2.6 adds float('inf') and float('nan') as cross-platform ways to
generate infinities and NaNs. The C99 standard (section 7.20.1.3,
paragraph 3) specifies that 'infinity' (in any case, with optional
pr
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Ah. I missed this. Apologies.
Sorry for the noise.
--
resolution: -> invalid
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
In Python 3.0, help(round) gives the following:
round(...)
round(number[, ndigits]) -> floating point number
Round a number to a given precision in decimal digits (default 0
digits).
This returns an int when ca
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
On Mon, Jun 23, 2008 at 5:25 PM, Jean Brouwers <[EMAIL PROTECTED]>
wrote:
> result is different for 32- and 64-bit
>
> > cc -xtarget=native log_inf.c -lm ; a.out
> -Inf 33
> Inf 33
>
That 33 for th
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10722/unnamed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> -1 on Nick's suggestion to normalize hex output so that nearby floats
> have nearby reprs. This unnecessarily complicates a simple, straight-
> forward presentation. In the paper referenced by Terry Reedy,
> n
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Nice reply from zal. His conclusion:
> The short answer to your question is to use the cc -xlibmieee
> option (and not rely on errno in the case of log(-Inf)) if you
> would like to see results in the spirit of IEEE 754.
New submission from Mark Dickinson <[EMAIL PROTECTED]>:
The documentation for the fractions module needs some rewriting---it
contains minor inaccuracies, outdated statements (e.g. the regex is
incomplete), and there are places that could use some clarification (e.g.
the descript
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
I'm reopening this to propose a last-minute minor change:
Can we remove the trailing 'L' from the numerator and denominator in
the repr of a Fraction instance? E.g.,
>>> x = Fraction('9.876543210'
New submission from Mark Summerfield <[EMAIL PROTECTED]>:
With 2.5.2 and 30b1 strings don't round trip like numbers do.
I guess it has been like this a long time so isn't a bug, but it does
seem inconsistent.
Both 2.5.2 and 30b1:
>>> x = 5
>>> x == int(repr(
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Fixed in r64526.
Thanks for the report!
--
nosy: +marketdickinson
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's a proposed new draft of the fractions documentation for 2.6.
Apart from wording changes, it:
- removes documentation for __floor__, __ceil__ and __round__, since
those no longer exist in 2.6
- describes construc
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Well, here's some Python code to output C99-style hexadecimal
representations of floats. It's not quite the same as Java's output,
which also special cases IEEE 754 subnormals (writing them with a fixed
exponent of -
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Trailing 'L's removed in r64557.
A couple more minor issues:
(1) fractions.gcd is exported but not documented. I'll add some
documentation for it, unless anyone feels that it shouldn't have been
exported in the f
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Hmm. I don't much like this, though:
>>> Fraction('1.23', 1.0)
Fraction(123, 100)
>>> Fraction('1.23', 1+0j)
Fraction(123, 100)
I'd say these should definitely be TypeErrors.
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Here's an updated doc patch; it fixes an indentation issue in the
previous patch, and adds documentation for the exported gcd function.
Added file: http://bugs.python.org/file10750/fractions
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Shouldn't make the second '.' optional or this will match plain
> numerators too.
Thanks. Fixed, and committed in r64561 (trunk), and r64562 (py3k).
--
resolution: ->
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Jean,
Could you try the attached patch and see if it fixes the problem?
And I'd welcome comments from others on the patch---I'm not much of an
autoconf hacker.
--
keywords: +patch
Added file: http://bugs.pyth
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> I agree that if the type of the 2nd arg isn't int or long it should be
> rejected. That should not slow down the common path (two ints).
Sounds good. Some care might be needed to avoid invalidating
Fraction(n, d)
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
This one's quite baffling.
Jean, can you confirm whether cmath.log(0.01, 0.5) and cmath.log(100.,
2.0) give the correct answer or not? They should both give
(6.6438561897747244-0j)
(the sign on the imaginary part might
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
test_multiprocessing is also still hanging for me, perhaps 30% of the
times I run the test suite.
When running the test by itself it seems to pass much more often, but
not always. I just got the following output (on OS X 10.5.3
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
This is a known problem, that's unlikely to change unless there's a
serious overhaul of Python's floating point.
The warning at the end of the math module documentation should probably
be taken to apply equally to all
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
More curious and more curious...
I assume that cmath.log(100.0) and cmath.log(2.0) return the right things?
(Both answers should have zero imaginary part.)
Might this be some optimization bug? Can you turn off all optimizations
a
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> However, the resulting build produces to wrong result:
Darn. That's probably because the linker needs the extra flag as well.
Here's a revised patch for you to try. (You might need to do an "svn up"
before
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10754/issue3167.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Keep in mind also, these Python builds are compiled with the SUN
> compilers, i.e. the ./configure command line includes --without-gcc.
> If we do change the CC- and LINKFLAGS, those changes should only apply
> in th
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
What about cmath.log(100.0) and cmath.log(2.0) on 64-bit?
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Okay, here's a third version of the patch. Same as before, except
that it makes sure that LDFLAGS are included in LDSHARED.
Jean, does this patch fix the problem with math.log on 32-bit? If so,
I'll check it in.
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10757/issue3167.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
This looks a lot like a compiler bug, then. Do you agree?
I guess the next step would be to try to extract a smallest failing
example from the Python code, and report the bug to Sun. It might first
be interesting to insert some prin
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Closing as 'won't fix'.
--
resolution: -> wont fix
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Sorry---my bad. I missed out the $ac_sys_release bit.
Patch updated again. Jean, could you please give it one more try?
Added file: http://bugs.python.org/file10760/issue3167.patch
___
Python t
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10759/issue3167.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Could you try the attached patch, and see what output you get from
cmath.log(100., 2.)? (On 64-bit, of course.)
--
keywords: +patch
Added file: http://bugs.python.org/file10763/issue3168
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> Trying to isolate and duplicate the problem with c_quot isn't quite
> working. See the attached c_quot.c file and the results at the end.
I'd expect that you'd need both the cmath_log and the c_quot functions,
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Add comment to patch.
Added file: http://bugs.python.org/file10764/issue3167.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10760/issue3167.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Martin,
Do you have a moment to do a sanity check on the attached patch? The
aim of the patch is to add the -xlibmieee flag when compiling and
linking on Solaris using Sun's compiler rather than gcc. Jean Brouwers
has confirm
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Okay---so committing this would be premature at this point.
It looks like the test_math errors are the same problem that Jean found.
Skip, does
LDFLAGS=-xlibmieee ./configure ...
do anything to alleviate the test_math errors?
The
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> LDFLAGS=-xlibmieee ./configure ...
I guess that should probably be:
LDFLAGS="-Xlinker -xlibmieee" ./configure
___
Python tracker <[EMAIL PROTECTED]>
<http
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Skip: one more question. What does
cmath.exp(710.0 + 1.5j)
give instead of the expected OverflowError?
Incidentally, the Solaris buildbot seems happy enough at the moment. I
wonder what the difference between Skip's mach
Changes by Mark Dickinson <[EMAIL PROTECTED]>:
--
nosy: +marketdickinson
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1580>
___
_
Mark Dickinson <[EMAIL PROTECTED]> added the comment:
> What about this case? Should cmath not produce the same result as math:
No; this is correct, I think. Note that the cmath.log result has nonzero
imaginary part, so can't be represented as a float.
Similarly, math.sqrt(-
1401 - 1500 of 12223 matches
Mail list logo
