Since Pd only has 19bits of integer resolution, we can't use UNIX time within Pd. So I was thinking that perhaps ISO format would would well in Pd since its a symbol:
For example:
Today is 2006-06-12. This email was sent written at 12:40:23. All of this can be lumped together as 20060612T124023. I am not sure if this ISO unified date/time format officially supports fractional seconds, but since it does support fractional seconds in the time (12:40:23.2342), and the digit positions are fixed, so I think we can easily just tack on fractional seconds like this: 20060612T124023.2342. I think keeping the "." is preferable since ISO 8601 says 12:40:23.2342 can be shorted to 124023.2342, but I didn't see mention of 1240232342.
One problem is that ISO 8601 allows you to omit the separators "-" and ":", which would then make it a float in Pd, and therefore it would be truncated to 6 digits. So we couldn't support that.
Here's a page all about ISO 8601 date/time formats:
http://www.cl.cam.ac.uk/~mgk25/iso-time.html#time
Thoughts? Comments? Flames? ;)
.hc
------------------------------------------------------------------------
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
Looking at this page, I am thinking maybe the unified format should keep the separators:
http://www.w3.org/TR/NOTE-datetime
Complete date plus hours and minutes: YYYY-MM-DDThh:mmTZD (eg 1997-07-16T19:20+01:00) Complete date plus hours, minutes and seconds: YYYY-MM-DDThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00) Complete date plus hours, minutes, seconds and a decimal fraction of a second YYYY-MM-DDThh:mm:ss.sTZD (eg 1997-07-16T19:20:30.45+01:00)
.hc
On Jun 12, 2006, at 12:47 PM, Hans-Christoph Steiner wrote:
Since Pd only has 19bits of integer resolution, we can't use UNIX time within Pd. So I was thinking that perhaps ISO format would would well in Pd since its a symbol:
For example:
Today is 2006-06-12. This email was sent written at 12:40:23. All of this can be lumped together as 20060612T124023. I am not sure if this ISO unified date/time format officially supports fractional seconds, but since it does support fractional seconds in the time (12:40:23.2342), and the digit positions are fixed, so I think we can easily just tack on fractional seconds like this: 20060612T124023.2342. I think keeping the "." is preferable since ISO 8601 says 12:40:23.2342 can be shorted to 124023.2342, but I didn't see mention of 1240232342.
One problem is that ISO 8601 allows you to omit the separators "-" and ":", which would then make it a float in Pd, and therefore it would be truncated to 6 digits. So we couldn't support that.
Here's a page all about ISO 8601 date/time formats:
http://www.cl.cam.ac.uk/~mgk25/iso-time.html#time
Thoughts? Comments? Flames? ;)
.hc
--
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
------------------------------------------------------------------------
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
Hi all, it may depend on the actual application, but generally i don't think that symbols are a good idea. Every generated symbol uses an entry in the symbol table and stays in memory until PD is restarted, which effectively is a memory leak for varying data. Since i use messages like [double hi lo( with summed single-precision parts hi and lo to represent double-precision numbers, i would suggest something like [date ymd hms( where ymd and hms are some numbers that get encoded and decoded by some objects.
greetings, Thomas
Am 12.06.2006 um 18:47 schrieb Hans-Christoph Steiner:
Since Pd only has 19bits of integer resolution, we can't use UNIX time within Pd. So I was thinking that perhaps ISO format would would well in Pd since its a symbol:
For example:
Today is 2006-06-12. This email was sent written at 12:40:23. All of this can be lumped together as 20060612T124023. I am not sure if this ISO unified date/time format officially supports fractional seconds, but since it does support fractional seconds in the time (12:40:23.2342), and the digit positions are fixed, so I think we can easily just tack on fractional seconds like this: 20060612T124023.2342. I think keeping the "." is preferable since ISO 8601 says 12:40:23.2342 can be shorted to 124023.2342, but I didn't see mention of 1240232342.
One problem is that ISO 8601 allows you to omit the separators "-" and ":", which would then make it a float in Pd, and therefore it would be truncated to 6 digits. So we couldn't support that.
Here's a page all about ISO 8601 date/time formats:
http://www.cl.cam.ac.uk/~mgk25/iso-time.html#time
Thoughts? Comments? Flames? ;)
.hc
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Yeah, I guess that makes sense to avoid symbols. In which case, it probably makes sense to split up the UNIX time_t into two numbers, the first is the date in days, the maximum being 49,710 days, then the time of day in seconds, the maximum being 86,400 seconds, then the number of fractional seconds as a float (eg. 0.023414)
It seems to me that breaking up the time into each component leads to some very long lists, so this method would be more compact. The parsing of this format could easily be done with Pd core.
.hc
On Jun 12, 2006, at 1:28 PM, Thomas Grill wrote:
Hi all, it may depend on the actual application, but generally i don't think that symbols are a good idea. Every generated symbol uses an entry in the symbol table and stays in memory until PD is restarted, which effectively is a memory leak for varying data. Since i use messages like [double hi lo( with summed single- precision parts hi and lo to represent double-precision numbers, i would suggest something like [date ymd hms( where ymd and hms are some numbers that get encoded and decoded by some objects.
greetings, Thomas
Am 12.06.2006 um 18:47 schrieb Hans-Christoph Steiner:
Since Pd only has 19bits of integer resolution, we can't use UNIX time within Pd. So I was thinking that perhaps ISO format would would well in Pd since its a symbol:
For example:
Today is 2006-06-12. This email was sent written at 12:40:23. All of this can be lumped together as 20060612T124023. I am not sure if this ISO unified date/time format officially supports fractional seconds, but since it does support fractional seconds in the time (12:40:23.2342), and the digit positions are fixed, so I think we can easily just tack on fractional seconds like this: 20060612T124023.2342. I think keeping the "." is preferable since ISO 8601 says 12:40:23.2342 can be shorted to 124023.2342, but I didn't see mention of 1240232342.
One problem is that ISO 8601 allows you to omit the separators "-" and ":", which would then make it a float in Pd, and therefore it would be truncated to 6 digits. So we couldn't support that.
Here's a page all about ISO 8601 date/time formats:
http://www.cl.cam.ac.uk/~mgk25/iso-time.html#time
Thoughts? Comments? Flames? ;)
.hc
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson
Yeah, I guess that makes sense to avoid symbols. In which case, it probably makes sense to split up the UNIX time_t into two numbers
Since i use messages like [double hi lo( with summed single-precision parts hi and lo to represent double-precision numbers, i would suggest something like [date ymd hms( where ymd and hms are some numbers that get encoded and decoded by some objects.
imo using the integer (float for subseconds) unixdate would be preferable, since it easily lends itself to simple processing - like adding 90 seconds without thinking about rolling over to the minute field. or nesting a set of abstractions for minute, hour, day, january, etc.. if pd can't really store the unix timestamp without munging it, that should be fixed.
Since Pd only has 19bits of integer resolution
are you sure about this? i seem to recall matju explaining its 23 bits or so..
On Jun 12, 2006, at 3:46 PM, carmen wrote:
Yeah, I guess that makes sense to avoid symbols. In which case, it probably makes sense to split up the UNIX time_t into two numbers
Since i use messages like [double hi lo( with summed single- precision parts hi and lo to represent double-precision numbers, i would suggest something like [date ymd hms( where ymd and hms are some numbers that get encoded and decoded by some objects.
imo using the integer (float for subseconds) unixdate would be preferable, since it easily lends itself to simple processing - like adding 90 seconds without thinking about rolling over to the minute field. or nesting a set of abstractions for minute, hour, day, january, etc.. if pd can't really store the unix timestamp without munging it, that should be fixed.
Since Pd only has 19bits of integer resolution
are you sure about this? i seem to recall matju explaining its 23 bits or so..
Either way, 32bits are needed for UNIX time. And making Pd support 32 bit ints would be a massive, fundamental change. The only option is get a 64-bit machine, then Pd will be able to represent 32 bit ints in a 64-bit float.
.hc
------------------------------------------------------------------------
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
On Mon, 12 Jun 2006, Hans-Christoph Steiner wrote:
Since Pd only has 19bits of integer resolution
are you sure about this? i seem to recall matju explaining its 23 bits or so..
PDa uses 19 bits for its fixed point representation, maybe thats where you got this number from ...
Günter
On Jun 15, 2006, at 4:53 AM, geiger wrote:
On Mon, 12 Jun 2006, Hans-Christoph Steiner wrote:
Since Pd only has 19bits of integer resolution
are you sure about this? i seem to recall matju explaining its 23 bits or so..
PDa uses 19 bits for its fixed point representation, maybe thats where you got this number from ...
Günter
999,999 is the largest number that can be represented in Pd without scientific notation. 999,999 in binary is:
1111 0100 0010 0011 1111
But Pd cannot represent this number exactly:
1111 1111 1111 1111 1111 (1,048,575)
but it can represent this number exactly:
0111 1111 1111 1111 1111 (524,287)
Therefore Pd can represent 19-bits of integer accurately.
.hc
------------------------------------------------------------------------
On Thu, 15 Jun 2006, Hans-Christoph Steiner wrote:
999,999 is the largest number that can be represented in Pd without scientific notation. 999,999 in binary is: 1111 0100 0010 0011 1111 But Pd cannot represent this number exactly: 1111 1111 1111 1111 1111 (1,048,575) but it can represent this number exactly: 0111 1111 1111 1111 1111 (524,287) Therefore Pd can represent 19-bits of integer accurately.
That's about right. (But then, the most significant bit is usually considered implicit because it's always worth 1: so that would be 18 bits instead)
But that's for text formats. As long as the data isn't converted to ascii decimals, there's still 23 bits (plus 1 implicit bit).
(Pd can be tweaked to display all bits during bin->dec conversion, but i'm not sure that it's worth it...)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Quoting Hans-Christoph Steiner hans@eds.org:
Yeah, I guess that makes sense to avoid symbols. In which case, it probably makes sense to split up the UNIX time_t into two numbers, the first is the date in days, the maximum being 49,710 days, then the time of day in seconds, the maximum being 86,400 seconds, then the number of fractional seconds as a float (eg. 0.023414)
It seems way more logical to me to split it into years and day of year at least. Of course we could work with katuns and tuns like the Maya, it's arguably a more rational system ;). Martin
It seems to me that breaking up the time into each component leads to some very long lists, so this method would be more compact. The parsing of this format could easily be done with Pd core.
A 7-component list is too much for pd?
Martin
On Jun 12, 2006, at 7:37 PM, martinrp@alcor.concordia.ca wrote:
Quoting Hans-Christoph Steiner hans@eds.org:
Yeah, I guess that makes sense to avoid symbols. In which case, it probably makes sense to split up the UNIX time_t into two numbers, the first is the date in days, the maximum being 49,710 days, then the time of day in seconds, the maximum being 86,400 seconds, then the number of fractional seconds as a float (eg. 0.023414)
It seems way more logical to me to split it into years and day of year at least. Of course we could work with katuns and tuns like the Maya, it's arguably a more rational system ;). Martin
It seems to me that breaking up the time into each component leads to some very long lists, so this method would be more compact. The parsing of this format could easily be done with Pd core.
A 7-component list is too much for pd?
Not at all. But dealing with 7 component lists means a lot of cord connections, which is not so fun. I just wrote a [stat] object to get info from files. It outputs access-time, modification-time, and status-change-time. That's 18 elements instead of 6, plus there are already 7 other properties output.
Plus I think its a neat breakdown the first element in days is equal to the date, so today is 13312, which is exactly equal to 2006-06-13. Right now, its 39325, which converts perfectly to 10:55:25. Then one more number for microseconds (since Pd can only do up to 6 digits). It seems quite clean to me, considering the limitations.
.hc
------------------------------------------------------------------------
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
Quoting Hans-Christoph Steiner hans@eds.org:
On Jun 12, 2006, at 7:37 PM, martinrp@alcor.concordia.ca wrote:
Quoting Hans-Christoph Steiner hans@eds.org:
Yeah, I guess that makes sense to avoid symbols. In which case, it probably makes sense to split up the UNIX time_t into two numbers, the first is the date in days, the maximum being 49,710 days, then the time of day in seconds, the maximum being 86,400 seconds, then the number of fractional seconds as a float (eg. 0.023414)
It seems way more logical to me to split it into years and day of year at
least. Of course we could work with katuns and tuns like the Maya, it's arguably a more rational system ;). Martin
It seems to me that breaking up the time into each component leads to some very long lists, so this method would be more compact. The parsing of this format could easily be done with Pd core.
A 7-component list is too much for pd?
Not at all. But dealing with 7 component lists means a lot of cord connections, which is not so fun. I just wrote a [stat] object to get info from files. It outputs access-time, modification-time, and status-change-time. That's 18 elements instead of 6, plus there are already 7 other properties output.
Plus I think its a neat breakdown the first element in days is equal to the date, so today is 13312, which is exactly equal to 2006-06-13. Right now, its 39325, which converts perfectly to 10:55:25. Then one more number for microseconds (since Pd can only do up to 6 digits). It seems quite clean to me, considering the limitations.
With that method you need another object to convert from raw days to the actual date. I'm not sure you really save on patch cords. Also you need to specify what date day zero refers to. What about using the Julian date, it's more of an international standard than Unix time?
Martin
.hc
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
On Jun 13, 2006, at 11:51 AM, martinrp@alcor.concordia.ca wrote:
Quoting Hans-Christoph Steiner hans@eds.org:
On Jun 12, 2006, at 7:37 PM, martinrp@alcor.concordia.ca wrote:
Quoting Hans-Christoph Steiner hans@eds.org:
Yeah, I guess that makes sense to avoid symbols. In which case, it probably makes sense to split up the UNIX time_t into two numbers, the first is the date in days, the maximum being 49,710 days, then the time of day in seconds, the maximum being 86,400 seconds, then the number of fractional seconds as a float (eg. 0.023414)
It seems way more logical to me to split it into years and day of year at
least. Of course we could work with katuns and tuns like the Maya, it's arguably a more rational system ;). Martin
It seems to me that breaking up the time into each component leads to some very long lists, so this method would be more compact. The parsing of this format could easily be done with Pd core.
A 7-component list is too much for pd?
Not at all. But dealing with 7 component lists means a lot of cord connections, which is not so fun. I just wrote a [stat] object to get info from files. It outputs access-time, modification-time, and status-change-time. That's 18 elements instead of 6, plus there are already 7 other properties output.
Plus I think its a neat breakdown the first element in days is equal to the date, so today is 13312, which is exactly equal to 2006-06-13. Right now, its 39325, which converts perfectly to 10:55:25. Then one more number for microseconds (since Pd can only do up to 6 digits). It seems quite clean to me, considering the limitations.
With that method you need another object to convert from raw days to the actual date. I'm not sure you really save on patch cords. Also you need to specify what date day zero refers to. What about using the Julian date, it's more of an international standard than Unix time?
Martin
I figure mostly people will be using dates to compare things. Either way, you'll want to have some objects to do things with dates since neither format allows straight comparison. But it wouldn't be too hard to make objects in Pd that support lists of 1-3 for the date/day/ microseconds or lists of 5-7 for year/month/day/hour/minute/second/ microsecond format.
Using a common standard like UNIX time or Julian date would be much preferred, but we are limited to 6 digits, so neither one of them works until Pd is all 64-bit.
.hc
------------------------------------------------------------------------
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I figure mostly people will be using dates to compare things. Either way, you'll want to have some objects to do things with dates since neither format allows straight comparison. But it wouldn't be too hard to make objects in Pd that support lists of 1-3 for the date/day/ microseconds or lists of 5-7 for year/month/day/hour/minute/second/ microsecond format.
You could use [list-idx] to get at a certain list element and [list-replace] to write it back at a certain position. Both are abstractions from [list]-abs and they are fairly fast list-processing objects as they don't need [list-drip], they just split lists.
Ciao
I also ran into this when attempting to use IP addresses. The solution I came up with was to make the address a list of floats like 192 168 0 1. I think it's more useful to do this with dates as well: a list 2006 6 12 12 0 0 is much easier to manipulate in pd than a symbol, which would need its own external to parse. I wrote a timestamp external a few months ago that outputs a list of floats as [year month day hour minute second millisecond] but I have a horrible feeling the only copy is on a dead hard drive :(. It's easy enough to reconstruct though.
Martin
Quoting Hans-Christoph Steiner hans@eds.org:
Since Pd only has 19bits of integer resolution, we can't use UNIX time within Pd. So I was thinking that perhaps ISO format would would well in Pd since its a symbol:
For example:
Today is 2006-06-12. This email was sent written at 12:40:23. All of this can be lumped together as 20060612T124023. I am not sure if this ISO unified date/time format officially supports fractional seconds, but since it does support fractional seconds in the time (12:40:23.2342), and the digit positions are fixed, so I think we can easily just tack on fractional seconds like this: 20060612T124023.2342. I think keeping the "." is preferable since ISO 8601 says 12:40:23.2342 can be shorted to 124023.2342, but I didn't see mention of 1240232342.
One problem is that ISO 8601 allows you to omit the separators "-" and ":", which would then make it a float in Pd, and therefore it would be truncated to 6 digits. So we couldn't support that.
Here's a page all about ISO 8601 date/time formats:
http://www.cl.cam.ac.uk/~mgk25/iso-time.html#time
Thoughts? Comments? Flames? ;)
.hc
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-
carmen -
Frank Barknecht -
geiger -
Hans-Christoph Steiner -
martinrp＠alcor.concordia.ca -
Mathieu Bouchard -
Thomas Grill