Return-Path: 
 <dev-return-138352-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 E829FD1EE
	for <apmail-commons-dev-archive@www.apache.org>;
 Mon, 10 Sep 2012 20:07:40 +0000 (UTC)
Received: (qmail 97499 invoked by uid 500); 10 Sep 2012 20:07:40 -0000
Delivered-To: apmail-commons-dev-archive@commons.apache.org
Received: (qmail 97401 invoked by uid 500); 10 Sep 2012 20:07:40 -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 97391 invoked by uid 99); 10 Sep 2012 20:07:40 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Sep 2012 20:07:40 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
	tests=RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of beneritter@gmail.com designates
 209.85.210.171 as permitted sender)
Received: from [209.85.210.171] (HELO mail-iy0-f171.google.com)
 (209.85.210.171)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Sep 2012 20:07:32 +0000
Received: by iabz25 with SMTP id z25so2661756iab.30
        for <dev@commons.apache.org>; Mon, 10 Sep 2012 13:07:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        bh=NpwuPMz13ZeuE73+EBRNnsBpE6vV4G7mJoiar2oiKHA=;
        b=mGCQy9b4jkL+yaU7AVm1ap+X5Fj8qqL7i8nzilNw3/4Uag1gRVzW6gamjm326a6RsG
         LNxjMPxrKuOM1JM3i1OIoG7h1qs9GGONIMp2NypYDyMhegDnzKsgOzNO4ngDeM7fTLG8
         eA13NB3h7AaecpdlX8P01laXc0aZccsNENhBMXbH3Dzw0j0FBK8T7jkDyNzucL9kf0kC
         VvHTyiIarcuwcTRObvGF0CVEQ2gGITkuAmSTkFhhF0PX530RYo2otCYnXqMqTaM1QjsX
         9JlSlXadZ4nQCP1dhnrd0Imc10fIHv091xWZHE/SPSjtMMoGZ0UOzEgx1Bj/L1hHstiq
         nqSg==
MIME-Version: 1.0
Received: by 10.50.237.66 with SMTP id va2mr12404548igc.65.1347307631836; Mon,
 10 Sep 2012 13:07:11 -0700 (PDT)
Received: by 10.64.162.131 with HTTP; Mon, 10 Sep 2012 13:07:11 -0700 (PDT)
In-Reply-To: <504E456F.8030602@free.fr>
References: 
 <CAGRH7Hr3Wd43XCKRnL7JHSxmrtwndiGE3WEX3KjLxLCfgFkoPQ@mail.gmail.com>
	<504E456F.8030602@free.fr>
Date: Mon, 10 Sep 2012 22:07:11 +0200
Message-ID: 
 <CAB917RKwrdnw8U8nxSztRrX3UBfhLM+BUCbbLrfB4XF+TN-CNQ@mail.gmail.com>
Subject: Re: [math] Is this good practice?
From: Benedikt Ritter <beneritter@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

2012/9/10 Luc Maisonobe <Luc.Maisonobe@free.fr>:
> Le 10/09/2012 21:08, S=E9bastien Brisard a =E9crit :
>> Hi,
>
> Hi S=E9bastien,
>
>> I thought it was not good practice to rely on exception in
>> unexceptional circumstances. In ArrayFieldVector, there are numerous
>> occurences of the following pattern
>>
>>     public FieldVector<T> add(FieldVector<T> v)
>>         throws DimensionMismatchException {
>>         try {
>>             return add((ArrayFieldVector<T>) v);
>>         } catch (ClassCastException cce) {
>>             checkVectorDimensions(v);
>>             T[] out =3D buildArray(data.length);
>>             for (int i =3D 0; i < data.length; i++) {
>>                 out[i] =3D data[i].add(v.getEntry(i));
>>             }
>>             return new ArrayFieldVector<T>(field, out, false);
>>         }
>>     }
>>
>> The "catch (ClassCastException cce)" seems uggly to me. Should I file
>> a JIRA issue and start replacing with instanceof?
>
> This was done on purpose a long time ago.
> At that time, it appeared that it was faster to do it this way, i.e.
> attempt by default the fast method which did not rely on getEntry, and
> fall back to a loop using getEntry only in the very rare cases the first
> fails.
>
> I am not sure this is useful anymore, as JVM optimizers are better and
> better (so they may well replace the getEntry on the fly and use direct
> array access when they can).
>
> Perhaps you could do some benchmark with a modern JVM and look if this
> hack is still useful or not.
>

If it still is, a comment should be added to make future maintainers
aware of this fact.

Benedikt

> best regards,
> Luc
>
>> Best regards,
>> 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
>

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