Kay C Lan wrote:
I certainly have to agee with Alex's statement about sitting back and
watching. So here is my effort:
_______________________________________________
So do I win the Cupie doll? ;-)
No, I don't think so, because your method gets wrong (IMHO) results in
two cases :-).
1. 10:30:28 + 50 results in
Alex 10:31:18.0
Kay 10:31:18.
(i.e. trailing full stop (period) rather than a "0" after it)
2. 23:59:59.3 + 50 results in
Alex 24:00:49.4
Kay 00:00:49.4
and the original problem statement said "hh can be greater than 24!"
which I take to mean that it should be in cases like this, to avoid
problems of knowing whether or not the values have wrapped. Using the
built in time functions will always wrap, so that may require the
surrounding code to change.
I've got the same amount of lines as Sarah's but more words; but less word's
than Alex's, assuming you set the twelveHourTime in an openStack handler.
for 150000 calculations on my machine (run 3 consecutive times)
IF the original time has no decimal ie 10:30:28
Dick 5.78, 5.83, 5.86
Alex 5.38, 5.73, 5.45
me 5.48, 5.46, 5.55
With decimal times ie 11:23:34.6
Dick 6.05, 6.21, 6.13
Alex 5.55, 5.65, 5.68
me 5.4, 5.46, 5.58
Dick's and Alex's seem to prefer no decimal, but mine doesn't seem fussed
either way.
Interesting. You didn't say what your machine was, but I get quite
different results (Sony laptop, Pentium 4, WinXP), with my method
consistently being faster then yours (note I set the twlevehourtime
*outside* the timing loop).
(You didn't say what number of seconds you were adding, so I couldn't
reproduce the comparison exactly. Note it does make a difference to some
methods whether or not you need to carry the increment - though probably
not to either of these two methods)
12:11:12.2 + 50
----------------
Alex 2.636 2.687 2.682
Kay 3.158 2.828 2.801
10:31:18 + 50
-------------
Alex 2.332 2.307 2.227
Kay 2.888 2.879 2.888
11:23:34.6 + 50
---------------
Alex 2.415 2.438 2.471
Kay 2.707 2.704 2.731
I think all this proves is:
1. we're down to the point where differences are tiny
2. hardware and OS may give different results
3. it's easy to get obsessive about speed beyond the point where it matters - I
do it all the time !!
--
Alex Tweedly http://www.tweedly.net
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.10/119 - Release Date: 04/10/2005
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
