Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming > #2331
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Newsgroups | comp.programming |
| Subject | Re: 64 bit code |
| Date | 2012-10-12 20:57 +0100 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <k59snb$oqm$1@speranza.aioe.org> (permalink) |
| References | <e5cd117b-219b-49a3-9054-3553ca359f21@googlegroups.com> <507595db$0$6898$e4fe514c@news2.news.xs4all.nl> <k5488o$cbv$1@dont-email.me> <k54j49$cns$1@speranza.aioe.org> <162dnU-Rw5IpVOrNnZ2dnUVZ8qCdnZ2d@bt.com> |
Chris Uppal wrote: > Rui Maciel wrote: > >> And let's not forget about the ever elusive 80-bit extended precision >> floating point format, also known as "why bother". > > For one answer, people might like to read: > > http://www.cs.berkeley.edu/~wkahan/Stnfrd50.pdf It appears that this text omits some important details which weight significantly on this issue. For example, in the text's part 2, where the author refers to discretized elliptic boundary-value problems, it is said: «(...) For many reasons not necessarily spawned by roundoff, the solution u has to be computed by an iteration, and that always entails the computation of a residual r := b – (A + Diag(q))·u The final accuracy of the computed u is limited by the accuracy with which the residual r can be computed. The accuracy of u , which is typically a potential, has to be sufficient to support differencing to estimate the Gradient Grad U(x), a field strength, without too much loss of accuracy to cancellation.» What must be taken under consideration in this regard is that the coefficients of A, q and b tend to assume the form of integral expressions, whose values are generally obtained by employing quadrature and cubature rules. The problem with this approach is that, in general, these quadrature/cubature rules were developed so that their result is only exact if they are used to integrate functions of a specific type. For example, a popular choise, the set of Gauss-Legendre quadrature rules, were devised to return the exact value of an integral if and only if the integrand function is a polynomial up to a certain degree. When these quadrature rules are employed to integrate functions other than the one they actually can integrate, which is what happens in practice, they only return approximate results. In other words, in this example, Matrix A and vectors q and b generally are themselves the result of an approximate calculation, and their error isn't small. To put things in perspective, It's not uncommon for these errors to be in the 1%-0.1% range. In some commercial number crunching applications that implement this class of methods, the error even goes up to 3%-4% in come applications. Meanwhile, discussing whether floats or doubles should be used is equivalent to discussing the significance of an error in the range of 0.0001%-0.00001%. Hence, why bother? To add insult to injury, discretized elliptic boundary-value problems only provide approximate solutions, unless we are dealing with a very specific problem. This means that if somehow it was possible to run all floating point operations without introducing any rounding error or any precision degradation, the end result would always be an approximate solution, not the exact one. So, although it might be nice to have heaps of precision at our disposal and a profound knowledge on how to leverage the existing tools to minimize this type of errors, spending time on this type of optimization, considering the returns that can be had from that investment, represents a complete waste of time. Rui Maciel
Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
64 bit code bob <bob@coolfone.comze.com> - 2012-10-10 08:22 -0700
Re: 64 bit code Jongware <jongware@no-spam.plz> - 2012-10-10 17:35 +0200
Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-10 17:37 +0100
Re: 64 bit code Robert Wessel <robertwessel2@yahoo.com> - 2012-10-10 12:54 -0500
Re: 64 bit code Fritz Wuehler <fritz@spamexpire-201210.rodent.frell.theremailer.net> - 2012-10-10 21:37 +0200
Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-10 21:46 -0500
Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-10 20:43 +0100
Re: 64 bit code "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-10-12 08:40 +0100
Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-12 12:36 -0500
Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-12 20:57 +0100
Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-12 21:30 +0100
Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-12 16:33 -0500
Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-13 00:44 +0100
Re: 64 bit code Ben Pfaff <blp@cs.stanford.edu> - 2012-10-12 20:07 -0700
Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-13 11:11 +0100
Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-13 13:11 +0100
Re: 64 bit code Willem <willem@turtle.stack.nl> - 2012-10-13 12:34 +0000
Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-13 09:50 -0500
Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-13 17:25 +0100
Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-13 17:53 +0100
Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-13 17:05 +0100
Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-13 10:37 +0200
Re: 64 bit code "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-10-27 12:18 +0100
Re: 64 bit code "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-10-27 12:54 +0100
Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-27 15:13 +0200
Re: 64 bit code Robert Miles <milesrf@Usenet-News.net> - 2012-10-28 04:12 -0500
Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-28 13:10 +0100
Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-29 04:38 +0000
Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-29 09:30 +0100
Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-30 22:09 +0000
Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-31 09:47 +0100
Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-31 09:55 +0100
Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-31 14:32 +0000
Re: 64 bit code Patricia Shanahan <pats@acm.org> - 2012-10-27 08:51 -0700
Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-27 17:23 +0100
Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-27 20:43 +0200
Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-30 22:16 +0000
Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-31 09:53 +0100
Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-31 14:33 +0000
Re: 64 bit code Fritz Wuehler <fritz@spamexpire-201211.rodent.frell.theremailer.net> - 2012-11-01 00:25 +0100
Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-10 21:04 +0100
Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-10 21:52 +0100
Re: 64 bit code Ian Collins <ian-news@hotmail.com> - 2012-10-11 10:50 +1300
Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-10 21:54 -0500
Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-11 13:11 +0100
Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-11 11:17 -0500
Re: 64 bit code Ben Pfaff <blp@cs.stanford.edu> - 2012-10-10 13:17 -0700
Re: 64 bit code Fritz Wuehler <fritz@spamexpire-201210.rodent.frell.theremailer.net> - 2012-10-11 19:36 +0200
Re: 64 bit code Ben Pfaff <blp@cs.stanford.edu> - 2012-10-12 08:13 -0700
Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-10 20:38 +0100
Re: 64 bit code Robin Vowels <robin.vowels@gmail.com> - 2012-10-10 15:22 -0700
Re: 64 bit code Robert Miles <milesrf@Usenet-News.net> - 2012-10-12 02:13 -0500
csiph-web