iota to array

[H. S. Teoh]

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