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

Groups > comp.lang.c > #25656

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

Show all headers | View raw

"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 

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

#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

csiph-web