"Tor Olav Kristensen" <tor### [at] hotmailcom> wrote in message
news:Xns### [at] 204213191226...

> > BTW, are you interested in the original functions?
> > The first part of the radial part of the function I've
> > reorganised, because a couple of variables occur
> > several times and this is gives a faster code.
>
> Jaap, I must admit that I know almost
> nothing about quantum mechanics. So I
> don't really understand the formulas
> that I now have modified.

My knowledge isn't so big. At the university I've
had some basic quantum mechanics that I didn't
understand very good I must admit. Later my
understanding has grown because your insight
becomes better when you combine your knowledge.
(Mmmh .. I hope I make myself clear with this.)

> But apart from that; Yes I would like
> to have a look at the original functions.
> Just because I'm curious !

You find it in H_Wave_Text.pov, together with
an explanation about the imaginary part and
my translation principle of the derivative.

You will see that one factor in exp_imPhi has to be
put back:  'm / abs(m)'
If you omit that, then the function is equal for positive
and negative values of 'm'.
'm / abs(m)' gives just the difference you need.
If you render 2p1 and 2p-1 without that factor,
you get identical pictures and with the factor they
have different directions in space.

> I have now had time to do some opti-
> mizations to the math part of your
> code, but I'm afraid the speed
> increase are rather modest.

Modest! It decreases render time with 25% with
my PIII 450MHz. That's considerable. Thank you
for that optimilization.
Your macro's and functions are very keen.
I couldn't have done that and so quickly.
I've still a lot to learn.

Now I have to find a formula for the container
radius, for, thanks to you, I can now choose
any combination I like!

Regards,

Jaap Frank

Post a reply to this message

Attachments:
Download 'H_Wave_Text.pov.txt' (3 KB) Download 'H_Wave_Functions v4_TOR.pov.txt' (26 KB)

"Jaap Frank" <jjf### [at] xs4allnl> wrote in news:3e24b87d@news.povray.org:
> 
> "Tor Olav Kristensen" <tor### [at] hotmailcom> wrote in message
> news:Xns### [at] 204213191226...
...
>> But apart from that; Yes I would like
>> to have a look at the original functions.
>> Just because I'm curious !
> 
> You find it in H_Wave_Text.pov, together with
> an explanation about the imaginary part and
> my translation principle of the derivative.

Thanks. I'll have a look at it to see if I
can "understand" it.


> You will see that one factor in exp_imPhi has to be
> put back:  'm / abs(m)'
> If you omit that, then the function is equal for positive
> and negative values of 'm'.
> 'm / abs(m)' gives just the difference you need.
> If you render 2p1 and 2p-1 without that factor,
> you get identical pictures and with the factor they
> have different directions in space.

Ok, I see. I must have misinterpreted your
function expression. This means that that
macro isn't really needed then.

This statement should give the same result:

#declare Exp_imPhi =
  function { cos(m*atan2(y, z)) + sin(m*atan2(y, z)) }


Since:

cos(AnyAngle) = cos(-AnyAngle)
sin(-m*AnyAngle) = -sin(m*AnyAngle)
cos(0*AnyAngle) + sin(0*AnyAngle) = 1

(Note that you should be careful with the use
of lowercase single character variable names
in your code. Because they are reserved for
future use in POV-Ray. I.e. they may get
special meanings in later POV-Ray versions.)

Even if the macro doesn't seem to be needed,
you could check if this version of it gives
any speed increase:


#macro Exp_imPhiFunction(M)

  #local imPhiFn =
    function(Angle) { cos(Angle) + sin(Angle) }

  function { imPhiFn(M*atan2(y, z)) }

#end // macro Exp_imPhiFunction


But I doubt that the speed difference will be
noticable.

(And in some cases, I think such an expression
will render slower. It remains for me to find
out in which cases it evaluates slower.)


One further little note:

If you want to use the sign of a variable in
an expression, then this:

select(variable, -1, 1, 1)

or:

select(variable, -1, 0, 1)

- would be a good way to write it.


