Return-Path: 
 <dev-return-129997-apmail-commons-dev-archive=commons.apache.org@commons.apache.org>
X-Original-To: apmail-commons-dev-archive@www.apache.org
Delivered-To: apmail-commons-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 160D19170
	for <apmail-commons-dev-archive@www.apache.org>;
 Mon,  3 Oct 2011 16:51:00 +0000 (UTC)
Received: (qmail 72600 invoked by uid 500); 3 Oct 2011 16:50:59 -0000
Delivered-To: apmail-commons-dev-archive@commons.apache.org
Received: (qmail 72514 invoked by uid 500); 3 Oct 2011 16:50:59 -0000
Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@commons.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@commons.apache.org>
List-Post: <mailto:dev@commons.apache.org>
List-Id: <dev.commons.apache.org>
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Delivered-To: mailing list dev@commons.apache.org
Received: (qmail 72506 invoked by uid 99); 3 Oct 2011 16:50:59 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Oct 2011 16:50:59 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
	tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of phil.steitz@gmail.com
 designates 209.85.214.43 as permitted sender)
Received: from [209.85.214.43] (HELO mail-bw0-f43.google.com) (209.85.214.43)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Oct 2011 16:50:53 +0000
Received: by bkas6 with SMTP id s6so7651246bka.30
        for <dev@commons.apache.org>; Mon, 03 Oct 2011 09:50:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        bh=xZwJYRIkoOYh8KWCV5Gt92Ci38g4sUb6syY68S5fMTQ=;
        b=uWHic8+HSM6YtIkOeucCXnadBrQqBodrSVwAFSw1YAp+N2cit8QyZYppHcBwSEsApJ
         S0AC817g9jWOIDzupOqVzKSrAJzNrd5LsEa3+/RwkEsWgT2ET4B/iv4OgpIe0dDoRIYJ
         Vm4MB6fwrZXF+pBdtb6G7Bod2jYXclToUjVzA=
MIME-Version: 1.0
Received: by 10.204.156.195 with SMTP id y3mr86880bkw.260.1317660632558; Mon,
 03 Oct 2011 09:50:32 -0700 (PDT)
Received: by 10.204.61.5 with HTTP; Mon, 3 Oct 2011 09:50:32 -0700 (PDT)
In-Reply-To: 
 <CAGRH7Ho_wRRoTgT_6Nnm=CV4Ydmff7na0EUCLLUdMPe99T10NA@mail.gmail.com>
References: 
 <CAGRH7HpV6XWhVUfXPXdzkPn024trqjnkfuMwtUocoMjBB199dw@mail.gmail.com>
	<4E89CD4A.9000603@gmail.com>
	<CAGRH7Ho_wRRoTgT_6Nnm=CV4Ydmff7na0EUCLLUdMPe99T10NA@mail.gmail.com>
Date: Mon, 3 Oct 2011 09:50:32 -0700
Message-ID: 
 <CAM=kAoRn3hE4nv-C+oKwTJJ5YmzX=v=qV1LjKmX4wL2m835CxA@mail.gmail.com>
Subject: Re: [math] Support for Abelian Groups and Rings?
From: Phil Steitz <phil.steitz@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Virus-Checked: Checked by ClamAV on apache.org

2011/10/3 S=E9bastien Brisard <sebastien.brisard@m4x.org>:
> 2011/10/3 Phil Steitz <phil.steitz@gmail.com>:
>> On 10/3/11 7:00 AM, S=E9bastien Brisard wrote:
>>> Hello,
>>> I'm using quite extensively the Field/FieldElement interfaces, but am
>>> sometimes feeling the need for less stringent sets like Abelian Groups
>>> (no multiplication) and Rings (no division). This would allow me to
>>> carry out some calculations on different types of number simply by
>>> changing the generic type.
>>> I was thinking of adding some interfaces along the lines of the two
>>> above mentioned
>>> =A0 - AbelianGroup<T>, AbelianGroupElement<T>,
>>> =A0 - Ring<T>, RingElement<T>.
>>>
>>> Do you think that would be useful?
>>
>> If you have practical applications, then OK; if this is just to have
>> more math abstractions, we have generally been conservative about
>> that (i.e., introduce the abstractions as we need them for practical
>> applications). =A0Can you describe a little the use cases?
>>
>> Phil
>>
> Hi Phil,
>
> The application I have in mind is the manipulation of Taylor
> expansions (stored as multivariate polynomials). I'm trying to use
> genericity in order to be able to work with different number
> representations (exact fractions, double values, etc...).
> From this point of view, it would be useful to be able to have a
> wrapper class for (for example) integers. However, this is not
> possible at the moment, since Z is only a ring.
>
> OK, I could go on, but honestly Phil, I think I won't be able to
> convince you. Indeed, if this feature existed, I would use it, but I
> must admit that I proposed it because I also find such a feature
> "beautiful" (which is not a very good reason for adding it to CM).
> What I'm going to do is implement those mathematical entities on my
> side, and try and use them. If I realize they could be useful to the
> core CM library, I'll raise this issue again later.

Sounds like a good plan.  Don't get me wrong - we added Field for the
same kinds of reasons (needed for some applications and code reuse).

Phil


> Thank you for trying to reason me...
> S=E9bastien
>
> ---------------------------------------------------------------------
> 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