[mkgmap-dev] Question reg. LinePreparer

Tue Feb 5 13:09:32 GMT 2013

Hi Steve,

thanks, I did also find no better explanation. 
Maybe at that time it was possible that a very long way was passed to
LinePreparer.

Gerd

Steve Ratcliffe wrote
> On 05/02/13 07:38, GerdP wrote:
>> Hi,
>>
>> I simply copied it to the LinePreparerFilter, but what is the idea behind
>> this code in LinePreparer?
>>
>> 			// compute normalized differences
>> 			//   -2^(shift-1) <= dx, dy < 2^(shift-1)
>> 			// XXX: relies on the fact that java integers are 32 bit signed
>> 			final int offset = 8+shift;
>> 			int dx = (lon - lastLong) << offset >> offset;
>> 			int dy = (lat - lastLat) << offset >> offset;
>>
>> I don't understand the comment. Why are the values shifted left and
>> right?
>> While debugging I did not see a case where this changed the result.
> 
> The code is to sign extend the value. So if shift was 0 (24 bit value)
> then 0x00800000 would become 0xff800000 or 0x01000000 would become
> 0x00000000.
> 
> Does this ever happen? I can't remember any problem it was fixing, but
> the code was previously just the simple "dx = (lon - lastLong)"
> and then Robert added the shifts, so it was probably in response
> to an observed problem. However there isn't any reason mentioned
> in the commit message, nor in any mailing list message around the
> time of the commit that I can see.
> 
> It is only going to happen either for very large differences that
> overflow the bit range that they should occupy, or if the input values
> are sometimes already sign extended and sometimes not. Or for some
> other reason I haven't thought of!
> 
> ..Steve
> _______________________________________________
> mkgmap-dev mailing list

> mkgmap-dev at .org

> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

--
View this message in context: http://gis.19327.n5.nabble.com/Question-reg-LinePreparer-tp5748142p5748192.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.