State of the lib and ellip functions

[Yatekii]

Hi!

Thanks for this lib! Took me quite some to find it! Is there a reason there is no active maintenance anymore?

I would be interested in adding safe wrappers for ellpk, etc. How would I do so? Is there any active plans for this lib?

Best,
Noah

[vks]

Is there a reason there is no active maintenance anymore?

I'm not really using the library myself currently, hence the current maintenance status. However, contributions are very welcome.

I would be interested in adding safe wrappers for ellpk, etc. How would I do so?

Looking at the source, you can see that the C function is already exposed. You would just need to add a safe wrapper to the FloatSpecial trait.

I'm not 100% sure the FloatSpecial is the right way to go about this, but it mirrors how the mathematical functions are implemented in std.

Is there any active plans for this lib?

I don't have any plans currently, but I'm always interested in contributions and suggestions.

[Yatekii]

Ok, I'll see, that I add a safe wrapper then! I would love to see this active again, as I just started replacing numpy for immense speedups, but there is quite some basic mathematical functions missing to have me completely switch over.
I would love to also contribute in the future, I just wanted to make sure first that you are actively here and would also accept PRs. Because opening PRs in a dead project is not of great use ;)

I am not sure if I like the FloatSpecial trait, as we are so used to the f(x) convention of calling functions in mathematical areas other than x.f() ;) It gets even more confusing when a function takes params like x.f(y). Because this notation would imply you do something with x with the help of y. Having more focus on x. But in fact, x and y are two equal params to f(x, y) , imo.

That's just how I see it.

Thanks for the quick answer, I guess I'll make a PR in the evening.
Also, I am always in for a chat on the state of the topic on IRC (same nick on Mozilla), if you maintain presence there too =)

[vks]

there is quite some basic mathematical functions missing to have me completely switch over.

This was one of the original motivations for this project!

I am not sure if I like the FloatSpecial trait, as we are so used to the f(x) convention of calling functions in mathematical areas other than x.f() ;) It gets even more confusing when a function takes params like x.f(y). Because this notation would imply you do something with x with the help of y. Having more focus on x. But in fact, x and y are two equal params to f(x, y) , imo.

I agree with your points, but it is a trade off. I'm not sure what the best design is, which is TBH one of the reasons I did not expose the other functions yet. To summarize the reasons for and against FloatSpecial:

Pro:

• Idiomatic notation. (The Rust standard library offers x.sqrt() but not sqrt(x). Note that UFCS allows f64::sqrt(x) though.)
• Complementary to num_traits::Float.
• Easier to write generic code for f32 and f64.

Contra:

• Different from mathematical notation.
• Possibly confusing with multiple parameters.

I guess I'll make a PR in the evening.

Looking forward to it!

[vks]

I just published a version on crates.io that allows access to the C functions, including ellpk. Safer abstractions still need to be implemented.