<br><br><div class="gmail_quote">On Mon, Nov 1, 2010 at 5:30 PM, Joon <span dir="ltr"><<a href="mailto:groups.and.lists@gmail.com">groups.and.lists@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">



<div style="font-family: 'Ubuntu'; font-size: 12px;">Hi,<br><br>I just found that using dot instead of sum in numpy gives me better results in terms of precision loss. For example, I optimized a function with scipy.optimize.fmin_bfgs. For the return value for the function, I tried the following two things:<br>
<br>    <font face="'DejaVu Sans Mono',monospace">sum(Xb) - sum(denominator)</font><br><br>and<br> <br>    <font face="'DejaVu Sans Mono',monospace">dot(ones(Xb.shape), Xb) - dot(ones(denominator.shape), denominator)</font><br>
<br><p>Both of them are supposed to yield the same thing. But the first one gave me -589112.30492110562 and the second one gave me -589112.30492110678.</p><p>In addition, with the routine using sum, the optimizer gave me "Warning: Desired error not necessarily achieved due to precision loss." With the routine with dot, the optimizer gave me "Optimization terminated successfully."</p>
I checked the gradient value as well (I provided analytical gradient) and gradient was smaller in the dot case as well. (Of course, the the magnitude was e-5 to e-6, but still)<br><p>I was wondering if this is well-known fact and I'm supposed to use dot instead of sum whenever possible. <br>
</p><p>It would be great if someone could let me know why this happens.</p></div></blockquote><div><br>Are you running on 32 bits or 64 bits? I ask because there are different floating point precisions on the 32 bit platform and the results can depend on how the compiler does things. The relative difference between your results is ~1e-15, which isn't that far from the float64 precision of ~2e-16, so little things can make a difference.<br>
<br>Chuck<br></div></div>