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