Mail Archives: geda-user/2016/01/05/06:04:20
--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'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, <<a href=3D"mailto:geda=
u AT igor2 DOT repo DOT hu">gedau AT igor2 DOT repo DOT hu</a>> 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'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'=
s easier to experiment with things like that.<br>
</blockquote></div>
--001a1136b270081db305289432bc--
- Raw text -