Some problems and inconsistencies with bits.

(1). The expression:

>       (a == b)

yields type int, not type bit. Indeed, the statement:

>       bit b = (a == b);

is rejected by the compiler, and must be transofmed into:

>       bit b = cast(bit)(a==b);

in order to compile.

(2) (BUG). The statements:

>       bit b = true;
>       uint i = -b;

leave i containing the value 0x000000FF. I would have expected 0xFFFFFFFF.

(3) The declaration:

>       bit[256] b;

creates an array of 256 bytes, not 32 bytes (which would be 256 bits in total).

Arcane Jill

Yep, it stinks. A proper boolean type, that's not implicitly convertible to any other type, is required. All (sub-)expressions should be of boolean type.


"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c8s7tg$1b7s$1@digitaldaemon.com...
> Some problems and inconsistencies with bits.
>
> (1). The expression:
>
> >       (a == b)
>
> yields type int, not type bit. Indeed, the statement:
>
> >       bit b = (a == b);
>
> is rejected by the compiler, and must be transofmed into:
>
> >       bit b = cast(bit)(a==b);
>
> in order to compile.
>
> (2) (BUG). The statements:
>
> >       bit b = true;
> >       uint i = -b;
>
> leave i containing the value 0x000000FF. I would have expected 0xFFFFFFFF.
>
> (3) The declaration:
>
> >       bit[256] b;
>
> creates an array of 256 bytes, not 32 bytes (which would be 256 bits in total).
>
> Arcane Jill
>
>

>Yep, it stinks. A proper boolean type, that's not implicitly convertible to any other type, is required. All (sub-)expressions should be of boolean type.

Not implicitly convertible _from_ either.

I can't reproduce items 1 or 3. Here's the code I ran:

int main() {
  int a1,a2;
  a1 = 3;
  a2 = 4;
  bit b = (a1 == a2);
  printf("%d\n",b);

  bit b2 = true;
  uint i = -b2;
  printf("%u\n",i);

  bit[256] b3;
  printf("%d\n",b3.sizeof);

  return 0;
}

results in

0
255
32

Personally item 2 seems like an odd programming practice so the current behavior doesn't bother me.

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c8s7tg$1b7s$1@digitaldaemon.com...
> Some problems and inconsistencies with bits.
>
> (1). The expression:
>
> >       (a == b)
>
> yields type int, not type bit. Indeed, the statement:
>
> >       bit b = (a == b);
>
> is rejected by the compiler, and must be transofmed into:
>
> >       bit b = cast(bit)(a==b);
>
> in order to compile.
>
> (2) (BUG). The statements:
>
> >       bit b = true;
> >       uint i = -b;
>
> leave i containing the value 0x000000FF. I would have expected 0xFFFFFFFF.
>
> (3) The declaration:
>
> >       bit[256] b;
>
> creates an array of 256 bytes, not 32 bytes (which would be 256 bits in
total).
>
> Arcane Jill
>
>

