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] support for discrete mathematics & number theory
Date Tue, 29 Sep 2015 21:24:51 GMT
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 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


Mime
View raw message