Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #25200 > unrolled thread

#define BYTES *8

Back to article view | Back to comp.lang.c

Contents

  #define BYTES *8 JohnF <john@please.see.sig.for.email.com> - 2012-08-28 07:44 +0000
    Re: #define BYTES *8 Mark Bluemel <mark_bluemel@pobox.com> - 2012-08-28 09:07 +0100
    Re: #define BYTES *8 Keith Thompson <kst-u@mib.org> - 2012-08-28 01:38 -0700
      Re: #define BYTES *8 JohnF <john@please.see.sig.for.email.com> - 2012-08-28 09:21 +0000
        Re: #define BYTES *8 "BartC" <bc@freeuk.com> - 2012-08-28 12:34 +0100
          Re: #define BYTES *8 JohnF <john@please.see.sig.for.email.com> - 2012-08-28 12:23 +0000
      Re: #define BYTES *8 Kenneth Brody <kenbrody@spamcop.net> - 2012-08-29 11:10 -0400
        Re: #define BYTES *8 Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-29 11:36 -0400
          Re: #define BYTES *8 Adrian Ratnapala <raka@scooter.fritz.box> - 2012-08-30 04:01 +0000
          Re: #define BYTES *8 Kenneth Brody <kenbrody@spamcop.net> - 2012-08-30 19:08 -0400
            <OT> Re: #define BYTES *8 Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-30 21:30 -0400
              Re: <OT> Re: #define BYTES *8 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-31 02:49 +0100
                Re: <OT> Re: #define BYTES *8 JohnF <john@please.see.sig.for.email.com> - 2012-08-31 08:32 +0000
                  Re: <OT> Re: #define BYTES *8 88888 Dihedral <dihedral88888@googlemail.com> - 2012-08-31 03:55 -0700
                Re: <OT> Re: #define BYTES *8 "BartC" <bc@freeuk.com> - 2012-08-31 10:58 +0100
                  Re: <OT> Re: #define BYTES *8 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-31 11:53 +0100
                    Re: <OT> Re: #define BYTES *8 "BartC" <bc@freeuk.com> - 2012-08-31 12:39 +0100
                      Re: <OT> Re: #define BYTES *8 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-31 15:35 +0100
                        Re: <OT> Re: #define BYTES *8 "BartC" <bc@freeuk.com> - 2012-08-31 19:15 +0100
                          Re: <OT> Re: #define BYTES *8 Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-31 14:39 -0400
              Re: <OT> Re: #define BYTES *8 Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-09-06 15:14 +0300
    Re: #define BYTES *8 "Scott Fluhrer" <sfluhrer@ix.netcom.com> - 2012-08-28 12:24 -0400
      Re: #define BYTES *8 "BartC" <bc@freeuk.com> - 2012-08-28 17:44 +0100
      Re: #define BYTES *8 Keith Thompson <kst-u@mib.org> - 2012-08-28 14:42 -0700
    Re: #define BYTES *8 pete <pfiland@mindspring.com> - 2012-08-28 23:47 -0400
    Re: #define BYTES *8 Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-08-29 22:20 -0600
    Re: #define BYTES *8 John Bode <jfbode1029@gmail.com> - 2012-09-06 15:32 -0700
      Re: #define BYTES *8 pete <pfiland@mindspring.com> - 2012-09-06 20:58 -0400
        Re: #define BYTES *8 Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-09-06 21:13 -0400
        Re: #define BYTES *8 Öö Tiib <ootiib@hot.ee> - 2012-09-07 03:00 -0700
          Re: #define BYTES *8 pete <pfiland@mindspring.com> - 2012-09-08 10:00 -0400
      Re: #define BYTES *8 "BartC" <bc@freeuk.com> - 2012-09-07 02:22 +0100
        Re: #define BYTES *8 John Bode <jfbode1029@gmail.com> - 2012-09-07 05:55 -0700
    Re: #define BYTES *8 Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 14:20 -0700

Page 1 of 2  [1] 2  Next page →

#25200 — #define BYTES *8

Anything wrong with that, i.e., with  #define BYTES *8
to multiply by 8? It looked a little weird to me, but
the more obvious #define BYTES(x) ((x)*8) isn't what
I wanted to write. This was to express units of measurement,
e.g., int bits = so_many BYTES; rather than
int bits=BYTES(so_many); . I just wanted to read and write
it the first way, and my test program
 #define BYTES *8
 #include <stdio.h>
 int main ( int argc, char *argv[] ) {
  int bytes=(argc<2?1:atoi(argv[1])),
      bits = bytes BYTES;
  printf("%d bytes = %d bits\n",bytes,bits);
  return(0); }
