Hi. Le lun. 17 juil. 2023 à 02:08, Gary Gregory <garydgreg...@gmail.com> a écrit : > > At one point, I had proposed to deprecate Commons Lang' math package in > favor of something else in Commons Math or elsewhere. Commons Lang would > NOT depend on Commons Math/Other, we would just deprecate with a forwarding > link. > > This idea was rejected IIRC because I do not think there was agreement on > where to put what.
I don't recall any outright rejection, and I don't remember a conversation about code "location". String parsing in "NumberUtils" do not belong in [Numbers] but would belong to [Text] (or it would be quite fine to keep in [Lang], just weird that it is in a package called "math"...). The weirdly named "IEEE754rUtils" class contains utilities that could be moved to [Math] (or some to [Numbers] if not covered already). The third and last class is "Fraction"... > I think the Lang Fraction class for example IIRC, we indeed *agreed* to not recommend its use (cf. below). > is not a > match for the one in Math or Numbers or wherever it is. Not sure what you mean by "is not a match"; meaning "less safe" would concur with the Javadoc: ---CUT--- * <p>Note that this class is intended for common use cases, it is <i>int</i> * based and thus suffers from various overflow issues. For a BigInteger based * equivalent, please see the Commons Math BigFraction class.</p> ---CUT--- [Note: "BigFraction" is in the "commons-numbers-fraction" module in "Commons Numbers", not "Commons Math".] > > One thing to keep in mind it's OK to fill in the gaps in one component > (Math, Numbers, and so on) but that does not automatically mean that a > dependency will be introduced. For example, it would be odd for Lang or IO > to depend on Math. I totally agree with the last sentence. Inter-dependencies within "Commons" would be an interesting conversation (that has always been killed off as if "no dependency" was a virtue by itself). Within what we like to call low-level components developed here, a hierarchy could be envisioned (with a number of "steps", TBD). At the bottom, no dependency would be allowed, while at the top, dependencies towards libraries that have a strict no JAR hell policy would be allowed (e.g. Log4J2 API ?). A "Commons" component at an intermediate "step" could only depend on another "Commons" component at a lower "step" (i.e. forbidding circular dependencies). [Lang], [IO], [Numbers], [RNG] are instances that sit at the bottom. [Math] would now be at the top (several users need logging!) [Geometry] and [Statistics] depend on [Numbers] and/or [RNG] so are at a higher "step". [Imaging] would also be at an intermediate "step". Regards, Gilles > > Gary > > On Sun, Jul 16, 2023, 19:55 Dimitrios Efthymiou < > efthymiou.dimitri...@gmail.com> wrote: > > > Hello everyone. > > One thing i would love to do is to go through the apache projects, see > > which ones already depend on the math library, and see if they implement > > some math stuff that could be replaced by a call to commons math or move > > that function to the math library. Would such cases be considered valid for > > implementing new math algorithms inside the math libraries? I don't think i > > have seen any ticket that wants to implement new math algorithms. > > > > Thank you > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
