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

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

Re: Application Exercises

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Application Exercises Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-06 23:46 +0100
    Re: Application Exercises Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-04-07 00:08 -0700
      Re: Application Exercises Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-08 01:24 +0100

#142874 — Re: Application Exercises

ram@zedat.fu-berlin.de (Stefan Ram) writes:

>   Disclaimer: I might have posted about the same programming
>   problem some years ago. But then it was my own invention,
>   while now I read about it in a book.
>
>   In a book about the job application as a programmer, I found
>   a paragraph, were they say that application exercises often
>   enforce arbitrary restrictions, which do not make sense
>   according to the author of this book, but the exercises have
>   to be done nevertheless. As an example he gave:
>
> |Write a function to detect whether two integral numbers are
> |equal without using any comparison operators.
>
>   . As a hint he wrote: "Think of bit operators.".

I think that's a bad hint.  It points towards thinking about
representations and not values, which looks to me to be the rockier
road.

I'm thinking along these lines:

 #define CMP(a, b) !((unsigned)(a) - (unsigned)(b))

 CMP(a/2, b/2) && CMP(a - a/2, b - b/2)

The reason you can't just do

  !((unsigned)a - (unsigned)b)

is that unsigned need only have the same range as the non-negative range
of int.  You can do a little better with

  !((uintmax_t)a - (uintmax_t)b)

but there would still be odd implementations where that could fail.

-- 
Ben.

[toc] | [next] | [standalone]

#142882

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>
>>   Disclaimer:  I might have posted about the same programming
>>   problem some years ago.  But then it was my own invention,
>>   while now I read about it in a book.
>>
>>   In a book about the job application as a programmer, I found
>>   a paragraph, were they say that application exercises often
>>   enforce arbitrary restrictions, which do not make sense
>>   according to the author of this book, but the exercises have
>>   to be done nevertheless.  As an example he gave:
>>
>> |Write a function to detect whether two integral numbers are
>> |equal without using any comparison operators.
>>
>>   . As a hint he wrote:  "Think of bit operators.".
>
> I think that's a bad hint.  It points towards thinking about
> representations and not values, which looks to me to be the rockier
> road.
>
> I'm thinking along these lines:
>
>  #define CMP(a, b) !((unsigned)(a) - (unsigned)(b))
>
>  CMP(a/2, b/2) && CMP(a - a/2, b - b/2)

An interesting (and nice!) idea.  How about

    CMP(a/5, b/5) && CMP(a%5, b%5)

instead?  (The choice of 5 is arbitrary, except that I
wanted to be well away from the boundary of the bad
ranges.)  Using the / and % I find it easier to convince
myself it's correct.

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

#142893

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>
>>>   Disclaimer:  I might have posted about the same programming
>>>   problem some years ago.  But then it was my own invention,
>>>   while now I read about it in a book.
>>>
>>>   In a book about the job application as a programmer, I found
>>>   a paragraph, were they say that application exercises often
>>>   enforce arbitrary restrictions, which do not make sense
>>>   according to the author of this book, but the exercises have
>>>   to be done nevertheless.  As an example he gave:
>>>
>>> |Write a function to detect whether two integral numbers are
>>> |equal without using any comparison operators.
>>>
>>>   . As a hint he wrote:  "Think of bit operators.".
>>
>> I think that's a bad hint.  It points towards thinking about
>> representations and not values, which looks to me to be the rockier
>> road.
>>
>> I'm thinking along these lines:
>>
>>  #define CMP(a, b) !((unsigned)(a) - (unsigned)(b))
>>
>>  CMP(a/2, b/2) && CMP(a - a/2, b - b/2)
>
> An interesting (and nice!) idea.  How about
>
>     CMP(a/5, b/5) && CMP(a%5, b%5)
>
> instead?  (The choice of 5 is arbitrary, except that I
> wanted to be well away from the boundary of the bad
> ranges.)  Using the / and % I find it easier to convince
> myself it's correct.

Yes, I like that.

-- 
Ben.

[toc] | [prev] | [standalone]

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

csiph-web