As you have noticed; variable/abs(variable)
requires extra care to make sure that a
division by 0 does not happen when the
variable is equal to zero. And I believe that
such an expression also forces povray to do a
float division, instead of just a quick check
of some of the bits in the variable's value.


> Now I have to find a formula for the container
> radius, for, thanks to you, I can now choose
> any combination I like!
> 
> Regards,
> 
> Jaap Frank

I hope that you post the radius formula when
you find it Jaap.


Tor Olav

Post a reply to this message

"Tor Olav Kristensen"  wrote

> This statement should give the same result:
>
> #declare Exp_imPhi =
>   function { cos(m*atan2(y, z)) + sin(m*atan2(y, z)) }
>
> Since:
> cos(AnyAngle) = cos(-AnyAngle)
> sin(-m*AnyAngle) = -sin(m*AnyAngle)
> cos(0*AnyAngle) + sin(0*AnyAngle) = 1

Yes, of course, that's the shortest way.

> Even if the macro doesn't seem to be needed,
> you could check if this version of it gives
> any speed increase:
>
> #macro Exp_imPhiFunction(M)
>
>   #local imPhiFn =
>     function(Angle) { cos(Angle) + sin(Angle) }
>
>   function { imPhiFn(M*atan2(y, z)) }
>
> #end // macro Exp_imPhiFunction
>
> But I doubt that the speed difference will be
> noticable.

I think that in this case there will be a slight profit,
because the atan2() is a serie expansion and that
takes considerable time.

> (And in some cases, I think such an expression
> will render slower. It remains for me to find
> out in which cases it evaluates slower.)

Only testing can give you the time needed to build
the subroutine that calls this 'sub-function'. That's
the loss you get if you nest deeper. So for time
consuming operations you can get a profit.

> One further little note:
> If you want to use the sign of a variable in
> an expression, then this:
>    select(variable, -1, 1, 1)
>    or:
>    select(variable, -1, 0, 1)
> - would be a good way to write it.
>
> As you have noticed; variable/abs(variable)
> requires extra care to make sure that a
> division by 0 does not happen when the
> variable is equal to zero. And I believe that
> such an expression also forces povray to do a
> float division, instead of just a quick check
> of some of the bits in the variable's value.

You can notice that I don't use these functions very
often, because I hadn't thought about this while I
used this function several times.

> I hope that you post the radius formula when
> you find it Jaap.

I think that the old fashioned formula for the Bohr
Radius might be a good choice to start with.
I have to test it jet.
When I made a preliminarily test with high values
of 'n', I discovered that I will have to invent a variable
intensity either, because the media got to dim.
If I have tested these things, I will let you know what
the solution for this will be (if I can find it).

Thanks again for all this tremendous help.


Jaap Frank

Post a reply to this message

> > I hope that you post the radius formula when
> > you find it Jaap.
>
> I think that the old fashioned formula for the Bohr
> Radius might be a good choice to start with.
> I have to test it jet.
[..]
> If I have tested these things, I will let you know what
> the solution for this will be (if I can find it).
>

