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

[Jonathan Wilkes via Pd-list]

> actually i think that a lot of code to review could be identified with a
grep for "\bfloat\b", so the chores might not be so horrific.
I doubt that would find everything, but that's certainly a good starting point 
if you're interested in pursuing this.
-Jonathan 

On Sunday, February 28, 2016 6:06 PM, IOhannes m zmölnig  
wrote:
 

 On 02/27/2016 06:09 PM, Jonathan Wilkes via Pd-list wrote:
>> 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")?
[...]
> 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.

ah, that's a different case.
in my memories katjas conclusion was not so drastic though.

>> 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.

actually i think that a lot of code to review could be identified with a
grep for "\bfloat\b", so the chores might not be so horrific.

gmards
IOhannes



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


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

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

[IOhannes m zmölnig]

On 02/27/2016 06:09 PM, Jonathan Wilkes via Pd-list wrote:
>> 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")?
[...]
> 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.

ah, that's a different case.
in my memories katjas conclusion was not so drastic though.

>> 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.

actually i think that a lot of code to review could be identified with a
grep for "\bfloat\b", so the chores might not be so horrific.

gmards
IOhannes





signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Jack]

Le 27/02/2016 17:31, IOhannes m zmölnig a écrit :
> 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).


Are you sure [1][2][3] ?
++

Jack

[1] Night of the Living Dead
https://en.wikipedia.org/wiki/Night_of_the_Living_Dead
[2] Dawn of the dead
https://en.wikipedia.org/wiki/Dawn_of_the_Dead_%281978_film%29
[3] Day of the Dead
https://en.wikipedia.org/wiki/Day_of_the_Dead_%281985_film%29


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




signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Jack]

Le 27/02/2016 16:49, Jonathan Wilkes via Pd-list a écrit :
>> we should have switched to doubles long ago.
> 
> According to katja, that would trigger a zombie apocalypse in external
> land. 
> 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.

Are you sure [1][2][3] ?
++

Jack

[1] Night of the Living Dead
https://en.wikipedia.org/wiki/Night_of_the_Living_Dead
[2] Dawn of the dead
https://en.wikipedia.org/wiki/Dawn_of_the_Dead_%281978_film%29
[3] Day of the Dead
https://en.wikipedia.org/wiki/Day_of_the_Dead_%281985_film%29


> 
> -Jonathan
> 
> 
> 
> On Saturday, February 27, 2016 10:31 AM, IOhannes m zmölnig
>  wrote:
> 
> 
> On 02/27/2016 09:55 AM, William Huston wrote:
>> I really wish Pd had a 32 bit integer data type for counters, and other
>> places where integers are appropriate.
> 
> actually i strongly disagree: i think it is one of Pd's killer features
> to have a single numeric type.
> 
> the only problem is that the actually used numeric type (single
> precision floating point) is rather limited.
> we should have switched to doubles long ago.
> 
> gfmdsar
> 
> IOhannes
> 
> 
> ___
> Pd-list@lists.iem.at  mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> 
> 
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
> 


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

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

[Jonathan Wilkes via Pd-list]

> 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  
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


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

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

[IOhannes m zmölnig]

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



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Jonathan Wilkes via Pd-list]

> It would change some pretty major things in vanilla, too. For instance, 
> [phasor~], [osc~], and [tabosc4~] all depend on a bit-manipulation trick to 
> wrap phase, which won't work with doubles.
katja addressed this with Pd Double.  
See:http://www.katjaas.nl/doubleprecision/doubleprecision.html
See the "benchmarks" section of that link.
-Jonathan

 

On Saturday, February 27, 2016 11:05 AM, Matt Barber  
wrote:
 

 It would change some pretty major things in vanilla, too. For instance, 
[phasor~], [osc~], and [tabosc4~] all depend on a bit-manipulation trick to 
wrap phase, which won't work with doubles. I'm not sure if the output is any 
different, but it does save the per-sample bounds check and is theoretically 
faster.
On Sat, Feb 27, 2016 at 10:49 AM, 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.  
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.
-Jonathan



On Saturday, February 27, 2016 10:31 AM, IOhannes m zmölnig 
 wrote:
 

 On 02/27/2016 09:55 AM, William Huston wrote:
> I really wish Pd had a 32 bit integer data type for counters, and other
> places where integers are appropriate.

actually i strongly disagree: i think it is one of Pd's killer features
to have a single numeric type.

the only problem is that the actually used numeric type (single
precision floating point) is rather limited.
we should have switched to doubles long ago.

gfmdsar
IOhannes


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


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





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

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

[Matt Barber]

It would change some pretty major things in vanilla, too. For instance,
[phasor~], [osc~], and [tabosc4~] all depend on a bit-manipulation trick to
wrap phase, which won't work with doubles. I'm not sure if the output is
any different, but it does save the per-sample bounds check and is
theoretically faster.

On Sat, Feb 27, 2016 at 10:49 AM, Jonathan Wilkes via Pd-list <
pd-list@lists.iem.at> wrote:

> > we should have switched to doubles long ago.
>
> According to katja, that would trigger a zombie apocalypse in external
> land.
> 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.
>
> -Jonathan
>
>
>
> On Saturday, February 27, 2016 10:31 AM, IOhannes m zmölnig <
> zmoel...@iem.at> wrote:
>
>
> On 02/27/2016 09:55 AM, William Huston wrote:
> > I really wish Pd had a 32 bit integer data type for counters, and other
> > places where integers are appropriate.
>
> actually i strongly disagree: i think it is one of Pd's killer features
> to have a single numeric type.
>
> the only problem is that the actually used numeric type (single
> precision floating point) is rather limited.
> we should have switched to doubles long ago.
>
> gfmdsar
>
> IOhannes
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[Jonathan Wilkes via Pd-list]

