> On Jan 31, 2018, at 6:46 PM, Rob Tompkins <[email protected]> wrote: > > > >>> On Jan 31, 2018, at 5:55 PM, Gilles <[email protected]> wrote: >>> >>> On Wed, 31 Jan 2018 15:04:50 +0100, Eric Barnhill wrote: >>> On Wed, Jan 31, 2018 at 2:25 PM, Gilles <[email protected]> >>> wrote: >>> >>>> Hi Eric. >>>> >>>> It would be great if we could either resolve the following issues >>>> or have a path forward for them that would not block the release >>>> of "Commons Numbers": >>>> https://issues.apache.org/jira/browse/MATH-1445 >>> >>> >>> So, to resolve this I should remove some of the Complex libraries from >>> math-4 >> >> Yes. >> >>> or math-3.x >> >> No. [Branch "MATH_3_X" is way too old.] > > It feels a bit heavy handed to call the branch containing the latest release > “old.” Sure we have substantive work that’s diverged from that branch, but it > still remains the latest publicly available consumable artifact and thus > warrants minimally security fixes if not considerably value.
Pardon I missed the bit about where we lift code from. Makes sense then. > >> >>> and replace them with a dependency on Numbers? >> >> Right. >> >>> Just want >>> to check if I understand. >> >> CM is a testing ground: CM algorithms that use concepts that were >> re-implemented in in "Numbers" should work as they did when those >> concepts were implemented in CM. >> When the unit tests still pass, it increases the confidence that >> the ported code works as expected. >> >>> Not all of the old numbers functionality was >>> brought over (e.g. ComplexField). >> >> Indeed. >> There's work about "Field" in a separate branch: see issue >> NUMBERS-51. I'll write another post about it. >> >> However, a lot of code does not need "Field". >> In particular, "ComplexField" is never used. >> >>> Also how does this impede release of >>> Numbers. >> >> It doesn't. >> But we don't want to leave a bug that could have been >> spotted by usage, as mentioned above. >> >>>> https://issues.apache.org/jira/browse/NUMBERS-54 >>>> https://issues.apache.org/jira/browse/NUMBERS-2 >>> >>> >>> So ComplexUtils should be converted Java 8 syntax too. Well, might as well >>> do it at the same time. I'll be a proper streaming expert by the end of all >>> of it. >> >> It's a suggestion. What do you think? >> IMHO, we should avoid bloating the API, especially if a >> better alternative can be proposed (possibly in v1.1). >> I'd thus propose to not ship the first release with >> "ComplexUtils". Also, it's a higher-level code that might >> deserve to be put in its own package/module (to depend on >> "commons-numbers-complex". >> >> Regards, >> Gilles >> >>> >>> >>>> >>>> https://issues.apache.org/jira/browse/NUMBERS-17 >>> >>> >>> Comment added to JIRA, this can be closed. >>> >>> Eric >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