works fine (and compiles with no -pedantic warnings).
But that #define BYTES *8 still looks a little funky to me.
I realize 2+2 BYTES must be written (2+2)BYTES, but is there
any other kind of "gotcha"?
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [next] | [standalone]

#25202

On 28/08/2012 08:44, JohnF wrote:
> Anything wrong with that, i.e., with  #define BYTES *8
> to multiply by 8? It looked a little weird to me, but
> the more obvious #define BYTES(x) ((x)*8) isn't what
> I wanted to write. This was to express units of measurement,
> e.g., int bits = so_many BYTES; rather than
> int bits=BYTES(so_many); . I just wanted to read and write
> it the first way, and my test program
>   #define BYTES *8
>   #include <stdio.h>
>   int main ( int argc, char *argv[] ) {
>    int bytes=(argc<2?1:atoi(argv[1])),
>        bits = bytes BYTES;
>    printf("%d bytes = %d bits\n",bytes,bits);
>    return(0); }
> works fine (and compiles with no -pedantic warnings).
> But that #define BYTES *8 still looks a little funky to me.
> I realize 2+2 BYTES must be written (2+2)BYTES, but is there
> any other kind of "gotcha"?
>

I hate the name - it doesn't actually convey the intent to my mind.

[toc] | [prev] | [next] | [standalone]

#25207

JohnF <john@please.see.sig.for.email.com> writes:
> Anything wrong with that, i.e., with  #define BYTES *8
> to multiply by 8? It looked a little weird to me, but
> the more obvious #define BYTES(x) ((x)*8) isn't what
> I wanted to write. This was to express units of measurement,
> e.g., int bits = so_many BYTES; rather than
> int bits=BYTES(so_many); . I just wanted to read and write
> it the first way, and my test program
>  #define BYTES *8
>  #include <stdio.h>
>  int main ( int argc, char *argv[] ) {
>   int bytes=(argc<2?1:atoi(argv[1])),
>       bits = bytes BYTES;
>   printf("%d bytes = %d bits\n",bytes,bits);
>   return(0); }
> works fine (and compiles with no -pedantic warnings).
> But that #define BYTES *8 still looks a little funky to me.
> I realize 2+2 BYTES must be written (2+2)BYTES, but is there
> any other kind of "gotcha"?

I'd say it violates the principle of least surprise.  Seeing an
identifer used that way, effectively as a postfix unary operator, is
confusing; it's very difficult to understand unless you examine the
definition of the macro.

Most macros can be understood, in terms of their meaning if not their
implementation, by looking at their names and arguments.

Something similar: Years ago, I thought that this:

    #define EVER (;;)

was clever, because I could write:

    for EVER {
        /* ... */
    }

I still think it's clever.  I just no longer think that's a good thing.

And as Mark Bluemel indicates, the name doesn't convey the meaning well.
It says that you're working with bytes somehow, but it doesn't imply
anything about a conversion to bits.

If you want to compute the number of bits in a given number of bytes,
and you're using the word "byte" as it's defined by the C standard, then
you need to multiply by CHAR_BIT, defined in <limits.h>:

    bits = bytes * CHAR_BIT;

That's clear enough that no additional macro is needed.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#25209

Keith Thompson <kst-u@mib.org> wrote:
> JohnF <john@please.see.sig.for.email.com> writes:
>> Anything wrong with that, i.e., with  #define BYTES *8
>> to multiply by 8? It looked a little weird to me, but
>> the more obvious #define BYTES(x) ((x)*8) isn't what
>> I wanted to write. This was to express units of measurement,
>> e.g., int bits = so_many BYTES; rather than
>> int bits=BYTES(so_many); . I just wanted to read and write
>> it the first way, and my test program
>>  #define BYTES *8
>>  #include <stdio.h>
>>  int main ( int argc, char *argv[] ) {
>>   int bytes=(argc<2?1:atoi(argv[1])),
>>       bits = bytes BYTES;
>>   printf("%d bytes = %d bits\n",bytes,bits);
>>   return(0); }
>> works fine (and compiles with no -pedantic warnings).
>> But that #define BYTES *8 still looks a little funky to me.
>> I realize 2+2 BYTES must be written (2+2)BYTES, but is there
>> any other kind of "gotcha"?
> 
> I'd say it violates the principle of least surprise. [...]
> [...] If you want to compute the number of bits in a given
>  number of bytes,
>    bits = bytes * CHAR_BIT;
> That's clear enough that no additional macro is needed.

