[PD-dev] buildbot/jenkins: q about hosts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ola! since i don't know any better place to ask, i'll ask here... debian-testing-amd64.pdlab.hfbk.net - --- for whatever reasons, this machine has /tmp (where jenkins creates the workspaces) mounted as tmpfs (that is, as mmapped disk). due to memory limitations, this means, that /tmp is 200MB large. this is a bit small for a build-server that usually does not delete workspaces. it's definitely too small for building Gem, where the extracted source alone takes abot 53MB i'd suggest to configure it the same as debian-stable-amd64.pdlab.hfbk.net, where /tmp is part of the /-partition. chaos.medien.uni-weimar.de - -- i seem to have great troubles to get the OSX10.6 (chaos.medien.uni-weimar.de) machine build a build without fink. mainly because autoreconf seems to find the fink-installed libtool when creating the build-scritps, but then wants to use the non-fink version. my approach was to remove the /sw/bin and /sw/sbin from the PATH, which works fine on the console of the given machine. if somebody could shed i light on how the fink installation differs on the macosx106 machine from the one on the macosx105 machine, i'd be grateful. the build log can be found at [1] jenk...@macosx105-i386.puredata.info - while i am all for using domain names within puredata.info, it would be great if the hostname could be more specific, ideally referencing to autobuild, buildbot or jenkins i'd suggest names like macosx105-i386.buildbot.puredata.info i'll happily add those names to the puredata.info DNS server, if i get the IPs. fgmasdr IOhannes [1] https://160.79.59.149:8443/job/Gem/all=macosx106/7/console -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk65BSEACgkQkX2Xpv6ydvQo0ACfQwVGcJIFLrW79kvpcetD7IZ0 uokAoKqVy1R4EcRD4jRCiBEzQu9xkU83 =Pjs7 -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] buildbot/jenkins: q about hosts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-08 11:32, IOhannes m zmoelnig wrote: chaos.medien.uni-weimar.de -- i seem to have great troubles to get the OSX10.6 (chaos.medien.uni-weimar.de) machine build a build without fink. mainly because autoreconf seems to find the fink-installed libtool when creating the build-scritps, but then wants to use the non-fink version. my approach was to remove the /sw/bin and /sw/sbin from the PATH, which works fine on the console of the given machine. if somebody could shed i light on how the fink installation differs on the macosx106 machine from the one on the macosx105 machine, i'd be grateful. the build log can be found at [1] it seems like i was able to resolve this issue, by deleting all workspaces associated in any way to the build, thus forcing ltversion.m4 to be properly recreated. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk65B2EACgkQkX2Xpv6ydvQSYQCg4vMqK673ju71l5Jpr2YPArlk v1UAoKb+spr8KGQDt4HawHrtfmjZhTw+ =OlRK -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] nightly builds broken
Today's autobuilds are broken again, still due to my double-precision commit! Sorry sorry. The real cause lies here: There is a small but crucial difference in the API between Pd-extended and Pd-double. In Pd-extended, float precision is defined with PD_FLOATSIZE and in Pd-double it is PD_FLOATPRECISION. This must be resolved before we can continue developing the external libs against Pd-double. In retrospect, it seems rather illogical to have these different macro names, so you may wonder how this came about. When I started rewriting Pd core code last summer to make it ready for double precision, there was only PD_FLOATTYPE which could be defined 'float' or 'double'. I soon found that the preprocessor could not do string comparison, and a numeric definition was needed to do conditional checks at compile time. I opted for PD_FLOATPRECISION, to be set at 32 or 64 for the number of bits. Around the same time, IOhannes introduced a macro PD_FLOATSIZE (to be set at 32 or 64) in Pd-extended when he rewrote PD_BIGORSMALL as an inline function. Yes, it is quite stupid that two nights of broken builds were needed to bring back these different macro's to mind. How should we resolve this? I'd like to stay with PD_FLOATPRECISION for it's unambiguity (size normally refers to number of bytes, not bits), but on the other hand, PD_FLOATSIZE may already be used by developers of external libs in the meantime. If we can not solve this today, I will undo my changes to creb for the moment, to no longer block the builds. Katja On Mon, Nov 7, 2011 at 5:08 PM, Hans-Christoph Steiner h...@at.or.at wrote: No big thing, we all break the build sometimes :) Thanks for the quick fix. As long as you follow up the next day, don't worry too much about breaking the build. Its only really a problem when we go more than a couple days without builds. But yes, it is better to not break the build ;) .hc On Nov 7, 2011, at 6:51 AM, katja wrote: Found my mistake, affecting single precision i386 and x86_64 builds. It is repaired now. I'll refine my procedures to make sure a mistake like this won't happen again. Apologies for the inconvenience caused by it. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder. - Chris McCormick ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] nightly builds broken
I think the solution is quite easy, PD_FLOATSIZE was introduced in a patch from IOhannes implement PD_BIGORSMALL() with unions. This patch is not yet included by Miller in pure-data.git. I think we should update that patch in Pd-extended, changing PD_FLOATSIZE to PD_FLOATPRECISION. IOhannes? .hc On Nov 8, 2011, at 7:18 AM, katja wrote: Today's autobuilds are broken again, still due to my double-precision commit! Sorry sorry. The real cause lies here: There is a small but crucial difference in the API between Pd-extended and Pd-double. In Pd-extended, float precision is defined with PD_FLOATSIZE and in Pd-double it is PD_FLOATPRECISION. This must be resolved before we can continue developing the external libs against Pd-double. In retrospect, it seems rather illogical to have these different macro names, so you may wonder how this came about. When I started rewriting Pd core code last summer to make it ready for double precision, there was only PD_FLOATTYPE which could be defined 'float' or 'double'. I soon found that the preprocessor could not do string comparison, and a numeric definition was needed to do conditional checks at compile time. I opted for PD_FLOATPRECISION, to be set at 32 or 64 for the number of bits. Around the same time, IOhannes introduced a macro PD_FLOATSIZE (to be set at 32 or 64) in Pd-extended when he rewrote PD_BIGORSMALL as an inline function. Yes, it is quite stupid that two nights of broken builds were needed to bring back these different macro's to mind. How should we resolve this? I'd like to stay with PD_FLOATPRECISION for it's unambiguity (size normally refers to number of bytes, not bits), but on the other hand, PD_FLOATSIZE may already be used by developers of external libs in the meantime. If we can not solve this today, I will undo my changes to creb for the moment, to no longer block the builds. Katja On Mon, Nov 7, 2011 at 5:08 PM, Hans-Christoph Steiner h...@at.or.at wrote: No big thing, we all break the build sometimes :) Thanks for the quick fix. As long as you follow up the next day, don't worry too much about breaking the build. Its only really a problem when we go more than a couple days without builds. But yes, it is better to not break the build ;) .hc On Nov 7, 2011, at 6:51 AM, katja wrote: Found my mistake, affecting single precision i386 and x86_64 builds. It is repaired now. I'll refine my procedures to make sure a mistake like this won't happen again. Apologies for the inconvenience caused by it. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder. - Chris McCormick ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev http://at.or.at/hans/ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] nightly builds broken
Ok, I chatted with IOhannes on #dataflow. He agreed, so I pushed this change to the pd-extended.git, so tomorrow's builds should have it. IOhannes, I could find where you posted this patch, perhaps its not on the patch tracker yet. In any case attached is the updated version: .hc implement-PD_BIGORSMALL-with-unions.patch Description: Binary data On Nov 8, 2011, at 10:37 AM, Hans-Christoph Steiner wrote: I think the solution is quite easy, PD_FLOATSIZE was introduced in a patch from IOhannes implement PD_BIGORSMALL() with unions. This patch is not yet included by Miller in pure-data.git. I think we should update that patch in Pd-extended, changing PD_FLOATSIZE to PD_FLOATPRECISION. IOhannes? .hc On Nov 8, 2011, at 7:18 AM, katja wrote: Today's autobuilds are broken again, still due to my double-precision commit! Sorry sorry. The real cause lies here: There is a small but crucial difference in the API between Pd-extended and Pd-double. In Pd-extended, float precision is defined with PD_FLOATSIZE and in Pd-double it is PD_FLOATPRECISION. This must be resolved before we can continue developing the external libs against Pd-double. In retrospect, it seems rather illogical to have these different macro names, so you may wonder how this came about. When I started rewriting Pd core code last summer to make it ready for double precision, there was only PD_FLOATTYPE which could be defined 'float' or 'double'. I soon found that the preprocessor could not do string comparison, and a numeric definition was needed to do conditional checks at compile time. I opted for PD_FLOATPRECISION, to be set at 32 or 64 for the number of bits. Around the same time, IOhannes introduced a macro PD_FLOATSIZE (to be set at 32 or 64) in Pd-extended when he rewrote PD_BIGORSMALL as an inline function. Yes, it is quite stupid that two nights of broken builds were needed to bring back these different macro's to mind. How should we resolve this? I'd like to stay with PD_FLOATPRECISION for it's unambiguity (size normally refers to number of bytes, not bits), but on the other hand, PD_FLOATSIZE may already be used by developers of external libs in the meantime. If we can not solve this today, I will undo my changes to creb for the moment, to no longer block the builds. Katja On Mon, Nov 7, 2011 at 5:08 PM, Hans-Christoph Steiner h...@at.or.at wrote: No big thing, we all break the build sometimes :) Thanks for the quick fix. As long as you follow up the next day, don't worry too much about breaking the build. Its only really a problem when we go more than a couple days without builds. But yes, it is better to not break the build ;) .hc On Nov 7, 2011, at 6:51 AM, katja wrote: Found my mistake, affecting single precision i386 and x86_64 builds. It is repaired now. I'll refine my procedures to make sure a mistake like this won't happen again. Apologies for the inconvenience caused by it. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder. - Chris McCormick ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev http://at.or.at/hans/ Access to computers should be unlimited and total. - the hacker ethic ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] nightly builds broken
On Tue, Nov 8, 2011 at 1:18 PM, katja katjavet...@gmail.com wrote: There is a small but crucial difference in the API between Pd-extended and Pd-double. In Pd-extended, float precision is defined with PD_FLOATSIZE and in Pd-double it is PD_FLOATPRECISION. This must be resolved before we can continue developing the external libs against Pd-double. And to correct myself once more: I used PD_FLOAT_PRECISION in Pd-double, not PD_FLOATPRECISION. Sigh... Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] buildbot/jenkins: q about hosts
On Nov 8, 2011, at 5:32 AM, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ola! since i don't know any better place to ask, i'll ask here... debian-testing-amd64.pdlab.hfbk.net - --- for whatever reasons, this machine has /tmp (where jenkins creates the workspaces) mounted as tmpfs (that is, as mmapped disk). due to memory limitations, this means, that /tmp is 200MB large. this is a bit small for a build-server that usually does not delete workspaces. it's definitely too small for building Gem, where the extracted source alone takes abot 53MB i'd suggest to configure it the same as debian-stable-amd64.pdlab.hfbk.net, where /tmp is part of the /-partition. Ok, I'll check this out now. chaos.medien.uni-weimar.de - -- i seem to have great troubles to get the OSX10.6 (chaos.medien.uni-weimar.de) machine build a build without fink. mainly because autoreconf seems to find the fink-installed libtool when creating the build-scritps, but then wants to use the non-fink version. my approach was to remove the /sw/bin and /sw/sbin from the PATH, which works fine on the console of the given machine. if somebody could shed i light on how the fink installation differs on the macosx106 machine from the one on the macosx105 machine, i'd be grateful. the build log can be found at [1] jenk...@macosx105-i386.puredata.info - while i am all for using domain names within puredata.info, it would be great if the hostname could be more specific, ideally referencing to autobuild, buildbot or jenkins i'd suggest names like macosx105-i386.buildbot.puredata.info i'll happily add those names to the puredata.info DNS server, if i get the IPs. I like the name standard that we used for the hfbk.net machines, i.e. debian-testing-amd64.pdlab.puredata.info -- debian-testing-amd64.pdlab.hfbk.net debian-stable-amd64.pdlab.puredata.info -- debian-stable-amd64.pdlab.hfbk.net macosx105-i386.pdlab.puredata.info -- 160.79.59.149 debian-stable-amd64.pdlab.puredata.info -- 128.238.56.50 ubuntu-lts-amd64.pdlab.puredata.info -- 128.238.56.55 ubuntu-current-amd64.pdlab.puredata.info -- 128.238.56.53 windowsxp-i386.pdlab.puredata.info -- 128.238.56.60 .hc fgmasdr IOhannes [1] https://160.79.59.149:8443/job/Gem/all=macosx106/7/console -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk65BSEACgkQkX2Xpv6ydvQo0ACfQwVGcJIFLrW79kvpcetD7IZ0 uokAoKqVy1R4EcRD4jRCiBEzQu9xkU83 =Pjs7 -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated -John Donne ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] nightly builds broken
On Nov 8, 2011, at 11:17 AM, katja wrote: On Tue, Nov 8, 2011 at 1:18 PM, katja katjavet...@gmail.com wrote: There is a small but crucial difference in the API between Pd-extended and Pd-double. In Pd-extended, float precision is defined with PD_FLOATSIZE and in Pd-double it is PD_FLOATPRECISION. This must be resolved before we can continue developing the external libs against Pd-double. And to correct myself once more: I used PD_FLOAT_PRECISION in Pd-double, not PD_FLOATPRECISION. Sigh... Fixed, and here's the updated patch: .hc implement-PD_BIGORSMALL-with-unions.patch Description: Binary data [T]he greatest purveyor of violence in the world today [is] my own government. - Martin Luther King, Jr. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] buildbot/jenkins: q about hosts
On Nov 8, 2011, at 5:32 AM, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ola! since i don't know any better place to ask, i'll ask here... debian-testing-amd64.pdlab.hfbk.net - --- for whatever reasons, this machine has /tmp (where jenkins creates the workspaces) mounted as tmpfs (that is, as mmapped disk). due to memory limitations, this means, that /tmp is 200MB large. this is a bit small for a build-server that usually does not delete workspaces. it's definitely too small for building Gem, where the extracted source alone takes abot 53MB i'd suggest to configure it the same as debian-stable-amd64.pdlab.hfbk.net, where /tmp is part of the /-partition. I bumped up the tmpfs size to 80% in /etc/default/tmpfs. That way it'll use the swap, which is currently basically unused. So /tmp is now 800Megs. .hc chaos.medien.uni-weimar.de - -- i seem to have great troubles to get the OSX10.6 (chaos.medien.uni-weimar.de) machine build a build without fink. mainly because autoreconf seems to find the fink-installed libtool when creating the build-scritps, but then wants to use the non-fink version. my approach was to remove the /sw/bin and /sw/sbin from the PATH, which works fine on the console of the given machine. if somebody could shed i light on how the fink installation differs on the macosx106 machine from the one on the macosx105 machine, i'd be grateful. the build log can be found at [1] jenk...@macosx105-i386.puredata.info - while i am all for using domain names within puredata.info, it would be great if the hostname could be more specific, ideally referencing to autobuild, buildbot or jenkins i'd suggest names like macosx105-i386.buildbot.puredata.info i'll happily add those names to the puredata.info DNS server, if i get the IPs. fgmasdr IOhannes [1] https://160.79.59.149:8443/job/Gem/all=macosx106/7/console -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk65BSEACgkQkX2Xpv6ydvQo0ACfQwVGcJIFLrW79kvpcetD7IZ0 uokAoKqVy1R4EcRD4jRCiBEzQu9xkU83 =Pjs7 -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev 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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] getting double fixes into extra/
Hey Katja,
I was just reviewing the double precision patches for the extra/ section of
pure-data. I think we should try to get Miller to accept the 'extra/' fixes
into pure-data.git now. It seems to me that almost all of these changes are
just float -- t_float, which are really no-brainers that would be really
difficult to imagine causing problems. Plus judging by all the tests you have
written, it looks like your code is already pretty well tested.
There are only a couple changes in this patch that are not no-brainers. The
first is in sigmund~.c, it looks like you just moved up the #ifdef PD and
#ifdef MSP blocks to the top of the file. Seems harmless enough. Then there
are a couple places where the code is using 'f' to force single precision, like:
@@ -677,8 +678,8 @@ static void bonk_doit(t_bonk *x)
{
if (x-x_useloudness)
growth += qrsqrt(qrsqrt(
-power/(h-h_mask[oldmaskphase] + 1.0e-15))) - 1.f;
-else growth += power/(h-h_mask[oldmaskphase] + 1.0e-15) - 1.f;
+power/(h-h_mask[oldmaskphase] + 1.0e-15))) - 1.;
+else growth += power/(h-h_mask[oldmaskphase] + 1.0e-15) - 1.;
}
if (!x-x_willattack countup = x-x_masktime)
maskpow *= x-x_maskdecay;
And cases where there are added typedefs which I don't really understand what's
going on, like:
--- extra_original/expr~/vexp.h 2011-09-06 11:13:12.0 +0200
+++ extra_double_ready/expr~/vexp.h 2011-09-06 11:13:12.0 +0200
@@ -37,6 +37,7 @@
#else /* MSP */
#include ext.h
#include z_dsp.h
+typedef float t_float; // t_float is from m_pd.h
#endif
#include fts_to_pd.h
--- extra_original/fiddle~/fiddle~.c2010-04-26 00:27:35.0 +0200
+++ extra_double_ready/fiddle~/fiddle~.c2011-09-06 11:36:28.0
+0200
@@ -108,11 +108,11 @@ static fts_symbol_t *dsp_symbol = 0;
#endif /* MSP */
#ifdef MSP
-#define t_floatarg double
#include ext.h
#include z_dsp.h
#include fft_mayer.proto.h
-
+typedef float t_float;
+typedef double t_floatarg;
#endif /* MSP */
#include math.h
--- extra_original/loop~/loop~.c2010-07-28 22:55:17.0 +0200
+++ extra_double_ready/loop~/loop~.c2011-09-06 11:33:54.0 +0200
@@ -14,7 +14,8 @@ This file is downloadable from http://ww
#ifdef PD
#include m_pd.h
#else
-#define t_sample float
+typedef float t_float;
+typedef float t_sample;
#endif
--- extra_original/pd~/pd~.c2010-07-28 22:55:17.0 +0200
+++ extra_double_ready/pd~/pd~.c2011-09-06 11:38:12.0 +0200
@@ -26,7 +26,7 @@
#include ext_support.h
#include ext_proto.h
#include ext_obex.h
-
+typedef float t_float;
typedef double t_floatarg;
#define w_symbol w_sym
#define A_SYMBOL A_SYM
.hc
I spent 33 years and four months in active military service and during that
period I spent most of my time as a high class muscle man for Big Business, for
Wall Street and the bankers. - General Smedley Butler
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] getting double fixes into extra/
On Tue, Nov 8, 2011 at 9:04 PM, Hans-Christoph Steiner h...@at.or.at wrote:
Hey Katja,
I was just reviewing the double precision patches for the extra/ section of
pure-data. I think we should try to get Miller to accept the 'extra/' fixes
into pure-data.git now. It seems to me that almost all of these changes are
just float -- t_float, which are really no-brainers that would be really
difficult to imagine causing problems. Plus judging by all the tests you
have written, it looks like your code is already pretty well tested.
In fact I only tested rewritten core functions intensively (on OSX and
Linux), for the extra's I just had a peek at the helpfiles so far, and
checked that there was no ridiculous output during normal use. So, I'm
not sure if it is wise to submit a patch file now. But I will try to
answer your questions below, one by one.
There are only a couple changes in this patch that are not no-brainers. The
first is in sigmund~.c, it looks like you just moved up the #ifdef PD and
#ifdef MSP blocks to the top of the file. Seems harmless enough.
These blocks had to move up because t_float was otherwise not known by
the compiler, for the first part of the code. It is now no longer the
case that the first part can be used without modification in an
arbitrary application, like it used to be the case. An application
programmer using this code for anything else than Pd/MaxMsp, should
define t_float in another way. A comment could be added to mention
that t_float may be float or double?
Then there are a couple places where the code is using 'f' to force
single precision, like:
@@ -677,8 +678,8 @@ static void bonk_doit(t_bonk *x)
{
if (x-x_useloudness)
growth += qrsqrt(qrsqrt(
- power/(h-h_mask[oldmaskphase] + 1.0e-15))) - 1.f;
- else growth += power/(h-h_mask[oldmaskphase] + 1.0e-15) -
1.f;
+ power/(h-h_mask[oldmaskphase] + 1.0e-15))) - 1.;
+ else growth += power/(h-h_mask[oldmaskphase] + 1.0e-15) -
1.;
}
if (!x-x_willattack countup = x-x_masktime)
maskpow *= x-x_maskdecay;
I removed float suffixes consistently from code which I came across.
In the case of 1., 2. etc. this is of no consequence for the actual
value, but for other numbers it is. For example a float 0.001 cast to
double precision becomes 0.001000474974513, while the double could
be precise almost up to it's last digit. There's a nice online applet
'IEEE 754 Converter' on
http://www.h-schmidt.net/FloatApplet/IEEE754.html, showing such
rounding effects. One could use the float suffix to make sure no
redundant typecasts are done, but in the case of code compilable for
single and double precision, it has no advantage to force single
precision.
I have seen it stated on internet that something like 'float f = 1.0'
cannot be compiled in C++, it should be 'float f = 1.0f'. However, in
practice I've not met such problems with C++. Hope this is true on any
platform (otherwise we're stuck).
And cases where there are added typedefs which I don't really understand
what's going on, like:
--- extra_original/expr~/vexp.h 2011-09-06 11:13:12.0 +0200
+++ extra_double_ready/expr~/vexp.h 2011-09-06 11:13:12.0 +0200
@@ -37,6 +37,7 @@
#else /* MSP */
#include ext.h
#include z_dsp.h
+typedef float t_float; // t_float is from m_pd.h
#endif
#include fts_to_pd.h
--- extra_original/fiddle~/fiddle~.c 2010-04-26 00:27:35.0 +0200
+++ extra_double_ready/fiddle~/fiddle~.c 2011-09-06 11:36:28.0
+0200
@@ -108,11 +108,11 @@ static fts_symbol_t *dsp_symbol = 0;
#endif /* MSP */
#ifdef MSP
-#define t_floatarg double
#include ext.h
#include z_dsp.h
#include fft_mayer.proto.h
-
+typedef float t_float;
+typedef double t_floatarg;
#endif /* MSP */
#include math.h
--- extra_original/loop~/loop~.c 2010-07-28 22:55:17.0 +0200
+++ extra_double_ready/loop~/loop~.c 2011-09-06 11:33:54.0 +0200
@@ -14,7 +14,8 @@ This file is downloadable from http://ww
#ifdef PD
#include m_pd.h
#else
-#define t_sample float
+typedef float t_float;
+typedef float t_sample;
#endif
--- extra_original/pd~/pd~.c 2010-07-28 22:55:17.0 +0200
+++ extra_double_ready/pd~/pd~.c 2011-09-06 11:38:12.0 +0200
@@ -26,7 +26,7 @@
#include ext_support.h
#include ext_proto.h
#include ext_obex.h
-
+typedef float t_float;
typedef double t_floatarg;
#define w_symbol w_sym
#define A_SYMBOL A_SYM
Ah these typedefs are nonsense indeed, t_float and t_floatarg are
defined in msp's zdsp.h as well, at least since Max/Msp5, earlier
versions I don't know.
Katja
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] getting double fixes into extra/
On Nov 8, 2011, at 8:32 PM, katja wrote:
On Tue, Nov 8, 2011 at 9:04 PM, Hans-Christoph Steiner h...@at.or.at wrote:
Hey Katja,
I was just reviewing the double precision patches for the extra/ section of
pure-data. I think we should try to get Miller to accept the 'extra/' fixes
into pure-data.git now. It seems to me that almost all of these changes are
just float -- t_float, which are really no-brainers that would be really
difficult to imagine causing problems. Plus judging by all the tests you
have written, it looks like your code is already pretty well tested.
In fact I only tested rewritten core functions intensively (on OSX and
Linux), for the extra's I just had a peek at the helpfiles so far, and
checked that there was no ridiculous output during normal use. So, I'm
not sure if it is wise to submit a patch file now. But I will try to
answer your questions below, one by one.
There are only a couple changes in this patch that are not no-brainers. The
first is in sigmund~.c, it looks like you just moved up the #ifdef PD and
#ifdef MSP blocks to the top of the file. Seems harmless enough.
These blocks had to move up because t_float was otherwise not known by
the compiler, for the first part of the code. It is now no longer the
case that the first part can be used without modification in an
arbitrary application, like it used to be the case. An application
programmer using this code for anything else than Pd/MaxMsp, should
define t_float in another way. A comment could be added to mention
that t_float may be float or double?
Then there are a couple places where the code is using 'f' to force
single precision, like:
@@ -677,8 +678,8 @@ static void bonk_doit(t_bonk *x)
{
if (x-x_useloudness)
growth += qrsqrt(qrsqrt(
-power/(h-h_mask[oldmaskphase] + 1.0e-15))) - 1.f;
-else growth += power/(h-h_mask[oldmaskphase] + 1.0e-15) -
1.f;
+power/(h-h_mask[oldmaskphase] + 1.0e-15))) - 1.;
+else growth += power/(h-h_mask[oldmaskphase] + 1.0e-15) -
1.;
}
if (!x-x_willattack countup = x-x_masktime)
maskpow *= x-x_maskdecay;
I removed float suffixes consistently from code which I came across.
In the case of 1., 2. etc. this is of no consequence for the actual
value, but for other numbers it is. For example a float 0.001 cast to
double precision becomes 0.001000474974513, while the double could
be precise almost up to it's last digit. There's a nice online applet
'IEEE 754 Converter' on
http://www.h-schmidt.net/FloatApplet/IEEE754.html, showing such
rounding effects. One could use the float suffix to make sure no
redundant typecasts are done, but in the case of code compilable for
single and double precision, it has no advantage to force single
precision.
I have seen it stated on internet that something like 'float f = 1.0'
cannot be compiled in C++, it should be 'float f = 1.0f'. However, in
practice I've not met such problems with C++. Hope this is true on any
platform (otherwise we're stuck).
And cases where there are added typedefs which I don't really understand
what's going on, like:
--- extra_original/expr~/vexp.h 2011-09-06 11:13:12.0 +0200
+++ extra_double_ready/expr~/vexp.h 2011-09-06 11:13:12.0 +0200
@@ -37,6 +37,7 @@
#else /* MSP */
#include ext.h
#include z_dsp.h
+typedef float t_float; // t_float is from m_pd.h
#endif
#include fts_to_pd.h
--- extra_original/fiddle~/fiddle~.c2010-04-26 00:27:35.0 +0200
+++ extra_double_ready/fiddle~/fiddle~.c2011-09-06
11:36:28.0 +0200
@@ -108,11 +108,11 @@ static fts_symbol_t *dsp_symbol = 0;
#endif /* MSP */
#ifdef MSP
-#define t_floatarg double
#include ext.h
#include z_dsp.h
#include fft_mayer.proto.h
-
+typedef float t_float;
+typedef double t_floatarg;
#endif /* MSP */
#include math.h
--- extra_original/loop~/loop~.c2010-07-28 22:55:17.0 +0200
+++ extra_double_ready/loop~/loop~.c2011-09-06 11:33:54.0 +0200
@@ -14,7 +14,8 @@ This file is downloadable from http://ww
#ifdef PD
#include m_pd.h
#else
-#define t_sample float
+typedef float t_float;
+typedef float t_sample;
#endif
--- extra_original/pd~/pd~.c2010-07-28 22:55:17.0 +0200
+++ extra_double_ready/pd~/pd~.c2011-09-06 11:38:12.0 +0200
@@ -26,7 +26,7 @@
#include ext_support.h
#include ext_proto.h
#include ext_obex.h
-
+typedef float t_float;
typedef double t_floatarg;
#define w_symbol w_sym
#define A_SYMBOL A_SYM
Ah these typedefs are nonsense indeed, t_float and t_floatarg are
defined in msp's zdsp.h as well, at least since Max/Msp5, earlier
versions I don't know.
Ah I see, they are for Max/MSP only? I didn't notice that before. So I guess
the thing to do
