Arlet wrote:
> 42Bastian Schick wrote:
> 
>>> Actually, it is
>>> s = sqrt(a);
>>> C programmer shall know basic standard library functions.
>> Sorry, failed. Question was: "...squart root of an integer"
>> Your solution imposes two castings and pulls in floating point
>> arithmetics.
> 
> But his solution does produce the square root of an integer, as
> requested. The solution is simple, and it works (although you could
> complain the result is truncated rather than properly rounded). It
> could also allow a smart compiler to recognize it can pull in an
> optimized version of integer square root.
> 

I'm not sure if a compiler is allowed to do that or not, but certainly 
no compiler would do it (a C++ compiler would be another matter).

> If you wanted it optimized, you should have provided more info. What is
> the word length, target CPU, required precision, and size/space
> constraints ? Do you want it in generic C, or ASM ?
> 

The thread subject is "interview embedded software questions" - when 
asked to find an integer square root, the interviewee should respond by 
asking what sort of constraints apply (and what ready-written functions 
and libraries are available).  If he has to answer without more 
information, a programmer who assumes floating point operations are okay 
for an integer task on a small micro fails on that question.

David Brown wrote:

> Arlet wrote:
> > 42Bastian Schick wrote:
> >
> >>> Actually, it is
> >>> s = sqrt(a);
> >>> C programmer shall know basic standard library functions.
> >> Sorry, failed. Question was: "...squart root of an integer"
> >> Your solution imposes two castings and pulls in floating point
> >> arithmetics.
> >
> > But his solution does produce the square root of an integer, as
> > requested. The solution is simple, and it works (although you could
> > complain the result is truncated rather than properly rounded). It
> > could also allow a smart compiler to recognize it can pull in an
> > optimized version of integer square root.
> >
>
> I'm not sure if a compiler is allowed to do that or not, but certainly
> no compiler would do it (a C++ compiler would be another matter).
>
> > If you wanted it optimized, you should have provided more info. What is
> > the word length, target CPU, required precision, and size/space
> > constraints ? Do you want it in generic C, or ASM ?
> >
>
> The thread subject is "interview embedded software questions" - when
> asked to find an integer square root, the interviewee should respond by
> asking what sort of constraints apply (and what ready-written functions
> and libraries are available).  If he has to answer without more
> information, a programmer who assumes floating point operations are okay
> for an integer task on a small micro fails on that question.

As always in embedded software: it depends.  If you automatically
assume embedded means a small micro, you're just making different
assumptions. Even though most embedded application use small 4/8 bit
CPUs, there are plenty of other embedded applications that use a full
power Pentium/AMD board. On such a CPU, the floating point square root
can be done by a single 'fsqrt' instruction, which beats the integer
version in size, and possibly speed.

Without any further information, there is something to be said for
providing the simplest answer to the question.

On 16 Nov 2006 07:45:18 -0800, "Arlet" <usenet+5...@ladybug.xs4all.nl>
wrote:

>Vladimir Vassilevsky wrote:
>
>If it doesn't need to be optimized, I prefer this version:
>
>    a = !a;

At least in C (AFAIK) the value of !a is not defined only it is 
unequal 0 (correct me if I am wrong).

Most compilers I have seen change an int from 0 to -1 and back.
But I've seen also one which does what was asked, changing 0->1->0.


-- 
42Bastian
Do not email to b...@yahoo.com, it's a spam-only account :-)
Use <same-name>@monlynx.de instead !

42Bastian Schick wrote:

>>> Next question: Compute the square root of an integer.
>>> Yuriy's answer: s = squareroot(a);
>> Actually, it is
>> s = sqrt(a);
>> C programmer shall know basic standard library functions.
> 
> Sorry, failed. 

I do not believe I would even consider going. Inability to ask an 
accurate questions is not a good sign.

> Question was: "...squart root of an integer"
> Your solution imposes two castings and pulls in floating point
> arithmetics.

My solution takes 15 seconds of expensive programmer time to write
and it works. If you expected employee to read minds, you should mention 
"psychic ability" in the job requirements. :)

As I quoted earlier, "Premature optimization is the root of all evil".
In 99% cases using standard library is the best choice.

The real questions to be answered are: "What need to be done?" and "How 
much time and money do we have?"
Calculating square roots is a minor technical problem with zillion 
different ways to do and it is not worth mentioning at all. :)

-- 
WBR, Yuriy.
"Resistance is futile"

