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]
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
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 zmoelnig@iem.at 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
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 sebpiq@gmail.com 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 zmoelnig@iem.at
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
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
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 <zmoelnig@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
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 < zmoelnig@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
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 <brbrofsvl@gmail.com> 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 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 <zmoelnig@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
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
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
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
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 <zmoelnig@iem.at> 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
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
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 zmoelnig@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 mailto: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
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
-
IOhannes m zmölnig -
Jack -
Jonathan Wilkes -
Matt Barber -
s p -
William Huston