I was hoping for feedback, from scientists, about what level of accuracy their codes or fields of study typically require. Maybe the weekend wasn't the best time to post.. hmm..
On Sun, May 1, 2016 at 1:31 AM, Peter St. John <peter.st.j...@gmail.com> wrote: > A bit off the wall, and not much help for what you are doing now, but sooner > or later we won't be hand-crating ruthlessly optimal code; we'll be training > neural nets. You could do this now if you wanted: the objective function is > just accurate answers (which you get from sub-optimal but mathematically > correct existing code) and the wall clock (faster is better), and you train > with the target hardware. So in principle it's easy, and if you look at how > fast Deep Mind trained AlphaGo it begins to sound feasible to train for fast > fourier transforms or whatever. > Peter > > On Fri, Apr 29, 2016 at 9:06 PM, William Johnson <meatheadmer...@gmail.com> > wrote: >> >> Due to the finite nature of number representation on computers, >> any answer will be an approximation to some degree. >> To me, it looks to be a non-issue to some 15 significant digits. >> I would say it depends how accurate you need. >> You could do long-hand general calculations that track percent error, >> and see how it gets compounded in a particular series of calculations. >> >> If you got right into the nuts and bolts of writing optimized functions, >> there are many clever ways to calculate common functions >> that you can find in certain math or algorithms & data structures texts. >> You would also need intimate knowledge of the target chipset. >> But it seems that would be way too much time in >> research and development to reinvent the wheel. >> >> >> On Fri, Apr 29, 2016 at 7:28 PM, Greg Lindahl <lind...@pbm.com> wrote: >>> >>> On Sat, Apr 30, 2016 at 02:23:31AM +0800, C Bergström wrote: >>> >>> > Surprisingly, glibc does a pretty respectable job in terms of >>> > accuracy, but alas it's certainly not the fastest. >>> >>> If you go look in the source comments I believe it says which paper's >>> algorithm it is using... doing range reduction for sin(6e5) is >>> expensive to do accurately. Which is why the x86 sin() hardware >>> instruction does it inaccurately but quickly, and most people/codes >>> don't care. >>> >>> -- greg >>> >>> >>> >>> _______________________________________________ >>> Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing >>> To change your subscription (digest mode or unsubscribe) visit >>> http://www.beowulf.org/mailman/listinfo/beowulf >> >> >> >> _______________________________________________ >> Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing >> To change your subscription (digest mode or unsubscribe) visit >> http://www.beowulf.org/mailman/listinfo/beowulf >> > > > _______________________________________________ > Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing > To change your subscription (digest mode or unsubscribe) visit > http://www.beowulf.org/mailman/listinfo/beowulf > _______________________________________________ Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
