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: r1169437 - /commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/FastMath.java
Date Sun, 11 Sep 2011 17:31:54 GMT
Hello.

> >>
> >>>+ * Precomputed literal arrays are provided in this class to speed up load
> >>>+ * time.
> >>
> >>This is an implementation detail, subject to change in the (hopefully
> >>not-so-distant) future.
> >
> >Disagree.

Why?
I'm only stating a fact: Code is subject to change.

> >>I would certainly not advertize it in the Javadoc.
> >
> >I agree here.
> 
> I have advertised it as we did introduce some comments about start
> up time some months ago, after a first Jira issue about this.
> 
> Please go ahead fixing these comments so they are most useful to users.
> 
> >
> >I would also not advertise the ability to change to on the fly
> >computation, as I think this facility should be removed.
> 
> It's not really on the fly, Gilles set it up as a compile-time option.
> 
> >
> >There is quite a lot of code that relates only to the computation.
> >The code should be kept, but in a separate class (may need to add some
> >package protected methods to provide access).
> >
> >I don't think minimising the class source file size is nearly as
> >important as the startup time.
> >
> >However, there are things that can be done to make the source file
> >easier to read.
> >
> >Moving the startup code into a separate class would reduce the size of
> >the class somewhat.
> >The private classes holding preset arrays can be moved to the end of
> >the class, and entries can be packaged several per line to shorten the
> >file.
> 
> This seems fine to me.

Maybe the tables are necessary, maybe not; there is no conclusive evidence
yet or, at least, it is not publicly available.
Or we don't have rules (or I don't know them) that would readily provide an
answer based on the benchmark results currently available.
Does someone care about having a way to objectively establish whether a
change is an improvement or not?

Last night I've spent a long time to try to convince myself that ~5000
computations would slow down startup significantly. The results I've
obtained show otherwise. Maybe I did the benchmark wrong. But anyways, I
think that the minimum, before making a change which not everyone agrees
on, it to prove that it is needed.

[Then, as I'm questioning the usefulness of precomputing (in particular,
factorials), a change is committed as if this issue did not need any
consensus.]

Thus, please explain why the same policy is not applied to everyone.
I don't want to be too annoying here but I don't appreciate that the burden
of the proof is always on me, whether I'm making a change, or whether
someone else is making it and I'm questioning its validity.
[But maybe there are some special rules I've yet to discover...]


Thank for your attention,
Gilles

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


Mime
View raw message