You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Nicola Vitucci <ni...@gmail.com> on 2020/09/25 09:55:14 UTC
[NUMBERS] Article on Commons Numbers
Hi everyone,
I am writing an article on Commons Numbers on my blog, with some background and several usage examples for each module. Anyway, I could not find a clear explanation of what Numbers is meant for and its relation to other libraries (e.g. Commons Math); my understanding is that Math has become too large and there is a desire to split it into smaller, easy-to-integrate libraries. Could you clarify a little? Furthermore, do you expect the release version to be somewhat/quite different from the current beta version?
Thanks,
Nicola
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [NUMBERS] Article on Commons Numbers
Posted by Matt Sicker <bo...@gmail.com>.
Very nice blog post! If you’re looking for inspiration on what Field could
be useful for, while there aren’t included implementations to make them
appropriate in production, you can model many cryptographic operations
using different fields. AES, RSA, ChaCha, ECC; they all operate on finite
fields. I say they’re not appropriate for production because a cryptography
library should always use constant time math algorithms rather than generic
but non-constant time algorithms (the latter is represented in BigInteger
and all classes dependent on it). The API allows for constant time
implementations, though!
On Mon, Sep 28, 2020 at 16:49 Nicola Vitucci <ni...@gmail.com>
wrote:
> Hi all,
>
>
>
> Here is my article on Numbers as promised:
> https://apothem.blog/apache-commons-numbers.html
>
>
>
> I hope it can be useful as a first comprehensive documentation and as an
> outsider's perspective on the current status of the library. Please feel
> free to comment and suggest improvements!
>
>
>
> Nicola
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>
> For additional commands, e-mail: user-help@commons.apache.org
>
>
>
> --
Matt Sicker <bo...@gmail.com>
Re: [NUMBERS] Article on Commons Numbers
Posted by Alex Herbert <al...@gmail.com>.
> On 1 Oct 2020, at 15:07, Gilles Sadowski <gi...@gmail.com> wrote:
>
> ---CUT---
> more operations for angles and vectors, close equality check for complex numbers
> ---CUT---
>
There are close equality checks in o.a.c.math3.complex.Complex:
public static boolean equals(Complex x, Complex y, int maxUlps)
public static boolean equals(Complex x, Complex y)
public static boolean equals(Complex x, Complex y, double eps)
public static boolean equalsWithRelativeTolerance(Complex x, Complex y, double eps)
However there are many ways to define closeness. Thus this was removed from the new numbers Complex class to simplify the API.
I would suggest something more like a user defined closeness operator:
public static boolean equals(Complex x, Complex y, DoubleBiPredicate equal)
There is no primitive specialisation of BiPredicate for double but we could declare one.
One issue is that the equality is defined using both real and complex parts. Should these be treated with the same closeness test? In addition some values such as infinity may have only one infinite component. So are these equal:
(inf + i 3) vs (inf + i 4)
(inf + i 3) vs (-inf + i 3)
Likewise there are multiple possible instances of Complex where isNaN() returns true. Currently these situations are not dealt with in the Object.equals method of Complex either. That implements a true binary equality using doubleToLongBits on each part.
With the large number of permutations this is one to discuss on the dev list.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [NUMBERS] Article on Commons Numbers
Posted by Gilles Sadowski <gi...@gmail.com>.
Hi.
Le lun. 28 sept. 2020 à 23:49, Nicola Vitucci
<ni...@gmail.com> a écrit :
>
> Hi all,
>
> Here is my article on Numbers as promised: https://apothem.blog/apache-commons-numbers.html
Thanks for a nice presentation!
> I hope it can be useful as a first comprehensive documentation and as an outsider's perspective on the current status of the library. Please feel free to comment and suggest improvements!
There is a minor typo:
"Angle between ..."
instead of
"Cosine of the angle between ..."
Below I quote excerpts from the article that could elicit clarifications.
From the "Arrays" section:
---CUT---
It could be useful if some vector algebra functions were added [...]
---CUT---
If the meaning of vector is in the geometrical sense, the component
to look at is "Apache Commons Geometry".
If something else, perhaps more details are needed to understand
what should be the focus of the "commons-numbers-arrays" module
so as to maintain full generality, "array" being a sequence of numbers
and not a more specific concept like "Cartesian coordinates".
Wrt "MultidimensionalCounter", the originally intended purpose was
to allow a (virtual) grid structure while saving storage (because in Java
an array of arrays takes much more space than a one-dimensional
array). There is a trade-off between speed and memory.
From the "Angle" section:
---CUT---
missing operations between angles, such as addition and multiplication
by scalars.
---CUT---
Perhaps a feature request and a nice usage of the utilities in module
"commons-numbers-field"?
From the section "Gamma":
---CUT---
this seems less connected to the concept of "number" and closer to the
concept of "function".
---CUT---
Quite true, but there is a compromise between creating totally low-level
components totally consistent with their main purpose (and name), and
do some amount of grouping into a "library".
["Commons Math" was too much grouping (with the already mentioned
consequence), and a component solely devoted to the Gamma function(s)
might seem the other extreme.]
This is still up for discussion...
For example, should all those functions implement "DoubleUnaryOperator"[1]?
From the "Conclusion" section:
---CUT---
Java itself is still missing a much desired feature (operator overloading)
---CUT---
As as been mentioned in a recent thread on the "dev" ML, the
"Commons" project could be the home to common utilities in
other languages (preferably IMO if some "sharing" with the Java
world is possible). Overloading is possible in Groovy[2], for
example...
---CUT---
more operations for angles and vectors, close equality check for complex numbers
---CUT---
Feature requests welcome. Even more so, why not become an
"insider"? After all, an Apache project is supposed to mean a
"community" project. :-)
You are also most welcome to provide a PR for an "official" user
guide since most of the work is done. ;-)
Best regards,
Gilles
[1] https://docs.oracle.com/javase/8/docs/api/java/util/function/DoubleUnaryOperator.html
[2] http://groovy-lang.org/operators.html#Operator-Overloading
>
> Nicola
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [NUMBERS] Article on Commons Numbers
Posted by Nicola Vitucci <ni...@gmail.com>.
Hi all,
Here is my article on Numbers as promised: https://apothem.blog/apache-commons-numbers.html
I hope it can be useful as a first comprehensive documentation and as an outsider's perspective on the current status of the library. Please feel free to comment and suggest improvements!
Nicola
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
RE: [NUMBERS] Article on Commons Numbers
Posted by al...@gmail.com.
Sorry, for a an offtopic. Our team has been working on a mathematics library for Kotlin for some time. We've taken some ideas from commons-numbers: specifically separating algebra operations from actual implementation and raised it to a new level using Kotlin unique features. I am not sure it is possible to do it in a same way in java, but I wonder if some of solutions could be back-ported to Java. The repository is here: https://github.com/mipt-npm/kmath/tree/dev. And here is an article with some design considerations: https://proandroiddev.com/an-introduction-context-oriented-programming-in-kotlin-2e79d316b0a2.
We plan to add some wrappings on top of commons-numbers the same way we did for commons-rng in future.
With best regards, Alexander Nozik.
> -----Original Message-----
> From: Nicola Vitucci <ni...@gmail.com>
> Sent: Saturday, September 26, 2020 0:37
> To: user@commons.apache.org
> Subject: Re: [NUMBERS] Article on Commons Numbers
>
> Hi Gilles,
>
> Thanks for the detailed answer, which made things much clearer. I'll publish
> my blog post by the end of the month, and your feedback will be very
> welcome!
>
> Thanks,
>
> Nicola
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [NUMBERS] Article on Commons Numbers
Posted by Nicola Vitucci <ni...@gmail.com>.
Hi Gilles,
Thanks for the detailed answer, which made things much clearer. I'll publish my blog post by the end of the month, and your feedback will be very welcome!
Thanks,
Nicola
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [NUMBERS] Article on Commons Numbers
Posted by Gilles Sadowski <gi...@gmail.com>.
Hello.
2020-09-25 11:55 UTC+02:00, Nicola Vitucci <ni...@gmail.com>:
> Hi everyone,
>
> I am writing an article on Commons Numbers on my blog,
> with some background
> and several usage examples for each module.
Great; thanks a lot!
> Anyway, I could not find a clear
> explanation of what Numbers is meant for
https://en.wikipedia.org/wiki/Number
So it just because many modules of the "Apache Commons
Numbers" were straightforwardly intended to implement
a type of "number":
* complex number -> class "Complex"[1]
* quaternion hypercomplex number -> class "Quaternion"[2]
* rational number -> classes "Fraction" and "BigFraction"[3]
* ...
Similarly, there are implementations of numbers with certain
properties (e.g. "prime"[4]) or additional "behaviours" (e.g. an
angle is periodic[5]).
Then there are some utilities, such as "Precision" (that operate
on some types of numbers) and "ArithmeticUtils".
Eventually, I came to think that "Commons Numbers" could
also be a home for collecting several low-level "function-like"
utilities with potentially many different use-cases; hence the
additional modules that provide
* root finding,
* combinatorics,
* linear combination,
* ...
> and its relation to other libraries
> (e.g. Commons Math);
Whenever a functionality was ported to "Commons Numbers" (or
"Commons RNG", or "Commons Statistics", or "Commons Geometry")
that was/is used by "Commons Math", the next major release of
"Commons Math" will depend on the new component.
> my understanding is that Math has become too large and
> there is a desire to split it into smaller, easy-to-integrate libraries.
> Could you clarify a little?
The short story is as you state, but also: Small, focused, tightly
scoped components are easier to develop and maintain.
The somewhat longer story is that "Commons Math" development
was subject to adverse trends: maintaining backwards compatibility
versus implementing fixes and improvements that would break
backwards compatibility.
I thought that both could be achieved (through modularization
and splitting off smaller, lower-level, components)...
The full story is in the "dev" ML archive.
It must be notes that some classes of "Commons Numbers"
got definite improvements wrt to their counterpart in the last
released version of "Commons Math" (3.6.1), e.g. consistency,
unit tests coverage, performance, corner cases.
[In particular, I'm thinking of classes "Complex", "Fraction" and
"BigFraction".]
> Furthermore, do you expect the release version
> to be somewhat/quite different from the current beta version?
The purpose of release a "beta" was to get feedback and act
accordingly. Hopefully your blog will help. :-)
I look forward to reading it.
Best regards,
Gilles
[1] http://commons.apache.org/proper/commons-numbers/commons-numbers-complex
[2] http://commons.apache.org/proper/commons-numbers/commons-numbers-quaternion
[3] http://commons.apache.org/proper/commons-numbers/commons-numbers-fraction
[4] http://commons.apache.org/proper/commons-numbers/commons-numbers-primes
[5] http://commons.apache.org/proper/commons-numbers/commons-numbers-angle
> Thanks,
>
> Nicola
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org