Truncate norms and Fvals and update .good files.
Merge branch 'quietMadchap' of https://github.com/chapel-lang/chapel into quietMadchap
Remove redundant truncation of fval and update test_diff.good.
Merge pull request #754 from hildeth/quietMadchap

Quiet madchap floating-point precision diffs on cygwin.

Numerical accuracy differences across platforms are not entirely surprising. It can depend on numerical library implementation choices as well as compiler heuristics (such as FPU register allocation). Running these all down and getting the same exact answer on all machines (especially across different compilers/runtime libraries) could be very time-consuming.

The strategy adopted here was to just print out a fixed number of digits. I also replaced quantities that printed out as "negative zero" with a positive zero, so that small fluctuations around zero do not produce a discernable difference in the output. The .good files were updated accordingly. This eliminates the apparent differences between the cygwin and linux outputs, while still displaying enough digits to allow detection of a serious computational error.

In particular, the internal FP regsiters on ia processors use 80 bits for the intermediate representation, so one can get different results depending on whether intermediate results remain in registers vs. being written back out to memory (as a 64-bit FP rep).  It would be silly to dumb down the results we obtain on linux64 to match the apparently less accurate results on cygwin, so trying to fix this in the backend compiler e.g. by throwing -ffloat-store makes little sense.  The strategy I adopted was to just truncate the printed results so we don't show enough significant digits to display the ones that vary.  I used a hard threshold at 1e-8, which is a zeroeth-order approximation of the numerical accuracy (and a very loose bound).  It will still fail to filter out variations in very large numbers.  But I tested this patch on linux64 as well as cygwin, so it seems like the epsilon (== 1e-8 absolute) is good enough.