[PD] what's the deal with [utime] object?

Jonathan Wilkes jancsika at yahoo.com
Sat Feb 27 18:09:34 CET 2016


> 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 at 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 at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160227/dfa4c06e/attachment.html>


More information about the Pd-list mailing list