"Thorsten Froehlich" wrote:
> Anyway, it turns out to be more natural to drop the
> initial_clock and final_clock in favor of a start_frame
> and end_frame.  This also has the benefit that no hacks
> need to be applied to the core code to get the
> user-specified initial_clock and final_clock.

Um, how then does the user derive the initial_clock and final_clock from the
avaiable clock variables?

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

Post a reply to this message

In article <3c9f57b4$1@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> Um, how then does the user derive the initial_clock and final_clock from the
> avaiable clock variables?

Doing this (untested, minor corrections will be necessary):

initial_clock = clock - (frame_number - initial_frame) * clock_delta
final_clock = initial_clock + (final_frame - initial_frame) * clock_delta

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" wrote:
> Doing this (untested, minor corrections will be necessary):
>
> initial_clock = clock - (frame_number - initial_frame) * clock_delta
> final_clock = initial_clock + (final_frame - initial_frame) * clock_delta

Calculating a constant from a variable?? Come on, this cries out for
confusing precision errors! And here, since we're not talking about
integers, it's not even possible to "correct" the result by using the int()
function.

The result will be that a value that even people familiar with precision
errors will expect to be exactly identical in every frame, may have small
but critical variations from frame to frame. I strongly advice against this
approach and ask that the initial_clock and final_clock values are available
as build-in values.

Also, I didn't quite get, if neither start_frame and end_frame nor
start_clock and end_clock are build in, then how do one calculate those? Or
will start_clock and end_clock indeed be build in? I didn't quite get that
from your reply.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

Post a reply to this message

In article <3c9fbe07@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> Calculating a constant from a variable?? Come on, this cries out for
> confusing precision errors!

No, you are completely misunderstanding how floating-point precision works.
If what you imply would be true, POV-Ray could not even work at all.

And even if it would matter, as the clock values are internally with single
precision and all declared floats are of course double precision, you probably
even gain precision by calculating them this way...

> Also, I didn't quite get, if neither start_frame and end_frame nor
> start_clock and end_clock are build in, then how do one calculate those? Or
> will start_clock and end_clock indeed be build in? I didn't quite get that
> from your reply.

You didn't read what I said:  "to drop the initial_clock and final_clock in
favor of a start_frame and end_frame"

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" wrote:
> > Calculating a constant from a variable?? Come on,
> > this cries out for confusing precision errors!
>
> No, you are completely misunderstanding how
> floating-point precision works.

You must have misunderstood me.

My point is that calculating a constant such as initial_clock from a
variable such as clock will cause the constant to slightly change from frame
to frame even though you'd expect it to be 100% the same in every frame.

I can prove this.

Render the code below with the given command line settings.

// -ga +gd +gf +ki0.5 +kff9000

#declare Initial_Clock1 =
initial_clock;
#declare Initial_Clock2 =
clock - (frame_number - initial_frame) * clock_delta;
#declare Value1 = (Initial_Clock1-0.5)*100000;
#declare Value2 = (Initial_Clock2-0.5)*100000;
#declare Test1 = (Value1=0);
#declare Test2 = (Value2=0);
#debug concat(
   "Frame: ",str(frame_number,4,0),
   " - Value1: ",str(Value1,16,13),
   " - Value2: ",str(Value2,16,13),
   " - Test1: ",str(Test1,1,0),
   " - Test2: ",str(Test2,1,0),"\n"
)
#if (Test2=true)
   sphere {z,0.1 pigment {green 10}}
#else
   sphere {z,0.1 pigment {red 10}}
#end


I used beta 14 to test it and I hope you get the same results as I. I see
Value2 gain greater and greater precision errors from frame to frame, and
this ultimately causes a test to be true in some frames and false in others,
which is based directly on the calculated initial clock based on your
formulae. The initial clock provided directly by POV-Ray on the other hand
truly is the same in every frame.

This is why it's a very bad idea to calculate a constant from a variable,
and this is why I think the values initial_clock, final_clock, start_clock
and end_clock should be provided directly by POV-Ray and not in some
animation.inc file.

I'd like to hear your arguments against this.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

Post a reply to this message

In article <3ca0688b@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> I can prove this.

Internally EPSILON is at 10e-10 for a reason.  And what you call "error" from
frame to frame stays within the same range because of the single
multiplication.  Only in iterative calculations floating-point errors
accumulate.  This isn't the case here, thus you have no valid point.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" wrote:
> Internally EPSILON is at 10e-10 for a reason.
> And what you call "error" from frame to frame
> stays within the same range because of the single
> multiplication.  Only in iterative calculations
> floating-point errors accumulate.  This isn't the
> case here, thus you have no valid point.

Err, what? Sorry, I literally don't understand what you're trying to tell
me. I tend to focus on results rather than theory.

What I see is that your calculated initial_clock is not precisely the same
from frame to frame and this can cause an expression which includes the
initial_clock value to evaluate differently in different frames, even though
you'd expect it to always evaluate to the same result. This is not the case
with the internal initial_clock, which is truly the same in all the frames.

As this will be a big problem in some of my POV-Ray macros, I have a very
valid point. When I tell you that it's a problem for me as a user it doesn't
make sense when you say that it isn't a valid point. It can only mean that
you have misunderstood what point I'm trying to make. You may however say
that you don't care.

I just don't understand how it can be such a big problem to make directly
available the initial_clock and final_clock values in POV-Ray. I can see
them right there in the command line/ini file, so surely making those values
available in the SDL should be a piece of cake?

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

Post a reply to this message

In article <3ca0d14f@news.povray.org> , "Thorsten Froehlich" <tho### [at] trfde>
wrote:

> Only in iterative calculations floating-point errors accumulate.

After playing with your example a bit more I concluded that the precision
decrease was unreasonable for a simple multiplication and investigated it:

You actually found a precision bug in POV-Ray because the animation loop uses
such an iterative approach by simply adding clock_delta to clock when it goes
from one frame to the next.  This can easily be corrected by applying a proper
multiplication, which should fix this precision problem as well.  This fix
will be in the next beta.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" wrote:
> You actually found a precision bug in POV-Ray because
> the animation loop uses such an iterative approach by
> simply adding clock_delta to clock when it goes from
> one frame to the next.

> will be in the next beta.

Thanks, this sounds great.

However, I still stand by my belief that a supposedly constant value such as
initial_clock should not even variate the slightest bit from frame to frame.

The current initial_clock value in POV-Ray does indeed stay exactly the same
in every frame, and what I ask is that the initial_clock and final_clock
values will not be dropped.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

Post a reply to this message

In article <3ca0dba3@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> However, I still stand by my belief that a supposedly constant value such as
> initial_clock should not even variate the slightest bit from frame to frame.

Try to see it this way:  Specify a value to to the 20th digit on the command
line and then look at what you get when displaying it.  You will notice some
variation (unless you select certain values that will always be precise).  Of
course this variation will not be from frame to frame, but it still exists.
in fact, by carefully tweaking the values in the INI file it is possible to
get *closer* or even match the value you specified using the calculation
method compared to the internally known initial_clock.

This is because the precision is _finite_ but _very_ complex to track when
using floating-point numbers, and the only correct way to handle this is to
not depend on infinite precision at all, ever.  For this reason POV-Ray
internally has its EPSILON at 10e-10 by default because most platforms cannot
provide more accurate results even after just a "few" calculations.  This is
also the reason why the equality comparison operators take EPSILON into
account in POV-Ray.

Sure, you can display the value such that the precision error is visible, but
then again you can probably display 40 digits in many cases and 30 of them
will just be "random" jitter...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message