RFR : 8221696: MappedByteBuffer.force method to specify range

[Andrew Dinn]

On 14/05/2019 10:57, Andrew Haley wrote:
> On 5/13/19 5:14 PM, Andrew Dinn wrote:
>> Thank you for looking at the patch.
>> . . .
>>    firstly, that ps-1 clears the original bit and sets all lower bits;
> 
> I think your core argument fails at this point. You have *already*
> moved to considering a bitwise transformation as arithmetic.

Hmm, yes. Well, at least that part doesn't drag in twos complement
arithmetic, simply an understanding of how (the oh so very satisfying)
rollover of all set bits happens when you add 1 to an all 1s pattern and
hence how that rollover must happen in reverse when you subtract 1 from
a single-bit pattern.

> It helps a lot to think of the operation as sign extending the most
> significant bit. This clears up the confusion and removes the need for
> the obfuscation, I think.

Yes, that's another interesting way to think about it.

What is more interesting to me is how different programmers use a
different base toolkit of concepts (and associated coding idioms) to
convince themselves that specific combinations of logical and/or
arithmetic operations achieve desired bit-twiddling outcomes. Of course,
in many cases they don't -- because many programmers either simply don't
encounter or carefully avoid bit-bashing problems. I suspect that, say,
your work on compilers and, say, my work on graphics renderers taught us
both many bit-twiddling tricks that are far from intuitive except when
they are, if only just to us.

> Still, it's not worth arguing about. You've at least thought about it.

And perhaps not just post-hoc ;-) I have always coded and thought about
rounding down this way having first seen the same idiom many years ago
(in Interlisp-D code, believe it or not).

regards,


Andrew Dinn
-----------