On Sun, 24 Dec 2023 at 13:58, sebb <seb...@gmail.com> wrote: > > On Sun, 24 Dec 2023 at 13:16, Alex Herbert <alex.d.herb...@gmail.com> wrote: > > > > On Sun, 24 Dec 2023 at 11:45, Elliotte Rusty Harold <elh...@ibiblio.org> > > wrote: > > > > > > On Sun, Dec 24, 2023 at 9:59 AM sebb <seb...@gmail.com> wrote: > > > > > > > > Both Numbers and Statistics have implementations of > > > > > > > > BigInteger toUnsignedBigInteger(long treatedAsUnsigned) > > > > > > > > > > Can you describe a use case for this? That might help decide where it > > > belongs. I wouldn't be surprised if this is more suitable for lang > > > than Math or Numbers. > > > > > > I'd also suggest a different method name. There's no such thing as an > > > UnsignedBigInteger in Java. All BigIntegers are signed. Maybe > > > something like toBigIntegerFromUnsigned > > > > The method is effectively (but without expensive string conversions): > > > > new BigInteger(Long.toUnsignedString(v)); > > > > I do not have a use case for it other than testing unsigned integer > > math implementations. It could be used to create a valid number when > > using a long counter that has overflowed to negative. > > > > A possible home is in [Lang]: > > > > org.apache.commons.lang3.math.NumberUtils > > > > That class has some conversion methods to BigDecimal for > > floating-point numbers with rounding to a number of significant > > digits. So creating BigInteger beyond the support of the JDK methods > > is in scope. > > > > Without a use case it would just be code bloat. > > If it were added to MATH, the implementations could be dropped from > NUMBERS and STATISTICS...
Math depends on Numbers and Statistics. So that would be a circular dependency. It is a simple two line method. I think this is fine duplicated across test codebases. We could make the method public in the Numbers test class and have the relevant test Statistics code depend on the Numbers test jar. But that seems overly convoluted for the simple method. Alex --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
