From GianLuigi Piacentini@21:1/5 to All on Fri Jul 15 23:14:36 2022
Hi all,

suppose we have some geometry related problem.
We know the approximate problem location, say it is around X = 10000, Y
= 10000 units and the whole problem may be inscribed in a square, say
100 by 100 units, so that every geometric entity involved in the
solution, and the solution itself, is around that (10000,10000).

We can solve directly, but we have a bias of 10000 that we carry along
in the calculations.
We can subtract the bias, we know it's (10000, 10000), obtainig a
problem confined in a square of 100 by 100 around origin, solve the
transformed problem, and backtransform.
But during that translation to bring problem near the origin, we
subtract numbers that are close together: it seems a candidate for
catastrophic cancellation.

How to handle such things ?

Apologizing for my english, thanks in advance.

Gigi

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From gah4@21:1/5 to GianLuigi Piacentini on Fri Jul 15 16:23:55 2022
On Friday, July 15, 2022 at 2:14:40 PM UTC-7, GianLuigi Piacentini wrote:

suppose we have some geometry related problem.
We know the approximate problem location, say it is around X = 10000, Y
= 10000 units and the whole problem may be inscribed in a square, say
100 by 100 units, so that every geometric entity involved in the
solution, and the solution itself, is around that (10000,10000).

We can solve directly, but we have a bias of 10000 that we carry along
in the calculations.
We can subtract the bias, we know it's (10000, 10000), obtainig a
problem confined in a square of 100 by 100 around origin, solve the transformed problem, and backtransform.
But during that translation to bring problem near the origin, we
subtract numbers that are close together: it seems a candidate for catastrophic cancellation.

If the coordinates are integer, then there is no cancellation problem.

Otherwise, a little more detail would help.

In the usual case, there is no problem subtracting as you say.
If there is loss, it already occurred.

If you have floating point numbers, then add 10000 to them, and
then subtract 10000, you will see significance loss. But the loss
occurs on adding, not on subtracting.

This is commonly seen in matrix problem, where in once step,
a large value is added, and then later subtracted. We notice it
at the subtraction, but it was already lost.

There is another to consider, and this is where the subtraction
is important. Many years ago, I had a polynomial least-squares
fit program. In the first step, it would find the arithmetic mean
for each coordinate and subtract. Then after the fit, it would add
back when giving the results.

Even for linear least squares, one computes the square of
the y coordinate values. (And the x coordinate to compute r.)
It is easy to overflow, and also precision loss is worse.
But if you compute a higher power fit, it is worse.
For a quadratic fit, y values are computed to the 4th power.
One can easily overflow if the numbers are large.

In any case, as noted, any loss has already occurred.
If that is a problem, you have to go back to see where
that occurred.

Note that many problems use double precision for intermediate
values, even when single precision results are needed.
That is to avoid such intermediate loss problems.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From GianLuigi Piacentini@21:1/5 to All on Sat Jul 16 09:49:18 2022
On 16/07/22 01:23, gah4 wrote:
On Friday, July 15, 2022 at 2:14:40 PM UTC-7, GianLuigi Piacentini wrote:

suppose we have some geometry related problem.
We know the approximate problem location, say it is around X = 10000, Y
= 10000 units and the whole problem may be inscribed in a square, say
100 by 100 units, so that every geometric entity involved in the
solution, and the solution itself, is around that (10000,10000).

We can solve directly, but we have a bias of 10000 that we carry along
in the calculations.
We can subtract the bias, we know it's (10000, 10000), obtainig a
problem confined in a square of 100 by 100 around origin, solve the
transformed problem, and backtransform.
But during that translation to bring problem near the origin, we
subtract numbers that are close together: it seems a candidate for
catastrophic cancellation.

If the coordinates are integer, then there is no cancellation problem.

Otherwise, a little more detail would help.

CAD/CAM-related problems, like laser-cutting ends on long pipes. Using double-precision floating point everywhere. It's a hobby project.
I understand that in that particular case a tolerance field within one
unit (mm) is adequate, but I would like to clarify my mind...

In the usual case, there is no problem subtracting as you say.
If there is loss, it already occurred.

If you have floating point numbers, then add 10000 to them, and
then subtract 10000, you will see significance loss. But the loss
occurs on adding, not on subtracting.

This is commonly seen in matrix problem, where in once step,
a large value is added, and then later subtracted. We notice it
at the subtraction, but it was already lost.

There is another to consider, and this is where the subtraction
is important. Many years ago, I had a polynomial least-squares
fit program. In the first step, it would find the arithmetic mean
for each coordinate and subtract. Then after the fit, it would add
back when giving the results.

Even for linear least squares, one computes the square of
the y coordinate values. (And the x coordinate to compute r.)
It is easy to overflow, and also precision loss is worse.
But if you compute a higher power fit, it is worse.
For a quadratic fit, y values are computed to the 4th power.
One can easily overflow if the numbers are large.

In any case, as noted, any loss has already occurred.
If that is a problem, you have to go back to see where
that occurred.

Note that many problems use double precision for intermediate
values, even when single precision results are needed.
That is to avoid such intermediate loss problems.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)