[tutor] Do I need to have a strong math skills to program

[Magnus Lycka]

At 03:02 2002-11-09 +0100, I wrote:
>My studies and experience in electrical measurements and trouble
>shooting have taught me a lot that has been useful in helping my
>wife with her medical research, and in all sorts of software
>problem solving.

I just found another one of these parallels from other work
and studies:

I'm preparing a questionnaire to my neigbours regarding our
internet connection, since we will have to renew our contract
and should get quotations from various suppliers. I'm looking
through the previous questionnaire from 1998 in my preparations.
(Our 101 flats and houses have been  on-line since '96!)

The old questionnaire is mainly multiple choice, and it's
interesting to see how many times redundant questions are
asked, and how many times the available choices for answers
overlap or have holes. Things like:

Who in the household uses the computer? (mark one of:)
  * All
  * Only the man
  * Only the woman
  * The children

Apart from making a possibly flawed assumption that there
is never more than one adult of the same sex in a household,
it's also impossible to reply that "the man" and the children
(but not "the woman") use the computer, or that some but not
all children use it.

A "normal" person who makes a multiple choice question will
typically try to figure out what kind of responses there might
be to such a question, and list them. Someone who is good at
designing digital electronics won't. That's not the way she
thinks. I'm sure that many people who have worked with mathe-
matics will think in the same way as the electronics designer.
Particularly if they are used to set theory and logic.

We've been taught to always see the whole sets of input and
output, and to divide these sets into meaningful categories,
rather than to pick out answers and hope that they form the
whole set of possible (or reasonable) replies. Since "normal"
people start from the other end, they often fail to reach a
coherent whole. There might well be both overlaps and gaps
between their categories.

I don't mean that engineers or mathematicians are abnormal,
or that other people are stupid, but to see a whole and
divide it like this is maybe not a natural way of looking at
things. I think it's an acquired skill, and one that comes
as the result of a lot of hard work. I don't think you can
just read that you should think like this and apply it.

I think you need to work with something that forces you to
think like this until you do it by reflex. I'm sure that anyone
who is persistent can learn to think this way, but digital
design makes it both easy (due to the clear binary nature of
the things we work with) and rewarding (since things work it
we do it right, and don't otherwise) to acquire this way of
thinking.

In studies and practical work, we've learnt how to do this,
first in very simple ways, and then in more and more complex
systems. We've started with simple rules, and learnt to apply
more and more advanced methods. Obviously, Boolean logic and
Set theory are the foundations here. In practice we rarely
need to use more advanced things like the Quine-Mc Cluskey
method, but it's in our tool box if we need it. (See
http://www.thinkware.se/cgi-bin/thinki.cgi/QuineMcCluskeyPy )

This kind of thinking eliminates a lot of bugs in software.

It's important to map this technical view of reality to the
way the users of a system thinks though. Sometimes it's very
useful to try to create a shift in the mind set of the users,
to make them think in other paths, but most of the time we
will have to map things in such a way that things seem clear
both to system design experts and to laymen. (Or rather people
who are experts in another field, as the users of our products
typically are.)

On a related issue I was once asked to write a report for
a case management system for a social welfare authority
that would provide statistics on:
A: Number of open cases by the end of the month.
B: Number of cases closed during the month.
C: Number of short cases (both opened and closed during
    the month).

When you look at this you realize that it refers to to
questions:
  * Was the case started before the beginning of the month?
  * Was the case closed before the end of the month?

This is two bits of information, i.e. there are four possible
answers. Any case will fall into the categories:

If we say that 1 is yes, and 0 is no, we will get
these categories:

0) 00, no, no: New, and not yet closed case.
1) 01, no, yes: New and closed case.
2) 10, yes, no: Old and not yet closed case.
3) 11, yes, yes: Old and closed case.

The categories they wanted were:
A: Open cases = number of 0) + number of 2)
B: Closed cases = number of 1) + number of 3)
C: Short cases = number of 1)

As you see this is an incomplete representation
of the two bit information described above. We
can't represent to bits with three categories, so
by showing the information as just these categories
(which is what they needed for some reports they
wrote) we lost konowlegde about the reality behind
the numbers. This makes the report much less useful
for someone who wants to find some fact beyond that
intended by those who designed the report.

I suggested that that they should complement the
open cases number with the "of these, this many
were started this month":
A2: New, open cases = 0)

Something like:
Region Short Closed Open cases
        cases cases  (started this month)
AAAA       5      7       9 (4)
BBBB       2      9      11 (5)
...

This would mean that they have the full set of
information, since they still have four non-redundant
categories derived from the information. We can show
that nothing is lost:

0) = A2
1) = C
2) = A - A2
3) = B - C

Obviously, the representaion [A, A2, B, C] is a
lossless transformation of [0), 1), 2), 3)].

My client agreed to do it like that, but he never
really understood my wishes and my reasoning, and
when it was done, he asked me to remove the fourth
category, since he thought it would just confuse the
users... Maybe he was right, but this kind of gaps
in the presentation of information is very irritating
for someone who has been taught to think about the
whole...


-- 
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/  mailto:magnus@thinkware.se