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@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Question-reg-LinePreparer-tp5748142p5748192.h... Sent from the Mkgmap Development mailing list archive at Nabble.com.