In article <c8t5d2$2ngh$1@digitaldaemon.com>, Ben Hinkle says...
>
>I can't reproduce items 1 or 3. Here's the code I ran:
>
>int main() {
>  int a1,a2;
>  a1 = 3;
>  a2 = 4;
>  bit b = (a1 == a2);
>  printf("%d\n",b);

It appears that ints behave differently from objects in this regard. The following (very similar) code fails to compile:

class A {}

int main() {
A a1,a2;
a1 = new A;
a2 = new A;
bit b = (a1 == a2);

return 0;
}

The error message is "cannot implicitly convert int to bit". Curious.


>  bit[256] b3;
>  printf("%d\n",b3.sizeof);

I was wrong. False alarm. My error was due to the fact that MS visual studio reports b3 as being of type unsigned char[256] when you use that to step through the code. But upon investigation, visual studio is simply wrong.

I must assume therefore that the debug information in the .obj file is somehow storing the type incorrectly - which does not change the execution of the program one iota.



>Personally item 2 seems like an odd programming practice so the current behavior doesn't bother me.

I noticed it because I encountered it. It's a normal thing to do in a subtract routine where you have to propogate a carry bit (note: bit) to the next uint of a multiprecision integer.

Personally, I would favor two distinct types: bit and bool, with bit being considered an arithmetic type (like a one bit wide unsigned integer), and bool able only to take values true and false. In this scenario, bits could be auto-promoted to int or uint (since those would be widening conversions) but bool could not (because logical types should not auto-convert to arithmetic types).

Arcane Jill wrote:
> Some problems and inconsistencies with bits.
> 
> (1). The expression:
> 
> 
>>      (a == b)
> 
> 
> yields type int, not type bit. Indeed, the statement:
> 
> 
>>      bit b = (a == b);
> 
> 
> is rejected by the compiler, and must be transofmed into:
> 
> 
>>      bit b = cast(bit)(a==b);
> 
> 
> in order to compile.
> 
> (2) (BUG). The statements:
> 
> 
>>      bit b = true;
>>      uint i = -b;
> 
> 
> leave i containing the value 0x000000FF. I would have expected 0xFFFFFFFF.
> 
> (3) The declaration:
> 
> 
>>      bit[256] b;
> 
> 
> creates an array of 256 bytes, not 32 bytes (which would be 256 bits in total). 
> 
> Arcane Jill
> 
> 

template F(bit value:true)
{
    void f() {printf("true\n");}
}

template F(bit value:false)
{
    void f() {printf("false\n");}
}



void main()
{
    F!(cast(bit)(1==1)).f();
    // F!(1==1).f(); // does crash the compiler
}



bye
roel

>Personally, I would favor two distinct types: bit and bool, with bit being considered an arithmetic type (like a one bit wide unsigned integer), and bool able only to take values true and false. In this scenario, bits could be auto-promoted to int or uint (since those would be widening conversions) but bool could not (because logical types should not auto-convert to arithmetic types).

Yay, another vote!

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c8t9sf$2uua$1@digitaldaemon.com...
> In article <c8t5d2$2ngh$1@digitaldaemon.com>, Ben Hinkle says...
> >
> >I can't reproduce items 1 or 3. Here's the code I ran:
> >
> >int main() {
> >  int a1,a2;
> >  a1 = 3;
> >  a2 = 4;
> >  bit b = (a1 == a2);
> >  printf("%d\n",b);
>
> It appears that ints behave differently from objects in this regard. The following (very similar) code fails to compile:
>
> class A {}
>
> int main() {
> A a1,a2;
> a1 = new A;
> a2 = new A;
> bit b = (a1 == a2);
>
> return 0;
> }
>
> The error message is "cannot implicitly convert int to bit". Curious.

Yes, that is curious. Also note
  bit b = (a1 is a2);
works.

On Mon, 24 May 2004 17:03:11 +0000 (UTC), Arcane Jill wrote:

[snip]

> Personally, I would favor two distinct types: bit and bool, with bit being considered an arithmetic type (like a one bit wide unsigned integer), and bool able only to take values true and false. In this scenario, bits could be auto-promoted to int or uint (since those would be widening conversions) but bool could not (because logical types should not auto-convert to arithmetic types).

100% agree.

'bit' is a very small unsigned integer whose value is in the range 0 (zero)
to 1 (one). And I presume 'sizeof(bit)' should return the number of bytes
the the implementation uses.

'bool' is NOT an integer. It can only have either of two values - TRUE or FALSE. But to make some people's lives a bit easier 'cast(bit)bool' ==> 0 for FALSE and 1 for TRUE.

-- 
Derek
25/May/04 8:36:43 AM

Arcane Jill wrote:

>Personally, I would favor two distinct types: bit and bool, with bit being
>considered an arithmetic type (like a one bit wide unsigned integer), and bool
>able only to take values true and false. 
>
I'm against having two types.  Bit and bool overlap on just about all functionality.  However I do think bit should work for all cases a bool would work.

-- 
-Anderson: http://badmama.com.au/~anderson/