delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/01/05/06:04:20

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlemail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type;
bh=8w5/jU8KCSA5sPN5paMqauHofpAQMN+JfEQHgG+E36E=;
b=O+jVqwnpvHeB6vYgvAheoQfuza2zR1amMjXQ+dp1snR8OR7ljWdvu6NhimikpI/2lq
/q7rS37PcTpEJ0EyIyTzOqJJpVmK8zI0PezGrRhNOeV196y0xOR6bHtDgwd7iQSG8jWV
wxJy1dr0DGozhEETCHjJAb+xfMy3gs6g1cWgspqpmEsQy6AiCYYyOvxXT/lterNmPRTg
8W4yM+ye1gZPq/q2yca7GkaTswZxkI/Cawh8729WDth10k7oTCsqWcIVrD4tsgHjolav
MEE3Zha5Js40P7JPqvM6cH5d8ajBYVQ6E4i7l14n1XDUvj/z1BsqvCMcJGCrLBmvFWbS
OFNA==
MIME-Version: 1.0
X-Received: by 10.60.233.132 with SMTP id tw4mr61687575oec.35.1451991843215;
Tue, 05 Jan 2016 03:04:03 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1601051124150.9035@igor2priv>
References: <CAJXU7q8jLiY2oAGmkgfXfzdNoAg2xVRx8bxgAXyF_qqYs=9Dgw AT mail DOT gmail DOT com>
<CAC4O8c8=Vh7DcVrdrG4GE7ssBNG_VuxDLw2JSyg=Bv7Lnvfysg AT mail DOT gmail DOT com>
<CAJXU7q-iNx7PVbZHe_SC+VGs1SN-zOSPEyQjBc6CS2qD8wnpvw AT mail DOT gmail DOT com>
<CAC4O8c8sm-jp7+jvV_QJ9Zskwb31JsmPUA+BY2UkUMg31_Htsg AT mail DOT gmail DOT com>
<CAJXU7q_K3xSdNWaZy3AZ_zCCAGWjvasc8TrJYrD5xz-CZujYDA AT mail DOT gmail DOT com>
<CAC4O8c_=Hch0ttt56fyfTFaw+tcpsNG9ZA9wyfeLCynK=Bqp0A AT mail DOT gmail DOT com>
<CAJXU7q8eto_ByskRgpQJB47YjEqOc5vaXwQ-7tGsQfefC403eQ AT mail DOT gmail DOT com>
<201601041946 DOT u04Jkn25014629 AT envy DOT delorie DOT com>
<CAJXU7q831fi7+iNYD_9J75y3cjAp1__Ao8nHewuz1emNYYrvUg AT mail DOT gmail DOT com>
<alpine DOT DEB DOT 2 DOT 00 DOT 1601050404350 DOT 9035 AT igor2priv>
<20160105090732 DOT GA17930 AT visitor2 DOT iram DOT es>
<alpine DOT DEB DOT 2 DOT 00 DOT 1601051124150 DOT 9035 AT igor2priv>
Date: Tue, 5 Jan 2016 11:04:03 +0000
Message-ID: <CAJXU7q9608UoM34ANVSHzXU4u9dyYrvGRs0rHEJOG3kNZutdPw@mail.gmail.com>
Subject: Re: [geda-user] Merging stuff. How to make it happen
From: "Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: gEDA User Mailing List <geda-user AT delorie DOT com>
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

--001a1136b270081db305289432bc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The gl rasteriser in my later branches borrows code from Cairo..

That uses 128 bit integer intermediates, since additional precision is
required for that process.

The polygon code drops into doubles at various places, and I rather suspect
changing would be hard - as are most things associated with that module.

Regarding board size:

I would suggest that we ought to apply a warning (and perhaps later on a
hard limit) on board size / coordinates,  then ensure we test operation up
to those limits. (If anyone bumps into the limit, that is the time to
decide if they should be larger).

The same goes for things like number of layers... From recollection, the
code can only handle up to a certain number - but I'm not sure we enforce
gracefully when loading files etc..

