> On 22 Feb 2020, at 01:15, Gilles Sadowski <gillese...@gmail.com> wrote: > > Le sam. 22 févr. 2020 à 01:30, Alex Herbert <alex.d.herb...@gmail.com > <mailto: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”).
Yes. I think a lot of the private methods in Complex would have to be promoted to package private for reuse so many of the functions could operate without having to actually create an instance of Complex. That would be my suggestion. Since the beta release would be on a fork we can delete the module from the fork. Then it can be sanitised in master when appropriate. > > Regards, > Gilles > >> >> Alex >> >> [1] https://issues.apache.org/jira/browse/NUMBERS-142# >> <https://issues.apache.org/jira/browse/NUMBERS-142#> >> <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 > <mailto:dev-unsubscr...@commons.apache.org> > For additional commands, e-mail: dev-h...@commons.apache.org > <mailto:dev-h...@commons.apache.org>
