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: References:

<201601041946 DOT u04Jkn25014629 AT envy DOT delorie DOT com> <20160105090732 DOT GA17930 AT visitor2 DOT iram DOT es> Date: Tue, 5 Jan 2016 11:04:03 +0000 Message-ID: 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]" To: gEDA User Mailing List Content-Type: multipart/alternative; boundary=001a1136b270081db305289432bc 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 Precedence: bulk --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, 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

The gl rasteriser in my later branches borrows code from Cai= ro..

That uses 128 bit integer intermediates, since additional pr= ecision 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 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).

The same goes for things like number of layers... From recol= lection, 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 intermediat= e calculations (for 32 bit coords). If the geo code is centralized, it'= s easier to experiment with things like that.

--001a1136b270081db305289432bc--