> >
> >
> > More nitpicking. I don't see that multiplying top and bottom by
> values.length
> > makes things better. In fact, it could reduce precision by inflating the
> > magnitude of the first term before subtracting from it and dividing it.
> >
>
> hmm, good points. this may be an example of where "consolidating
> division operations" to limit the amount of division going on does not
> necessarily lead to a better algorithm. Its general practice to
> consolidate division operations to produce a more efficient algorithm
> where ever possible.
These kinds of statements need to be substantiated from a numerical analysis
standpoint. I would like to suggest that from this point forward all assertions
about numerical stability or "best practices" in numerical computing using J2SE
be accompanied by references to definitive sources.
Now I have my doubts that its proper to do from
> what you've suggested. Yes, its optimized an will be a faster
> calculation ("values.length" fewer expensive divisions) , but it will be
> less accurate as you've suggested. Accuracy should probably be weighted
> of greater importance than efficiency in much of our work.
That is a debatable assertion. The best approach is to actually do the analysis
to determine exactly what the computational cost difference is, examine the use
cases and make a decision on what to implement and whether or not to give the
user a choice.
>
> > Also, do we really need the explicit casts to double? It seems to me that
> the
> > numerators are doubles, so the whole calculation will be double.
> >
>
> It may be an artifact from learning to program in other languages and
> not truly understanding type conversion in java arithmetic. Is it the
> case that in double/int --> double the int is converted to a double
> *prior* to the division occurring. I remember a discussion where it was
> recommended by others in the group to explicitly cast int's to double's
> in algorithms as a best practice.
>
Omitting explicit casts has caused us problems in the past. I suggest that we
continue to follow the practice of adding them.
Phil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