My bad. The actual app involves physical units. I just used
bits/bytes as an example for the post. Moreover, the actual
program is user-modifiable at compile time by way of an
#include "userformulas.h" in the middle of the code (not as
a header) containing stuff like length=10 feet; width=3 inches;
height=4 meters; etc; (And please don't tell me that
should be input as data. The alternatives were considered
and the decision's been made.) So you can see why I want
to do this. And the aspect of the semantics you're talking
about isn't really relevant. The only question I'm asking
is about any straightforward semantic problems arising from
the funky-looking syntactic construction.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [next] | [standalone]

#25223

"JohnF" <john@please.see.sig.for.email.com> wrote in message
news:k1i2i2$6k6$1@reader1.panix.com...

> My bad. The actual app involves physical units. I just used
> bits/bytes as an example for the post. Moreover, the actual
> program is user-modifiable at compile time by way of an
> #include "userformulas.h" in the middle of the code (not as
> a header) containing stuff like length=10 feet; width=3 inches;
> height=4 meters; etc;

I use the same thing elsewhere:

 x = 3m+50cm

so x ends up as 3500 when the basic unit is mm (m scales by 1000, and cm by
10).

So it sounds reasonable enough and using #define as you have sounds like the
closest you might get in C source code.

However:

o I only use such a suffix after a constant
o It only applies to the immediately preceding constant

So your 2+2 BYTES example elsewhere would need to be written as 2 BYTES + 2
BYTES, which makes more sense anyway.

> The only question I'm asking
> is about any straightforward semantic problems arising from
> the funky-looking syntactic construction.

Without proper language support, your macro could be used in ways that were
not intended (2 BYTES BYTES BYTES for example).

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#25228

BartC <bc@freeuk.com> wrote:
> JohnF <john@please.see.sig.for.email.com> wrote
>> stuff like length=10 feet; width=3 inches;
>> height=4 meters; etc;
> 
> I use the same thing elsewhere: x = 3m+50cm
> so x ends up as 3500 when the basic unit is mm
> (m scales by 1000, and cm by 10).
> So it sounds reasonable enough and using #define as you have
> sounds like the closest you might get in C source code.

Thanks, Bart. I figured it would work because I tested it
and it worked. But I still wanted to double-check becuase
it looked strange, and I'd never used that kind of #define
construction before, nor seen similar stuff used.
   In fact, full disclosure, it would never have occurred
to me except I saw  /mm {2.834646 mul} def  in some
postscript code (who knew there were 2.83 seventy-seconds
of an inch in a mm?).

> However:
> o I only use such a suffix after a constant
> o It only applies to the immediately preceding constant
> So your 2+2 BYTES example elsewhere would need to be written
> as 2 BYTES + 2 BYTES, which makes more sense anyway.
> 
>> The only question I'm asking
>> is about any straightforward semantic problems arising from
>> the funky-looking syntactic construction.
> 
> Without proper language support, your macro could be used
> in ways that were not intended (2 BYTES BYTES BYTES for example).

-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [next] | [standalone]

#25394

On 8/28/2012 4:38 AM, Keith Thompson wrote:
[...]
> Something similar: Years ago, I thought that this:
>
>      #define EVER (;;)
>
> was clever, because I could write:
>
>      for EVER {
>          /* ... */
>      }
>
> I still think it's clever.  I just no longer think that's a good thing.

:-)

Perhaps:

    #define FOREVER for(;;)

Not that I'd ever use such a thing, of course.  Still clever.  Still "not 
really a good thing to do".

[...]

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#25398

On 8/29/2012 11:10 AM, Kenneth Brody wrote:
> On 8/28/2012 4:38 AM, Keith Thompson wrote:
> [...]
>> Something similar: Years ago, I thought that this:
>>
>>      #define EVER (;;)
>>
>> was clever, because I could write:
>>
>>      for EVER {
>>          /* ... */
>>      }
>>
>> I still think it's clever.  I just no longer think that's a good thing.
>
> :-)
>
> Perhaps:
>
>     #define FOREVER for(;;)
>
> Not that I'd ever use such a thing, of course.  Still clever.  Still
> "not really a good thing to do".

     In my own young and foolish days, I used

	#define until(x) while(!(x))

