On 2008-05-04, Dombo <dombo@disposable.invalid> wrote:
Agreed. I encouraged the use of assert() on this very group only
a couple of days ago. It has a few things that your typical range
checking code doesn't. Firstly of course it compiles to nothing
with a flick of a compile time switch. Also when an assert fails
the action is to crash and burn. That is good because the function
interfaces do not need to allow for the possibility of an error
occurring.

This is one of the main problems when testing prerequisites in a
language such as C that lacks exceptions - there often isn't any
natural method of indicating the error to the caller, which forces
yet more logic there to test for the error condition that was picked
up by the callee. That is one reason why it is usually better
simply to test the prerequisites in the caller in the first instance.

That is an argument for better specification and documentation,
not for redundant code in the final product. If there is ambiguity
in what input is valid for an particular function then that says
more about design processes and project management than it does
about the quality of the code in question.

--
Andrew Smallshaw
andrews@sdf.lonestar.org

Andrew Smallshaw schreef:
It depends on your error strategy. Which error strategy is most
appropriate depends on the application. For some applications the log,
crash and burn strategy is preferable over muddling along in an
inconsistent state with unknown consequences. In other applications it
may be better to just continue and hope the customer will never notice.

Ideally one would be able to prove that there are no errors in the code
instead of adding runtime checks (being it at the side of the caller or
the callee). Source code analysis tooling like Coverity, Grammatech and
Polyspace should render those runtime checks unnecessary. I have no
first hand experience with any of these tools, but I'm interested in
hearing from anyone who has.

Even with perfect specifications and documentation in place you still
have to deal with people who may have misread, forgot or just interpret
things differently. Training people to make their assumptions explicit
(e.g. by using assert()) makes it easier to detect deviations from the
design specification, identify gaps and ambiguities in the design
specification and it triggers people to check the design specification.

Of course this wouldn't be necessary if all specifications were perfect
(they rarely are, even official specifications, like those from ISO,
often have ambiguities), and if all people would perfectly adhere to the
specifications. Unfortunately I live in an imperfect world; neither the
specifications nor the people (including myself) are flawless. The best
way to deal with that is to assume errors will be made at any stage of
the process and try to catch (and correct) them as early as possible.
Finding the right balance however is the real challenge.

In article <481DF1B6.56D5FBDD@yahoo.com>, CBFalconer says...
I had to check back to make sure I had, my apologies for forgetting it.
Your solution does at least limit the range of outputs. It does leave
open the question of whether values other than 1 or 2 are acceptable
inputs.

At least someone is considering other inputs may occur.

Robert
** Posted from http://www.teranews.com **

Robert Adsett wrote:
No, look again. It accepts all inputs, but only outputs the values
1 and 2. It was:

if (1 == x) x = 2;
else x = 1;

or similar.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.


** Posted from http://www.teranews.com **

"nospam" <nospam@please.invalid> skrev i meddelandet
news:t07n14h0inv7d48quvn4ffnu120mtdlusq@4ax.com...
You mean:

x = "\00\02\01"[x];

--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB

In article <481e224e$0$24420$5fc3050@news.tiscali.nl>, Dombo <dombo@disposable.invalid> wrote:
Another error strategy is to continue on, using the best possible failsafe
state, and resume normal operation as soon as the fault is corrected.

Consider the microcontroller in an electric stove: when the temperature sensor
on the rear left burner fails, what is the best strategy:
1. Log the error in some internal EEPROM and shut down the entire stove.
2. Try to use the temperature sensor reading anyway even though it is clearly
out of range.
3. Cycle the heating element at a 50% duty cycle hoping that the user will
never notice.
4. Let the other three burners and oven operate normally, and force the rear
left burner to 0% until its temperature sensor is fixed.

For those of us who still want to eat, choice #1 is not an option, and for
those of us who don't particularly enjoy the taste of burnt mashed potatoes,
choices #2 and #3 are out as well.

My experience has been that there are way too many programmers who believe
that #1 is OK, and #2 is...um...well... not their fault because it's a
hardware problem.

It's bad enough that network routers and cellphones have reset buttons, I just
hope I never see the day when cars have reset buttons.

--Tom.

In article <fvnvpj$k6d$1@aioe.org>, Ulf Samuelsson <ulf@a-t-m-e-l.com>
wrote:

You are insufficiently depraved.
x = x["0\02\01"];
works, and is perfectly valid C.

--
David M. Palmer dmpalmer@email.com (formerly @clark.net, @ematic.com)

On Mon, 5 May 2008 23:55:57 +0200, the renowned "Ulf Samuelsson"
<ulf@a-t-m-e-l.com> wrote:


This one is perhaps mathematically attractive, but maybe less so for
programming:

x = (3 - cos(pi*x))/2;

- gives results of 1 or 2 for all integer inputs
- is continuous
- is differentiable
- is infinitely differentiable (smooth)





Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

"David M. Palmer" <dmpalmer@email.com> wrote in message
news:050520082215555636%dmpalmer@email.com...
Not when working on my team, it isn't:-)

tim

In comp.arch.embedded,
Tom <tom@nospam.com> wrote:
I think that hope is shared by car dealers. ;-)
Just think of the income they will loose when an owner can just press a
button to clear a erroneous warning light instead of going to the shop
and have them reset the light with a fancy 'analyzer'.

