(nbits + 7) // 8

?

At least that's how I'd do it in C.

Even for the nbytes case, I think I'd probably stick with my version in my own code; it's clearer to me what's going on. And in the general case there aren't always simplifications like that (although I'll have to remember this one; I'm rusty on that sort of thing).

As a long time C coder[1] ... if I had to do the same in python, and I didn't want to use the if inline, I'd almost certainly create a function:

  def ibool(x):
    """ Convert x into a 1 or a 0. """
    if x:
      return 1
    return 0

  nbytes = (nbits // 8 + ibool(nbits % 8))

...because it's just more convenient to create simple ones like that in python.

[1] Still more than python, in fact I had to stare at the nbytes expression a couple of seconds before I remembered that "//" is an operator and not a comment (I guess I should start using that more, before python 3000 forces me too :)

The thing is, (nbits+7)/8 generalizes in a mathematically clean way: (nbits+k)/8. You can generalize the boolean one: nbits/8 + (n%8 >= k'), but it obfuscates what's going on mathematically; it's much easier to integrate the former into mathematical reasoning than the latter.

I can see arguing for either one, but to me (nbits+7)/8 is basically HOW I think of floor and ceiling.

Let me illustrate both of these points with an example.

Most people know you can define round(x) as floor(x+0.5). So round(x_int / 8) is floor(x__int / 8 + 0.5) is floor((x_int + 4) / 8) is (x_int+4)//8. ceil() is floor(x + 1 - epsilon), so a similar logic can be used to generate my original solution.

I agree of course that your point about the general issue of how to get a number from a boolean is interesting and useful, and you're right, I was just taking exception to this example rather than addressing your point.

In general in C I've moved away from using !!x if I want to treat the result as an integer. (I might use !! to force something to be literally 0 or 1 just because some other API takes a boolean and I want to be on the safe side.) Instead if math is involved I tend to use a ternary operation; I'll write 3*(x ? 1 : 0) before I'll write 3*!!x -- and of course I'll tend to try to distribute out the ternary as much as possible. In this case, if I want either 0 or 3, I don't conceptualize it as 'get 0 or 1, and multiply by 3', I conceptualize it as (x ? 3 : 0). I find this tends to be easier to read and understand, since it's more of a 'say what you mean, don't try to be clever' ism. I vaguely recall you had a previous python post about how to achieve an equivalent operation, though, so if I'm remember right maybe that approach is less effective in python.

(I know I've complained before, but jesus DWikiText is the hardest-to-use plain-text-markup system I've ever used. [[_|]] for _ ?! )

I agree with the previous commenter: a ternary is the way to go if you want to be clear. The typecast is OK in the sense that it’s not obscure, but I still think it does not actually express intent directly.

For some reason I have a small addiction to little overly clever Python idioms like this.

See, it’s not just us Perl folk. :-) (I mostly grew out of that phase several years ago, but when I was new to Perl I revelled in such trickery just as much. No doubt I’ll soon be unreasonably enamoured with it in Haskell. It’s part of the journey.)

—Aristotle Pagaltzis

cmp() would be, IMHO, poor form: it is documented only to return a negative, zero, or positive integer--not -1, 0 or 1 specifically, even though int.__cmp__() happens to do so.

One might (though I probably wouldn't) perhaps consider int(n.__nonzero__()) instead of int(bool(n)); the latter calls the former, but __nonzero__ expresses what you're really testing for and is marginally faster.

Even faster than that, perhaps surprisingly, seems to be 0**(0**abs(n)) (ugh), which avoids boolean types altogether. But an if...then...else would be faster still, and probably clearer.

--Dan

I can see arguing for either one, but to me (nbits+7)/8 is basically HOW I think of floor and ceiling.

I'm not arguing for my version in general, for everyone; I am saying that my version is what I thought of, so clearly it is clearer for me, at least right now. (If I internalize your idiom strongly enough, that may change.)

On the markup: part of the problem is that DWiki's usage has drifted since I picked the markup characters. In this case, underscore does not come up very often when writing about Unix commands but comes up all the time when writing about identifiers in programming languages.

(I have toyed with ways of overriding underscore but have yet to be satisfied enough with what I've come up with to commit to it.)