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

jim jim at well.com
Sat Oct 4 08:52:06 PDT 2008

```   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)
>

```