Had an interview

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

Not when working on my team, it isn't:-)

tim

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'.

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 | snipped-for-privacy@pcserviceselectronics.co.uk PC Services Timing Diagram Font GNU H8 - compiler & Renesas H8/H8S/H8 Tiny For those web sites you hate

tims next home schrieb:

How about x = 4>>x

:-)

Nils

"Spehro Pefhany" skrev i meddelandet news: snipped-for-privacy@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)

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.

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?

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

... snip ...

Wrong. My suggestions ensured correct output for any input.

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

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

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

That is an external input in my book. Maybe not external to the system but certainly to the software. As such it comes within the requirements for idiot-proofing. My original post was primarily concerned with not constantly checking _internally_ generated values, at least not in an program not in debug trim.

As for what action to take in the eventuality you decribe it isn't perfectly clear cut. If it is perfectly clear (to the code) that it is in fact a sensor failiure then disabling that ring is indeed a sensible option. However, this depends on the sensor failing in a consistent and predetermined fashion, that manner being known by the SW people, and the system actually havign the capability to robustly diagnose the failiure from within.

If the cooker is in an 'unknown' state then 1) is the best option. You can live without a cooker after all. Sure it may be inconvenient but you will get by. The situation is no different to that experienced in a power cut after all.

For a start it has to be clear (to the code) that it is in fact a sensor failiure for disabling that hob to be the obvious option. If the cooker is in an 'unknown' state 1) would be the best bet.

Does anyone remember when you used to turn on your TV and it just came on? Well, the audio came on straight away and it took a few seconds for the screen to warm up. Changing channels was always instantaneous. Now it takes maybe ten seconds for the picture to appear, another couple of seconds for the audio to commence and what seems like three weeks for the onscreen display to disappear so you can see what you are watching.

Only for the OSD to reappear (taking up literally half the screen) advising you of a slightly dodgy signal that you would have been completely oblivious to in terms of picture quality unless you had been advised of it. Then you have the curse of set top boxes - I have one in particular that ties itself up in knots that can only be resolved by power cycling at least once a week.

Many devices have an automatic reset button, better known as 'watchdog timer'.

I'm coming into this discussion late but I'm amazed nobody suggested x ^= 3. If you want to ensure some meaningful output with out of range input then x = (x ^3) & 3 or x = (x & 3) ^ 3. Of course, none of these solutions works if x is 0 or 3 intially.

Who you callin' a nobody, and why are you amazed? Best regards, Spehro Pefhany