believing it improved readability.  Foolishness never leaves us
altogether, but youth and inexperience do -- and clevernesses of
this kind went into my personal "Wish I'd never done that" file
long ago.  (Right next to the FORTRAN II code that avoided an IF
by using a computed GOTO.)

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#25492

>      In my own young and foolish days, I used
>
> 	#define until(x) while(!(x))
>
> believing it improved readability.  Foolishness never leaves us

I wouldn't do that in C, but the "until" is one of the things that I did
enjoy about Perl.

[toc] | [prev] | [next] | [standalone]

#25598

On 8/29/2012 11:36 AM, Eric Sosman wrote:
> On 8/29/2012 11:10 AM, Kenneth Brody wrote:
[...]
>> Perhaps:
>>
>>     #define FOREVER for(;;)
>>
>> Not that I'd ever use such a thing, of course.  Still clever.  Still
>> "not really a good thing to do".
>
>      In my own young and foolish days, I used
>
>      #define until(x) while(!(x))
>
> believing it improved readability.  Foolishness never leaves us
> altogether, but youth and inexperience do -- and clevernesses of
> this kind went into my personal "Wish I'd never done that" file
> long ago.  (Right next to the FORTRAN II code that avoided an IF
> by using a computed GOTO.)

Ah.  You must have read that famous article "If Considered Harmful".

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#25608 — <OT> Re: #define BYTES *8

On 8/30/2012 7:08 PM, Kenneth Brody wrote:
> On 8/29/2012 11:36 AM, Eric Sosman wrote:
>> On 8/29/2012 11:10 AM, Kenneth Brody wrote:
> [...]
>>> Perhaps:
>>>
>>>     #define FOREVER for(;;)
>>>
>>> Not that I'd ever use such a thing, of course.  Still clever.  Still
>>> "not really a good thing to do".
>>
>>      In my own young and foolish days, I used
>>
>>      #define until(x) while(!(x))
>>
>> believing it improved readability.  Foolishness never leaves us
>> altogether, but youth and inexperience do -- and clevernesses of
>> this kind went into my personal "Wish I'd never done that" file
>> long ago.  (Right next to the FORTRAN II code that avoided an IF
>> by using a computed GOTO.)
>
> Ah.  You must have read that famous article "If Considered Harmful".

<off-topic>

     Perhaps you overlooked the Roman numeral.  In those days,
FORTRAN's only IF had the form

	IF ( expression ) n1, n2, n3

... with the meaning: "GOTO statement number `n1', `n2', or `n3'
as `expression' is negative, zero, or positive."  Thus

	IF (X) 1, 2, 1

... was a zero/nonzero test,

	IF (X) 1, 2, 2

... was a negative/nonnegative test, and so on.  IF(X) 1,1,1
was a plain old unconditional GOTO 1 in disguise.

     FORTRAN IV added an alternate kind of IF that was closer to
what we find in C -- but only a little bit closer.

<super-off-topic>

     Every now and then -- not often, but every now and then --
I find myself longing for the good old three-way IF.  A binary
search needs two of these newfangled two-way `if' tests where
one three-way test would suffice, and a similar situation crops
up in the inner loop of Heapsort.  Ah, well: Change (even change
for the better) always involves loss.

</super-off-topic>
</off-topic>
</maudlin-reminiscence>

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#25610 — Re: <OT> Re: #define BYTES *8

Eric Sosman <esosman@ieee-dot-org.invalid> writes:
Borrowing your off-topicality...
> <off-topic>
>
>     Perhaps you overlooked the Roman numeral.  In those days,
> FORTRAN's only IF had the form
>
> 	IF ( expression ) n1, n2, n3
>
> ... with the meaning: "GOTO statement number `n1', `n2', or `n3'
> as `expression' is negative, zero, or positive."  Thus
>
> 	IF (X) 1, 2, 1
>
> ... was a zero/nonzero test,
>
> 	IF (X) 1, 2, 2
>
> ... was a negative/nonnegative test, and so on.  IF(X) 1,1,1
> was a plain old unconditional GOTO 1 in disguise.
>
>     FORTRAN IV added an alternate kind of IF that was closer to
> what we find in C -- but only a little bit closer.
>
> <super-off-topic>
>
>     Every now and then -- not often, but every now and then --
> I find myself longing for the good old three-way IF.  A binary
> search needs two of these newfangled two-way `if' tests where
> one three-way test would suffice, and a similar situation crops
> up in the inner loop of Heapsort.  Ah, well: Change (even change
> for the better) always involves loss.

