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

> #declare Value1 = (Initial_Clock1-0.5)*100000;

After looking closer at what you are doing (multiplication by 100000  to see
more digits right of the comma) and your precision arguments and way of
testing it, I conclude you are probably misunderstanding the meaning of
"precision of floating-point numbers".

See, what you are effectively doing is tricking the display to show 19 digits.

I guess you assume "precision" refer to the part right of the comma.  However,
this is _not_ how floating-point precision is defined!

Floating-point numbers are not you every day binary (or decimal for that
matter) numbers.  I am not sure you are aware, but in memory double precision
(IEEE754 standard) floating-point numbers have exactly 64-bits to store your
number.  64 bits allow exactly 2^64 possible numbers to be represented.  This
implies about 1.845*10^19 possible numbers, which makes it obvious that more
than 19 digits of a number (which is not one of these 1.845*10^19 numbers that
can be represented as exact values) are impossible to be represented no matter
how you calculate it.  In order to allow very small values down to 2*10^-308
and very big values up to 2*10^+308 floating-point numbers use an exponent-
based format (there are many books about, so I am not going to explain it
here).  Effectively you get only about 15 to 16 digits precision after a few
calculations, and a steady decrease of precision when applying more and more
calculations.

So, what you are displaying in your example is in fact exceeding (!!!) the
available precision that is mathematically possible at some point.  I hope
this explains a bit better why you cannot expect never changing values - they
will nearly always change in a not mathematically exact way after applying
even a single operation to them.  thus, requiring a value to be always
constant is only possible if you never use it, because as soon as you do you
likely will perform some calculation and thus create similar inaccuracies
sooner or later.

    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:
> After looking closer at what you are doing
> (multiplication by 100000  to see more digits
> right of the comma)

Look, when I don't multiply with 1000000 and run the code, the value Test2
evaluates to 1 in all the frames. But when I multiply with 1000000, it
evaluates to 0 in frame 36 and the following ones. So I had to multiply with
1000000 to prove my point, which was that the changes in precision errors
from frame to frame could ultimately lead an expression to evaluate to
different results in different frames.

Now, having looked closer at my code, why would you say that I was just
multiplying with 1000000 to show the digits in a different way???

> and your precision arguments and way of testing it, I
> conclude you are probably misunderstanding the meaning
> of "precision of floating-point numbers".

Why?

> See, what you are effectively doing is tricking the
> display to show 19 digits.

As mentioned, it had nothing to do with showing the digits in a specific
way. The evaluation of the values Test1 and Test2 is what's interesting. And
these were dependent on that multiplication I did.

> I guess you assume "precision" refer to the part right of
> the comma.

No. I know that floating points are exponentially based, and I know they
have precision limited to about 16 digits of precision in base 10. But in my
code the multiplication with 1000000 made a difference, as I have explained,
and which you can test on your own.

> So, what you are displaying in your example is in fact
> exceeding (!!!) the available precision that is
> mathematically possible at some point.  I hope this
> explains a bit better why you cannot expect never
> changing values - they will nearly always change in a
> not mathematically exact way after applying even a
> single operation to them.

I can and will expect the constant values such as initial_clock to stay
completely the same from frame to frame. Maybe you didn't grasp the point I
wanted to show in my code, but there are two parallel set of calculations
going on. One based on the initial_clock value provided by POV-Ray, and the
other based on the initial clock formulae you provided, which is based
partly on the ever-changing clock variable.

Value1 and Test1 are derived from the initial_clock value from POV-Ray while
Value2 and Test2 are derived from your initial clock formulae. As the debug
steam shows when you run the code, Value1 and Test1 are *exactly* the same
from frame to frame, while Value2 and Test2 changes from frame to frame.
This is why I don't like your formulae and prefers an initial_clock value
given directly by POV-Ray.

Now, I know that the values derived from POV-Ray's initial_clock keyword are
just as inaccurate, but that's not the point. The point is that the value
doesn't change from frame to frame, because constants that change from frame
to frame would be a hell to debug for scene builders and macro coders.

Again, I'm still curious to hear why it's so important for you to drop the
initial_clock and final_clock keywords, when obviously, it would make things
more difficult for the users.

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

> No. I know that floating points are exponentially based, and I know they
> have precision limited to about 16 digits of precision in base 10. But in my
> code the multiplication with 1000000 made a difference, as I have explained,
> and which you can test on your own.

Hmm, maybe I still failed to explain it.  The precision refers to the total
number of precise digits let or right of the comma:

You intentionally "break" the comparison operator.  Your number then has *19*
digits, which is basically above the precision available.  If you do
comparisons on numbers this way the internal EPSILON is not big enough and you
need to do "fix" it yourself by rounding.  It has nothing to do with the
calculation (assuming the precision bug in the animation loop is fixed).

    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 intentionally "break" the comparison operator.

Yes. But comparison operators are often broken by coders unintentionally.
The initial_clock keyword could easily be involved in a long series of
calculations which for each new calculation gets a little more imprecise.

When you have an animation with one object moving in a specific way and you
see a bug in the behaviour that changes from frame to frame, and there are
100 different places the bug could origin from, the first thought that comes
to your mind is not exactly the initial_clock value, which should be exactly
the same in every frame. An initial_clock value that has small variations
from frame to frame thus makes debugging much more difficult than needed be.

I must again refer to the fact that the current initial_clock value in
POV-Ray is indeed the same in every frame. Even if it's imprecise, it's the
*same* imprecise value in every frame, as one would expect. Why do you want
to take that away in favour of a worse solution where there are small
changes from frame to frame?

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

sad to see there has bin no change in this matter.
(and yes, this issue has driven me nuts ... again)

Bad documentation is worse then no documetation!

Post a reply to this message

What's the problem?

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

hum, well, ok ...

basicly it come down to the fact that the animation INI settings
[Subset_Start_Frame] & [Subset_End_Frame]
effect the built-in variable values of
[initial_clock], [final_clock], [initial_frame] & [final_frame].

I personally don't understand the WHY of this behaver,
but worse, there is no indication in the documentation of this behaver.

basic rood-map to flame:
1) you think you understand those settings/variables (based on doc)
2) you start using those settings/variables (experimenting and finding out
there usefulness)
3) at some point you try to render a subset of your animation
4) and your completely surprised by a subset render that make no sense.
5) you finally figure out you got to rip out all used
(initial/final_clock/frame) and
replace them with hard core value's, just to get that subset rendered
correctly.
(very high innocence level, if you ask me)

In my case I use like to use the AVI frame-time value to my animation work,
instead of the raw [clock] value.
But to make this work I need to know the 'real' start and ending frame of
the whole animation sequence.
And there is no way to calculate them ... unless you cheat.
besides, calculating them also defeats the purpure of having built-in
variable that refer to INI settings.

I still don't understand why they don't just provide a full set of build-in
animation variable that
directly give the value's of the used setting.
It would be a good thing, because its clear, simple to use, and effective.
(if it would be really useful ... is something that should be judge by
Animators,
 not the programmers!)

haaaaaa, that feels a lot better :)

ps:
- I'm not a regular (webpage-login), nor a great talker (no discussion)
- so, it will probably take along time for me to react (if ever)
- however, I do read up ... from time to time.

Post a reply to this message

In article <web.41129b4e217d299beb697f1c0@news.povray.org> , "...Tyrell..."
<Tyr### [at] hotmailcom> wrote:

> sad to see there has bin no change in this matter.
> (and yes, this issue has driven me nuts ... again)

This is the wrong group to discuss anything in POV-Ray 3.6.  this group was
for the beta test of POV-Ray, which has been over for several month now.

Please read the posting as well as bug reporting guidelines in the
frequently asked questions group.

    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