Mail Archives: geda-user/2016/01/05/05:34:55
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--0-1681394706-1451990233=:9035
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
On Tue, 5 Jan 2016, Gabriel Paubert (paubert AT iram DOT es) [via geda-user AT delori=
e.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=20
intermediate calculations (for 32 bit coords). If the geo code is=20
centralized, it's easier to experiment with things like that.
--0-1681394706-1451990233=:9035--
- Raw text -