--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

"CBFalconer" <cbfalconer@yahoo.com> wrote in message
news:481B7BAC.7122C23F@yahoo.com...
As others have said as long as the input is guaranteed to be in the right
domain
and getting a wrong value (e.g. x==3 on entry returning 3), would not cause
downstream errors.

Be sure that the DEFAULT state as shown here being x = 1, is the correct
default
state and does not cause

Launch nuclear attack
Turn on microwave with door open
Keep cruise control on or accelerate
Turn brakes OFF
Turn off power grid
Advance volume on audio device up (again and again)
.....

Self healing in this way is VERY system and application dependent, and makes
documentation and maintenance across modules etc.. more difficult and prone
to the "change one line and everything goes to shit" form of code
maintenance.

--
Paul Carpenter | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

tims next home schrieb:

How about x = 4>>x

:-)

Nils

"Spehro Pefhany" <speffSNIP@interlogDOTyou.knowwhat> skrev i meddelandet
news:78ov14dfdf3f2emus5v27vhs9drmpi5hqm@4ax.com...
x = 2/x;

will do as well. If the division routine rounds down, then
it will give 0 out for all illegal values except 0 which will trap.
(assuming an unsigned int)

--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB

Robert Adsett wrote:
Absolutely not. The correct view of the situation is that the notion of
"verifying the input" is not generally applicable to and abstract
interview-level problem, aside from the questions specifically crafted
for the purpose of testing the subject's ability to perform the
verification.

There are different approaches to verifying the input and each one is
applicable in its own set of situations. One can use a permanent
run-time check, a debug-only assertion, something else or not check
input at all. The key moment here is that the major part of the art of
programming is to develop solutions that solve specific, concrete
problems by applying generic, abstract algorithms.

For example, given a interview problem of sorting an array of integers,
filled with only even values, one might decide to use some known generic
sorting algorithm (say, quicksort). But should one check the input first
and make sure that there are no odd numbers in the array? When the
solution does not rely on that, the answer is - no! The value of generic
sort solution in this case is that it not only solves the original
problem, but also applies to the whole variety of inputs (i.e. any input).

The same logic applies in this case. A solution that depends on the
input to be in range is a B-grade solution. A solution that does not
depends on the input to be in range, but still verifies it is a C-grade
solution. An A-grade solution would behave correctly on the specified
input, but also do something similar (and theoretically "useful") on the
other inputs (meaning that there no need to verify the input). This is
actually the main reason why the 'x = 3 - x' is the best solution of all
presented. It is readable and at the same time it is based on the
cleverly noticed elegant mathematical generalization. Adding an input
check would make it as ugly as the 'if'-based solution. No, the input
check is the responsibility of the caller in this case.

--
Best regards,
Andrey Tarasevich

Nils wrote:
After seeing the weird solutions I have decided that I AM
insufficiently depraved. These ridiculous solutions just never
occur to me. Am I missing something in the humour line?

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.


** Posted from http://www.teranews.com **

In article <fvqipm$c9k$1@aioe.org>, Andrey Tarasevich says...
Well, we really had moved away from interview questions. Even then
though it would be instructive to see which candidates noted the range
limitations of their approach. I was more struck not that some disn't
note the limitation but so few did and no-one actually checked the input
for validity or added a comment that the output was only valid over a
certain input range.


While it is 'cute' and a clever trick, I wouldn't call it either the
best solution or an elegant mathematical generalization or even
particulary readable(1). If it showed up in a code review I'd send it
back to be re-written in a more obvious form unless there was a really
compelling reason to use it. Even then I would expect copious comments
as to why such an obscure form was being used.

And a note to that effect eouldn't be appropriate? It's that there
appeared to be little appreciation for the restrictions of the
approaches I was finding interesting. And I'm not sure I would have
noted them myself if I suggested an approach which I also find
interesting.

Robert

1 - it did make a decent punch line,
** Posted from http://www.teranews.com **

Robert Adsett wrote:
Wrong. My suggestions ensured correct output for any input.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.


** Posted from http://www.teranews.com **

In article <4820FBF6.1D03B3C7@yahoo.com>, CBFalconer says...
It ensures a particular output. Whether it is correct or not is another
question. My reading of the problem would preclude a correct output for
any input other than 1 or 2.

Robert
** Posted from http://www.teranews.com **

CBFalconer schrieb:
I use computed shifts on magic numbers in time-critical code to compress
small lookup-tables into a single integer and index via shifts. That
little trick works well if the talbe only has few indices and each
element contains few bits. If all information fits into a machine-word
you get a very cheap LUT.

It saved my a** more than once.

But I'm doing low-level graphic rendering functions and most of the
stuff I write is in assembler. Saving a memory-access on the TI C64x+
DSP may give a factor2 performance win.

I wouldn't like to see such code in a non-critical path as well.

Nils

CBFalconer wrote:

ISA's have changed over the years. I was amazed at
algorithmic opportunities that came with the first
barrel shifter where shift by 1 and shift by x took the
same execution time.

Partially microcoded instruction sets that allow different
operations on different execution cycles in a pipelined
processor may be a nightmare to code but it only has
to be right once.

Regards

--
Walter Banks
Byte Craft Limited
Tel. (519) 888-6911
http://www.bytecraft.com
walter@bytecraft.com