Can 3.1 still be built without complex?
I notice that WITHOUT_COMPLEX still appears in Python.h and several .c files but nowhere else in the 2.6, 2.7 or 3.1 source, most particularly not in configure or pyconfig.h.in. Are builds --without-complex still supported? Has it been tested at any time in the recent past?
Skip
skip@pobox.com wrote:
I notice that WITHOUT_COMPLEX still appears in Python.h and several .c files but nowhere else in the 2.6, 2.7 or 3.1 source, most particularly not in configure or pyconfig.h.in. Are builds --without-complex still supported? Has it been tested at any time in the recent past?
I haven't tested it, but I still see WITHOUT_COMPLEX in trunk and py3k branches. In py3k, it's referenced in:
./Include/Python.h ./Misc/HISTORY ./Objects/complexobject.c ./Objects/object.c ./Parser/tokenizer.c ./Python/ast.c ./Python/bltinmodule.c ./Python/getargs.c ./Python/marshal.c ./Python/modsupport.c
I checked complexobject.c, and it looks like it's used correctly there.
Eric.
Eric> I haven't tested it, but I still see WITHOUT_COMPLEX in trunk and py3k Eric> branches. In py3k, it's referenced in: ...
Sure, but is it ever exercised? A name like WITHOUT_COMPLEX suggests that it should be flipped on/off by configure using --without-complex, but that script doesn't know about it and it's not mentioned in pyconfig.h.in, where the various --with-* flags work their magic.
Skip
skip@pobox.com wrote:
Eric> I haven't tested it, but I still see WITHOUT_COMPLEX in trunk and py3k Eric> branches. In py3k, it's referenced in: ...Sure, but is it ever exercised? A name like WITHOUT_COMPLEX suggests that it should be flipped on/off by configure using --without-complex, but that script doesn't know about it and it's not mentioned in pyconfig.h.in, where the various --with-* flags work their magic.
Ah, I misunderstood. I thought you were asking "does setting WITHOUT_COMPLEX work?"
No idea about any configure option, sorry.
Eric.
[I originally sent this reply to Skip instead of to the list; apologies.]
On Thu, Oct 15, 2009 at 12:39 PM, skip@pobox.com wrote:
I notice that WITHOUT_COMPLEX still appears in Python.h and several .c files but nowhere else in the 2.6, 2.7 or 3.1 source, most particularly not in configure or pyconfig.h.in. Are builds --without-complex still supported? Has it been tested at any time in the recent past?
Apparently not. :)
I just tried the following with an svn checkout of trunk (r75433), on OS X 10.6:
dickinsm$ CC='gcc -DWITHOUT_COMPLEX' ./configure && make
The build fails with:
gcc -DWITHOUT_COMPLEX -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Python/compile.o Python/compile.c Python/compile.c: In function ‘compiler_add_o’: Python/compile.c:914: error: ‘Py_complex’ undeclared (first use in this function) Python/compile.c:914: error: (Each undeclared identifier is reported only once Python/compile.c:914: error: for each function it appears in.) Python/compile.c:914: error: expected ‘;’ before ‘z’ Python/compile.c:931: warning: implicit declaration of function ‘PyComplex_Check’ Python/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 -DWITHOUT_COMPLEX -u _PyMac_Error -o python.exe \ Modules/python.o \ libpython2.7.a -ldl Undefined symbols: "_PyComplex_RealAsDouble", referenced from: __PyComplex_FormatAdvanced in libpython2.7.a(formatter_string.o) "_PyComplex_ImagAsDouble", referenced from: __PyComplex_FormatAdvanced in libpython2.7.a(formatter_string.o) ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [python.exe] Error 1
<skip <at> pobox.com> writes:
I notice that WITHOUT_COMPLEX still appears in Python.h and several .c files but nowhere else in the 2.6, 2.7 or 3.1 source, most particularly not in configure or pyconfig.h.in. Are builds --without-complex still supported? Has it been tested at any time in the recent past?
Is there any point in building without complex? Size reduction perhaps? If nobody uses it, we could remove that option. We have trouble staying compatible with lots of build options (see how --without-threads is little exercised).
Regards
Antoine.
On Thu, Oct 15, 2009 at 11:06 AM, Antoine Pitrou solipsis@pitrou.net wrote:
We have trouble staying compatible with lots of build options (see how --without-threads is little exercised).
I don't know if folks deploying on embedded platforms are using these options (directly or indirectly), but expect that's the primary audience.
Hopefully somebody who's doing that can tell us if they're using the defines, and what versions of Python they're currently using. Then we can determine whether the should be supported.
If they should be, there should be buildbot's set up for relevant configurations. Otherwise removal is best.
-Fred
On Thu, Oct 15, 2009 at 4:06 PM, Antoine Pitrou solipsis@pitrou.net wrote:
<skip <at> pobox.com> writes:
I notice that WITHOUT_COMPLEX still appears in Python.h and several .c files but nowhere else in the 2.6, 2.7 or 3.1 source, most particularly not in configure or pyconfig.h.in. Are builds --without-complex still supported? Has it been tested at any time in the recent past?
Is there any point in building without complex? Size reduction perhaps? If nobody uses it, we could remove that option. We have trouble staying compatible with lots of build options (see how --without-threads is little exercised).
Size reduction is the only point I can think of.
There's one respect in which complex is slightly more tightly integrated in py3k than in trunk: raising a negative number to a non-integer power (e.g., (-1)**0.5) gives a complex result in py3k.
In trunk this raises ValueError, which means that the only way to get a complex number in trunk is if you explicitly ask for one somehow (e.g., by invoking complex, or using the cmath module, or using imaginary literals, ...), so it makes slightly more sense to build without the complex type there.
+1 for removing the WITHOUT_COMPLEX define from py3k. -0 for removing it from trunk.
Mark
Mark Dickinson <dickinsm <at> gmail.com> writes:
There's one respect in which complex is slightly more tightly integrated in py3k than in trunk: raising a negative number to a non-integer power (e.g., (-1)**0.5) gives a complex result in py3k.
(-1)**.5
(6.123031769111886e-17+1j)
Don't we have a precision problem here? 0.5 is supposed to be represented exactly, isn't it?
On Thu, Oct 15, 2009 at 8:17 PM, Antoine Pitrou solipsis@pitrou.net wrote:
(-1)**.5
(6.123031769111886e-17+1j)
Don't we have a precision problem here? 0.5 is supposed to be represented exactly, isn't it?
0.5 is represented exactly, but complex.__pow__ makes no pretence 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, cmath.sqrt produces better results.
Mark
http://bugs.python.org/issue7147
Passes test (no big surprise there). Doesn't yet include any changes to documentation or Misc/NEWS entry. Should this be decided I will take a look at that.
Skip
participants (6)
-
Antoine Pitrou -
Eric Smith -
Fred Drake -
Mark Dickinson -
Skip Montanaro -
skip＠pobox.com