thank you Gilles once again for this exchange. I will go for some pull requests for simple stuff first for the commons math libraries, see how that goes, and then I will consider a bigger investment
On Thu, 13 Jul 2023 at 09:55, Gilles Sadowski <gillese...@gmail.com> wrote: > 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 > >
