Le sam. 22 févr. 2020 à 01:30, Alex Herbert <alex.d.herb...@gmail.com> a écrit : > > > > > On 22 Feb 2020, at 00:29, Gilles Sadowski <gillese...@gmail.com> wrote: > > > > Hi. > > > > Le ven. 21 févr. 2020 à 23:15, Matt Juntunen > > <matt.juntu...@hotmail.com> a écrit : > >> > >> Are we waiting on anything for a numbers release? > > > > I don't think so. > > Are you talking about a beta release where the API is not yet frozen?
Yes. > I’m still testing versions of LinearCombination. But from the discussion on > NUMBERS-142 [1] it seems the choice may be to just change the current class > to use a more precise method. It will be slower than the current method but > will have an ensured accuracy of 1 ULP. It will be much faster than > BigDecimal. All the testing implementations can go into the examples module > for reference. > > I have 1 PR for Complex to add an internal version of Math.hypot > (NUMBERS-143). I’ll go over this soon and bring it in. The method is faster > and more accurate than Math.hypot. > > I think Complex is ISO C99 compliant and quite robust to edge cases. The > javadoc needs a second pass and then an internal rearrangement of the code > layout. I’ve left this until last so that the git change history is clear. > But the methods and API are done. > > Then there is the implementation of ComplexList for storing and working with > many complex numbers. This would be a replacement for part of > numbers.complex.stream.ComplexUtils. The question is should this part of the > API be established before any release? If a beta then we can remove redundant > methods from ComplexUtils later. I would not include the "commons-numbers-complex-streams" module (IIRC you mentioned that for performance, "ComplexList" should be in the same module as "Complex"). Regards, Gilles > > Alex > > [1] https://issues.apache.org/jira/browse/NUMBERS-142# > <https://issues.apache.org/jira/browse/NUMBERS-142#> > > > > > > Best, > > Gilles > > > >> > >>> [...] --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
