Kristjan Onu wrote:
Raymond E. Rogers wrote:
Kristjan Onu wrote:
I noticed some oddities in the way the function ellipke from the
specfun package handles vector input. For example,
ellipke([.1; .2])
completes successfully, whereas the following fails:
ellipke([.1 .2])
I've modified ellipke.m to make both of the above work (patch
below). If you wish, I can apply the patch to the Octave-Forge
SourceForge repository myself, however, I don't currently have
developer access. My SourceForge username is konu.
The autoloaded special functions from gsl seem to work as a double
check.
a=ellint_Kcomp([.2 .1],0)
a=ellint_Ecomp([.90 .1; .4 .5],0)
etc...
Unfortunately there must be a interpretation/scaling error since
they disagree with ellipke. I can look into it later if nobody has
an explanation.
I believe the scaling difference is the following:
ellint_Kcomp(m,0) = ellipke(m^2)
This can be seen explicitly by comparing the GSL documentation [1] to
the Abramowitz and Stegun's, formula 17.3.1 [2].
I think it would be helpful to document ellipke, ellint_Kcomp and
ellint_Ecomp with the definitions used for elliptic integrals, i.e.
[k,e] = ellipke(m)
k = \int_0^\pi/2 dt 1/\sqrt((1 - m \sin^2(t)))
e = \int_0^\pi/2 dt \sqrt((1 - m \sin^2(t)))
k = ellint_Kcomp(m)
k = \int_0^\pi/2 dt 1/\sqrt((1 - m^2 \sin^2(t)))
e = ellint_Ecomp(m)
e = \int_0^\pi/2 dt \sqrt((1 - m^2 \sin^2(t)))
Since ellint_Kcomp and ellint_Ecomp perform the same operations as
ellipke, could ellipke be modified to call the GSL functions? This
would seem to avoid code duplication; the patch I gave in my first
message wouldn't be needed.
Thanks for pointing out the GSL functions to me, Raymond!
Kristjan
[1]
http://www.gnu.org/software/gsl/manual/html_node/Definition-of-Legendre-Forms.html
[2] http://www.math.sfu.ca/~cbm/aands/page_590.htm
You know I read that and blew right past it without a thought. I will
do a writeup in Latex on the versions and transformations. I have no
problem doing a ellipke wrapper; but I am very reluctant to arbitrarily
change working (more or less) code without agreement of several other
people. One of the items is agreeing on the precision. Presumably the
double precision mode "0" would be what is wanted but it is supposed to
be slower. I guess I can generate some tests to make sure it doesn't
slow things down a lot.
OTOH: there is not a lot of traffic in the special functions so a change
would be low risk.
Although I have used octave since 94; it has only been on a sporadic
basis as a EE needs it. I don't qualify as an authority or old hand.
I have been paying more attention now that I am retired.
RayR
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Octave-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/octave-dev
