I just noticed that in x_arithmetic.c, powf() and its single precision friends are all macroed to the double precision version saying "MSW and OSX don't appear to have single-precision ANSI math". But according to /usr/include/architecture/ppc/math.h, it does have all them, you just have to link in libmx:
/* * N.B. When using the C99 "float" entry points that follow, an additional * flag must be added to the link step that produces the executable binary * -- specify "-lmx". */
Any problem with using the right functions on Mac OS X? This should speed things up a bit, no? I'll make the patch if there's no problem...
.hc
________________________________________________________________________ ____
"Computer science is no more related to the computer than astronomy is related to the telescope." -Edsger Dykstra
Zitiere Hans-Christoph Steiner hans@eds.org:
Any problem with using the right functions on Mac OS X? This should speed things up a bit, no? I'll make the patch if there's no problem...
yes! the "right functions" have been only been added to recent versions of os-X. so abandoning the macros would make pd unusable on older versions of this os. in zexy and Gem, jamie has incorporated a more or less generic way (without(!) autoconf, just header magic) to test whether the right functions exist or not.
mfg..r IOhannes
On Jan 28, 2006, at 3:13 AM, zmoelnig@iem.at wrote:
Zitiere Hans-Christoph Steiner hans@eds.org:
Any problem with using the right functions on Mac OS X? This should speed things up a bit, no? I'll make the patch if there's no problem...
yes! the "right functions" have been only been added to recent versions of os-X. so abandoning the macros would make pd unusable on older versions of this os. in zexy and Gem, jamie has incorporated a more or less generic way (without(!) autoconf, just header magic) to test whether the right functions exist or not.
This is what autoconf is all about. Its pretty easy to do, and it would look something like this in x_arithmetic.c:
#if defined(MSW) || ( defined(__APPLE__) && !defined(HAVE_LIBMX) ) #define sinf sin #define cosf cos #define atanf atan #define atan2f atan2 #define sqrtf sqrt #define logf log #define expf exp #define fabsf fabs #define powf pow #endif
and this in configure.in:
dnl Checking for `powf' function in -lmx, which provides : AC_CHECK_LIB(mx, powf, PDLIB="$PDLIB -lmx"; MORECFLAGS="$MORECFLAGS -DHAVE_LIBMX", echo "using libmx for single precision")
And by the way, compiling with gcc 4.0 on Mac OS X automatically includes libmx, so Pd builds on Mac OS X 10.4 will only run on 10.3.9 or newer (unless you make it compile with gcc 3.3 and compatibility libs).
.hc ________________________________________________________________________ ____
"Information wants to be free." -Stewart Brand
#if defined(MSW) || ( defined(__APPLE__) && !defined(HAVE_LIBMX) )
not sure, but is there any definition, that's set if the compiler supports c99?
t
On Jan 28, 2006, at 10:39 AM, Tim Blechmann wrote:
#if defined(MSW) || ( defined(__APPLE__) && !defined(HAVE_LIBMX) )
not sure, but is there any definition, that's set if the compiler supports c99?
(From http://publib.boulder.ibm.com/infocenter/macxhelp/index.jsp?topic=/ com.ibm.vacpp6m.doc/language/ref/clrc09cplr367.htm )
__STDC__ For C, the integer 1 (one) indicates that the C compiler supports the ISO standard. (When a macro is undefined, it behaves as if it had the integer value 0 when used in a #if statement.)
__STDC_VERSION__ The integer constant of type long int: 199409L for the C89 language level, 199901L for C99.
The question is whether gcc 3.3 on Mac OS X changes this based on libmx presence.
.hc ________________________________________________________________________ ____
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams