 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Francois Labreque" <fla### [at] videotron ca> wrote in message
news:3A95C73E.8AE8DD82@videotron.ca...
>
> I forgot to type the #break statement, so sue me!
>
> [Note to self: Never post before your morning coffee]
;-) Applies to me more often than not, morning noon or night (less the
coffee part).
Bob H.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Geoff Wedig <wed### [at] darwinepbicwruedu> wrote:
> :> Are you sure clock is an integer?
> : Well, initial_clock and final clock are both integers, and equal to initial
> : frame and final frame respectively. And in the log they're all .00000, so
> : yeah, pretty sure. ;)
> It may (seem to) have an integer value, but that doesn't mean that it's
> an integer type.
> As all values in povray, it's a floating point value. It shouldn't be
> necessary to say more...
Except for the slight problem that floats can represent integers, the
initializers and additions are integers. There's absolutely no reason why
these wouldn't be integers too. Or are you saying that Pov gets numerical
error when adding 1 succesively to 0 for values < 100? If so, then POv has
far worse problems than the range statement.
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a9690a0@news.povray.org> , Geoff Wedig
<wed### [at] darwinepbicwruedu> wrote:
> Except for the slight problem that floats can represent integers
The problem is not that they can't represent integers if rounded at for
example the tenth digit, but if you take the whole floating-point number
you may well have a case like this (the error is just a _very_ simple
example, the real error will be more complicated and may appear in
different operations because of the way floating-point numbers are
represented internally).
Imagine: integer 4 = floating-point 4.00000000001
integer 2 = floating-point 2.0000000001
2.00000000001 + 2.00000000001 = 4.00000000002 != 4.00000000001
Get the idea?
Thorsten
PS: In some cases POV-Ray tries to compensate for this with a little
threshold when comparing for equality.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> In article <3a9690a0@news.povray.org> , Geoff Wedig
> <wed### [at] darwinepbicwruedu> wrote:
>> Except for the slight problem that floats can represent integers
> The problem is not that they can't represent integers if rounded at for
> example the tenth digit, but if you take the whole floating-point number
> you may well have a case like this (the error is just a _very_ simple
> example, the real error will be more complicated and may appear in
> different operations because of the way floating-point numbers are
> represented internally).
> Imagine: integer 4 = floating-point 4.00000000001
> integer 2 = floating-point 2.0000000001
> 2.00000000001 + 2.00000000001 = 4.00000000002 != 4.00000000001
> Get the idea?
I deal with float and integer problems every day. My work is in
mathematical computation, so yeah, I've heard of the idea.
And it's completely irrelevant. It may be true in many cases, but in *this*
case, we're dealing with a float that was *initialized* to an integer, and
with integral values small enough to fit in the storage bits, they're stored
as integers (basically). It's only when you have to use the shift bits that
funky things happen. This has *long* been a standard. If I were doing
dividing, where a small roundoff could have occured, then there might've
been some question, but in this case, we're dealing with integers added to
integers, albeit stored as floats. I can't see why they'd conflict in this
fashion. Or is POV doing something extremely funky with the clock? I
suppose it's possible that rather than use the settings I gave it for
initial and final clock, it still does 0-1, but then multiplies it by the
difference and adds the initial_clock, to get the clock setting given to the
scene file, but that seems like a lot of work when the true values are right
there.
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23 Feb 2001 14:36:47 -0500, Geoff Wedig wrote:
>funky things happen. This has *long* been a standard. If I were doing
>dividing, where a small roundoff could have occured, then there might've
>been some question, but in this case, we're dealing with integers added to
>integers, albeit stored as floats. I can't see why they'd conflict in this
>fashion. Or is POV doing something extremely funky with the clock? I
>suppose it's possible that rather than use the settings I gave it for
>initial and final clock, it still does 0-1, but then multiplies it by the
>difference and adds the initial_clock, to get the clock setting given to the
>scene file, but that seems like a lot of work when the true values are right
>there.
That's what I thought it must be doing, too, at first, but I see now that
it computes the clock delta and adds it for each frame. The clock delta is
given by (final_clock-initial_clock)/(final_frame-initial_frame), which
should be exactly 1 unless you're using an old Pentium, but perhaps there's
something funky about division that I don't understand.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Is Cyclic_Animation turned on or off?
--
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povrayorg> wrote:
> On 23 Feb 2001 14:36:47 -0500, Geoff Wedig wrote:
>>funky things happen. This has *long* been a standard. If I were doing
>>dividing, where a small roundoff could have occured, then there might've
>>been some question, but in this case, we're dealing with integers added to
>>integers, albeit stored as floats. I can't see why they'd conflict in this
>>fashion. Or is POV doing something extremely funky with the clock? I
>>suppose it's possible that rather than use the settings I gave it for
>>initial and final clock, it still does 0-1, but then multiplies it by the
>>difference and adds the initial_clock, to get the clock setting given to the
>>scene file, but that seems like a lot of work when the true values are right
>>there.
> That's what I thought it must be doing, too, at first, but I see now that
> it computes the clock delta and adds it for each frame. The clock delta is
> given by (final_clock-initial_clock)/(final_frame-initial_frame), which
> should be exactly 1 unless you're using an old Pentium, but perhaps there's
> something funky about division that I don't understand.
May be. I've not spent any time on it, figuring that it looked like a doc
problem, and even if it wasn't, the fix I used worked quite well, so why
worry too much about it?
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Wagner <mar### [at] gtenet> wrote:
> Is Cyclic_Animation turned on or off?
Dunno why that'd make a difference, but no, it wasn't.
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 26 Feb 2001 12:13:34 -0500, Geoff Wedig wrote:
>Mark Wagner <mar### [at] gtenet> wrote:
>
>> Is Cyclic_Animation turned on or off?
>
>Dunno why that'd make a difference, but no, it wasn't.
It makes a difference in the computation of clock_delta. And you didn't
answer the question. :)
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povrayorg> wrote:
> On 26 Feb 2001 12:13:34 -0500, Geoff Wedig wrote:
>>Mark Wagner <mar### [at] gtenet> wrote:
>>
>>> Is Cyclic_Animation turned on or off?
>>
>>Dunno why that'd make a difference, but no, it wasn't.
> It makes a difference in the computation of clock_delta. And you didn't
> answer the question. :)
Sorry, no, it wasn't turned on. Better? ;)
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
