Extending the elliptic12 and elliptic3 functions

[Will Robertson]

Hi,

I have a student working with me over summer and one of the things
we've talked about is extending the elliptic12/3 functions for ranges
outside 0<=m<=1.

Before we start discussing the best interface for doing this, can I
ask what the difference between elliptic12 and elliptic12i are? It
seems to me that elliptic12i is a superset of elliptic12 since it
handles both real and complex input -- so can elliptic12 be made
redundant (by embedding it within elliptic12i) and could we then drop
the "i" in elliptic12i?

Cheers,
Will

[moiseev.igor]

Hi Will!

> I have a student working with me over summer and one of the things
> we've talked about is extending the elliptic12/3 functions for ranges
> outside 0<=m<=1.

That would be great! Glad that it is interesting for someone.

> Before we start discussing the best interface for doing this, can I
> ask what the difference between elliptic12 and elliptic12i are?

There are no big difference, it is a wrapper for the complex inputs.

> so can elliptic12 be made
> redundant (by embedding it within elliptic12i) and could we then drop
> the "i" in elliptic12i?

Yes it redundant, you can use elliptic12i with the real inputs and it
gives the same result as the elliptic12.
The point of dividing them into two different files is the pure
structural design.
It is easier to construct the building using of the small bricks.

elliptic12i differs A LOT, in sense of algorithms and dimensions of
inputs
(it is double of the dimension of the real inputs) from the
elliptic12.

Don't speak about the analytical properties of integrals.
Singularities, degeneracy etc.

Then the additional checks as

isreal(u)

Memory heap, which is double
% capture memory and save the structure of input arrays
F1 = zeros(size(u)); F2 = zeros(size(u));
E1 = F1; E2 = F1;
Z1 = F1; Z2 = F1;
Fi = F1; Ei = F1;
Zi = F1;

becomes essential in some application. So I decided to keep the
complex realisation in 'I'-th denoted files.

Unfortunately the Matlab scripting language is very poor (actually
they already introduced it in the limited way), so you cannot
construct the wise abstract class hierarchy, so you could reuse the
code, so what remains is to be redundant.

So the correct structure should be something like (the sign ":" means
extension/inheritance)

AGM :
LANDEN TRANSFORMATION :
ELLIPTIC12 :
ELLIPTIC12I
ELLIPJ :
ELLIPJI

So the ELLIPTIC12I accumulates the methods from "AGM", "LANDEN
TRANSFORMATION" and "ELLIPTIC12" classes. An so on.
All the best!
Igor.

[Will Robertson]

On Jan 8, 5:54 am, "moiseev.igor" <moiseev.i...@gmail.com> wrote:
> So the correct structure should be something like (the sign ":" means
> extension/inheritance)
>
> AGM :
>    LANDEN TRANSFORMATION :
>       ELLIPTIC12 :
>          ELLIPTIC12I
>       ELLIPJ :
>          ELLIPJI
>
> So the ELLIPTIC12I accumulates the methods from "AGM", "LANDEN
> TRANSFORMATION" and "ELLIPTIC12" classes. An so on.

Hi Igor,

Okay, this is sensible. So what would be your desired structure for us
to add code to the repository?

I was thinking, perhaps, of a single file called elliptic123.m that
can be called as

[K, E] = elliptic123(m) % complete
[K, E, PI] = elliptic123(m,n) % complete

[F, E] = elliptic123(m,b) % incomplete
[F, E, PI] = elliptic123(m,b,n) % incomplete

