Hi,

Thank you for the answer.

I can indeed have an instance per thread. I was just wondering if it was
thread safe. Having one instance is easier to manage, especially with DI
frameworks.

As for the use case. I actually need to solve an ODE. I was afraid of using
plain double's since I know precision errors can arise.
The other option in Commons Math is to use a Field integrator; that's why I
went for the DfpField.

Does this make sense?

Anyway, I will remove the single instance; just to be safe.

Regards,

Philippe

On Wed, Aug 19, 2020 at 1:19 PM Gilles Sadowski <[email protected]>
wrote:

> Hi.
>
> 2020-08-19 8:09 UTC+02:00, schophil <[email protected]>:
> > Hi,
> >
> > I have a question regarding the use of DfpField.
> >
> > Is an instance of DfpField thread safe?
>
> Personally I don't know. Sorry.
> I've just looked at some of the code, and there is an occurrence
> of the "synchronized" keyword; so it seems that thread-safety
> was at least taken into account.
> Maybe someone else can provide a more accurate answer...
>
> This functionality is implemented by old classes, dating before
> the project had decided to focus on immutable instances in
> order to ensure their thread-safety.
>
> And IIRC, it's the first time, in more than 10 years, that someone
> mentions using "Dfp"...
>
> > Can I use a single instance to
> > perform Dfp calculations in different threads?
>
> Could you provide an example of your use-cases?
> Isn't it possible to make copies, rather than share a single
> instance?
>
> More generally, I'm curious: why would you use it rather
> than JDK's "BigDecimal"?
>
> > I have looked at the code of Dfp and I am a bit worried by the calls to
> > DfpField.setIEEEFlagsBits().
> > Can I just set the flags in advance?
>
> You can, of course; but there are several places where the
> question of thread-safety could be raised...
>
> Also, in the new "Commons Numbers" component[1], there is an
> attempt to implement the concept of "field" in a cleaner (IMHO)
> way than in "Commons Math" (CM).
> Functionality in "Commons Numbers" is probably incomplete.
> Looking for volunteers in order to continue porting more useful
> stuff from CM (refactoring them on the way by making use of
> Java 8 features).
>
> Regards,
> Gilles
>
> [1] http://commons.apache.org/proper/commons-numbers/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to