<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 10 Dec 2020 at 01:25, Dante Doménech <<a href="mailto:dante19031999@gmail.com">dante19031999@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I-ll implement a second order kahan algorithm. Third order would be overkill ( I don't think anyone is gonna use it for high precision calculus  ).<br></div><div>But it's not only sum and average, variance (stats) and any other formula with sums is affected. That's why I need time to track it.<br></div><div>And by the way, what about using long double for intermediate steps, to improve precision. For what I know glibc or whatever uses gcc on fedora uses it, </div></div></blockquote><div><br></div><div><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Note that calc is, in general, quite performance sensitive in that people care about how long it takes to calculate large spreadsheets (and some of them can get very large indeed).</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">So 128-bit floating point would probably be tricky since CPU largely don't have hardware support for direction operations on that.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"></div></div></div>