Home > Archive > APL > July 2007 > APL numercial precision
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
APL numercial precision
|
|
| sasgirl 2007-05-29, 6:57 pm |
| Anyone knows what precision APL+Win 5.0 follows? I have a recent task
to rewrite an APL program to SAS and got stuck with the rounding error
problem. Because SAS follows IEEE754, and APL only states that it also
follows 64 bits IEEE, but not specifically any further info., the
precision are different in two systems. it is often a problem when
e-18 is 0 in SAS, but positive in APL, and afterwards the branching
goes to the wrong step... I briefly understand the []pp and []ct, but
could not use it to twrist the whole calculation especially the
division... is there any utility available to upgrade APL to the
IEEE754 so that two systems got exactly the same precision?
thanks a lot,
ariel
| |
| Ibeam2000 2007-06-03, 6:56 pm |
| SAS had its origins with Fortran, and Fortran (at least IBM Fortran
Level H) had more built-in corrections for floating point edge
conditions than C does today.
Regardless, I would phrase all my floating point comparisons a bit
differently.
Rather than
:if a = b
I would write
:if eps > | a - b
Where eps (epsilon, something small) is 1e-10. In principle, []CT
should do this for you, but it could be eps should be larger than the
largest value of []CT. I would regard 1e-8 as the largest value eps
should ever be. 1e-10 is usually the largest value of []CT. (The
basic idea behind []CT is similar, but APL comparisons will
automatically scale the numbers if you are dealing with extremely
large or small numbers)
This technique also works well in languages which don't have something
like []CT, such as visual basic.
[]PP - what you see is not what you get. Setting []PP to the maximum
of 16 potentially warns you of the extra digits you don't see.
Remember, []PP affects display and formatting only. It does not
affect comparisons or arithmetic.
This technique works well in most languages
| |
|
| On Jun 3, 5:36 pm, Ibeam2000 <Ibeam2...@gmail.com> wrote:
> SAS had its origins with Fortran, and Fortran (at least IBM Fortran
> Level H) had more built-in corrections for floating point edge
> conditions than C does today.
>
> Regardless, I would phrase all my floating point comparisons a bit
> differently.
>
> Rather than
>
> :if a = b
>
> I would write
>
> :if eps > | a - b
>
> Where eps (epsilon, something small) is 1e-10. In principle, []CT
> should do this for you, but it could be eps should be larger than the
> largest value of []CT. I would regard 1e-8 as the largest value eps
> should ever be. 1e-10 is usually the largest value of []CT. (The
> basic idea behind []CT is similar, but APL comparisons will
> automatically scale the numbers if you are dealing with extremely
> large or small numbers)
>
> This technique also works well in languages which don't have something
> like []CT, such as visual basic.
>
> []PP - what you see is not what you get. Setting []PP to the maximum
> of 16 potentially warns you of the extra digits you don't see.
> Remember, []PP affects display and formatting only. It does not
> affect comparisons or arithmetic.
>
> This technique works well in most languages
The formal (and what should be the ISO Standard) definition of
"tolerant equality" in APL is:
teq: ({abs}(a-b)) {<=} {quad}ct {times}({abs} a) {max} {abs} b
Bob
| |
|
|
|
|
|