|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot wrote:
> I am deeply impressed. I could very well use these kind of patterns, and I
> shall... with due credit of course.
Seconded. The one thing that code is missing is an explicit copyright and
license :D
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
stbenge <THI### [at] hotmailcom> wrote:
>
> #declare V=V+1/100;
Do you often use fractional loop counters?
Lovely pattern.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Cousin Ricky wrote:
> stbenge <THI### [at] hotmailcom> wrote:
>> #declare V=V+1/100;
>
> Do you often use fractional loop counters?
Yes, that's my automatic way of laying out a loop. I do this because
variables which go from 0 to 1 are easier to implement in color_maps and
sin/cos statements. It wasn't needed for this particular loop, but since
POV-Ray treats all variables as floats, I can't see how it could harm
things. I should have made it different so the code was easier to read,
but like I said, I'm on automatic when writing code sometimes ;)
> Lovely pattern.
Thanks!
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
stbenge wrote:
> Yes, that's my automatic way of laying out a loop. I do this because
> variables which go from 0 to 1 are easier to implement in color_maps and
> sin/cos statements. It wasn't needed for this particular loop, but since
> POV-Ray treats all variables as floats, I can't see how it could harm
> things. I should have made it different so the code was easier to read,
> but like I said, I'm on automatic when writing code sometimes ;)
The problem with doing #declare V=V+1/100; is that it might not reach 1.0000
exactly at the end of the loop (because of floating point inaccuracies), so
it might run one time too many.
Since integers are accurate (unless they're really big), I personally do
this:
#declare I=0;
#declare V=0;
#while (I<100)
//useful code
#declare I=I+1;
#declare V=I/100;
#end
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> The problem with doing #declare V=V+1/100; is that it might not reach
> 1.0000 exactly at the end of the loop (because of floating point
> inaccuracies), so it might run one time too many.
Or even if it runs runs the correct number of times, it may have slightly
off values. And errors would *accumulate*.
Tested in Python:
>>> x = 0;
>>> for i in range(0,100):
... x += 1.0/100;
...
>>> print x;
1.0000000000000007
>>>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Nicolas Alvarez wrote:
>> The problem with doing #declare V=V+1/100; is that it might not reach
>> 1.0000 exactly at the end of the loop (because of floating point
>> inaccuracies), so it might run one time too many.
>
> Or even if it runs runs the correct number of times, it may have slightly
> off values. And errors would *accumulate*.
>
> Tested in Python:
>>>> x = 0;
>>>> for i in range(0,100):
> ... x += 1.0/100;
> ...
>>>> print x;
> 1.0000000000000007
I see what you mean. I've never encountered any unwanted effects from
using fractional number-dependent loops, but it's a good thing to keep
in mind. Errors at the 16th decimal place are acceptable for most of the
things I do, but there will probably come a time when your input saves
me from beating my head against a hard surface :)
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> The problem with doing #declare V=V+1/100; is that it might not reach 1.0000
> exactly at the end of the loop (because of floating point inaccuracies), so
> it might run one time too many.
>
Right. If you MUST use floats, more robust is this sort of thing:
#local xmin = ....;
#local xmax = ....;
#local dx = .....;
#local x = xmin;
#while (x < xmax + dx / 2)
#local x = x + dx;
#end
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
stbenge wrote in message <49027f8c@news.povray.org>:
> but since
> POV-Ray treats all variables as floats, I can't see how it could harm
> things.
You mean, instead of using an integer counter? There is a big difference:
with most architectures, floats can represent reasonably-small integers in
an exact manner. On the other hand, 1/100 is not an exact float; 1/64 and
1/128 would have been, but not 1/100.
So the point that PoV internally uses floats is not valid: there are more
robust ways to use floats than others, and using an integer counter for
looks is one.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
stbenge wrote:
> I see what you mean. I've never encountered any unwanted effects from
> using fractional number-dependent loops, but it's a good thing to keep
> in mind. Errors at the 16th decimal place are acceptable for most of the
> things I do, but there will probably come a time when your input saves
> me from beating my head against a hard surface :)
It's mainly relevant if you loop thousands of times. With 100 iterations
it's not a big problem :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote in message <4903699f@news.povray.org>:
> It's mainly relevant if you loop thousands of times. With 100 iterations
> it's not a big problem :)
Quite the contrary, with this code, there may be problems even for a very
small number of iterations.
For example, consider the following code:
#local n = 10;
#local t = 0;
#while(t < 1)
#local t = t + 1/n;
#end
and the same with n = 11. It happens that the float value for 1/10 is
slightly smaller than the exact value 1/10, while the float value for 1/11
is slightly greater than the exact value for 1/11. The result is that both
loops make 11 iterations.
This issue can be fixed by using a float-friendly bound, as suggested
earlier by someone: t < 1 + dt / 2 or t < 1 - dt / 2, depending on whether
the loop is supposed to be inclusive or not.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |