> hmm, what again was wrong with my proposal to distinguish between single
and double precision externals, allowing to have externals that would

work on both precisions ("phat")?

The problem I'm describing is how to distinguish between the externals with

t_float=double that work as they should, and the externals with t_float=double

whose insides turn rotten.

For example,

Matt mentioned one example with regard to internal signal classes that rely on

a trick that can't be used when t_float=double. Just those classes are a research

project by themselves.

And that's just a single issue with type punning. I doubt that's the only issue that

can crop up from changing a data type like this, esp. when a lot of the external

code seems to assume that t_float would only ever be an alias for float.

-Jonathan

On Saturday, February 27, 2016 11:31 AM, IOhannes m zmölnig <zmoelnig@iem.at> wrote:

On 02/27/2016 04:49 PM, Jonathan Wilkes via Pd-list wrote:
>> we should have switched to doubles long ago.
> According to katja, that would trigger a zombie apocalypse in external land.

first of all, we should have switched to doubles *long* ago.

> And the only way to tell the zombies from the survivors would be to... *gulp*...
> actually read external library code.
> Personally, I'd rather get eaten by a zombie than do that.

hmm, what again was wrong with my proposal to distinguish between single
and double precision externals, allowing to have externals that would
work on both precisions ("phat")?

it would probably lead to mass extinction of externals that have no
source code available (which - unlike zombie apocalypse - is probably a
good thing anyhow).

gmdsar

IOhannes

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list