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