Alain AND Everybody:
Some minds just can't deal with logic, much less logical operators.
Once upon a time, I had the job of trying to make a colonel in the U.S. Army
sound literate. (I was drafted.) I soon found out that progress would be made
only one tiny step at a time, if at all.
My first step was to get the "slashes" out. He loved the slipperiness of
"and/or" and used it all the time, but pronounced it "and-slash-or." I finally
persuaded him that that was not the "college" way to do it, and he got pretty
good at just saying "and-or."
But then I over-reached. I tried to explain to him that "x and/or y" really was
the same as "x or y or both," and that this was the much more natural way is
speaking. "Is that the college way?" "Yessir." So we went through a big
speech replacing all the and/or's. He was so proud of himself when he delivered
it: but all the way through he was saying "x and-slash-or y and-slash-or both."
Sorry to be not exactly on-topic, but I had to unburden myself. Now I feel much
Philip Blair (ex-P.F.C.)
"Alain" <firstname.lastname@example.org> on 06/09/2000 11:02:19 AM
To: "Unicode List" <Unicode@Unicode.Org>
cc: Tc304@Dkuug.Dk, Unicode@Unicode.Org, Cac-Jtc1-Sc22@Scc.Ca, Sc22@Dkuug.Dk
Subject: Re: (TC304.2308) translating logical operators
À 09:58 2000-06-09 -0400, François Pinard a écrit:
Tom Garland <Tom.Garland@ireland.sun.com> writes:
> TC304. Does anyone know if the following logical operators are globally
> understood or must they be translated for each language?
> ~ (not)
There was a discussion on the Python list, last week, on the fact that
these operators do not have a clear intuitive meaning, even in English.
Yet for old-fashioned programmers, this is generally clear. It was said
that some programming language (I forgot which) allows `and then' and
`or else' as an attempt to make things more clear.
[Alain] Right. Of course, when we talk about antedeluvian programming
languages, translation is not absolutely required. Habits are already taken and
in practice it is not worth it (in addition to the fact that some programmers
prefer that their comments, in their native language, be not confused with the
cryptic -- and mechanically interpreted -- actually programmed instructions per
However for any new *application*, boolean operators and mathematical
functions in general exist in different languages already (mathematics were not
invented yesterday). Therefore, if a product is aimed at end-users who already
have a culture (who has none?) versions in different languages should typically
be required (maybe not in some cases, you have to survey those languages
As François says, for example, the meaning of "OR" ("OU" en français) is also
ambiguous due to bad practices encouraged by many users (in both English and
French, "OR" ("OU") is by definition an inclusive OR but many consider it rather
means "EITHER x OR y" ("SOIT x, SOIT y"), which is exclusive, to the point that
they use the bad formula "and/or" ("et/ou") to make sure that "OR" will be even
more ambiguous in the future -- I think damage is already done to both of these
Even "AND" ("ET" en français) may lead to misunderstanding, as the natural
language use of these operators may *not correspond* to the boolean meaning.
Many years ago, in a "natural-language"-to-data-base interface, just to play
(I know, it was vicious), I asked the following natural language sentence to the
program called "Intellect" (at the time, it was on an IBM mainframe): "How many
men and women are listed in the database?"... After many minutes going trough a
relatively big database, I got the single answer: 0 (i.e. ZERO)... (%=
The program had provided me with the translation into a data-base programming
language and it had done something like: "IF SEX=MALE AND SEX=FEMALE THEN..." Of
course an optimizer could have known the answer in advance, it was not very
clever programming... However how many users would believe what a machine would
answer in those occasions? Unfortunately most non-programmers, to whatever
That is the problem I see. A big one. So yes, operators should be translated,
explained, and even presented to end-users with a tutorial explaining the usual
traps. This, even for English-speaking end-users. It is a matter of good
user-machine interface. The user must be aware in advance of the kind of
commitment he/she has contracted with the machine. So far we assume too much on
both sides (programmers and end-users), only the machine is strightforward...
"Garbage in, garbage out" is still quite of age.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:21:03 EDT