It took me a while to find a formula for the container radius, but I've found
something useful.
The following you can find in the attached file too.
(As you suggested I've changed the variables to upper case.)

/*  Container formula:
  The Bohr radii are proportional with N*N.
  For N=1 the quantum maximum equals the Bohr radius when R = 1,
  but for N=2 it's around 5*R instead of the expected 4*R.

  For the quantum functions I've found some interesting correction factors when
L = 0:
  - With N > 2 else it's nonsense.
  - The main maxima are around:    N*N * (N-1)/(N/2)
  - The fall off towards nearly zero: N*N * (N-1)/(N/2) * (N-1)/(N-2)
  - Expansion for very low values:  N*N * (N-1)/(N/2) * (N-1)/(N-2) * (1 +
0.4/N)
  It doesn't give the exact maxima, but it's amazingly close. The limit (N >>>)
is 2*N*N.

  L > 0:
  The deviation between the quantum maxima and the Bohr radii becomes smaller
for
  larger values of L.
  The maximum of the 2p is nearly 4*R, of the 3d it's nearly 9*R and of the 4f
nearly
  16*R.  The maxima of the 4p and 4d are between the 4s and the 4f.
*/

As you can see there is a regularity in the maxima. I was led by the fact that
these kind of factors are used in the wave function too, but it was trial and
error at first. The last factor contains 0.4 and is only a choice to keep the low
density part visible.
It can become smaller with increasing N, because the whole density is lower
then (total volume is 1 because of the normalization factor).

Further there are some small optimisations with pow() when the power is zero
or one. The speed increase was noticeable but not great. Well, all small steps
help.

I removed a bug from the macro CreateAxis() and made it ready for high
values of N.

Curiosity made me try some very high values of N, up to 100. With N=100
there's nothing to see. I went down and with N=77 it appears suddenly again,
although with very bad quality.
First I was puzzled about this, but 77 was somehow a familiar number. Then I
remembered that that is the maximum number for facultity in a normal calculator.
There are lots of facultities in the formula, so this must be the cause of this.

This brings me to another subject.
About a year ago I was trying to understand the working of  poly.cpp of the
source code of POV-Ray (3.1g). What I was (and still am) is figuring out
how a polynomial of high degree is solved for its roots.
I cannot code in C, but I've coded in Pascal (TurboPascal), so I can follow
(with some difficulty) what is done there.
In PolySolve the binomial(int n, int r) is heavily used, so I tried to figure
out
how that was done. In the loop there is a 'Goto' to get out of the loop when
something is found and done. That was the point where I couldn't follow it
anymore. To my opinion this was not done correctly, so a bug.
To proof myself, I coded this function in SDL and compared the results
with the strait forward method that I use in the wave functions too.
(Attachment Test_PolyC). It proofs that I was right about it. It's a bug.
Years ago I had poly.cpp printed from POV version 2_?  for another
reason and to my surprise the bug was already there. I think it may exist
from the beginning of POV-Ray!
In that time I hadn't internet (I was very late with that) and got POV_Ray
from a friend, so I couldn't report it. Because for the first 15 powers
there is a look up table it is possible that this bug doesn't show up, for
MaxPower = 15. Further I thought that this must be known and nobody
bothered about it.
To my surprise the bug still exists in version 3.5. It's possible that this
part is still unused, but maybe with the new possibilities with the functions
there is need for solving higher powers and then there is a problem with this
function.
I think it's no use that I report this, for I once found a strange behaviour
with brackets during the beta testing period, but got no reaction about this
after I had reported that.
Maybe they listen to you.

What do you think about this?

Regards,

Jaap Frank

PS Is your email tor### [at] hotmailcom still active?
      Bonus: A nice wave :).

Post a reply to this message

Attachments:
Download 'H_Wave_Functions v4_TOR_4.pov.txt' (29 KB) Download 'Test_PolyC.pov.txt' (14 KB) Download 'H_PROB_7H-3_MED_TOR_4.png' (363 KB)

Preview of image 'H_PROB_7H-3_MED_TOR_4.png'

"Jaap Frank" <jjf### [at] xs4allnl> wrote in news:3e3457ed@news.povray.org:

>On 26 jan 2003, you wrote in povray.binaries.scene-files:
> 
>> > I hope that you post the radius formula when
>> > you find it Jaap.
>>
>> I think that the old fashioned formula for the Bohr
>> Radius might be a good choice to start with.
>> I have to test it jet.
> [..]
>> If I have tested these things, I will let you know what
>> the solution for this will be (if I can find it).
>>
> 
> It took me a while to find a formula for the container radius, but
> I've found something useful.
> The following you can find in the attached file too.
> (As you suggested I've changed the variables to upper case.)
...

That's good !


...
> PS Is your email tor### [at] hotmailcom still active?

Yes it is. - Sorry for not reading my email
so often these days.

I had just started reading your email to me,
when I saw your new post.

But I think I will need some time before I
am able to reply thoroughly. I will try to
look into the binomial() problem that you
describe.


>       Bonus: A nice wave :).

This 7h-3 image image is great too !


Tor Olav

Post a reply to this message