Le 06/08/2011 13:15, Gilles Sadowski a écrit :
Hi.
[...]
I've allowed myself to adapt your code to an array version of the
accurate "linearCombination" (committed in revision 1154416).
Thanks Gilles,
I wanted to add this too and simply forgot :-(
Here is a micro-benchmark (for an array of length 3):
-----
linearCombination (runs per timed block: 10000, timed blocks: 1000)
direct inline: 1.789185e-05 (1.580520e-05) ms
direct array: 2.009243e-05 (1.257636e-05) ms
accurate inline: 4.244761e-05 (5.882379e-05) ms
accurate array: 9.365895e-05 (6.902221e-05) ms
-----
Mre efficient implementation in revision 1154485:
-----
linearCombination (runs per timed block: 10000, timed blocks: 1000)
direct inline: 1.899314e-05 (5.587518e-05) ms
direct array: 1.918198e-05 (1.133822e-05) ms
accurate inline: 4.178593e-05 (5.697845e-05) ms
accurate array: 7.144897e-05 (3.897243e-05) ms
-----
However, I'm concerned that the "stress" test ("testLinearCombination1")
taken from your test case for Vector3D might not be stringent enough. [I
think that while changing my implemementation, the test was still passing
just before I dicovered that I was using an unitialized (set to 0 by
default) variable.]
Could you devise one sure to detect bugs like this (i.e. where all the
various variables in "linearCombination" would be significant)?
I think we could try something like generating randomly the first n-1
components of a and b arrays as high accuracy Dfp, then set up the last
component of each array so that the higher bits cancels out and some
non-zero lower bits remains. The Dfp computations would represent
reference values and we would check if the method can retrieve at least
some of the lower bits. With a large number of different arrays (say a
few hundreds, with a few dozen elements each), this would stress the
algorithm.
Does this make sense ?
Luc
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
