Re: [Bug: 21.4.19] Bruised floating point numbers from string-to-int
Rodney Sparapani wrote:
[33] -6.154E-1 4.865E-1 -1.000E+0 0.000E+0 -1.000E+0
[34] 3.878E-1 4.872E-1 0.000E+0 1.000E+0 0.000E+0
[35] 3.886E-1 4.874E-1 0.000E+0 1.000E+0 0.000E+0
[36] 7.267E-1 4.456E-1 0.000E+0 1.000E+0 1.000E+0
[37] -2.721E-1 4.450E-1 -1.000E+0 0.000E+0 0.000E+0
[38] -2.741E-1 4.460E-1 -1.000E+0 0.000E+0 0.000E+0
[39] 3.948E-1 4.888E-1 0.000E+0 1.000E+0 0.000E+0
[40] 3.878E-1 4.872E-1 0.000E+0 1.000E+0 0.000E+0
[41] 3.837E-1 4.862E-1 0.000E+0 1.000E+0 0.000E+0
[42] -2.662E-1 4.419E-1 -1.000E+0 0.000E+0 0.000E+0
[43] -6.059E-1 4.886E-1 -1.000E+0 0.000E+0 -1.000E+0
[44] 7.278E-1 4.450E-1 0.000E+0 1.000E+0 1.000E+0
[45] 7.193E-1 4.493E-1 0.000E+0 1.000E+0 1.000E+0
...
And one thing that I forgot to add. The second and third columns
are unknown parameters that are being estimated. So, even though
they are all E-1 in this example, that is not always the case. So,
trying to come up with a format is not easy. That's why they are
in scientific notation in the first place. However, when you are
looking at a table of numbers it becomes difficult to easily compare
the numbers when the exponents are all over the place. Hence
the need for a function.
Thanks,
Rodney