Prev: Inputs left floating at the very start
Next: Microcontroller USB interface chip
From: Ulf Samuelsson on 6 May 2008 16:06
"Spehro Pefhany" <speffSNIP(a)interlogDOTyou.knowwhat> skrev i meddelandet
news:78ov14dfdf3f2emus5v27vhs9drmpi5hqm(a)4ax.com...
> On Mon, 5 May 2008 23:55:57 +0200, the renowned "Ulf Samuelsson"
> <ulf(a)a-t-m-e-l.com> wrote:
>
>>
>>"nospam" <nospam(a)please.invalid> skrev i meddelandet
>>news:t07n14h0inv7d48quvn4ffnu120mtdlusq(a)4ax.com...
>>> andrew.nesterov(a)softhome.net wrote:
>>>
>>>>Implement a block that inputs either 1 or 2 and outputs the opposite:
>>>>1 -> 2, 2 -> 1
>>>>The author continue with three hypotetical solutions:
>>>>1. A programming class instructor:
>>>> if ( x == 1) x = 2;
>>>> if ( x == 2) x = 1;
>>>>2. A programmer:
>>>> if ( x == 1) x = 2;
>>>> else if ( x == 2) x = 1;
>>>>3. A mathematitian:
>>>> x = 3 - x;
>>>
>>>
>>> So who writes this one?
>>>
>>> x = x["0\02\01"];
>>>
>>> --
>>
>>You mean:
>>
>>x = "\00\02\01"[x];
>
>
> 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)
>

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


From: Ulf Samuelsson on 5 May 2008 17:55

"nospam" <nospam(a)please.invalid> skrev i meddelandet
news:t07n14h0inv7d48quvn4ffnu120mtdlusq(a)4ax.com...
> andrew.nesterov(a)softhome.net wrote:
>
>>Implement a block that inputs either 1 or 2 and outputs the opposite:
>>1 -> 2, 2 -> 1
>>The author continue with three hypotetical solutions:
>>1. A programming class instructor:
>> if ( x == 1) x = 2;
>> if ( x == 2) x = 1;
>>2. A programmer:
>> if ( x == 1) x = 2;
>> else if ( x == 2) x = 1;
>>3. A mathematitian:
>> x = 3 - x;
>
>
> So who writes this one?
>
> x = x["0\02\01"];
>
> --

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



From: Andrey Tarasevich on 6 May 2008 17:32
Robert Adsett wrote:
> However, the fact that no one considered that the inputs could be out of
> range (and for that matter your reaction to the observation) is an
> interesting commentary on how we view this practice we call programming.
> We seem to default to the assumption that the input values to our
> current problem will be in the range we expect.

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
From: Tom on 5 May 2008 23:24
In article <481e224e$0$24420$5fc3050(a)news.tiscali.nl>, Dombo <dombo(a)disposable.invalid> wrote:
>> 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.
>
>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.

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.
From: David M. Palmer on 6 May 2008 00:15
In article <fvnvpj$k6d$1(a)aioe.org>, Ulf Samuelsson <ulf(a)a-t-m-e-l.com>
wrote:

> "nospam" <nospam(a)please.invalid> skrev i meddelandet
> news:t07n14h0inv7d48quvn4ffnu120mtdlusq(a)4ax.com...
> > andrew.nesterov(a)softhome.net wrote:
> >
> >>Implement a block that inputs either 1 or 2 and outputs the opposite:
> >>1 -> 2, 2 -> 1
> >>The author continue with three hypotetical solutions:
> >>1. A programming class instructor:
> >> if ( x == 1) x = 2;
> >> if ( x == 2) x = 1;
> >>2. A programmer:
> >> if ( x == 1) x = 2;
> >> else if ( x == 2) x = 1;
> >>3. A mathematitian:
> >> x = 3 - x;
> >
> >
> > So who writes this one?
> >
> > x = x["0\02\01"];
> >
> > --
>
> You mean:
>
> x = "\00\02\01"[x];

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

--
David M. Palmer dmpalmer(a)email.com (formerly @clark.net, @ematic.com)
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Inputs left floating at the very start
Next: Microcontroller USB interface chip