Peter
On 5 Jan 2016 10:36, <gedau AT igor2 DOT repo DOT hu> wrote:

>
>
> On Tue, 5 Jan 2016, Gabriel Paubert (paubert AT iram DOT es) [via
> geda-user AT delorie DOT com] wrote:
>
>>
>>> Since the coordinate type is an integer (I consider it sort of a
>>> fixed point number, as it is in nanometer), and values are large,
>>> calculations may overflow. E.g. assume signed 32 bit coords, you get
>>> about 2.1 meters as max board size. Now look at rubber_callback():
>>> at some point it does an x*=3Dx. This means x has to be wider than
>>> int32_t else the actual limit comes down to sqrt(2.1).
>>>
>>
>> Confused, sqrt(2^31) is about 46000, so that's 46=C2=B5m.
>>
>
> You are right, I forgot to ^2 the nanometer multiplier.
>
> Please, do no use long doubles for anything. While doubles are more or
>> less standardized on IEEE-754 (or 854?) representation (there are
>> variations wrt the bit-level representation of NaN and infinities),
>> there are at least 4 different flavours of long doubles I know of:
>>
>
> I agree.
>
> An interesting theoretical option is to use 64 bit integers for
> intermediate calculations (for 32 bit coords). If the geo code is
> centralized, it's easier to experiment with things like that.
>

--001a1136b270081db305289432bc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">The gl rasteriser in my later branches borrows code from Cai=
ro..</p>
<p dir=3D"ltr">That uses 128 bit integer intermediates, since additional pr=
ecision is required for that process.</p>
<p dir=3D"ltr">The polygon code drops into doubles at various places, and I=
 rather suspect changing would be hard - as are most things associated with=
 that module.</p>
<p dir=3D"ltr">Regarding board size:</p>
<p dir=3D"ltr">I would suggest that we ought to apply a warning (and perhap=
s later on a hard limit) on board size / coordinates,=C2=A0 then ensure we =
test operation up to those limits. (If anyone bumps into the limit, that is=
 the time to decide if they should be larger).</p>
<p dir=3D"ltr">The same goes for things like number of layers... From recol=
lection, the code can only handle up to a certain number - but I&#39;m not =
sure we enforce gracefully when loading files etc..</p>
<p dir=3D"ltr">Peter</p>
<div class=3D"gmail_quote">On 5 Jan 2016 10:36,  &lt;<a href=3D"mailto:geda=
u AT igor2 DOT repo DOT hu">gedau AT igor2 DOT repo DOT hu</a>&gt; wrote:<br type=3D"attribution"=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><br>
<br>
On Tue, 5 Jan 2016, Gabriel Paubert (<a href=3D"mailto:paubert AT iram DOT es" tar=
get=3D"_blank">paubert AT iram DOT es</a>) [via <a href=3D"mailto:geda-user AT delori=
e.com" target=3D"_blank">geda-user AT delorie DOT com</a>] wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Since the coordinate type is an integer (I consider it sort of a<br>
fixed point number, as it is in nanometer), and values are large,<br>
calculations may overflow. E.g. assume signed 32 bit coords, you get<br>
about 2.1 meters as max board size. Now look at rubber_callback():<br>
at some point it does an x*=3Dx. This means x has to be wider than<br>
int32_t else the actual limit comes down to sqrt(2.1).<br>
</blockquote>
<br>
Confused, sqrt(2^31) is about 46000, so that&#39;s 46=C2=B5m.<br>
</blockquote>
<br>
You are right, I forgot to ^2 the nanometer multiplier.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Please, do no use long doubles for anything. While doubles are more or<br>
less standardized on IEEE-754 (or 854?) representation (there are<br>
variations wrt the bit-level representation of NaN and infinities),<br>
there are at least 4 different flavours of long doubles I know of:<br>
</blockquote>
<br>
I agree.<br>
<br>
An interesting theoretical option is to use 64 bit integers for intermediat=
e calculations (for 32 bit coords). If the geo code is centralized, it&#39;=
s easier to experiment with things like that.<br>
</blockquote></div>

--001a1136b270081db305289432bc--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019