Rocksolid Light

Welcome to RetroBBS

mail  files  register  newsreader  groups  login

Message-ID:  

If a train station is a place where a train stops, what's a workstation?


devel / comp.lang.fortran / Question about geometry

SubjectAuthor
* Question about geometryGianLuigi Piacentini
`* Re: Question about geometrygah4
 `- Re: Question about geometryGianLuigi Piacentini

1
Question about geometry

<taslbt$358gi$1@dont-email.me>

  copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=2525&group=comp.lang.fortran#2525

  copy link   Newsgroups: comp.lang.fortran
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: ggpiace@tin.it (GianLuigi Piacentini)
Newsgroups: comp.lang.fortran
Subject: Question about geometry
Date: Fri, 15 Jul 2022 23:14:36 +0200
Organization: A noiseless patient Spider
Lines: 22
Message-ID: <taslbt$358gi$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 15 Jul 2022 21:14:37 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="66940e8ad3c9c48ffaa71c36cb80db7a";
logging-data="3318290"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+9E16lDXk5PjamA9Rox3Ro"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Cancel-Lock: sha1:xLxkiVDFZZLkEOUPZtWYNYWGT0s=
Content-Language: en-US
 by: GianLuigi Piacentini - Fri, 15 Jul 2022 21:14 UTC

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

Re: Question about geometry

<7901ec5b-ab61-41ab-99f1-a7588409a38fn@googlegroups.com>

  copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=2526&group=comp.lang.fortran#2526

  copy link   Newsgroups: comp.lang.fortran
X-Received: by 2002:a05:622a:551:b0:31e:cdf0:4acc with SMTP id m17-20020a05622a055100b0031ecdf04accmr12215109qtx.194.1657927435671;
Fri, 15 Jul 2022 16:23:55 -0700 (PDT)
X-Received: by 2002:a05:6902:724:b0:66e:8c2b:ef78 with SMTP id
l4-20020a056902072400b0066e8c2bef78mr17925908ybt.313.1657927435424; Fri, 15
Jul 2022 16:23:55 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.fortran
Date: Fri, 15 Jul 2022 16:23:55 -0700 (PDT)
In-Reply-To: <taslbt$358gi$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2601:602:9700:4689:ac14:afef:b729:ce86;
posting-account=gLDX1AkAAAA26M5HM-O3sVMAXdxK9FPA
NNTP-Posting-Host: 2601:602:9700:4689:ac14:afef:b729:ce86
References: <taslbt$358gi$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <7901ec5b-ab61-41ab-99f1-a7588409a38fn@googlegroups.com>
Subject: Re: Question about geometry
From: gah4@u.washington.edu (gah4)
Injection-Date: Fri, 15 Jul 2022 23:23:55 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 3537
 by: gah4 - Fri, 15 Jul 2022 23:23 UTC

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.

Re: Question about geometry

<tatqi0$3b1aa$1@dont-email.me>

  copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=2532&group=comp.lang.fortran#2532

  copy link   Newsgroups: comp.lang.fortran
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!weretis.net!feeder8.news.weretis.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: ggpiace@tin.it (GianLuigi Piacentini)
Newsgroups: comp.lang.fortran
Subject: Re: Question about geometry
Date: Sat, 16 Jul 2022 09:49:18 +0200
Organization: A noiseless patient Spider
Lines: 65
Message-ID: <tatqi0$3b1aa$1@dont-email.me>
References: <taslbt$358gi$1@dont-email.me>
<7901ec5b-ab61-41ab-99f1-a7588409a38fn@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 16 Jul 2022 07:49:20 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="f0b8a92c2ccf57d063b00de7e8f669e8";
logging-data="3507530"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/nwN1bKe2WNotU2K4RAAFL"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Cancel-Lock: sha1:SjxEBr0x+lwZHIYUWFPortTs4nk=
In-Reply-To: <7901ec5b-ab61-41ab-99f1-a7588409a38fn@googlegroups.com>
Content-Language: en-US
 by: GianLuigi Piacentini - Sat, 16 Jul 2022 07:49 UTC

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.
Many thanks for your reply.

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.
>
>
>
>
>

1
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor