ED]>
> Sent: Sunday, July 25, 2004 7:13 PM
> Subject: Re: [math] Design review pre 1.0
>
> > Updated response interspersed. Pls correct / comment as necessary...
Yes, many thanks to Phil for so much work done! I'm sorry I haven't had time
to contribute more.
Al
===
Congratulations on the work put into [math]!
Stephen
- Original Message -
From: "Phil Steitz" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Sunday, July 25, 2004 7:13 PM
Subject: Re: [math] Design review pre 1.0
Updated response interspersed. Pls correct / comment as necessary...
Stephen Colebourne wrote:
I have performed a lightweight review of [math] from a code/style POV (not
technically as I'm not mathematical...)
1) Remember your public API that you must maintain includes both public and
protected cl
--- "Mark R. Diggory" <[EMAIL PROTECTED]> wrote:
> Al Chou wrote:
> > Before we go too far down this path, it would be very helpful to know just
> how
> > much performance penalty is incurred by specifying strictfp. That FAQ
> > certainly suggests that the difference is large and undesirable, but
Al Chou wrote:
Before we go too far down this path, it would be very helpful to know just how
much performance penalty is incurred by specifying strictfp. That FAQ
certainly suggests that the difference is large and undesirable, but like
profiling, you never really know what it is until you actua
--- "Mark R. Diggory" <[EMAIL PROTECTED]> wrote:
> Phil Steitz wrote:
>
> > [Yoav] You probably want strictfp:
> > http://www.jguru.com/faq/view.jsp?EID=17544.
> >
> >[Phil] I am not sure that we want this, but I am by no means a JVM expert.
> From what I understand, the decision comes down to s
Phil Steitz wrote:
[Yoav] You probably want strictfp:
http://www.jguru.com/faq/view.jsp?EID=17544.
[Phil] I am not sure that we want this, but I am by no means a JVM expert. From what
I understand, the decision comes down to strict consistency of results on different
platforms (mostly involvin
Yoav,
Thanks for the comments. See attempt at interspersed responses below.
Hola,
>Yes, it would be good to maintain acceptable html in javadoc. Yet, I'd
>like to point out that javadoc isn't java code. while we would like to
>maintain lots of it to help our users understand it, the library w
Hola,
>Yes, it would be good to maintain acceptable html in javadoc. Yet, I'd
>like to point out that javadoc isn't java code. while we would like to
>maintain lots of it to help our users understand it, the library works
>just fine without it.
But if you do have it, it's be nice if it were in a
I want to review this list and add in my comments...
Stephen Colebourne wrote:
I have performed a lightweight review of [math] from a code/style POV (not
technically as I'm not mathematical...)
1) Remember your public API that you must maintain includes both public and
protected classes/methods/fie
Tim O'Brien wrote:
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
3) Javadocs are sometimes thin. On occasions, they are written as
paragraphs
visually but without the HTML tag. (eg. UnivariateRealSolver) or
missing, eg StandardDeviation
[Tim O'Brien]
Agree, JavaD
> -Original Message-
> From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
> 3) Javadocs are sometimes thin. On occasions, they are written as
> paragraphs
> visually but without the HTML tag. (eg. UnivariateRealSolver) or
> missing, eg StandardDeviation
[Tim O'Brien]
Agree, JavaDocs ar
> -Original Message-
> From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
> 6) ComplexFormat doesn't extend the JDK Format class
[Tim O'Brien]
Good catch, this makes sense, and it is now has the milestone of being the
29,000th Bugzilla issue.
Tim
-
Stephen,
This ROCKS, but its going to take me all weekend to respond
accurately... ;-) I have some interesting comments for many of these issues.
-Mark
Stephen Colebourne wrote:
I have performed a lightweight review of [math] from a code/style POV (not
technically as I'm not mathematical...)
1) R
14 matches
Mail list logo
