On Sun, 24 Dec 2023 at 16:31, sebb <seb...@gmail.com> wrote: > > On Sun, 24 Dec 2023 at 16:14, Alex Herbert <alex.d.herb...@gmail.com> wrote: > > > > 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. > > I've just noticed that the methods are slightly different. > One uses add, the other or and a mask. > > Numbers: > return number < 0L ? > BigInteger.ONE.shiftLeft(64).add(BigInteger.valueOf(number)) : > BigInteger.valueOf(number); > > Statistics: > return v < 0 ? TWO_POW_63.or(BigInteger.valueOf(v & Long.MAX_VALUE)) : > BigInteger.valueOf(v);
Yes. I wrote the one with the or method today as I realised my original using the add was not required. Here we are combining non-overlapping bits. Doing an add will create the same result. But it will do extra work to compute the carry (of zero) up through the number. E.g. a000 + 0bcd = abcd a000 | 0bcd = abcd I'll update the original. > > > 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
