commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gil...@harfang.homelinux.org>
Subject Re: svn commit: r1165846 [2/2] - /commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/FastMath.java
Date Wed, 07 Sep 2011 11:07:43 GMT
On Wed, Sep 07, 2011 at 11:22:24AM +0100, sebb wrote:
> On 7 September 2011 10:46, Gilles Sadowski <gilles@harfang.homelinux.org> wrote:
> > On Wed, Sep 07, 2011 at 12:42:06AM +0100, sebb wrote:
> >> On 7 September 2011 00:04, Gilles Sadowski <gilles@harfang.homelinux.org>
wrote:
> >> > Hello.
> >> >
> >> >> Modified: commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/FastMath.java
> >> >> URL: http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/FastMath.java?rev=1165846&r1=1165845&r2=1165846&view=diff
> >> >> ==============================================================================
> >> >> --- commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/FastMath.java
(original)
> >> >> +++ commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/FastMath.java
Tue Sep  6 21:06:58 2011
> >> >> @@ -74,31 +74,6147 @@ public class FastMath {
> >> >>      /** Napier's constant e, base of the natural logarithm. */
> >> >>      public static final double E = 2850325.0 / 1048576.0 + 8.254840070411028747e-8;
> >> >>
> >> >> +    private static final int EXP_INT_TABLE_MAX_INDEX = 750;
> >> >> +    private static final int EXP_INT_TABLE_LEN = EXP_INT_TABLE_MAX_INDEX
* 2;
> >> >> +
> >> >>      /** Exponential evaluated at integer values,
> >> >> -     * exp(x) =  expIntTableA[x + 750] + expIntTableB[x+750].
> >> >> +     * exp(x) =  expIntTableA[x + EXP_INT_TABLE_MAX_INDEX] + expIntTableB[x+EXP_INT_TABLE_MAX_INDEX].
> >> >>       */
> >> >> -    private static final double EXP_INT_TABLE_A[] = new double[1500];
> >> >> +    private static final double EXP_INT_TABLE_A[] =
> >> >> +    {
> >> >> +        +0.0d,
> >> >> +        Double.NaN,
> >> >
> >> > [More than 6000 lines stripped.]
> >> >
> >> > Wouldn't it be advantageous to store those tabulated data in separate
> >> > Java files? E.g.
> >> > ---
> >> > class ExpIntTables {
> >> >    static final double[] A = {
> >> >      // Very long table.
> >> >    };
> >> >    static final double[] B = {
> >> >      // ...
> >> >    };
> >> > ---
> >> >
> >> > And in "FastMath.java":
> >> > ---
> >> > public class FastMath {
> >> >    private static final double[] EXP_INT_TABLE_A = ExpIntTables.A;
> >> >    private static final double[] EXP_INT_TABLE_B = ExpIntTables.B;
> >> > }
> >> > ---
> >>
> >> That would be possible, but would require the tables to be
> >> non-private, increasing the theoretical risk of accidental changes.
> >
> > I know, but having "package" access level reduces the risk to our own
> > mistakes, similar to any bug we can introduce when writing code.
> 
> Except that there are now many more files that may need to be debugged.

I'm not sure I understand. Once the tables are generated, you put them in
their file and those data files need not be touched anymore.

> 
> > One can also assumes that the tables  will need much less changes (if
> > at all) than actual code in "FastMath.java"; so having them in separate
> > files could reduce the risk of messing with them... And of course, there is
> > the practical advantage of not having to load/scroll 6000+ lines in orde to
> > have a look at the code.
> 
> We could move the tables and disabled setup code to the end of the source file.

I don't remember the exact setup, but I once run into a source code file
size problem by putting a lot of tables (as arrays) within the same Java
file. It was solved by separating them out in several files...
So, here one could imagine adding more and more tables (or adding more
entries to the existing ones) until this will occur.

> 
> Some of the setup code could be moved into a separate class - e.g. the
> slowExp, slowSin and SlowCos methods use the FACT table, which is not
> needed elsewhere.
> 
> > By the way, how much faster is now the first use of a method from
> > "FastMath"?
> 
> Not checked. Perhaps the OP of the JIRA will be able to help there.
> 
> That probably needs to be the next step.

If the benefit is not significant, I'd rather have the previous setup.


Gilles

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


Mime
View raw message