[UEB Maths] Missing emails

[Phippen, Stephen]

To: UEB Maths Committee
From: Stephen Phippen
Date: 9 June 2005
Subject: Missing emails

Joe said that he probably missed my recent emails talking about =
functions, etc. I think it is probably worth me resending them as they =
discuss the general idea of embedding functions within maths, not just =
for the sake of achieving compactness, as Joe refers to. So here they =
are again ...=20


To: UEB Maths Committee
From: Stephen Phippen
Date: 31 May 2005
Subject: Formatting and special functions.

As regards using format or some other means to imply grade one mode,
I agree with Joe that the method would not be watertight, e.g. for
braille to print translation. But I still regard it as practical,
and could well be used in transcription - independently of what is
specified in UEB. Indeed, regarded in this way, I would say that you
should not try to specify such things in UEB, because it is not
a coding matter as such, but a transcription technique.

In the same vein, I don't think we would necessarily expect
transcription agencies to use the formal UEB method of escaping from
UEB into another language code and back again for the entries in an
English-foreign language dictionary: surely a colon would do. I don't
regard this as contrary to UEB, but just being pragmatic. Of course
the formal mechanism is needed, but I wouldn't exclude these other
techniques.

On the other hand, I think the possibility raised by Joe of using
a single cell sign, dots 346, to indicate grade 1 passage mode is
intriguing, and this could sway me to thinking that, contrary to
what I have said above, I would want to use the indicator even for
set out maths. Would the presence of such an efficient indicator
affect what we have said in the draft about preference between using
the grade one symbol, word or passage modes? (I find the sign
specially attractive because it is similar to the sign aready used in
BAUK codes to introduce computer code, i.e. dot 6 dots 346, so would
be fairly familiar, and with an analogous meaning.) If we were to go
down this route I would prefer to retain the existing termination
sign (partly influenced by the following).

As for the question of special functions such as sin, cos, etc., I
am used to the perspective where these are treated as special objects
within maths; as they are typographically (i.e. being printed in
normal type as opposed to italic type for algebraic letters), in
typsetting languages like TEX, and of course in the BAUK braille
maths code. My instict is to be concerned about having the letters
of such functions loose amongst algebraic letters, especially with
rules as in the currect draft where spaces can be omitted (e.g. we
have example of tanx and argz with the algebraic letter unspaced,
and hence undistingushed, from the function). I don't think anything
is said in the draft about algebraic letters preceding a function,
but the issue is the same. In the BAUK maths code we have the fun
but realistic example w ord s (where w and s are algebraic letters,
and ord is a function) to highlight the issue.

In the BAUK code we use the dots 1246 sign to distingush such
functions (written in ordinary type) from algebraic letters. We
could do something similar in UEB using the free sign dots 16
(which Janet and Bruce have also suggested).
The rule could be something like:

"A function or other word fragment within a maths expression should
be preceded by the function indicator dots 16, which has force
over letters, stops, and the capital sign. The presence of any other
sign thus reverts to normal notation. The function termination sign
(say dot 3), may be used to terminate this mode in any case."

Thus [in the following I write dots 16 as a backslash (a la TEX!)]:

sin x would be coded \sin'x
sin(x) would be \sin(x)
w ord s would be w\ord's
log tan x would be \log\tan'x

etc., all in grade 1 mode.

Bruce and Janet more specificly were thinking about special forms
for common functions like sin and cos, etc. I think you could include
these within this scheme if we assume that you are not going to
get special functions with a single letter, i.e. in cases such as
f(x) the f is printed as an algebraic letter, not in a normal font
like sin or cos. So the above rule could be extended to include
a fixed set of common special functions:

"In addition to the general rule, \s represents sin, \c represents
cos, \l represents log, ..., (as opposed to single letter functions
s c and l, etc.)."

According to this you would still require a terminator as in the
general rule, so the examples would be changed to:

sin x would be coded \s'x
sin(x) would be \s(x)
w ord s would be w\ord's
log tan x would be \l\t'x

I agree with Joe that if we followed this route such coding would
formally have to be available in literary contexts, (i.e. you
could write "grade one indicator \s" for the word "sin") but I don't
this this would be very attractive and so could be discounted. After
all you could write "grade one indicator s i n" for "sin", but you
don't.

I'm sure Joe is (rightly) concerned with computability issues. I don't
see that braille to print would be a problem with such rules. Indeed,
to the contrary, it would enable better quality print to be produced
as you could then control the proper appearance of such functions
(e.g. if you were using a typesetting program like TEX, where sin needs
to be coded as \sin). I suppose the print to braille direction might
be a problem, but only where the functions are not properly identified
amongst the algebraic letters, which I would say they should be anyway.

To answer Janet's question: since this kind of method is already used
in the BAUK maths code it would certainly not be a problem for us.

* * *

To: UEB Maths Committee
From: Stephen Phippen
Date: 3 June 2005

Reading again what I said in my previous message about format and UEB
code switches, I should perhaps clarify by saying that I am not sure
about this matter myself. Part of my motivation for omitting the
grade 1 mode indicators for the set out equations in the sample on the
BAUK web site was to make it more attractive to UK readers.
I had in mind that such "conveniences" might be necessary to make UEB
acceptable to the UK public, and could be something which we might do
in the UK for the UK audience. But this is speculation, and need not
affect the specification of UEB itself (unless we want it to).

Another thought on computability: What are we actually expecting as
regards automatic translation? Are we expecting translation software
to be able to identify mathematical or computing expressions in a
source file, and treat them appropriately, or would we envisage
such expressions being marked up in some way prior to translation?
UEB is designed so that such expressions would be translated
unambiguously in either case, but can we expect them to be translated
ideally, e.g. as regards our transcription rules for grade 1 indicators
and the spacing of arithmetic operators and relations, without some kind
of markup?

Another case is "sin x". How would translation software know to
treat it as maths, and leave it uncontracted and to ignore the
italics on the x; or, according the suggestion we are thinking
about, use some sort of function indicator? I was wondering if
having function indicators would be problemmatic for
translation, but really it would be no more problemmatic than
without, if we are expecting maths to be translated as we expect.
(Or maybe the answer is that we shouldn't expect anything.)

Another case: a+b+c=3DROT. Again, the translator has to know not
to italicise the letters, even where they may look like a literary
word (unless the user ensures that italics are removed beforehand).

With more sophisticated source files, such as TEX, none of this is
an issue because the maths expressions are coded up properly.

Anyway, I think that's more than enough rambling for now!


--=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