> we should have switched to doubles long ago.
According to katja, that would trigger a zombie apocalypse in external land.  
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.
-Jonathan



On Saturday, February 27, 2016 10:31 AM, IOhannes m zmölnig 
 wrote:
 

 On 02/27/2016 09:55 AM, William Huston wrote:
> I really wish Pd had a 32 bit integer data type for counters, and other
> places where integers are appropriate.

actually i strongly disagree: i think it is one of Pd's killer features
to have a single numeric type.

the only problem is that the actually used numeric type (single
precision floating point) is rather limited.
we should have switched to doubles long ago.

gfmdsar
IOhannes


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


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

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

[IOhannes m zmölnig]

On 02/27/2016 09:40 AM, s p wrote:
> Yes, I guessed the issue was with precision, but in that case why would
> anyone want to use it?

[utime]? i have no idea.
what's worse: i have no clue why anyone would *write* that object with
the given limitations of a single precision Pd.

gmasrd
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[IOhannes m zmölnig]

On 02/27/2016 09:55 AM, William Huston wrote:
> I really wish Pd had a 32 bit integer data type for counters, and other
> places where integers are appropriate.

actually i strongly disagree: i think it is one of Pd's killer features
to have a single numeric type.

the only problem is that the actually used numeric type (single
precision floating point) is rather limited.
we should have switched to doubles long ago.

gfmdsar
IOhannes




signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[William Huston]

I really wish Pd had a 32 bit integer data type for counters, and other
places where integers are appropriate.

This problem with single precision floats is my #1 gripe/ buzz-killer

(but overall, I am very, very happy with Pd!)

e.g. I spent aa few hours with it, but was unable to master the onset inlet
of [tabread4~], and find the example to be highly contrived and hard to
understand.

The Perl programming language had a very amazing mechanism. There is only a
"scalar" datatype, which can be (depending on context), a character string,
a float, or an integer.

There was some real genius under the hood which did automatic conversions
when necessary, so the programmer didn't really have to worry about it. The
runtime (a hybrid compiler/interpreter) always would do the right thing.

Not sure if there are any lessons from Perl we can borrow, or if the
intelligence is to costly for real-time.

BH

On Saturday, February 27, 2016, s p  wrote:
> Yes, I guessed the issue was with precision, but in that case why would
anyone want to use it?
> I was about to use [zexy/time], but [utime] would have been so much
simpler in my case ...
>
> On Sat, Feb 27, 2016 at 10:23 AM, IOhannes m zmölnig 
wrote:
>>
>> On 02/27/2016 12:34 AM, s p wrote:
>> > Hi!
>> >
>> > I am trying to use [utime] to get an absolute date in seconds since
epoch.
>> > However, the number of seconds seems to be rounded, so I don't
understand
>> > how is it of any use!? For example, the following patch prints 0 ...
>> >
>>
>> short answer: single precision floating point precision.
>>
>> depending on your use-case, you probably can use zexy's [date] and
>> [time] objects instead.
>>
>> gmdsar
>> IOhannes
>>
>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
>>
>
>
>
> --
> Sébastien Piquemal
>
>  - @sebpiq
>  - http://github.com/sebpiq
>  - http://funktion.fm
>

-- 
--
May you, and all beings
be happy and free from suffering :)
-- ancient Buddhist Prayer (Metta)
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[s p]

Yes, I guessed the issue was with precision, but in that case why would
anyone want to use it?
I was about to use [zexy/time], but [utime] would have been so much simpler
in my case ...

On Sat, Feb 27, 2016 at 10:23 AM, IOhannes m zmölnig 
wrote:

> On 02/27/2016 12:34 AM, s p wrote:
> > Hi!
> >
> > I am trying to use [utime] to get an absolute date in seconds since
> epoch.
> > However, the number of seconds seems to be rounded, so I don't understand
> > how is it of any use!? For example, the following patch prints 0 ...
> >
>
> short answer: single precision floating point precision.
>
> depending on your use-case, you probably can use zexy's [date] and
> [time] objects instead.
>
> gmdsar
> IOhannes
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>


-- 

*Sébastien Piquemal*

 -* @sebpiq*
 - http://github.com/sebpiq
 - http://funktion.fm
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[IOhannes m zmölnig]

On 02/27/2016 12:34 AM, s p wrote:
> Hi!
> 
> I am trying to use [utime] to get an absolute date in seconds since epoch.
> However, the number of seconds seems to be rounded, so I don't understand
> how is it of any use!? For example, the following patch prints 0 ...
> 

short answer: single precision floating point precision.

depending on your use-case, you probably can use zexy's [date] and
[time] objects instead.

gmdsar
IOhannes




signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[s p]

Hi!

I am trying to use [utime] to get an absolute date in seconds since epoch.
However, the number of seconds seems to be rounded, so I don't understand
how is it of any use!? For example, the following patch prints 0 ...

[image: Inline image 1]

-- 

*Sébastien Piquemal*

 -* @sebpiq*
 - http://github.com/sebpiq
 - http://funktion.fm


utime-demo.pd
Description: application/pd
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list