and for which the input args accept as large a range as we can
calculate with the reciprocal-modulus and imaginary-modulus
transformations. (We are running into some issues with requiring
imaginary input into elliptic3 but we'll discuss this later.)

How does this sound to you? Would you prefer adding a separate
function for the complete forms (say, "ellipkepi.m") even if
elliptic123 uses it internally?

Cheers,
Will

[moiseev.igor]

Hi Will, I was thinking for some days on this and cannot come up with
a conclusion! I mean non contradictory. There are a lot of constraints
in the story of giving names and notations.
The elliptic world is very old, so we have a mess of different names-
representations-definitions-notations for the same things. I'd prefer
not to increment the entropy with some new notations.

> Okay, this is sensible. So what would be your desired structure for us
> to add code to the repository?

You got me Will, I don't know ;) My weakest part is the naming
conventions.

> I was thinking, perhaps, of a single file called elliptic123.m that
> can be called as
>
>    [K, E] = elliptic123(m) % complete
>    [K, E, PI] = elliptic123(m,n) % complete
>
>    [F, E] = elliptic123(m,b) % incomplete
>    [F, E, PI] = elliptic123(m,b,n) % incomplete

I see incongruence/inconvenience here. That is the order of parameters
depends on the number of output arguments. I'd keep the "complete"
part under the different name, like you told the "ellipkepi.m" would
be more appropriate.

The notation of arguments, I'm trying to follow is the Milne-Thomson
notation published in Ambramovitz-Stegun (not very strictly and need
to be remastered)
So
elliptic123(n,phi,m) % incomplete 3d int
ellipkepi(n,m) % complete 3d int

But since we want to evaluate at the same time all three types of
integrals so the standard notation make a bad joke, that is the
disappearance of the parameter "n"

elliptic123(phi,m) % incomplete 1-2nd int
ellipkepi(m) % complete 1-2nd int

so the parameters are exchanging, this is a bad style in programming.
Maybe we could do the following

Phi = elliptic(3,n,phi,m) % incomplete 3d
F = elliptic(1,phi,m) % incomplete 1st
[F, E] = elliptic([1 2], phi,m) % incomplete 1-2nd
[K, E] = elliptic([1 2], m) % complete 1-2nd

it is more flexible and does not macerate as an integral, it looks
like the interface method to the whole library. In any case we have
one problem if we permit the call like

[F, E, PI] = elliptic([1 2 3], n, phi,m) % incomplete 1, 2 and 3

what would be the dimension of output

size(F) = size(phi) x size(m)
size(E) = size(phi) x size(m)
size(PI) = size(n) x size(phi) x size(m)

it is confusing. I don't know, but the third integral is toooo
different from the first and second.

> and for which the input args accept as large a range as we can
> calculate with the reciprocal-modulus and imaginary-modulus
> transformations. (We are running into some issues with requiring
> imaginary input into elliptic3 but we'll discuss this later.)

You know my current realisation of elliptic3 is quite weak it is based
on the gauss approximation, so forget about good precision close to
singularities. Always wanted to implement the theta approximation or
the elliptic integrals approximation version. So you rule here as
you'll find it better.

> How does this sound to you? Would you prefer adding a separate
> function for the complete forms (say, "ellipkepi.m") even if
> elliptic123 uses it internally?

I like the idea to make the wrapper that is "ready to use" for any
inputs. I mean if you don't want to worry about the inputs use the
elliptic123, but see the drawbacks discussion at the beginning. If you
know that your integrals are complete (and don't know much about the
modulus) use ellipkepi.m. In any case the complete integral is the
smaller realisation of the incomplete, the period, and quite often in
applications you need only this. I think it should keep it in a
separate file.

So the mostly the answer is I agree to have the interface method
(maybe even graphical or both) to the library. But inside the library
we should have the very discrete, well defined, as shorter as possible
but not shorter definitions of methods which does the job!
Thats it.



_/ _/ _/ _/ _/
_/_/ _/ _/ _/_/_/ _/_/_/_/ _/_/_/
_/_/_/_/ _/ _/ _/ _/ _/ _/ _/ _/
_/ _/ _/ _/ _/ _/ _/ _/ _/
_/_/_/ _/ _/ _/ _/_/_/ _/_/ _/ _/_/_/
_/
_/ http://elliptic.googlecode.com

[moiseev.igor]

Shorter answer. Lets take the standard name "ellipke" and extend its
functionality. Then will see.