Re: Smaller than milliseconds?
On Friday, July 11, 2003, at 03:47 PM, Ray G. Miller wrote: Ok, who's faster now! Errr! I am pleased that we can get the longs in 2 to 4 microseconds. Dar Scott Dar Scott Consultinghttp://www.swcp.com/dsc/Programming Services ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Smaller than milliseconds?
From: Dar Scott <[EMAIL PROTECTED]> > You can get even shorter times on the longs, if you throw away the > first long of each type. For example... >put the long seconds into junk > Put that just before your first use of the long seconds. Do likewise > with other longs. The original way: the long seconds: 1057959579.060119 delta: 0.09 the ticks: 63477574743 delta: 0 the milliseconds: 1057959579062 delta: 0 the long ticks: 63477574743.85434 delta: 0.000366 the long milliseconds: 1057959579065.631958 delta: 0.005981 And with "put the long into junk" the long seconds: 1057959894.692325 delta: 0.03 the ticks: 63477593681 delta: 0 the milliseconds: 1057959894695 delta: 0 the long ticks: 63477593681.815025 delta: 0.000122 the long milliseconds: 1057959894698.46106 delta: 0.002075 the long seconds: 1057959900.740434 delta: 0.04 the ticks: 63477594044 delta: 0 the milliseconds: 1057959900744 delta: 0 the long ticks: 63477594044.748299 delta: 0.61 the long milliseconds: 1057959900747.609985 delta: 0.002075 Ok, who's faster now! let's go rotate our tires Ray G. Miller __ Turtlelips Productions 4009 Everett Ave. Oakland, CA 94602 MailTo:[EMAIL PROTECTED] (V) 510.530.1971 (F) 510.482.3491 ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Smaller than milliseconds?
On Friday, July 11, 2003, at 12:24 PM, Ray G. Miller wrote: Looks like mine is a bit quicker ;-) You can get even shorter times on the longs, if you throw away the first long of each type. For example... put the long seconds into junk Put that just before your first use of the long seconds. Do likewise with other longs. With that, I got 3, sometimes 4, microseconds to get the value. Which is quicker now? Dar ** Dar Scott Consulting Programming Services [EMAIL PROTECTED] ** ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Smaller than milliseconds?
On Friday, July 11, 2003, at 12:54 PM, Ray G. Miller wrote: Adding three more zeros yielded: 1057948840.14027500152587890625000 1057948841.41388595104217529296880 1057948842.74860799312591552734380 1057948848.56447696685791015625000 1057948852.67774403095245361328120 1057948979.99965500831604003906250 1057948984.09295594692230224609380 1057948985.36483705043792724609380 1057948998.36404299736022949218750 1057948999.02833700180053710937500 ^ And right about here (depending on how quoting is handled in your mail client and whether you use a fixed-pitch font) is a column that consists of only 0's and 9's. I think that means the real resolution is 1 microsecond. The rest is all binary-to-decimal. The binary floating point can only represent values to about 1/9 of a microsecond. The extra digits are the results of the number not being able to get closer than 1/9 microsecond. Dar Scott ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Smaller than milliseconds?
From: Nelson Zink <[EMAIL PROTECTED]> Microseconds? Now we're talkin'. OK, here's the deal: A high quality Random Number Generator (RNG) needs two things: a good seed and a clever algorithm to turn the seed into pattern-less numbers. Nelson, Just running Dar's script with a pause between clicks, I got (Scott, avert your eyes or you'll get another haedache): the long seconds: 1057947474.546898 delta: 0.07 the ticks: 63476848472 delta: 0 the milliseconds: 1057947474549 delta: 0 the long ticks: 63476848473.015358 delta: 0.000359 the long milliseconds: 1057947474551.332031 delta: 0.005005 the long seconds: 1057948125.980394 delta: 0.11 the ticks: 63476887558 delta: 0 the milliseconds: 1057948125983 delta: 0 the long ticks: 63476887559.09742 delta: 0.000298 the long milliseconds: 1057948125986.495972 delta: 0.005005 the long seconds: 1057948145.708382 delta: 0.13 the ticks: 63476888742 delta: 0 the milliseconds: 1057948145711 delta: 0 the long ticks: 63476888742.800217 delta: 0.000359 the long milliseconds: 1057948145714.977051 delta: 0.005005 the long seconds and the long ticks did generate a delta, but the long millseconds did not. So, compute something meaningless like deriving God's last name (about a half second) (I got "Yenarttocs" for god's last name. What did you get?) and use the run time as a good unpredictable seed for the rest of the RNG. Thus it would be possible to have a high quality RNG based in software alone. Also: set the numberformat to "0." put the long seconds Punches up the fraction with digits other than zeros, where they come from I don't know. I got: 1057948791.84405899047851562500 1057948800.13185596466064453125 1057948801.46816802024841308594 1057948807.55658400058746337891 1057948808.14822602272033691406 1057948819.56501805782318115234 Adding three more zeros yielded: 1057948840.14027500152587890625000 1057948841.41388595104217529296880 1057948842.74860799312591552734380 1057948848.56447696685791015625000 1057948852.67774403095245361328120 1057948979.99965500831604003906250 1057948984.09295594692230224609380 1057948985.36483705043792724609380 1057948998.36404299736022949218750 1057948999.02833700180053710937500 The last three digits seem to be repeating... Scott, Ray G. Miller __ Turtlelips Productions 4009 Everett Ave. Oakland, CA 94602 MailTo:[EMAIL PROTECTED] (V) 510.530.1971 (F) 510.482.3491 ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Smaller than milliseconds?
From: Dar Scott <[EMAIL PROTECTED]> try this: on mouseUp put the long seconds into time1 put the long seconds into time2 put "the long seconds: " & time2 && "delta: " & (time2-time1) & LF into field "Report" put the ticks into time1 put the ticks into time2 put "the ticks: " & time2 && "delta: " & (time2-time1) & LF after field "Report" put the milliseconds into time1 put the milliseconds into time2 put "the milliseconds: " & time2 && "delta: " & (time2-time1) & LF after field "Report" put the long ticks into time1 put the long ticks into time2 put "the long ticks: " & time2 && "delta: " & (time2-time1) & LF after field "Report" put the long milliseconds into time1 put the long milliseconds into time2 put "the long milliseconds: " & time2 && "delta: " & (time2-time1) & LF after field "Report" end mouseUp On my OS X, I get this: the long seconds: 1057873624.51924 delta: 0.09 the ticks: 63472417471 delta: 0 the milliseconds: 1057873624527 delta: 0 the long ticks: 63472417471.80954 delta: 0.000778 the long milliseconds: 1057873624533.140991 delta: 0.014038 Yep, the same thing (at a different time ;-) ) with MOS 9.2... the long seconds: 1057947474.546898 delta: 0.07 the ticks: 63476848472 delta: 0 the milliseconds: 1057947474549 delta: 0 the long ticks: 63476848473.015358 delta: 0.000359 the long milliseconds: 1057947474551.332031 delta: 0.005005 I guess we can compare the actual speed of our CPUs. Looks like mine is a bit quicker ;-) Ray G. Miller __ Turtlelips Productions 4009 Everett Ave. Oakland, CA 94602 MailTo:[EMAIL PROTECTED] (V) 510.530.1971 (F) 510.482.3491 ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Smaller than milliseconds
On Friday, July 11, 2003, at 01:04 AM, Nelson Zink wrote: Computational results are predictable, completion time wobbles. The finer time is cut, the greater the unpredictability. The problem I see is that the ruler you use to measure the time is not independent. You are using a timer based on the same clock. However, because there is a lot going on in OS that can add randomness, such as communications interrupts, fan control interrupts or whatever, there will be some. Dar Scott ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Smaller than milliseconds
Dar, > You can collect some random bits using the long seconds, I think, but I > don't think you want to base it on how long it takes to execute some > code. You might want to harvest it from operator interactions and if > you don't have enough of those, from Internet response times. The > number of bits you can harvest depends on your estimate of > predictability. Good ideas. As far as I know there is no calculation one can make that 'wobbles'--that is, you always get the same answer. And healthy computers work the same way. The result is the same, but the time to complete it isn't. Computational results are predictable, completion time wobbles. The finer time is cut, the greater the unpredictability. And while it may not be obvious, most events we think of as being random are random only in the time dimension. Nelson ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Smaller than milliseconds?
Not to sound like a specialist but I've read quite a bit on randomness theory. 1st, nothing is truely random. Calculating something truely random is of truely infinite complexity. 2nd, celular automata are just like digits in a number (or sequence of #s) BUT consider each to be individually picked based on some neighbor number rules Meaning one affects the other... This means there is a pattern - it's time-based! If you want truely random without much fuss do this: take a serie of long numbers pick random digits in them associate them randomly... repeat a random number of times... This can easily be done picking some random digits in random picks of the milliseconds. Last but not least... To make it even more random, you can change the randomseed global before any use of the random function... And even make sure that any pick is not = to the last or within a Standard deviation of last picked choices... How much more random do you want? cheers Xavier On 11/07/2003 00:34:16 metacard-admin wrote: >Nelson, > >If you're looking for a random number generator you should check out "a >new kind of science" by stephen wolfram. They are using an automata to >generate a map that contains extremely (he claimed completely) random >sequences. This should not be a computationally intensive process and, >again according to him, gives good randomness (good enough to be the >random number generation technique used in mathematica where the audience >is made up of picky people who actually care). He mentioned this as an >aside during a lecture at xerox parc, so I suspect the full algorithm is >somewhat more complex. Interesting stuff. > >YMMV. > >J/ > > > >[EMAIL PROTECTED] wrote on 7/10/2003 3:11 PM > >>Microseconds? Now we're talkin'. >> >>OK, here's the deal: >>A high quality Random Number Generator (RNG) needs two things: a good seed >>and a clever algorithm to turn the seed into pattern-less numbers. A good >>seed is one that's unpredictable. And for good security RNGs, the seed often >>comes from some real world event--quantum stuff like radioactive decay or >>chaos stuff like lava lamps. (see the current WIRED, p. 88) For low-level >>security or something with no security concerns one can use computer clock >>time and be done with it. >> >>My idea is this: the time it takes to run some little bit of code isn't >>predictable (temperature of the processor and about a zillion other factors) >>and changes from moment to moment, and is specific to every local machine >>and circumstance. So it might be possible to write a very secure RNG that >>uses the unpredictability of run time for the seed. >> >>So, compute something meaningless like deriving God's last name (about a >>half second) and use the run time as a good unpredictable seed for the rest >>of the RNG. Thus it would be possible to have a high quality RNG based in >>software alone. >> >>Also: >>set the numberformat to "0." >>put the long seconds >> >>Punches up the fraction with digits other than zeros, where they come from I >>don't know. >> >>Nelson > > > >--- >Jonathan Feinstein >Shrink2Fit Software > > >___ >metacard mailing list >[EMAIL PROTECTED] >http://lists.runrev.com/mailman/listinfo/metacard Visit us at http://www.clearstream.com IMPORTANT MESSAGE Internet communications are not secure and therefore Clearstream International does not accept legal responsibility for the contents of this message. The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any views expressed in this e-mail are those of the individual sender, except where the sender specifically states them to be the views of Clearstream International or of any of its affiliates or subsidiaries. END OF DISCLAIMER
Re: Smaller than milliseconds?
On Thursday, July 10, 2003, at 09:12 PM, Nelson Zink wrote: But do you have any reason to believe the processor clock and the long seconds clock are not the same? Generally no, but strictly? I suppose I do. My long seconds are being displayed to 20 magnitudes of precision (with proper numberFormat adjustment). Either an alien technology has taken up residence in my machine or something's screwy. I'm betting on the later. The results of many operations and functions are internally double precision floating point numbers. They are converted to strings when they need to be. We can do much of our scripting without knowing or caring. The floating point representation is binary. There are 52 bits in the precision plus an invisible bit for the left most one (for non-zero values). The current date-time in seconds is about 1,058,000,000. (1Gs = 32 years, 1 year = 31 Ms, 1Ms = 11 1/2 days, 1ks = 17 minutes, approx.) The floating point number can represent about 16 digits. That means you can't do better than about 100 ns (with the current number scheme). I think we are seeing 1 microsecond resolution on OS X and 1 ms resolution on XP. All those extra digits are from the binary to decimal conversion and are not meaningful, that is, not meaningful in time, but are predictable meaning they are worthless to as random bits. (I think 1 microsecond 'long seconds' resolution is a reasonable goal for all platforms for the time being.) You can collect some random bits using the long seconds, I think, but I don't think you want to base it on how long it takes to execute some code. You might want to harvest it from operator interactions and if you don't have enough of those, from Internet response times. The number of bits you can harvest depends on your estimate of predictability. If we are really seeing only 1 ms on XP, then you have less bits to harvest and it will take you longer to get enough for a seed; save 'em up. Dar Scott ** Dar Scott Consulting Programming Services [EMAIL PROTECTED] ** ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Smaller than milliseconds?
J/, > If you're looking for a random number generator you should check out "a > new kind of science" by stephen wolfram. Wolfram's Rule 30 thing is great at producing a string of random digits, but what we need is a random seed. What we need is the finger that points out the section of Wolfram's string to use. The digits of Pi are random so we could do the same thing with a huge file of Pi digits. We still need the finger. The whole deal with RNGs used for security purposes isn't about having random digits, it about my picking a certain group of the digits and you not being able to guess which group I chose. We're talkin' encryption. Dar, > But do you have any reason to believe the processor clock and the long > seconds clock are not the same? Generally no, but strictly? I suppose I do. My long seconds are being displayed to 20 magnitudes of precision (with proper numberFormat adjustment). Either an alien technology has taken up residence in my machine or something's screwy. I'm betting on the later. Nelson ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Smaller than milliseconds?
Nelson, If you're looking for a random number generator you should check out "a new kind of science" by stephen wolfram. They are using an automata to generate a map that contains extremely (he claimed completely) random sequences. This should not be a computationally intensive process and, again according to him, gives good randomness (good enough to be the random number generation technique used in mathematica where the audience is made up of picky people who actually care). He mentioned this as an aside during a lecture at xerox parc, so I suspect the full algorithm is somewhat more complex. Interesting stuff. YMMV. J/ [EMAIL PROTECTED] wrote on 7/10/2003 3:11 PM >Microseconds? Now we're talkin'. > >OK, here's the deal: >A high quality Random Number Generator (RNG) needs two things: a good seed >and a clever algorithm to turn the seed into pattern-less numbers. A good >seed is one that's unpredictable. And for good security RNGs, the seed often >comes from some real world event--quantum stuff like radioactive decay or >chaos stuff like lava lamps. (see the current WIRED, p. 88) For low-level >security or something with no security concerns one can use computer clock >time and be done with it. > >My idea is this: the time it takes to run some little bit of code isn't >predictable (temperature of the processor and about a zillion other factors) >and changes from moment to moment, and is specific to every local machine >and circumstance. So it might be possible to write a very secure RNG that >uses the unpredictability of run time for the seed. > >So, compute something meaningless like deriving God's last name (about a >half second) and use the run time as a good unpredictable seed for the rest >of the RNG. Thus it would be possible to have a high quality RNG based in >software alone. > >Also: >set the numberformat to "0." >put the long seconds > >Punches up the fraction with digits other than zeros, where they come from I >don't know. > >Nelson --- Jonathan Feinstein Shrink2Fit Software ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Smaller than milliseconds?
On Thursday, July 10, 2003, at 04:24 PM, Dar Scott wrote: A headache, from looking at all those digits OK, this has less digits. But this is better. The first call to long seconds or long milliseconds is thrown away on this one. It takes longer for some reason. on mouseUp set the cursor to watch put "Upper bounds on time resolution:" & LF into field "Report" -- put the seconds into time1 put the seconds into time2 repeat while time1 is time2 put the seconds into time2 end repeat put "the seconds resolution: " & (time2-time1) & LF after field "Report" -- put the long seconds into junk put the long seconds into time1 put the long seconds into time2 repeat while time1 is time2 put the long seconds into time2 end repeat put "the long seconds resolution: " & (time2-time1) & LF after field "Report" -- put the ticks into time1 put the ticks into time2 repeat while time1 is time2 put the ticks into time2 end repeat put "the ticks resolution: " & (time2-time1) & LF after field "Report" -- put the long ticks into time1 put the long ticks into time2 repeat while time1 is time2 put the long ticks into time2 end repeat put "the long ticks resolution: " & (time2-time1) & LF after field "Report" -- put the milliseconds into time1 put the milliseconds into time2 repeat while time1 is time2 put the milliseconds into time2 end repeat put "the milliseconds resolution: " & (time2-time1) & LF after field "Report" -- put the long milliseconds into junk put the long milliseconds into time1 put the long milliseconds into time2 repeat while time1 is time2 put the long milliseconds into time2 end repeat put "the long milliseconds resolution: " & (time2-time1) & LF after field "Report" -- end mouseUp Now, I'm really really gone for the evening. Dar ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Smaller than milliseconds?
On Thursday, July 10, 2003, at 04:04 PM, Scott Rossi wrote: What do you folks get? A headache, from looking at all those digits OK, this has less digits. on mouseUp set the cursor to watch put "Upper bounds on time resolution (maybe 10 to 20 microseconds high):" & LF into field "Report" -- put the seconds into time1 put the seconds into time2 repeat while time1 is time2 put the seconds into time2 end repeat put "the seconds resolution: " & (time2-time1) & LF after field "Report" -- put the long seconds into time1 put the long seconds into time2 repeat while time1 is time2 put the long seconds into time2 end repeat put "the long seconds resolution: " & (time2-time1) & LF after field "Report" -- put the ticks into time1 put the ticks into time2 repeat while time1 is time2 put the ticks into time2 end repeat put "the ticks resolution: " & (time2-time1) & LF after field "Report" -- put the long ticks into time1 put the long ticks into time2 repeat while time1 is time2 put the long ticks into time2 end repeat put "the long ticks resolution: " & (time2-time1) & LF after field "Report" -- put the milliseconds into time1 put the milliseconds into time2 repeat while time1 is time2 put the milliseconds into time2 end repeat put "the milliseconds resolution: " & (time2-time1) & LF after field "Report" -- put the long milliseconds into time1 put the long milliseconds into time2 repeat while time1 is time2 put the long milliseconds into time2 end repeat put "the long milliseconds resolution: " & (time2-time1) & LF after field "Report" -- end mouseUp My OS X result: Upper bounds on time resolution (maybe 10 to 20 microseconds high): the seconds resolution: 1 the long seconds resolution: 0.15 the ticks resolution: 1 the long ticks resolution: 0.000847 the milliseconds resolution: 1 the long milliseconds resolution: 0.010986 I would guess the XP result will show ms resolution. Note that the long milliseconds seems to be faster than the long seconds. You guys pick up the ball; I'm out the door. Dar Scott ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Smaller than milliseconds?
On Thursday, July 10, 2003, at 04:10 PM, Nelson Zink wrote: My idea is this: the time it takes to run some little bit of code isn't predictable (temperature of the processor and about a zillion other factors) and changes from moment to moment, and is specific to every local machine and circumstance. So it might be possible to write a very secure RNG that uses the unpredictability of run time for the seed. But do you have any reason to believe the processor clock and the long seconds clock are not the same? Dar Scott ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Smaller than milliseconds?
Microseconds? Now we're talkin'. OK, here's the deal: A high quality Random Number Generator (RNG) needs two things: a good seed and a clever algorithm to turn the seed into pattern-less numbers. A good seed is one that's unpredictable. And for good security RNGs, the seed often comes from some real world event--quantum stuff like radioactive decay or chaos stuff like lava lamps. (see the current WIRED, p. 88) For low-level security or something with no security concerns one can use computer clock time and be done with it. My idea is this: the time it takes to run some little bit of code isn't predictable (temperature of the processor and about a zillion other factors) and changes from moment to moment, and is specific to every local machine and circumstance. So it might be possible to write a very secure RNG that uses the unpredictability of run time for the seed. So, compute something meaningless like deriving God's last name (about a half second) and use the run time as a good unpredictable seed for the rest of the RNG. Thus it would be possible to have a high quality RNG based in software alone. Also: set the numberformat to "0." put the long seconds Punches up the fraction with digits other than zeros, where they come from I don't know. Nelson ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Smaller than milliseconds?
Recently, "Dar Scott" wrote: > On my OS X, I get this: > > the long seconds: 1057873624.51924 delta: 0.09 > the ticks: 63472417471 delta: 0 > the milliseconds: 1057873624527 delta: 0 > the long ticks: 63472417471.80954 delta: 0.000778 > the long milliseconds: 1057873624533.140991 delta: 0.014038 > > I forgot how many digits we get with double floating point. Between 14 > and 15? This might limit how small of a time we can measure. > > What do you folks get? A headache, from looking at all those digits :-) Regards, Scott Rossi Creative Director Tactile Media, Multimedia & Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Smaller than milliseconds?
On Thursday, July 10, 2003, at 02:57 PM, [EMAIL PROTECTED] wrote: try this: put the long ticks into tTicks wait 1 tick put(the long ticks - tTicks) on WINXP pro, the result is in microtick resolution But, put the long seconds into tSecs wait 1 second put(the long seconds - tSecs) gives only millisecond resolution H. LONG ticks? Hey, I just noticed there are LONG milliseconds! Wow! For this handler (needs field "Report"): on mouseUp put the long seconds into time1 put the long seconds into time2 put "the long seconds: " & time2 && "delta: " & (time2-time1) & LF into field "Report" put the ticks into time1 put the ticks into time2 put "the ticks: " & time2 && "delta: " & (time2-time1) & LF after field "Report" put the milliseconds into time1 put the milliseconds into time2 put "the milliseconds: " & time2 && "delta: " & (time2-time1) & LF after field "Report" put the long ticks into time1 put the long ticks into time2 put "the long ticks: " & time2 && "delta: " & (time2-time1) & LF after field "Report" put the long milliseconds into time1 put the long milliseconds into time2 put "the long milliseconds: " & time2 && "delta: " & (time2-time1) & LF after field "Report" end mouseUp On my OS X, I get this: the long seconds: 1057873624.51924 delta: 0.09 the ticks: 63472417471 delta: 0 the milliseconds: 1057873624527 delta: 0 the long ticks: 63472417471.80954 delta: 0.000778 the long milliseconds: 1057873624533.140991 delta: 0.014038 I forgot how many digits we get with double floating point. Between 14 and 15? This might limit how small of a time we can measure. What do you folks get? Dar Scott ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Smaller than milliseconds?
Ken Ray writes: 1057853216369 1057853216.369436 OS X 10.2.6 on MDD G4 dual 1.25 GHz. Nyah-nyah! Nyah! Nyah! Test seem to indicate that I really get microseconds, yes, right down to the microsecond. (Some clever person can find out when we did the tests.) What wimpy OS are you using? ;-) You're right! It's OS-dependent. The "wimpy" OS was Windows XP; I checked it on my Mac (same config as yours) and I get the extra microseconds. Cool! Ken Ray Sons of Thunder Software = try this: put the long ticks into tTicks wait 1 tick put(the long ticks - tTicks) on WINXP pro, the result is in microtick resolution But, put the long seconds into tSecs wait 1 second put(the long seconds - tSecs) gives only millisecond resolution miscdas ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Smaller than milliseconds?
On Thursday, July 10, 2003, at 11:38 AM, Ken Ray wrote: What wimpy OS are you using? ;-) You're right! It's OS-dependent. The "wimpy" OS was Windows XP; I checked it on my Mac (same config as yours) and I get the extra microseconds. Cool! It might not be XP's fault. I have used NT and Win2K system calls that had nanosecond resolution. This does not mean the OS or the hardware can handle that, but it does hint at greater time resolution (smaller than ms). The same engine is used for all supported Windows platforms, whether 95/98/NT/2000/Me/XP, whether home, pro or server. I imagine parts of the engine might use the reduced common capability and parts might make runtime decisions based on the OS. Perhaps the long seconds is in the first part. I, personally, wouldn't mind if the Windows engine split into two if the 2K and XP Pro got some improvement or features. BTW, the microseconds in OS X (and, it seems from Ray's comments, Mac OS 9.2) are handy for timing operations when using a repeat loop is awkward or otherwise inappropriate. Dar Scott ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Smaller than milliseconds?
From: Dar Scott <[EMAIL PROTECTED]> Ken Ray wrote: > Dar, I think "the long seconds" > returns milliseconds as well, but in a slightly different format: I > opened the message box and typed: > > put the milliseconds && the long seconds > > I got 1057862149009 1057862149.009601 running MOS 9.2 with MC 2.5. Looks like microseconds to me, too (unless the random generator is running in overdrive ;-) ). Ray Ray G. Miller __ Turtlelips Productions 4009 Everett Ave. Oakland, CA 94602 MailTo:[EMAIL PROTECTED] (V) 510.530.1971 (F) 510.482.3491 ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
RE: Smaller than milliseconds?
> 1057853216369 1057853216.369436 > > OS X 10.2.6 on MDD G4 dual 1.25 GHz. Nyah-nyah! Nyah! Nyah! > > Test seem to indicate that I really get microseconds, yes, right down > to the microsecond. > > (Some clever person can find out when we did the tests.) > > What wimpy OS are you using? ;-) You're right! It's OS-dependent. The "wimpy" OS was Windows XP; I checked it on my Mac (same config as yours) and I get the extra microseconds. Cool! Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Smaller than milliseconds?
On Thursday, July 10, 2003, at 09:57 AM, Ken Ray wrote: Dar, I think "the long seconds" returns milliseconds as well, but in a slightly different format: I opened the message box and typed: put the milliseconds && the long seconds and got this: 1057852538054 1057852538.054 Identical, except for where the decimal point was placed... 1057853216369 1057853216.369436 OS X 10.2.6 on MDD G4 dual 1.25 GHz. Nyah-nyah! Nyah! Nyah! Test seem to indicate that I really get microseconds, yes, right down to the microsecond. (Some clever person can find out when we did the tests.) What wimpy OS are you using? ;-) Dar Scott ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
RE: Smaller than milliseconds?
> the ticks is the smallest unit I think... Actually, ticks are 1/60 of a second, whereas MC/Rev supports milliseconds (1/1000 of a second). Dar, I think "the long seconds" returns milliseconds as well, but in a slightly different format: I opened the message box and typed: put the milliseconds && the long seconds and got this: 1057852538054 1057852538.054 Identical, except for where the decimal point was placed... Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of Nelson Zink > > Sent: Thursday, 10 July, 2003 04:31 > > To: [EMAIL PROTECTED] > > Subject: Smaller than milliseconds? > > > > > > Is there any way to access a time period/measurement smaller than > > milliseconds in either MetaCard or Rev? > > > > Nelson Zink > > > > ___ > > metacard mailing list > > [EMAIL PROTECTED] > > http://lists.runrev.com/mailman/listinfo/metacard > > > ___ > metacard mailing list > [EMAIL PROTECTED] > http://lists.runrev.com/mailman/listinfo/metac> ard > ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
RE: Smaller than milliseconds?
the ticks is the smallest unit I think... > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Nelson Zink > Sent: Thursday, 10 July, 2003 04:31 > To: [EMAIL PROTECTED] > Subject: Smaller than milliseconds? > > > Is there any way to access a time period/measurement smaller than > milliseconds in either MetaCard or Rev? > > Nelson Zink > > ___ > metacard mailing list > [EMAIL PROTECTED] > http://lists.runrev.com/mailman/listinfo/metacard > ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Smaller than milliseconds?
On Wednesday, July 9, 2003, at 08:30 PM, Nelson Zink wrote: Is there any way to access a time period/measurement smaller than milliseconds in either MetaCard or Rev? the long seconds I get microsecond resolution on OS X on my blue & white and on my MDD Macs. It may be different on other OS's. Dar Scott ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Smaller than milliseconds?
Is there any way to access a time period/measurement smaller than milliseconds in either MetaCard or Rev? Nelson Zink ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
