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
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
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
the t_atom - Tcl_Obj converasion happens in tcl_class.c
using the pdatom_to_tcl function (defined in tcl_typemap.c)
since pd has only one numeric type (float), the conversion is as follows:
switch (input-a_type) {
[...]
case A_FLOAT: {
tcl_t_atom[0] = Tcl_NewStringObj(float, -1);
I'm interpretting lists as filenames with spaces in it. Its a hack, I know,
but it works well for the most part. So something like:
[this contains 20 rows.csv(
Would give me this contains 20.0 rows.csv in tclpd. Perhaps just the proc
pd::strip_selectors could do the %g formatting. That's
Bugs item #3437142, was opened at 2011-11-12 20:11
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=478070aid=3437142group_id=55736
Please note that this message will contain a full copy of the
