> We can hardly add an override of valueOf(float).
correction
We can hardly add an overload of valueOf(float).
On 2025-02-14 15:12, Raffaello Giulietti wrote:
I think that we should definitely improve the documentation of
valueOf(double) to clarify that passing a float might not be the best
u
I think that we should definitely improve the documentation of
valueOf(double) to clarify that passing a float might not be the best
usage of the method, and suggest using the idiom
valueOf(Float.toString(f))
as already noted in this thread.
We can hardly add an override of valueOf(floa
My latest thoughts; please advise if I have misunderstood anything.
On Jan 24, 2025, at 3:11 AM, Jan Kowalski wrote:
I'd say that, if it's possible, we should reduce the arithmetic artifacts,
rather than introduce them through not really needed, and not visible at the
first sight, type conver
I ran the benchmark once again for a smaller float, and a bigger float, and
seems like suggested implementation still outperforms current one, however
as the number grows the difference seems to be less significant.
Benchmark (iterations)
(value) Mod
Hi Jan,
just to note that the benchmark results only measure the case 0.1f. For
more general floats, the perf gains might look less impressive (but I
didn't check).
Anyway, a fresh name seems to be the less risky solution, if we agree
that the problem is widespread enough to justify adding t
Thank you all for your replies!
I'm aware of the workaround (we are using this approach in our project) and
the problematic issues with decimal conversions. However, I also think that
we should make sure that the behaviour of the code is more predictable. For
me and other developers, it might be c
Hi Jan,
to add to the other replies, it's a bit unfortunate that the doc of
valueOf(double) suggests that this method should preferably be used to
convert _float_ values as well.
You are right that your valueOf(float) would be a better fit, but again,
that's hardly possible for source compat
On 1/23/2025 2:35 PM, Remi Forax wrote:
Hello Jan,
what you are suggesting is not a backward compatible change.
There is a source compatibility impact, meaning that for some call
sites, the mapping of existing code using BigDecimal before and after
the addition of the overloaded method would
Hello,
On 1/23/2025 1:46 PM, Kevin Bourrillion wrote:
Hi,
Before addressing your request I want to try to just add a little
context as to what’s really going on (after which Joe will probably
correct me).
I'll augment Kevin's reply anyway :-)
You might know some or all of this, but it’s
, 2.0 is a double and there is no FloatStream while
there is a DoubleStream.
regards,
Rémi
> From: "Kevin Bourrillion"
> To: "Jan Kowalski"
> Cc: "core-libs-dev"
> Sent: Thursday, January 23, 2025 10:46:51 PM
> Subject: Re: Adding BigDecimal.val
Hi,
Before addressing your request I want to try to just add a little context as to
what’s really going on (after which Joe will probably correct me). You might
know some or all of this, but it’s a refresher for everyone (including myself).
First, the value 0.1d is a “human-friendly” representa
Hi!
I’m currently working on a project that heavily relies on float values, and
we occasionally use BigDecimal for more precise mathematical operations.
However, I’ve noticed that the current BigDecimal constructor
implementation only supports double, which can lead to unintentional type
conversio
12 matches
Mail list logo
