Re: [NUMBERS] Article on Commons Numbers

[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

[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