commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [Math][Numbers] Move Field, etc. to numbers?
Date Wed, 20 Sep 2017 11:29:58 GMT
On Sat, 16 Sep 2017 14:19:04 -0400, Raymond DeCampo wrote:
> [...]
>>
>> So from the POV of a "Commons Numbers" developer, what is the
>> added value of "Field"?
>> [IMO none at the moment (but that could change).]
>
>
> I'm not looking at it from the POV of a CN developer.  I am looking 
> at it
> from the POV of a CN user.

If "Commons Numbers" were only to be a copy from what is/was
in CM I'd have to agree that there was no point in having a
new component in the first place.

Since there are no users right now, it seems reasonable to
me that the KISS principle should apply.

> I believe this is covered in the following
> paragraph you quoted.

It is a nice feature, but as with any feature implemented on
top of a more basic utility, we should first look for a solution
that is compatible with the upstream dependency.

>> Since Java is strongly typed and does not support duck typing 
>> without
>>> resorting to reflection gymnastics, there is currently no way to 
>>> write an
>>> algorithm using e.g. the add() method which could be applied to
>>> o.a.c.n.f.Fraction and o.a.c.n.c.Complex without duplication, 
>>> reflection
>>> or
>>> pointless wrapper extensions.

You may be right.
But is the CM solution the best we can do, now that it is
the moment where other solutions can be explored?

>> [...]
>>
> To be blunt I don't agree with the approach

Which one?

> so I am not about to devote
> time and effort to supporting it.

You are smarter than I ever was, since I devoted a lot of time
to implement compromise decisions in CM, although I knew that
they were bad (and proven to be so later on).

You are definitely right that the wrapper approach takes a
lot of time, mainly because of the awful amount of duplication
in the CM unit tests classes.
[I spent countless hours fixing the same in the RNG code.]

I badly underestimated the task for "Fraction"/"BigFraction". :-/

> I'm also not particularly interested in
> arguing about it.  So I have completed the portions where we have 
> agreement
> and left the rest.
>
> Summarizing the other issues I found while trying to eliminate 
> BigFraction,
> Fraction and Complex from CM:
>
> I found nine test classes which use FractionField, those would need 
> to be
> rewritten.  I imagine they could use a different Field implementation
> without a great deal of difficulty.

You are quite right; the "main" code is easy to adapt.
Adapting the unit tests, however, is a nightmare (+100 errors).

And I don't understand why it had to be, since the common "Field"
interfaces should in principle have allowed to write a test base
class, with the actual types be automatically exercised through
factory subclasses.

> I also found a couple of public methods in MatrixUtils that I imagine 
> will
> need to be deleted.  I don't think they would be missed but OTOH they 
> were
> added because somebody wanted them.
>
> What you do propose to do about the ComplexField, FractionField and
> BigFractionField classes?  These were part of the CM API in the last
> release are is the plan to just drop them?

I'd have thought they could be modified so that under the hood,
they use the "Numbers" implementations.

Gilles


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message