...and how many seconds?

Carnildo

Statistics from a recent 3D render I did:

[img]http://i84.photobucket.com/albums/k19/Carnildo/Forums/povstatwtf.png[/img]

Renan

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

DaEagle

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.

PJH

@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.

Thief

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

XIU

@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??

KenW

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.

DaveK1

@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?

SuperousOxide

@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.

iwpg

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.

durnurd

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

Carnildo

@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.

dphunct

@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.

iwpg

@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.