Hi.

Le jeu. 13 juil. 2023 à 02:04, Dimitrios Efthymiou
<efthymiou.dimitri...@gmail.com> a écrit :
>
> Thank you very much for replying.
> 1--If I understood you correctly, apache commons will keep only the
> existing 5 math-related libraries. Meaning that any math theory has to be
> implemented in 1 of these 5 libraries. Is that correct?

Currently, yes.  But it is not cast in stone; the (PMC) decision could be
revisited, for example if the same principles, that led to some a component
being created, can be applied to another codebase.  [At the time, there
were quite opposite opinions about which principles were important for
taking the decision.]

> 2--my implementation uses only BigDecimal for unlimited precision. No
> primitives are involved. Of course I can change that, but the point of
> OrionMath was to have unlimited precision.

Some algorithms in "Commons Math" are coded twice: one performs
basic operations (addition, multiplication) on primitive "double", while
the other uses a "field" object, an interface that can provide alternative
"numbers", e.g. with extended precision.
Many tasks can be considered in this area.

> 3--of course I would be willing to do the work

Thanks!

> of implementing the thing
> the Apache Way.

Actually, it's more about following the current conventions of the
project/component, so as to alleviate reviewing work...

> 4--there is functionality that already exists in the commons math-related
> libraries. Absolutely. I would implement math algorithms that don't exist.

Even if they exist, they may not with high precision.  It might be interesting
to set up a "benchmark" framework to display precision vs performance
trade-offs.

> 5--I built that library, because I wanted to apply the math stuff i learnt
> in the math school from 2004-2008. I wanted to start a library in late
> 2008, but I only got around in doing it in 2019+2020.
> 6--i built it only to get happiness from it and not because I needed a math
> library. But i am sure that AI, physics, data science and all branches of
> engineering would need a comprehensive math library.

Yes, but the main drivers for a design could differ depending whether the
purpose is illustrating a school course, or solving a "real-world" problem.
In the latter case, the first requirement is usually speed if "double" precision
is good enough for the task at hand.

> I understand the YAGNI
> principle, but I don't know how many people have to implement their own
> math library that do the things OrionMath does, because the open source
> libraries don't provide those algorithms.

While in other languages (C, C++), there seems to be a convergence
towards a "standard" math library, in Java, everyone wants to make his own
from scratch... :-/

> Take vector algebra, for example.
> How many functions do math libraries have related to vectors? Mine has 60
> functions just for vectors.

Well, "Commons Math" has vectors in the "o.a.c.math4.legacy.linear"
package (but perhaps it should not, as the "matrix" concept would cover
it), and "Commons Geometry" also has vectors, because those in "linear"
are too bloated for the purpose (and in practice, because the "Geometry"
component is lower-level and thus cannot depend on "Commons Math").

> There are useful stuff there that are needed in
> machine learning or physics. You know?

Interesting stuff, for sure. "Commons Math" has packages
 * o.a.c.math4.neuralnet
 * o.a.c.math4.legacy.ml

There have long been several JIRA issues associated with the clustering
algorithms implemented in "ml".  It would be great to refactor/fix it...

> 7--here is my code
> https://github.com/orionlibs/orion/tree/main/orion_math/src/main/java/com/orion/math

Thanks.  I'll have a look; however, based on the above considerations,
do not hesitate to make concrete and focused proposals in every area
where you think that you can contribute to enhance the math-related
components (bug-fixes, new features, unit tests, benchmarks, ...).
For example, if you have an alternative implementation to some algo,
you could add it to the "src/test" area of the repository (or perhaps in the
"examples" module), and compare it (in various ways) with the "nominal"
one.

Regards,
Gilles

>>> [...]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Reply via email to