[sf-lug] [PYCLASS] Still on exercise 2.1

[jim]

   all good points. jeffrey's way is better 
than mine, i think. 
   note that the approach is the same: convert 
all data to the same format first, then screw 
around with it, then convert back to whatever 
format the user wants. 
   the floating point division in this case 
does indeed return a slightly screwy value, 
part of why i didn't return the seconds part. 
   this is a general problem: in the case of 
an result such as 2.3500017 where the final 
two digits are spurious, how to truncate to 
get 2.350000 ? 



On Sat, 2008-10-04 at 07:40 -0700, Charles-Henri Gros wrote:
> > /* Set some constants */
> > MIN = 60
> > HOUR = MIN*60
> > easy_pace = 8*MIN+15
> > tempo_pace = 7*MIN+12
> > start_time = 6*HOUR+52*MIN
> > 
> > secs = easy_pace * 1 + tempo_pace * 3 + easy_pace * 1
> > print "%d:%02d" % ( (secs/ MIN), (secs%MIN) )
> > 
> > /* Now add start time plus run time and convert to hours, minutes and seconds */
> > total = start_time + secs
> > print "%d:%02d:%02d" % ( (total/HOUR), (total%HOUR/MIN), (total%HOUR%MIN) )
> > 
> > The reason why this can be considered "more correct" is that time is
> > always represented in seconds in UNIX systems (eg, the well known UNIX
> > epoch).
> 
> Another reason is that floating point arithmetic is often approximate
> (e.g. 1/60 hour doesn't have a finite decimal representation), while
> integer is exact as long as it doesn't overflow (overflow in seconds is
> about 60 years for 32-bit signed integer) and you don't divide (which
> you don't here)
>