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

Reply via email to