On Fri, Mar 25, 2016 at 12:48:17AM +0800, Ben Coman wrote:
On Thu, Mar 24, 2016 at 7:12 AM, David T. Lewis lewis@mail.msen.com wrote:
I'm actually quite happy with the idea of the value being a Number that is an Integer for all reasonable values that could ever be supplied by the VM, but that might be a Fraction if we want to represent time values at some higher precision. Mainly I like it because it seems good conceptually to think of time as continuous, and not as discreet ticks of a clock.
It also works well computationally, because the normal case uses integer values (immediates in 64-bit Spur), and because Fractions involve two integer values, which presumably would be no worse than a design that added another field. But given that none of our computers or VMs can report time to a precision greater than microseconds, I think that we can safely ignore the issue for another 20 years or so ;-)
Its not so far away. Three contemporary examples...
- Systems that synchronise time from GPS do so "typically well within
40 nanoseconds" [1]
- The distributed clock of EtherCAT networks synchronises nodes to
better than 100ns. See slide 23 [2] and figure 7 [3].
- IEEE 1588 provides synchronised network time "in the range of
+/-200ns between some nodes and even +/-50ns and less between the better ones." [4]
This matters for applications like financial trading, motion control and sequence-of-event logging on industrial plants. Maybe not Smalltalk's bread and butter, but the last two are areas I'd like to use it at a co-ordinator level.
cheers -ben
[1] http://gpsinformation.net/main/gpstime.htm [2] https://ece.uwaterloo.ca/~sfischme/rate/Joey-Stubbs-Ethercat.pdf [3] http://www.iestcfa.org/bestpaper/wfcs10/wfcs10_bpa.pdf [4] https://home.zhaw.ch/~wei/IEEE1588/embedded_World_05_Contribution_final.pdf
Indeed you are quite right. And thank you for those links.
Our current Squeak platforms are certainly not real time systems, but our representation of DateAndTime should not be limited by that.
I guess that all I can add at this point is my basic premise that a simple representation of a time scale is better than a complicated one. For now, the idea of microseconds as the unit of measure seems to work quite well. Maybe in the future some different representation will be better.
At higher levels of precision, I suspect that Fraction (or ScaledDecimal, which is more readable) will be a very efficient representation. And since DateAndTime instances are likely to be important for databases, forcing all of the values to be Fraction (i.e. two integers) might be a good policy. But for now, microseconds since the epoch works well, yielding Integer representations in all practical cases, and overflowing into Fraction if nanosecond precision is needed.
Dave