Mail Archives: geda-user/2016/01/06/19:29:23
--089e0122f088844e700528b38f36
Content-Type: text/plain; charset=UTF-8
> <snip>
>
>> Hmm. I had intended the geometry.h as a sort of portable source library,
>> without any encapsulated pcb-specific decisions. As it happens I already
>> have pcb_geometry.h as well which does some adaptation. Perhaps the
>> latter
>> just needs to grow a bit, at which point our ideas of how to handle this
>> are
>> probably about the same.
>>
>
> Sounds good. I'll start "drawing" because I am not sure I can follow the
> details. Upper libs depend on lower libs.
>
> A pcb
> B pcb-specific-geo (often with complex pcb types)
> C generic-geo
>
> So you say C does everything in floating point, and B is responsible for
> proper rounding/conversions? Or did I get the whole stack wrong?
>
You've pretty much got it. B would maybe also be responsible for doing
something intelligent with degenerate inputs (where pcb allows them) and
maybe some obnoxious cases for which there is no obvious generally correct
floating point approach (e.g. arcs of identical or nearly identical
circles).
I admit that by the time you do all this it gets tempting to roll your own
fixed-point math.h, but I suspect there are a lot of subtle traps there as
well.
Britton
>
>
>
> <snip>
>
>> Here's one attempt at a general approach to this problem:
>>
>>
>> http://www.gnu.org/software/gsl/manual/html_node/Approximate-Comparison-of-
>>
>> Floating-Point-Numbers.html#Approximate-Comparison-of-Floating-Point-Number
>> s
>>
>
> Nice!
>
> <snip>
>
>> I'm not sure about this. A wider float type can actually represent
>> everything in a narrower int type. Consider:
>>
>> #include <float.h>
>> #include <stdint.h>
>> #include <math.h>
>> #include <stdio.h>
>>
>> int
>> main (void)
>> {
>> printf (
>> "INT32_MAX: %i\n", INT32_MAX);
>> printf (
>> "pow (FLT_RADIX, DBL_MANT_DIG) - 1: %f\n",
>> pow (FLT_RADIX, DBL_MANT_DIG) - 1 );
>> printf (
>> "pow (FLT_RADIX, DBL_MANT_DIG): %f\n",
>> pow (FLT_RADIX, DBL_MANT_DIG) );
>> printf (
>> "pow (FLT_RADIX, DBL_MANT_DIG) + 1: %f\n",
>> pow (FLT_RADIX, DBL_MANT_DIG) + 1 );
>>
>> return 0;
>> }
>>
>> which gives:
>>
>> $ gcc --std=c11 -Wall -Wextra -Werror text.c
>> $ ./a.out
>> INT32_MAX: 2147483647
>> pow (FLT_RADIX, DBL_MANT_DIG) - 1: 9007199254740991.000000
>> pow (FLT_RADIX, DBL_MANT_DIG): 9007199254740992.000000
>> pow (FLT_RADIX, DBL_MANT_DIG) + 1: 9007199254740992.000000
>> $
>>
>> The largest double to which you can count "by ones" is much greater than
>> INT32_MAX.
>>
>
> <snip>
>
> Yes, the relationship must be such that e.g. pow (FLT_RADIX, DBL_MANT_DIG)
>> >
>> INT32_MAX (or whatever largest coord you want to handle), or else you have
>> to worry about the exact consequences for every case (impractical).
>>
>
>
> Yup, this is generally true, and double has more bits than int32. However,
> I think you should also cosinder the x^2 cases: what happens to an
> sqrt(x^2), if x^2 was in the range of 2^31?
>
Yeah DJ hinted at this as well. My knee-jerk reaction is to use an even
winder type for the internal floating point representation. Short of
arbitrary precision there's no way to support arbitrary intermediate
results, but if you can count bye ones all the way to a squared value that
would seem to cover all the simple geometrical calculations we're
interested in. Things like hypot() help, but I admit I don't fully
understand exactly how much. They certainly keep the numbers smaller and
thereby prevent overflow, but I don't fully understand the consequences for
intermediate results outside the range where the float can represent all
integers.
Unfortunately people think of long doubles as flaky and I have this
impression also. Still, the real question is their relative flakiness
compared to everything else.
Probably none of this matters and int coordinates with double calculations
inside are fine, but it would be nice to feel certain.
Britton
--089e0122f088844e700528b38f36
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<snip><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Hmm.=C2=A0 I had intended the geometry.h as a sort of portable source libra=
ry,<br>
without any encapsulated pcb-specific decisions.=C2=A0 As it happens I alre=
ady<br>
have pcb_geometry.h as well which does some adaptation.=C2=A0 Perhaps the l=
atter<br>
just needs to grow a bit, at which point our ideas of how to handle this ar=
e<br>
probably about the same.<br>
</blockquote>
<br>
Sounds good. I'll start "drawing" because I am not sure I can=
follow the details. Upper libs depend on lower libs.<br>
<br>
A pcb<br>
B pcb-specific-geo (often with complex pcb types)<br>
C generic-geo<br>
<br>
So you say C does everything in floating point, and B is responsible for pr=
oper rounding/conversions? Or did I get the whole stack wrong?<br></blockqu=
ote><div><br></div><div>You've pretty much got it.=C2=A0 B would maybe =
also be responsible for doing something intelligent with degenerate inputs =
(where pcb allows them) and maybe some obnoxious cases for which there is n=
o obvious generally correct floating point approach (e.g. arcs of identical=
or nearly identical circles).</div><div><br></div><div>I admit that by the=
time you do all this it gets tempting to roll your own fixed-point math.h,=
but I suspect there are a lot of subtle traps there as well.</div><div>=C2=
=A0</div><div style=3D"">Britton</div><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
<br>
<br>
<br>
<br>
<snip><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Here's one attempt at a general approach to this problem:<br>
<br>
<a href=3D"http://www.gnu.org/software/gsl/manual/html_node/Approximate-Com=
parison-of-" rel=3D"noreferrer" target=3D"_blank">http://www.gnu.org/softwa=
re/gsl/manual/html_node/Approximate-Comparison-of-</a><br>
Floating-Point-Numbers.html#Approximate-Comparison-of-Floating-Point-Number=
<br>
s<br>
</blockquote>
<br>
Nice!<br>
<br>
<snip><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I'm not sure about this.=C2=A0 A wider float type can actually represen=
t<br>
everything in a narrower int type.=C2=A0 Consider:<br>
<br>
=C2=A0 =C2=A0 =C2=A0#include <float.h><br>
=C2=A0 =C2=A0 =C2=A0#include <stdint.h><br>
=C2=A0 =C2=A0 =C2=A0#include <math.h><br>
=C2=A0 =C2=A0 =C2=A0#include <stdio.h><br>
=C2=A0=C2=A0<br>
=C2=A0 =C2=A0 =C2=A0int<br>
=C2=A0 =C2=A0 =C2=A0main (void)<br>
=C2=A0 =C2=A0 =C2=A0{<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0printf (<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "INT32_MAX: =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0%i\n&q=
uot;, INT32_MAX);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0printf (<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"pow (FLT_RADIX, DBL_MANT_DIG=
) - 1: =C2=A0%f\n",<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pow (FLT_RADIX, DBL_MANT_DIG) - 1 =
);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0printf (<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"pow (FLT_RADIX, DBL_MANT_DIG=
): =C2=A0 =C2=A0 =C2=A0%f\n",<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pow (FLT_RADIX, DBL_MANT_DIG) );<b=
r>
=C2=A0 =C2=A0 =C2=A0 =C2=A0printf (<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"pow (FLT_RADIX, DBL_MANT_DIG=
) + 1: =C2=A0%f\n",<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pow (FLT_RADIX, DBL_MANT_DIG) + 1 =
);<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0return 0;<br>
=C2=A0 =C2=A0 =C2=A0}<br>
<br>
which gives:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 $ gcc --std=3Dc11 -Wall -Wextra -Werror text.c=C2=A0<b=
r>
=C2=A0 =C2=A0 =C2=A0 $ ./a.out=C2=A0<br>
=C2=A0 =C2=A0 =C2=A0 INT32_MAX: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"tel:2147483647" =
value=3D"+12147483647" target=3D"_blank">2147483647</a><br>
=C2=A0 =C2=A0 =C2=A0pow (FLT_RADIX, DBL_MANT_DIG) - 1: =C2=A090071992547409=
91.000000<br>
=C2=A0 =C2=A0 =C2=A0pow (FLT_RADIX, DBL_MANT_DIG): =C2=A0 =C2=A0 =C2=A09007=
199254740992.000000<br>
=C2=A0 =C2=A0 =C2=A0pow (FLT_RADIX, DBL_MANT_DIG) + 1: =C2=A090071992547409=
92.000000<br>
=C2=A0 =C2=A0 =C2=A0$=C2=A0<br>
<br>
The largest double to which you can count "by ones" is much great=
er than<br>
INT32_MAX.<br>
</blockquote>
<br>
<snip><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Yes, the relationship must be such that e.g.=C2=A0pow (FLT_RADIX, DBL_MANT_=
DIG) ><br>
INT32_MAX (or whatever largest coord you want to handle), or else you have<=
br>
to worry about the exact consequences for every case (impractical).<br>
</blockquote>
<br>
<br>
Yup, this is generally true, and double has more bits than int32. However, =
I think you should also cosinder the x^2 cases: what happens to an sqrt(x^2=
), if x^2 was in the range of 2^31?<br></blockquote><div><br></div><div sty=
le=3D"">Yeah DJ hinted at this as well.=C2=A0 My knee-jerk reaction is to u=
se an even winder type for the internal floating point representation.=C2=
=A0 Short of arbitrary precision there's no way to support arbitrary in=
termediate results, but if you can count bye ones all the way to a squared =
value that would seem to cover all the simple geometrical calculations we&#=
39;re interested in.=C2=A0 Things like hypot() help, but I admit I don'=
t fully understand exactly how much.=C2=A0 They certainly keep the numbers =
smaller and thereby prevent overflow, but I don't fully understand the =
consequences for intermediate results outside the range where the float can=
represent all integers.</div><div style=3D""><br></div><div style=3D"">Unf=
ortunately people think of long doubles as flaky and I have this impression=
also.=C2=A0 Still, the real question is their relative flakiness compared =
to everything else.</div><div style=3D""><br></div><div style=3D"">Probably=
none of this matters and int coordinates with double calculations inside a=
re fine, but it would be nice to feel certain.</div><div>=C2=A0</div><div s=
tyle=3D"">Britton</div><div><br></div></div></div></div>
--089e0122f088844e700528b38f36--
- Raw text -