[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    Re: [math] support for discrete mathematics & number theory
From:       Phil Steitz <phil.steitz () gmail ! com>
Date:       2015-09-29 21:56:10
Message-ID: 560B08FA.5000007 () gmail ! com
[Download RAW message or body]

On 9/29/15 2:24 PM, Gilles wrote:
> On Tue, 29 Sep 2015 13:58:21 -0700, Phil Steitz wrote:
>> On 9/29/15 11:26 AM, Luca Vercelli wrote:
>>> Dear developers,
>>> I think that commons-math lacks support for number theory and
>>> algebra.
>>> In particular, the "primes" package is quite poor, as it only
>>> supports
>>> "int" primes, where some "BigInteger" would be required when
>>> searching
>>> for large primes.
>>> Second fact, for algebra applications, Rings and such would be
>>> preferred
>>> to Fields.
>>> I did some try here:
>>> https://github.com/apache/commons-math/pull/17
>>
>> I am not opposed to adding some number theory and more discrete math
>> applications; but in general we have steered away from adding
>> abstractions just to have them - i.e., our aim is not to provide a
>> universal math API.  We are really an applied math library.  We have
>> always focused on applications, adding the abstractions that we need
>> to solve the problems that [math] developers and users have in
>> applications.  For example, Field and FieldElement exist because
>> without them we could not have implemented some algorithms (or more
>> precisely, we would have had to implement some things separately for
>> real and complex numbers.)  Can you provide some examples showing
>> how Rings and Monoids would be used to solve applied problems?  I am
>> asking this naively so that we can focus the abstraction that we add
>> on the problems we are going to solve.  In other words, I would be
>> much happier extending interfaces if I had a problem whose solution
>> was easier as a result of the added abstraction.
>
> Would it hurt (technically) if the code is more OO?
> If "Field" is defined, mathematically, in terms of more basic
> concepts,
> it makes sense to mimic that at the code level.

Not necessarily.  If you want your code to be as simple and
approachable as possible, you limit abstractions to what is needed
to solve the problem(s) it is solving.  Excessive abstraction makes
code harder to follow and maintain.  Gratuitous abstraction is
actually bad OO design.  Good design models the domain
characteristics relevant and useful to the programming problems
being solved. I have no objection to adding algebraic objects as
part of implementation of applied algorithms.  Just adding rings
because fields are rings makes no more sense than turning all of the
linear objects into elements of abstract linear spaces - until we
need such abstraction for an actual algorithm.

I would like to see some actual applications before we add more to
these base interfaces.

Phil

> [Not disagreeing that using those blocks in CM would be welcome.]
>
> I'd suggest that all these classes go into their own to-be-created
> package ("o.a.c.m.algebra"?) rather than stay at top-level.
>
> Gilles
>
>>
>> Phil
>>>
>>> Luca
>>> (Apologizes if this email was sent multiple times)
>>>
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>



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

[prev in list] [next in list] [prev in thread] [next in thread]