externals implementing PD_FLOAT_PRECISION can't be compiled against pure-data, libpd, pd-l2ork etc
We now have PD_FLOAT_PRECISION in the Pd-extended API (even though it's value is still fixed at 32) and in Pd-double. This macro is sometimes needed for conditional compilation when making external libs ready for double precision. For example, to call sf_read_float() or sf_read_double() in libsndfile, or in case of a type punning trick which must be defined according to data type.
Libs which use PD_FLOAT_PRECISION for such reason, are no longer compilable against pure-data, libpd, pd-l2ork and other types of pd. This is now the case for creb and smlib, for which I committed double-ready changes this week.
Before I proceed committing to other libs, this issue should discussed with authors and maintainers of pure-data, it's forks, and external libraries. Historically, external libs have always been compilable against Pd flavours other than Pd-extended, no? It would be an awkward experience for anyone unsuspectingly copying a lib's latest revision from pure-data.svn and find it's no longer compatible with Pd other than Pd-extended and Pd-double! Technically, the solution is simple: a line '#define PD_FLOAT_PRECISION 32' in the API's would restore compatibility, when t_float etc. are still typedef'ed as float. It is not so elegant we have to bother many people with our double precision efforts, but it's impossible to develop this in isolation.
Katja
To answer my own mail, let's just do this whenever using PD_FLOAT_PRECISION:
#ifndef PD_FLOAT_PRECISION #define PD_FLOAT_PRECISION 32 #endif
to make sure code remains compilable against all sorts of Pd. When PD_FLOAT_PRECISION is not defined, it is safe to assume t_float etc are float.
Katja
On Sat, Nov 12, 2011 at 3:30 PM, katja katjavetter@gmail.com wrote:
We now have PD_FLOAT_PRECISION in the Pd-extended API (even though it's value is still fixed at 32) and in Pd-double. This macro is sometimes needed for conditional compilation when making external libs ready for double precision. For example, to call sf_read_float() or sf_read_double() in libsndfile, or in case of a type punning trick which must be defined according to data type.
Libs which use PD_FLOAT_PRECISION for such reason, are no longer compilable against pure-data, libpd, pd-l2ork and other types of pd. This is now the case for creb and smlib, for which I committed double-ready changes this week.
Before I proceed committing to other libs, this issue should discussed with authors and maintainers of pure-data, it's forks, and external libraries. Historically, external libs have always been compilable against Pd flavours other than Pd-extended, no? It would be an awkward experience for anyone unsuspectingly copying a lib's latest revision from pure-data.svn and find it's no longer compatible with Pd other than Pd-extended and Pd-double! Technically, the solution is simple: a line '#define PD_FLOAT_PRECISION 32' in the API's would restore compatibility, when t_float etc. are still typedef'ed as float. It is not so elegant we have to bother many people with our double precision efforts, but it's impossible to develop this in isolation.
Katja
That's a good idea for now for a workaround.
In the case of type-punning, I think that code should be replaced with something that uses a different technique rather than making separate type punning for 32 and 64 bits. I think unions can be used in many of those situations. Type punning is very deprecated and not allowed in the C99 standard (which is 12 years old).
.hc
On Nov 12, 2011, at 9:56 AM, katja wrote:
To answer my own mail, let's just do this whenever using PD_FLOAT_PRECISION:
#ifndef PD_FLOAT_PRECISION #define PD_FLOAT_PRECISION 32 #endif
to make sure code remains compilable against all sorts of Pd. When PD_FLOAT_PRECISION is not defined, it is safe to assume t_float etc are float.
Katja
On Sat, Nov 12, 2011 at 3:30 PM, katja katjavetter@gmail.com wrote:
We now have PD_FLOAT_PRECISION in the Pd-extended API (even though it's value is still fixed at 32) and in Pd-double. This macro is sometimes needed for conditional compilation when making external libs ready for double precision. For example, to call sf_read_float() or sf_read_double() in libsndfile, or in case of a type punning trick which must be defined according to data type.
Libs which use PD_FLOAT_PRECISION for such reason, are no longer compilable against pure-data, libpd, pd-l2ork and other types of pd. This is now the case for creb and smlib, for which I committed double-ready changes this week.
Before I proceed committing to other libs, this issue should discussed with authors and maintainers of pure-data, it's forks, and external libraries. Historically, external libs have always been compilable against Pd flavours other than Pd-extended, no? It would be an awkward experience for anyone unsuspectingly copying a lib's latest revision from pure-data.svn and find it's no longer compatible with Pd other than Pd-extended and Pd-double! Technically, the solution is simple: a line '#define PD_FLOAT_PRECISION 32' in the API's would restore compatibility, when t_float etc. are still typedef'ed as float. It is not so elegant we have to bother many people with our double precision efforts, but it's impossible to develop this in isolation.
Katja
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
"Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman
On Sat, Nov 12, 2011 at 4:43 PM, Hans-Christoph Steiner hans@at.or.at wrote:
In the case of type-punning, I think that code should be replaced with something that uses a different technique rather than making separate type punning for 32 and 64 bits. I think unions can be used in many of those situations. Type punning is very deprecated and not allowed in the C99 standard (which is 12 years old).
Yes I replace all type punning with unions, in the way PD_BIGORSMALL is defined in Pd-extended and Pd-double. It is a kind of 'legitimate type punning', still a way to access a float variable as an int, and Qt devs reportedly had problems with such a method. See http://labs.qt.nokia.com/2011/06/10/type-punning-and-strict-aliasing/. I've also experimented with memcpy(), this is completely safe, and not expensive because memcpy() translates to a single instruction for a float or double. But the disadvantage is, it needs <string.h>, and I did not want to include <string.h> in m_pd.h because it would be included in every executable then.
Katja
-
Hans-Christoph Steiner -
katja