[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-gawk] bitwise functions with negative values
From: |
Andrew J. Schorr |
Subject: |
Re: [bug-gawk] bitwise functions with negative values |
Date: |
Wed, 5 Oct 2016 10:57:01 -0400 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
On Wed, Oct 05, 2016 at 03:45:59PM +0200, Manuel Collado wrote:
> El 05/10/2016 2:16, Andrew J. Schorr escribió:
> >[...]
> >Also, I think it's pretty weird that bits2str in the doc uses
> >zero-padding on the left. That gives strange results for negative values.
> >
> >It's not clear how to address these various issues. One idea is to stop
> >supporting negative values with these bitwise functions. And I'm not sure
> >whether compl makes any sense at all. Thoughts?
>
> Perhaps the simplest approach is to consider bitwise functions as operations
> on bit strings of fixed length, regardless of their possible numeric
> interpretation.
That does seem conceptually simplest, and I think that's sort of what the
existing regular (not -M) code tries to do, effectively for 53 or 54 bits,
the IEEE 754 precision. But there's some weird behavior at the edges. For
example:
bash-4.3$ ./gawk 'BEGIN {print compl(0)}'
9007199254740991
bash-4.3$ ./gawk 'BEGIN {print compl(1)}'
18014398509481982
The compl(0) result uses 53 bits, and the compl(1) result uses 54.
And -M is totally different.
So perhaps we should set a fixed width, such as 53 bits, and make both
regular and -M honor that width. Is that what you have in mind?
> For right shifts (similar for left shifts), there are usually three
> variants:
>
> - Logical, padding with zeros.
> - "Arithmetic", propagating the leftmost bit.
> - Circular, recycling the rightmost bit.
>
> IMHO, all these distinct variants could/should be provided.
So do you propose to extend these bitwise functions by adding an additional
argument to select which variant is used? I'm not sure it is a good idea
to add more complexity. I wonder if we would be better off if the bitwise
functions were in an extension library instead of inside core gawk, but it's
probably not a great idea to remove them at this point. We could certainly
add a more complete bitwise library in an extension, although we still
haven't grappled with how to handle MPFR support in extensions...
Regards,
Andy