I, too, missed it on occasion, but then I got it back!  In Haskell, any
type that "inherits" from Ord (all ordered things, in effect) provides a
'compare' function that returns EQ, LT or GT.  You then "switch" on the
result.  (Scare quotes because Haskell names everything differently.)

Given that C's comparisons (struggling to get topical again) already
produce ints, it would not have seemed odd to have provided, say, <>
that yields -1, 0 or 1 in the expected way.  If strcmp and friends had
been similarly constrained, these value could have been sensible named
CMP_LT, CMP_EQ and CMP_GT (or whatever) and we could switch on them with
no magic numbers in sight.

> </super-off-topic>
> </off-topic>
> </maudlin-reminiscence>

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#25621 — Re: <OT> Re: #define BYTES *8

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> ...struggling to get topical again...
I, the op, hereby grant dispensation to all persons
in this thread to get as far off-topic as they like.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [next] | [standalone]

#25633 — Re: <OT> Re: #define BYTES *8

On Friday, August 31, 2012 4:32:57 PM UTC+8, JohnF wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> 
> > ...struggling to get topical again...
> 
> I, the op, hereby grant dispensation to all persons
> 
> in this thread to get as far off-topic as they like.
> 
> -- 
> 
> John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

Well, for an ordered set with comparison operations, 

I'll use non-zero, less than for  the signed , and smaller
for the unsigned, and just test whether the compiler is 
stupid or smart to chunk out results with some goto, i.e. jump
in the final instructions.

[toc] | [prev] | [next] | [standalone]

#25627 — Re: <OT> Re: #define BYTES *8

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
news:0.42024609db3e0dd44276.20120831024906BST.873933al0t.fsf@bsb.me.uk...
> Eric Sosman <esosman@ieee-dot-org.invalid> writes:

