 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Overhauling the POV-Ray codebase, I've stumbled across something
surprising (to me) in the implementation of the fractal currently
implemented via the `HypercomplexFunctionFractalRules` type. Can someone
with a bit of "fractal fu" please help me and test this out?
In SDL parlance, that should be any fractal using:
julia_fractal {
...
hypercomplex FUNCTION
...
}
where FUNCTION is any of:
acos
acosh
asin
asinh
atan
atanh
cosh
cos
exp
ln
pwr(FLOAT,FLOAT)
sin
sinh
tan
tanh
Please tell me whether you think the results are ok or bogus.
For reference, the following values of FUNCTION should be fine:
cube
sqr
reciprocal
The oddity in the code is as old as POV-Ray 3.6.1, maybe even older.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Le 28/06/2015 09:58, clipka a écrit :
> Overhauling the POV-Ray codebase, I've stumbled across something
> surprising (to me) in the implementation of the fractal currently
> implemented via the `HypercomplexFunctionFractalRules` type. Can
> someone with a bit of "fractal fu" please help me and test this
> out?
>
> In SDL parlance, that should be any fractal using:
>
> julia_fractal { ... hypercomplex FUNCTION ... }
>
> where FUNCTION is any of:
>
> acos acosh asin asinh atan atanh cosh cos exp ln pwr(FLOAT,FLOAT)
> sin sinh tan tanh
>
> Please tell me whether you think the results are ok or bogus.
>
> For reference, the following values of FUNCTION should be fine:
>
> cube sqr reciprocal
>
> The oddity in the code is as old as POV-Ray 3.6.1, maybe even
> older.
The same code seems to be already in 3.1g
Checking exp, the computation seems ok (in regard to >
http://mathworld.wolfram.com/ExponentialFunction.html
)
At least hcmpl.c / hcmpl.cpp code seems ok
exp(z) = exp(x).(cos y + i.sin y) with z = x+i.y (x and y in R)
That is for the complex (in C) operations.
Hypercomplex is a waste family (see
> http://mathworld.wolfram.com/HypercomplexNumber.html
)
The hypercomplex of povray seems to match the Davenport's type
Now, for something interesting in Normal_Calc_HCompl_Func (from
hcmplx.c in 3.1g, it uses global (from fractal.h ) to perform
computation, as input...
how did it handle more than one object at once ?
(Sx, Sy, Sz and Sw)
What I do not like either, in 3.7 now, is the conflict of name between
IStack (as type) and IStack[4] (array of pointer to array of DBL)
(IStack[] replaces the Sx, Sy, Sz, Sw; I have yet to find where it is
filled)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iJwEAQEIAAYFAlWP5kIACgkQhKAm8mTpkW2bEAP/T0N3X75cgTw1KqVFESdpKq1m
ZAWfWYO4kkfok0YtOV1MAGe44O1x8HOaCf1wK+5wtzr9b+Q86Wg9ynM2L6Yj4ULV
oaCW1WndJic7jxervJCg2flJA5VCK7WcADu6njrZZ3YCW2SeGjYjV6dEIL1Nep9F
s2P2306+IqcJ5bt94EI=
=aQoz
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 28.06.2015 um 14:19 schrieb Le_Forgeron:
> The same code seems to be already in 3.1g
>
...
> The hypercomplex of povray seems to match the Davenport's type
Take a closer look at the initialization of the iteration, in the
3-parameter overload of the HypercomplexFunctionFractalRules::Iterate
function. Still happy with it?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Le 28/06/2015 16:01, clipka a écrit :
> Am 28.06.2015 um 14:19 schrieb Le_Forgeron:
>
>> The same code seems to be already in 3.1g
>>
> ...
>> The hypercomplex of povray seems to match the Davenport's type
>
> Take a closer look at the initialization of the iteration, in the
> 3-parameter overload of the
> HypercomplexFunctionFractalRules::Iterate function. Still happy
> with it?
>
That code (in master branch, because in stable it is in
Iteration_HCompl_Func inside hcmplx.cpp) seems ok in regard to julia
computation:
v_(n+1) <-- Function(v_n) + c, repeat for n from 0 to max_iteration-1
unless it goes too far from center (that's a classical optimisation:
once the point get far enough from center, it is known that it will
not converge again)
Thanks for the light of the computation stack (and it confirm that in
3.1g, if you had more than one julia with a different limit on the
number of interaction ( *max_iteration* count), you were in trouble.
Deep trouble of out of range memory write & read.
from http://www.povray.org/documentation/view/3.6.1/280/ the
hypercomplex julia is due to FractInt .
The initialisation of the iteration (n=0) seems fine, but for one
thing: The Sz[0]/IterStack[Z][0] is getting IPoint[Y] instead of
IPoint[Z] .
That's a big typo, if you consider the result, but a single letter in
thousand of line of code :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iJwEAQEIAAYFAlWQMdIACgkQhKAm8mTpkW3lZQQAlBxc0pojVF1bl0n8gzqH6FUU
cb64Pr37ItZelG2SyrOPwq8M1uIWH405aiq5dp2U+E6hCtqwPGztgjn+y3t40pzh
FkoAhHyj2AoTeO1SCAH+narMAmqr+swWGnnMzz1UvH5fGnu/3JkEwE9pQtG5sKeM
5JAZg11MRQF2PIa9pv4=
=3V6j
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 15-06-28 03:58, clipka a écrit :
> Overhauling the POV-Ray codebase, I've stumbled across something
> surprising (to me) in the implementation of the fractal currently
> implemented via the `HypercomplexFunctionFractalRules` type. Can someone
> with a bit of "fractal fu" please help me and test this out?
>
> In SDL parlance, that should be any fractal using:
>
> julia_fractal {
> ...
> hypercomplex FUNCTION
> ...
> }
>
> where FUNCTION is any of:
>
> acos
> acosh
> asin
> asinh
> atan
> atanh
> cosh
> cos
> exp
> ln
> pwr(FLOAT,FLOAT)
> sin
> sinh
> tan
> tanh
>
> Please tell me whether you think the results are ok or bogus.
>
The oddity may explain the strange results I got a while back when
testing those functions.
I got missmatched dirrect image, shadows and reflection.
Often, it looked as is I was looking at the inside surfaces.
The self shadowing was often just plain wrong.
I still have the images and code and may post them if asked.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <kua### [at] videotron ca> wrote:
> Le 15-06-28 03:58, clipka a écrit :
> > Overhauling the POV-Ray codebase, I've stumbled across something
> > surprising (to me) in the implementation of the fractal currently
> > implemented via the `HypercomplexFunctionFractalRules` type. Can someone
> > with a bit of "fractal fu" please help me and test this out?
> >
> > In SDL parlance, that should be any fractal using:
> >
> > julia_fractal {
> > ...
> > hypercomplex FUNCTION
> > ...
> > }
> >
> > where FUNCTION is any of:
> >
> > acos
> > acosh
> > asin
> > asinh
> > atan
> > atanh
> > cosh
> > cos
> > exp
> > ln
> > pwr(FLOAT,FLOAT)
> > sin
> > sinh
> > tan
> > tanh
> >
> > Please tell me whether you think the results are ok or bogus.
> >
>
> The oddity may explain the strange results I got a while back when
> testing those functions.
> I got missmatched dirrect image, shadows and reflection.
> Often, it looked as is I was looking at the inside surfaces.
> The self shadowing was often just plain wrong.
>
> I still have the images and code and may post them if asked.
>
>
> Alain
There are actually quite a few bugs, not only in the hypercomplex code, but the
quaternion code as well. I've been going through the code myself, and, alas,
the Y / Z typo is just the beginning. (I actually started this to implement the
rest of the functions for quaternions. I didn't mean to get in so deep, but...
well, here I am.) To wit (I think this is all of them):
* The last iteration is not checked against the bailout in any of the
julia_fractal codes (which is wrong), although the normal is computed off of the
last iteration (which is only sometimes right; see below)
* The normal is computed off of the last iteration, which is only correct if the
last iteration was the one that produced that portion of the surface (this falls
apart, for instance, with the reciprocal type)
* The distance estimator fails to include the bailout in its calculations (this
does not apply necessarily to quaternions)
* The distance estimator (as implemented) fails to assist until it estimates
that the distance remaining is less than 30 times the precision
* None of the normal calculations take into account the slicing
* The intersection code pretty much always will miss intersections that occur at
the edge of the fractal when leaving it and sometimes when entering it
* Hypercomplex cube is actually sqr
* There are oddities in the computation of acos and acosh due to branch cut
issues
* Discontinuities of the iterated function are not accounted for when computing
normals
And ...
* The normal calculations for pretty much all of the hypercomplex fractals
(excluding sqr and exp) are broken: the function value is used where the
derivative should be
To make matters somewhat worse, these bugs are all present in the code for
version 3.0, meaning that fixing things will affect scenes that far back.
To the best of my knowledge, though, the rest is correct (with the possible
exception of the distance estimators for the quaternions, which I am still
working on figuring out).
So, no, it's not just you.
A couple of fairly easy ways to verify some of the problems:
Render a hypercomplex sqr fractal.
Render again with cube instead of sqr. (You get the *same* result as before.)
Render again, with pwr(2,0) instead. (You *don't* get the same result. Same
shape, but different shading.)
Render a hypercomplex sin fractal with max_iteration 1, parameter 0, and
standard slicing (i.e., t). (You get a sphere of radius 4 with funky shading,
half of it missing in a random-looking fashion, and no back side.)
Anyways, I've actually been working on writing a corrected version to work with
the current git source, and am mostly done -- meaning that everything works fine
(so far), but more testing and documentation would be good, and another look at
optimization might be worthwhile. If anyone would like to check my work, I
would be most appreciative. (Also, if anyone knows what the best way would be
for me to contribute this for review / use / whatever, let me know. I'm
thinking that a pull request on GitHub is probably the correct way, but I'm not
sure.)
Ben Small
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> There are actually quite a few bugs, not only in the hypercomplex code, but the
> quaternion code as well. I've been going through the code myself, and, alas,
> the Y / Z typo is just the beginning. (I actually started this to implement the
> rest of the functions for quaternions. I didn't mean to get in so deep, but...
> well, here I am.) To wit (I think this is all of them):
>
> * The last iteration is not checked against the bailout in any of the
> julia_fractal codes (which is wrong), although the normal is computed off of the
> last iteration (which is only sometimes right; see below)
> * The normal is computed off of the last iteration, which is only correct if the
> last iteration was the one that produced that portion of the surface (this falls
> apart, for instance, with the reciprocal type)
> * The distance estimator fails to include the bailout in its calculations (this
> does not apply necessarily to quaternions)
> * The distance estimator (as implemented) fails to assist until it estimates
> that the distance remaining is less than 30 times the precision
> * None of the normal calculations take into account the slicing
> * The intersection code pretty much always will miss intersections that occur at
> the edge of the fractal when leaving it and sometimes when entering it
> * Hypercomplex cube is actually sqr
> * There are oddities in the computation of acos and acosh due to branch cut
> issues
> * Discontinuities of the iterated function are not accounted for when computing
> normals
>
> And ...
>
> * The normal calculations for pretty much all of the hypercomplex fractals
> (excluding sqr and exp) are broken: the function value is used where the
> derivative should be
>
> To make matters somewhat worse, these bugs are all present in the code for
> version 3.0, meaning that fixing things will affect scenes that far back.
>
> To the best of my knowledge, though, the rest is correct (with the possible
> exception of the distance estimators for the quaternions, which I am still
> working on figuring out).
>
>
> So, no, it's not just you.
>
>
> A couple of fairly easy ways to verify some of the problems:
>
> Render a hypercomplex sqr fractal.
> Render again with cube instead of sqr. (You get the *same* result as before.)
> Render again, with pwr(2,0) instead. (You *don't* get the same result. Same
> shape, but different shading.)
>
> Render a hypercomplex sin fractal with max_iteration 1, parameter 0, and
> standard slicing (i.e., t). (You get a sphere of radius 4 with funky shading,
> half of it missing in a random-looking fashion, and no back side.)
>
>
> Anyways, I've actually been working on writing a corrected version to work with
> the current git source, and am mostly done -- meaning that everything works fine
> (so far), but more testing and documentation would be good, and another look at
> optimization might be worthwhile. If anyone would like to check my work, I
> would be most appreciative. (Also, if anyone knows what the best way would be
> for me to contribute this for review / use / whatever, let me know. I'm
> thinking that a pull request on GitHub is probably the correct way, but I'm not
> sure.)
>
>
> Ben Small
>
>
>
It's not often that you see Julia fractals using something else than
quaternions, and most of the time, they use sqr.
I don't think that fixing those bugs will break anything as the bugs
where probably why the Julia fractal was underused.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 21.03.2016 um 16:44 schrieb Bent:
> Anyways, I've actually been working on writing a corrected version to work with
> the current git source, and am mostly done -- meaning that everything works fine
> (so far), but more testing and documentation would be good, and another look at
> optimization might be worthwhile. If anyone would like to check my work, I
> would be most appreciative.
Thanks a lot for picking up this glove.
How's progress?
> (Also, if anyone knows what the best way would be
> for me to contribute this for review / use / whatever, let me know. I'm
> thinking that a pull request on GitHub is probably the correct way, but I'm not
> sure.)
A pull request would be the best way to go indeed.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 21.03.2016 um 16:44 schrieb Bent:
>
> > Anyways, I've actually been working on writing a corrected version to work with
> > the current git source, and am mostly done -- meaning that everything works fine
> > (so far), but more testing and documentation would be good, and another look at
> > optimization might be worthwhile. If anyone would like to check my work, I
> > would be most appreciative.
>
> Thanks a lot for picking up this glove.
> How's progress?
>
> > (Also, if anyone knows what the best way would be
> > for me to contribute this for review / use / whatever, let me know. I'm
> > thinking that a pull request on GitHub is probably the correct way, but I'm not
> > sure.)
>
> A pull request would be the best way to go indeed.
Sorry for the (rather long) delay in response.
So far, so good. I've got a fork up and working
(https://github.com/BentSm/povray.git), but it still has similar needs to what
it had before. (I'm still getting used to git, so if anything's funny, please
let me know.) Should I wait on the pull request until everything's all ready,
or put it in now?
Do feel free to look it over, try it out, critique it, whatever. It should
compile and run fine (it does on my end, at least); if it doesn't, please do let
me know.
(Note that there are a few other things -- besides the fractal rewrite -- that
I've added; it should be fairly simple to separate them out if desired. I've
been updating them in separate commits; I don't know if that's necessary or
useful, but it's simple enough to do.)
Bent
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
