[UEB Maths] A Math Mode for UEB?

Phippen, Stephen uebmaths@nbp.org
Fri, 10 Jun 2005 17:26:51 +0100


To: UEB Maths Committee
From: Stephen Phippen
Date: Friday 10 June 2005

An interesting message from Joe. A couple of quick comments: With the =
proposal for having a function indicator, I would say that there is no =
need to ask the transcriber to interpret variant forms of a function; =
i.e. according to UEB philosophy I would expect \s to be defined as =
exactly the letters "sin", etc.

Also, as long as mathematical expressions as a whole could be =
recognized, the identification of such functions within them would =
normally be easy, as they are printed in normal type as opposed to =
italic type for algebraic letters. The idea of the function indicator is =
only to give you a distinction in braille which the sighted reader =
already has in print.

But in cases where the print did not make the distinction between =
functions (normal type) and algebraic letters (italic type), then we =
could say that there are two options:

(a) a knowledgeable transcriber could still treat those functions as if =
they were distinct;

(b) otherwise a transcriber could just braille them at face value, =
letter for letter, without the function indicator.

(A transcriber might even use contractions (apart from in grade mode) - =
should we worry about this? I quite like the idea of allowing it, in the =
spirit of UEB.)

As regards Joe's "balloon", my initial reaction is that we perhaps =
shouldn't move towards developing a special maths mode at this stage, as =
it would muddy the concept of UEB which is being projected to the =
public. Compressed notation for special areas could be developed =
(chemistry is a specially good example), but I think we should now try =
to do our best within normal UEB, and then gain some experience about =
using it in real situations, before contemplating special modes. I think =
our working assumption should be that there won't be special modes.

On the other hand, initial reactions are not always reliable. I might =
have changed my mind by Monday!





-----Original Message-----
From: uebmaths-admin@nbp.org [mailto:uebmaths-admin@nbp.org]On Behalf Of =
Joe Sullivan
Sent: 09 June 2005 21:45
To: uebmaths@nbp.org
Subject: [UEB Maths] A Math Mode for UEB?


Hello all,

Thanks to Janet and Stephen for forwarding the message that I had missed =
-- not, as it turned out, because of our server woes but because of a =
procedural mistake on my part. Thanks also to Warren for the pointer to =
my old words, which is a reminder that this is far from a new subject. =
In fact, the first time that I recall expressing the opinion that UEB =
would not eliminate the need for specialty codes was in a speech I gave =
in 1995, in Winnipeg, Manitoba. Darleen, who was there, didn't shoot me, =
so I took that as a sign that such views were not inconsistent with UEB =
philosophy.

I agree with Stephen's idea that pragmatic considerations could override =
strict adherence to rules in some cases. We had said, for example, that =
there would be no need for language indicators when you had two columns =
of corresponding words in different languages; surely the dictionary =
example would be like that even though columns are not involved. I also =
agree that this kind of thing is best left to producer convention and =
not "the rules."

Turning to the "math function series" question, the more that I think =
about adding such a series to the definition of UEB grade 1 -- which =
would have the effect of making its use mandatory wherever math =
functions might appear --, the more I worry that it would create a =
difficult complication for readers, transcribers and teachers who are =
not intensively involved with higher math. For example, "gcd" and "lcm," =
with or without periods, can come up in fairly early grades, when it =
would seem unnecessary to require something as ordinary in appearance as =
"lcm(2,3)" to be treated so specially. There would also be the matter of =
requiring all transcribers to be aware of what is math and what is not, =
and (presumably, if we are keyed to mathematical meaning) to transcribe =
alike some things that can be written rather differently in print -- for =
example "csc" and "cosec" or "arc sin x" and "sin^-1 x" (where here the =
^ indicates that the -1 is in superscript position).  Those are the =
kinds of things that strike me as OK in a specialty code, but =
questionable in a general code that is based on the philosophy of =
representing the symbol sequence without deeply involving the meaning of =
those symbols.

Mulling those thoughts, I wonder if we don't want to consider a "math =
mode" after all, perhaps incorporating some of the following:

1. Math mode would be optional, and typically used only within entire =
works judged to be substantially mathematical, and for students or =
professionals at higher levels of math (according to some general =
guideline, not necessarily airtight). It would not be used for lower =
grades, nor for works in which math appears just here and there.

2. A mode entry indicator would be needed, which is easily accomplished.

3. Math mode would be essentially like UEB grade 1 (i.e. no use of the =
literary contractions), but in effect it would have contractions of its =
own, including a "math function series" along the lines we have been =
discussing.

4. In math mode, the dot 5 would be eliminated from the plus sign. Any =
instance of an exclamation mark, including its use for the factorial, =
would require a preceding grade 1 symbol indicator. (Factorials, which =
certainly occur in math, are surely much less common than plus signs.)

5. Likewise all minus signs would be just dots 36, and any hyphens would =
need a preceding dots 56.

6. Our one-cell quotation marks could be used instead of the two-cell =
ordinary (round) parentheses. The two-cell forms of the quotation marks =
would be required if any should occur. (I don't recall ever seeing a =
quotation mark within a math expression, but we might as well be =
covered.) Any question marks would need a preceding dots 56.

7. Such a mode could be combined with our already-established "numeric =
passage" mode whenever it was felt desirable to optimize the treatment =
of numbers vs. letters a-j. I don't think such cases would occur very =
commonly.

I won't go on -- this isn't intended to be a fully worked-out proposal, =
but a trial balloon to see what people think of such an idea. I realize =
that this kind of approach would still not satisfy the needs of people =
working in certain sub-specialties within math and science. A truly =
efficient code for intensive work in chemistry, for instance, would =
probably be very different from UEB, from the ground up. Likewise we're =
not going to beat the current BANA or BAUK computer codes for the work =
of programmers creating hundreds of lines of code daily. However, a =
"general math mode" could, I think, be quite useful from the point where =
students who are going to specialize in technical subjects take a =
decided turn in that direction -- about the second year of secondary =
school, I would guess -- up to the point where immersion in some deep =
specialty becomes a possibility (or the student drops out and becomes a =
Romanian folk dancer). And such a math mode would not, I think, require =
a very large leap of learning when the student reached the point where =
it would be useful.

Cheers,
Joe

--=20
DISCLAIMER:

NOTICE: The information contained in this email and any attachments is=20
confidential and may be privileged.  If you are not the intended=20
recipient you should not use, disclose, distribute or copy any of the=20
content of it or of any attachment; you are requested to notify the=20
sender immediately of your receipt of the email and then to delete it=20
and any attachments from your system.

RNIB endeavours to ensure that emails and any attachments generated by
its staff are free from viruses or other contaminants.  However, it=20
cannot accept any responsibility for any  such which are transmitted.
We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email and=20
any attachments are those of the author and do not necessarily represent
those of RNIB.

RNIB Registered Charity Number: 226227

Website: http://www.rnib.org.uk