> A binary
>> search needs two of these newfangled two-way `if' tests where
>> one three-way test would suffice

(But sounds like an extra subtraction is needed to yield a single 3-way 
value.)

>, and a similar situation crops
>> up in the inner loop of Heapsort.  Ah, well: Change (even change
>> for the better) always involves loss.
>
> I, too, missed it on occasion, but then I got it back!  In Haskell, any
> type that "inherits" from Ord (all ordered things, in effect) provides a
> 'compare' function that returns EQ, LT or GT.  You then "switch" on the
> result.  (Scare quotes because Haskell names everything differently.)
>
> Given that C's comparisons (struggling to get topical again) already
> produce ints, it would not have seemed odd to have provided, say, <>

<> sometimes means 'not-equal' in other syntaxes.

> that yields -1, 0 or 1 in the expected way.

Such a compare could equally usefully provide an 8-way result: 3 bits that 
represent (LT,EQ,GT), giving a value 000B to 111B. With the 3-way scheme, 
you can't then feed the result to a switch that wants to deal with LT and 
LE, for example, in separate branches.

Not-equal is also badly defined in the 3-way result (either -1 or 1), but is 
101B in the 8-way one.

And if you needed to encode the desired comparison itself, to send to a 
function for example, then the 8-way code allows you to represent all six 
comparisons (000B and 111B are no-ops), instead of just three.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#25631 — Re: <OT> Re: #define BYTES *8

"BartC" <bc@freeuk.com> writes:

> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
> news:0.42024609db3e0dd44276.20120831024906BST.873933al0t.fsf@bsb.me.uk...
<snip>
>> I, too, missed it on occasion, but then I got it back!  In Haskell, any
>> type that "inherits" from Ord (all ordered things, in effect) provides a
>> 'compare' function that returns EQ, LT or GT.  You then "switch" on the
>> result.  (Scare quotes because Haskell names everything differently.)
>>
>> Given that C's comparisons (struggling to get topical again) already
>> produce ints, it would not have seemed odd to have provided, say, <>
>
> <> sometimes means 'not-equal' in other syntaxes.
>
>> that yields -1, 0 or 1 in the expected way.
>
> Such a compare could equally usefully provide an 8-way result: 3 bits
> that represent (LT,EQ,GT), giving a value 000B to 111B. With the 3-way
> scheme, you can't then feed the result to a switch that wants to deal
> with LT and LE, for example, in separate branches.
>
> Not-equal is also badly defined in the 3-way result (either -1 or 1),
> but is 101B in the 8-way one.
>
> And if you needed to encode the desired comparison itself, to send to
> a function for example, then the 8-way code allows you to represent
> all six comparisons (000B and 111B are no-ops), instead of just three.

Ha!  You nearly got me!  I'll be honest with you -- I'd commented on
three points before I got that you were joking.  If I'd seen it before
my coffee, you'd probably have had a straight answer to chuckle over.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#25637 — Re: <OT> Re: #define BYTES *8

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
news:0.01952024e6fe117e2fa0.20120831115310BST.87oblr8h9l.fsf@bsb.me.uk...
> "BartC" <bc@freeuk.com> writes:
>
>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>> news:0.42024609db3e0dd44276.20120831024906BST.873933al0t.fsf@bsb.me.uk...
> <snip>
>>> I, too, missed it on occasion, but then I got it back!  In Haskell, any
>>> type that "inherits" from Ord (all ordered things, in effect) provides a
>>> 'compare' function that returns EQ, LT or GT.  You then "switch" on the
>>> result.  (Scare quotes because Haskell names everything differently.)
>>>
>>> Given that C's comparisons (struggling to get topical again) already
>>> produce ints, it would not have seemed odd to have provided, say, <>
>>
>> <> sometimes means 'not-equal' in other syntaxes.
>>
>>> that yields -1, 0 or 1 in the expected way.
>>
>> Such a compare could equally usefully provide an 8-way result: 3 bits
>> that represent (LT,EQ,GT), giving a value 000B to 111B. With the 3-way
>> scheme, you can't then feed the result to a switch that wants to deal
>> with LT and LE, for example, in separate branches.
>>
>> Not-equal is also badly defined in the 3-way result (either -1 or 1),
>> but is 101B in the 8-way one.
>>
>> And if you needed to encode the desired comparison itself, to send to
>> a function for example, then the 8-way code allows you to represent
>> all six comparisons (000B and 111B are no-ops), instead of just three.
>
> Ha!  You nearly got me!  I'll be honest with you -- I'd commented on
> three points before I got that you were joking.  If I'd seen it before
> my coffee, you'd probably have had a straight answer to chuckle over.

It wasn't a joke ...

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#25648 — Re: <OT> Re: #define BYTES *8

"BartC" <bc@freeuk.com> writes:

> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
> news:0.01952024e6fe117e2fa0.20120831115310BST.87oblr8h9l.fsf@bsb.me.uk...
>> "BartC" <bc@freeuk.com> writes:
>>
>>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>>> news:0.42024609db3e0dd44276.20120831024906BST.873933al0t.fsf@bsb.me.uk...
>> <snip>
>>>> I, too, missed it on occasion, but then I got it back!  In Haskell, any
>>>> type that "inherits" from Ord (all ordered things, in effect) provides a
>>>> 'compare' function that returns EQ, LT or GT.  You then "switch" on the
>>>> result.  (Scare quotes because Haskell names everything differently.)
>>>>
>>>> Given that C's comparisons (struggling to get topical again) already
>>>> produce ints, it would not have seemed odd to have provided, say, <>
>>>
>>> <> sometimes means 'not-equal' in other syntaxes.

I know.  That's why I chose it.  In C, 'if (a <> b)' would work as
expected.

>>>> that yields -1, 0 or 1 in the expected way.
>>>
>>> Such a compare could equally usefully provide an 8-way result:

I count 5, not 8.

> 3 bits
>>> that represent (LT,EQ,GT), giving a value 000B to 111B. With the 3-way
>>> scheme, you can't then feed the result to a switch that wants to deal
>>> with LT and LE, for example, in separate branches.

If you have a switch case for LT, LE is the same as EQ, no?  Maybe I'm
missing your point.

>>> Not-equal is also badly defined in the 3-way result (either -1 or 1),
>>> but is 101B in the 8-way one.

No one can argue against a complaint of "badly defined".  Bad how?
Seems fine to me, but obviously not to you.

Why would you allocate a special value for not-equal?  How does the
operator decide what to return when a is > b -- the encoding for GT or
the encoding for NE?  You've added redundancy to the encoding and
prevented bit-testing.

BTW, if I were doing this I'd make EQ the bottom bit so that the 5 sane
values are compact.

>>> And if you needed to encode the desired comparison itself, to send to
>>> a function for example, then the 8-way code allows you to represent
>>> all six comparisons (000B and 111B are no-ops), instead of just
>>> three.

Obviously, in a HLL you just pass the comparison operator directly, but
in C, you could encode the operator from EQ/LT/GT by using 1<<c+1.  (The
precedence rules even avoid the need for brackets: 1<<EQ+1 | 1<<LT+1).
Given that this situation is rare, I don't think this is asking too
much.  (I'd still be tempted, even in C, to pass a function pointer.)

>> Ha!  You nearly got me!  I'll be honest with you -- I'd commented on
>> three points before I got that you were joking.  If I'd seen it before
>> my coffee, you'd probably have had a straight answer to chuckle over.
>
> It wasn't a joke ...

Oh, OK.  It was the testing of LE and LT separately that made me think
you were winding me up.  Sorry about that.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#25656 — Re: <OT> Re: #define BYTES *8

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
news:0.fefb42d7f899a9f7547f.20120831153514BST.87627z86zh.fsf@bsb.me.uk...
> "BartC" <bc@freeuk.com> writes:

>>
>> It wasn't a joke ...
>
> Oh, OK.  It was the testing of LE and LT separately that made me think
> you were winding me up.  Sorry about that.

I didn't think it was a joke because I seriously thought I'd actually
programmed such a thing somewhere or other. But I can't find a trace of it
now! So my apologies.

The nearest I found was a function that at one time returned 100, 010, or
001 binary, to represent lt, eq, gt, (which I later changed to -1,0,1). And
of course the six comparison codes (eq,ne,lt,le,ge,gt) but encoded as a
6-way linear code, and used as an *input*, not an *output* of any comparison
function.

(Having more than 3 comparison codes as a result of a comparison *is*
possible, but as a set, not a linear value: 3<4 might return (le,lt,ne) for
example. But that requires 6 bits, which could be 'switch'-ed on when
interpreted as a 0..63 code, but not what I had in mind...)

>>>> Not-equal is also badly defined in the 3-way result (either -1 or 1),
>>>> but is 101B in the 8-way one.

> No one can argue against a complaint of "badly defined".  Bad how?
> Seems fine to me, but obviously not to you.

Because you don't know what value will represent not-equal. A bit like
working out what True is in C.

>>>> And if you needed to encode the desired comparison itself, to send to
>>>> a function for example, then the 8-way code allows you to represent
>>>> all six comparisons (000B and 111B are no-ops), instead of just
>>>> three.
>
> Obviously, in a HLL you just pass the comparison operator directly, but
> in C, you could encode the operator from EQ/LT/GT by using 1<<c+1.  (The
> precedence rules even avoid the need for brackets: 1<<EQ+1 | 1<<LT+1).

OK, so you'd need to construct a special code (and in practice you would
pre-define the 6 compare codes needed).

The problem I was thinking of, was being given a 6-way relative compare code
(one of eq, lt, etc) and 3-way result of comparison (-1, 0 or 1), then 
determining if the result is true for the given compare code.

Obviously that can be sorted out given enough code. However, by using this
set of binary codes (similar to my original proposal, but now used as
input):

 EQ=010, NE=101, LT=100, LE=110, GE=011, GT=001.

and making the compare function in it's turn return 100, 010, and 001, then
a simple & operation will tell you if the result matches the desired compare
code.

> It was the testing of LE and LT separately that made me think
> you were winding me up.

That's not so crazy: X<=Y and X<Y could well have different results. But not
in the exclusive form needed to work in a 6-way switch statement.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#25661 — Re: <OT> Re: #define BYTES *8

On 8/31/2012 2:15 PM, BartC wrote:
>[...]
> (Having more than 3 comparison codes as a result of a comparison *is*
> possible, but as a set, not a linear value: [...]

     You need a fourth outcome to support NaN, or to support
other "incomparable" things (or "mutually incomparable" if the
language doesn't reconcile mixed types.  However, the FORTRAN II
I recall didn't have such issues.  I haven't touched any flavor
of FORTRAN/Fortran in decades, and have no idea what the three-
way IF would do with a NaN-valued expression.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web