"Thorsten Froehlich" wrote:
> > start_frame, end_frame,
>
> No, there is no need: You can easily calculate them
> yourself given the existing keyword work correctly!

But surely calculating an integer from floats can easily lead to floating
point precision errors? Ok, one can add 0.5 and use the int() function on
that, but the typical new user surely don't know that.

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 <3c9e5bca@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> But surely calculating an integer from floats can easily lead to floating
> point precision errors? Ok, one can add 0.5 and use the int() function on
> that, but the typical new user surely don't know that.

Well, all what is needed is an "animation.inc" file which provides the correct
calculations.  And also there would be some minor error, only very few
operations are applied and the error would be on the 10th or so digit.

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.

    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:
> 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