On Mon, Feb 26, 2018 at 05:18:00PM -0700, Jonathan M Davis via Digitalmars-d-learn wrote: > On Monday, February 26, 2018 16:04:59 H. S. Teoh via Digitalmars-d-learn > wrote: [...] > > (There *are* exact representations for certain subsets of > > irrationals that allow fast computation that does not lose > > precision. But generally, they are only useful for specific > > applications where you know beforehand what form(s) your numbers > > will take. For general arithmetic, you have to compromise between > > speed and accuracy.) > > No. No. No. Floating point values are just insane. ;)
Ah, but I wasn't talking about floating point values. :-D I was thinking more along the lines of: https://github.com/quickfur/qrat [...] > In all seriousness, floating point values do tend to be highly > frustrating to deal with, and personally, I've gotten to the point > that I generally avoid them unless I need them. And much as that talks > is titled "Using Floating Point Without Losing Your Sanity," I came > away from it even more convinced that avoiding floating point values > is pretty much the only sane solution - though unfortunately, > sometimes, you really don't have a choice. [...] Well, the way I deal with floating point is, design my code with the assumption that things will be inaccurate, and compensate accordingly. :-P For the most part, it works reasonably well. Though, granted, there are still those odd cases where you have total precision loss. So yeah, it does get frustrating to deal with. But my usual Large Blunt Object approach to it is to just arbitrarily rewrite expressions until they stop exhibiting pathological behaviour. I suppose ultimately if it really absolutely matters that the code works in all possible cases with the best results, I'd sit down and actually work through how to minimize precision loss. But generally, I just don't have the patience to do that except in the few important places where it matters. At one point, I even threw in the towel and write a hackish "accuratizer" program that basically matches the first 7-8 digits of numbers and substituted them from a pregenerated list of known values results can take on. :-P This is highly context-sensitive, of course, and depends on outside knowledge that only works for specific cases. But it was very satisfying to run the program on data that's about 6-8 digits accurate, and have it spit out linear combinations of √2 accurate to 14 digits. :-D (Of course, this only works when the data is known to be combinations of √2. Otherwise it will only produce nonsensical output.) T -- I think Debian's doing something wrong, `apt-get install pesticide', doesn't seem to remove the bugs on my system! -- Mike Dresser