Hacker News Reader

Comment by Monkeyget | Hacker News Reader

I read the original erroneous code, the mistake and attempted to write a correct solution. I ended up with '(2048 - (size % 2048)) + size', the same expression as the original :/.

Us humans just don't do well with edge cases in ranges/bounds. Another seemingly simple task which is easy to trip over is : determining if a time interval overlaps another.

View on HN

I think my default code these for cases where like this where an option is to "do nothing" or "return 0" is to always to have a first line like:

if (dont_have_to_do_anything) return;

His corrected version

  padded_size := (size + 2047) & ~2047

may be correct or it may not be, I can't really tell quickly because it's so oblique to me. Combining decimal and binary arithmetic like that is a bit too old school for me -- of course I still use it on occasion but I try to avoid it. I guess it's second nature to game devs.

What's wrong with

  padded_size := ceil(size / 2048) * 2048

apart from the fact that it's much much slower but still really really fast in what I can only assume is a part of the source where performance doesn't matter, anyway.

   padded_size := ceil(size / 2048) * 2048

... may be wrong if size is large that can't be store in mantissa of double/float.

Assuming C (or equivalent), I usually do this:

    padded_size = ((size + 2047) / 2048) * 2048;

this is generic. You can also take into account that 2048 is a power of 2. So you can shift right and then left again.

All relevant compilers do that automatically.

The corrected version is more recognizable to me as "round"; I believe this is a fairly common pattern in code that needs to round or align to powers of two.

However, I'll agree that it is perhaps overly clever. I recently wrote some code that used this pattern, except I had remembered it wrong and wrote something like:

    padded_size := (size + 2047) & ~2048

(2048 instead of 2047.) Luckily it was caught in code review, but it's worth being a bit more explicit; our solution (aside from fixing the number) was to add ASSERT(padded_size % 2048 == 0) so that it was clear what the code was trying to do.

Reply on news.ycombinator.com