42Bastian Schick wrote:

> On 16 Nov 2006 07:45:18 -0800, "Arlet" <usenet+5...@ladybug.xs4all.nl>
> wrote:
>
> >Vladimir Vassilevsky wrote:
> >
> >If it doesn't need to be optimized, I prefer this version:
> >
> >    a = !a;
>
> At least in C (AFAIK) the value of !a is not defined only it is
> unequal 0 (correct me if I am wrong).

According to the standard, section 6.5.3.3:

1101 The result of the logical negation operator ! is 0 if the value of
its operand compares unequal to 0, 1 if the value of its operand
compares equal to 0.

42Bastian Schick wrote:

>> Because three years later new programmer will spend two hours trying to 
>> figure out if *a* can or can not be equal to 2 or 3, and what is this 
>> silly line meant to do.
> 
> I expect a "new programmer" to understand the whole source he is
> responsible for and not only one line of code.

I feel pity for them. I saw quite a few projects that were easier to 
rewrite completely than maintain and modify. Original developer was able 
to write five lines of code "efficiently", but had no clue about project 
design in general.

> Most code (C,Assembler, Cobol ....) is hard to understand without
> the context.

Bad written code like is hard to understand. Good written code is easy.

>> More often than not it is more important than saving two bytes and 500 
>> nanoseconds.
> 
> It is about embedded where 500ns could mean "go" or "no go".

There is no point to spend time optimizing small pieces of code. Most 
efficient optimization is changing the whole algorithm, not improving 
bit-banging.

-- 
WBR, Yuriy.
"Resistance is futile"

42Bastian Schick wrote:
> "Arlet" <usenet+5...@ladybug.xs4all.nl> wrote:
>> Vladimir Vassilevsky wrote:
>>
>> If it doesn't need to be optimized, I prefer this version:
>>
>>    a = !a;
> 
> At least in C (AFAIK) the value of !a is not defined only it is
> unequal 0 (correct me if I am wrong).
> 
> Most compilers I have seen change an int from 0 to -1 and back.
> But I've seen also one which does what was asked, changing 0->1->0.

Then it is not a C compiler.  From N869:

  6.5.3.3  Unary arithmetic operators

... snip ...

  Semantics

... snip ...

  [#5] The result of the logical negation operator ! is  0  if
  the  value  of  its  operand compares unequal to 0, 1 if the
  value of its operand compares equal to 0.   The  result  has
  type int.  The expression !E is equivalent to (0==E).

-- 
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>;

On 16 Nov 2006 23:51:13 -0800, "Arlet" <usenet+5...@ladybug.xs4all.nl>
wrote:

>> >    a = !a;
>>
>> At least in C (AFAIK) the value of !a is not defined only it is
>> unequal 0 (correct me if I am wrong).
>
>According to the standard, section 6.5.3.3:
>
>1101 The result of the logical negation operator ! is 0 if the value of
>its operand compares unequal to 0, 1 if the value of its operand
>compares equal to 0.

Now I know it better ;-)
-- 
42Bastian
Do not email to b...@yahoo.com, it's a spam-only account :-)
Use <same-name>@monlynx.de instead !

On Fri, 17 Nov 2006 01:56:35 -0600, "Yuriy K." <y...@mail.ru> wrote:

>>> More often than not it is more important than saving two bytes and 500 
>>> nanoseconds.
>> 
>> It is about embedded where 500ns could mean "go" or "no go".
>
>There is no point to spend time optimizing small pieces of code. Most 
>efficient optimization is changing the whole algorithm, not improving 
>bit-banging.

Last comment (we are meanwhile far away from the OT):
What if bit-banging is the only part of the algorithm or the algorithm
is already optimized ?
-- 
42Bastian
Do not email to b...@yahoo.com, it's a spam-only account :-)
Use <same-name>@monlynx.de instead !

"Arlet" <usenet+5...@ladybug.xs4all.nl> a écrit dans le message news:
1...@f16g2000cwb.googlegroups.com...
>
> Lanarcam wrote:
>
> > The only reasonable instruction is:
> >  a = ++a & 0x01 ;
>
> No, that one is undefined, because it has two side effects to 'a' and
> only one sequence point.
>
In this case the preincrement operator ++a is used and not the
postincrement operator a++. What is the error in this line
of reasoning: a is incremented first, then the new value of a is
used to evaluate the right hand expression , then the result
is assigned to a?