[mkgmap-dev] Rounding bug in splitter?

Tue Aug 11 07:52:35 BST 2009

>> private int roundDown(int val) {
>> return val >> SHIFT << SHIFT;
>> }
> I would write this as
> 
> return val & ~(1 << SHIFT);

That's not the same thing though. I assume you really mean:

return val & ~((1 << SHIFT) - 1);

And in fact that's what was there originally for positive numbers. Negative 
numbers were handled differently, for reasons I don't understand (hence why 
I'm asking on here).

I think I still prefer val >> SHIFT << SHIFT, it's clearer what's happening 
(to me at least, I appreciate everything thinks about these things differently). 
It's also fewer clock cycles unless you're on a 286 or lower ;) Though the 
clock cycle argument isn't relevant here, the code is only called twice during 
the entire split!

>> private int roundUp(int val) {
>> return (val + (1 << SHIFT) - 1) >> SHIFT << SHIFT;
>> }
> And this one as
> 
> return (val + ((1 << SHIFT) - 1))) & ~(1 << SHIFT);

Again, that would need to be (val + ((1 << SHIFT) - 1))) & ~((1 << SHIFT) 
- 1);

> It's probably not a big deal, but if SHIFT is a compile-time constant
> and the compiler performs constant folding, the run-time code should
> be shorter and faster.

Yep I'd seen that and had originally coded it that way. I've now actually 
moved the code to the Utils class and passed 'shift' in as a parameter for 
flexibility, and because in this case performance doesn't matter.

Chris