On 10/7/05, Alex Tweedly <[EMAIL PROTECTED]> wrote: So *if* Rob can accept the missing trailing "0" then Kay is the "winner > apparent" for the QP (pending any other faster method).
Not so fast:-) Ithink Alex you were spot on when you said: 3. it's easy to get obsessive about speed beyond the point where it matters > - I do it all the time !! > Having been jolted out of 'reduce the speed' mode when my errors were pointed out it was time to see what other faults were out there. You've already mentioned lack of trailing zeros. I note also that only your code Alex includes a leading zero, ie 03:13:45.0, again, that may or may not be important. As far as my code not correctly showing hours greater than 24 it was most definitely a case of looking at the speed and not the output. In a button I put this code to feed the function, just commenting out the function I didn't want to run - then read the output from the message box. on mouseUp put the ticks into tStartTime repeat 150000 times put return & addTime("18:26:43.5",random(20000)) after tMyTime -- Wayne --put return & addDivandFormat("18:26:43.5",random(20000)) after tMyTime --Alex --put return & addTimeAndSeconds("18:26:43.5",random(20000)) after tMyTime-- Dick end repeat put (the ticks - tStartTime)/60 & tMyTime into msg end mouseUp I would have put a random time in but I just couldn't be bothered so I just made one up. It just happens that in this case there are only three instances where the result will exceed 23:59:59. The message box obviously contained the elapsed time at the top followed by 150000 lines of results. I was too busy checking the time and a couple of pages of results to not notice that it never came up with an answer like 27:xx:xx.x I know some comment has gone back and forward between Dick and Alex about whether my code can handle negative seconds. Whilst I checked Dick's example and came to the same conclusion that Alex did - that my code doesn't have problems with negative seconds, the comments did make me realize that there was a SERIOUS error with my code. If someone takes the trouble of recording hh:mm:ss.s then there is a good chance that the seconds they want to add will also contain a decimal. In this case my code produces an error regardless of whether you add or subtract. I know Rob indicated that he was happly only to add time, which is lucky because this amended code will not work for subtract: function addTime pTime,pSeconds set the itemDelimiter to "." convert item 1 of pTime to seconds convert (item 1 of pTime + item 1 of pSeconds) to long time return it & "." & (item 2 of pTime + item 2 of pSeconds) end addTime But when I now run this new code it is about 0.1 seconds slower that Alex's code!! So not only does it appear that Alex's code is fastest, it works for both add and subract AND the format is consistent. I'll now put away my acceptance speech and return the tuxedo;-) _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution