...and how many seconds?





  • Well. 6 minutes plus 60 seconds does equal 7 minutes. But showing it as 6 minutes AND sixty seconds is odd.



  • Pretty obvious to me... looks like he's grabing the seconds as an integer (or maybe a float) and rounding to the nearest 10 meaning if it took 6min 58secs, it would round up to 6min 70secs. A little weird, yes, but I can clearly see how it's happened.


  • Discourse touched me in a no-no place

    @DaEagle said:

    Pretty obvious to me... looks like he's grabing the seconds as an integer (or maybe a float) and rounding to the nearest 10 meaning if it took 6min 58secs, it would round up to 6min <font color="#ff0000">70</font>secs. A little weird, yes, but I can clearly see how it's happened.
    Are you using Excel 2007 to compose your posts? Enquiring minds would like to know.



  • Or just 59.95 seconds, which when rounded to 1 decimal place is 60.0.



  • @DaEagle said:

    Pretty obvious to me... looks like he's grabing the seconds as an integer (or maybe a float) and rounding to the nearest 10 meaning if it took 6min 58secs, it would round up to 6min 70secs. A little weird, yes, but I can clearly see how it's happened.

     Why would you round seconds to the nearest 10 and how them with one decimal? Why round them AT ALL??
     



  • Nope. This is obviously a case of using "greater than" instead of "greater than or equal to".

    if seconds > 60 then

    instead of

    if seconds >= 60

    would cause this problem easily.
     



  • @PJH said:

    @DaEagle said:
    Pretty obvious to me...
    looks like he's grabing the seconds as an integer (or maybe a float)
    and rounding to the nearest 10 meaning if it took 6min 58secs, it would
    round up to 6min <font color="#ff0000">70</font>secs. A little
    weird, yes, but I can clearly see how it's happened.
    Are you
    using Excel 2007 to compose your posts? Enquiring minds would like to
    know.

     

    Maybe he's using Banker's rounding-to-ten?

     



  • @KenW said:

    Nope. This is obviously a case of using "greater than" instead of "greater than or equal to".

    if seconds > 60 then

    instead of

    if seconds >= 60

    would cause this problem easily.
     



    More likely it uses seconds >=60, but applies that condition before it rounds to the displayed number. So 59.99 is less than 60, not
    triggering the "Carry the minute" code, but then being rounded to 60.0 for display.



  • That looks like POV-Ray.  If it is, what version?  The source is available, so we can find out for sure what the code does.



  • If rounding is occurring, then there certainly should be no decimal after the 60. Significant figures and all that. Unless it was rounded up from 59.95 or more



  • @iwpg said:

    That looks like POV-Ray.  If it is, what version?  The source is available, so we can find out for sure what the code does.

    MLPov 0.83, which is a derivative of POV-Ray 3.5.  I'm using the Unix port.



  • @KenW said:

    Nope. This is obviously a case of using "greater than" instead of "greater than or equal to".

    if seconds > 60 then

    instead of

    if seconds >= 60

    would cause this problem easily.
     

    or > 59 would work just fine.  it would take care of that rounding issue too.



  • @Carnildo said:


    MLPov 0.83, which is a derivative of POV-Ray 3.5.  I'm using the Unix port.

    The MLPov changes don't affect any of the relevant code as far as I can see.  Here's the code that prints the message:

        if (tparse_frame != 0.0)
        {
          SPLIT_TIME(tparse_frame,&hours,&minutes,&seconds);
    
      Statistics ("Time For Parse:  %3ld hours %2ld minutes %5.1f seconds (%ld seconds)\n",
          hours, minutes, seconds, (long)tparse_frame);
    }</pre></blockquote>
    

    Since (long)tparse_frame is 420 (= 7 * 60), that probably means that tparse_frame itself is greater than or equal to 420 (unless they changed the rounding mode, but grep doesn't turn up any calls to fesetround, and in any case I'm not sure whether that affects casts to an integral type).  Therefore we would expect seconds to be between 0 and 1, so the culprit probably isn't the rounding done by %5.1f.

    SPLIT_TIME is a macro that just calls POV_Std_Split_Time:

    void POV_Std_Split_Time(DBL time_dif, unsigned long *hrs, unsigned long *mins, DBL *secs)
    {
      *hrs = (unsigned long)(time_dif / 3600.0);
    

    *mins = (unsigned long)((time_dif - (DBL)(*hrs * 3600)) / 60.0);

    *secs = time_dif - (DBL)(*hrs * 3600 + *mins * 60);
    }

    I don't see anything obviously wrong there, so it's probably just one of the usual floating point rounding errors that we all know and love.

    For what it's worth, it appears to be fixed in POV-Ray 3.6.1:

            if(ret == kNoErr)
                    Printf(STATISTIC_STREAM, "  Parse Time:  %3d hours %2d minutes %2d seconds (%d seconds)\n", (int)(i / 3600), (int)((i / 60) % 60), (int)(i % 60), (int)i);

    i is already an int, so those casts look pointless, but it's certainly immune to floating point silliness.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.