🚀 go-pugleaf

In article <BvpCAJ.Dy1@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>In article <1992Oct5.105741.26289@bnr.co.uk> pgh@bnr.co.uk (Peter Hamer) writes:
>>In the referenced article izahi@bsc.no (Raul Izahi Lopez Hernandez) writes:
>>>In article <1992Sep29.232852.22456@CS.ORST.EDU> crowl@jade.CS.ORST.EDU (Lawrence Crowl) writes:
>
>
>
>>2) Many formulae depend on type-setting facilities [ie graphical layout] 
>>   to indicate their meaning; eg a/b+c.
>
>This is an essential problem in converting from 2 dimensions to one.  I
>would suggest that a more versatile type of bracketing than now used in
>languages be developed, but nothing will really do the job well until
>we can use two dimensions.  

I recommend you read "The Design of APL\360", which goes way back in time.
The issue of converting mathmatical formulae to a linear form is
discussed in a fair bit of detail there, if I recall correctly (Can't
find my copy).


>>   *Many* times I have had to re-derive a published formula to understand
>>   how it should be parsed.
>
>This is even a problem for mathematicians.  Again, something sensible 
>should be done, and the sensible thing will not be found by ignoring the
>mathematicians.

Look at APL and J. They are generalizations of mathematical notation
which have the advantage of being executable notations. Hence, they HAVE
a known parse, AND you can TEST your hypotheses to some degree other
than handwaving their claimed truth. Use of an executable notation
in this group, for example, might reduce some of the:
    Can do it.
    Nope, it's impossible.
threads we see from time to time. For example, if we could get Herman
to model his problem in J, (or C), we'd know what he's talking about,
and whether it makes sense, or is pure hooey.


>But are these problems any worse than those involved in trying to read
>expressions in which there are 20-letter names, sometimes with the difference
>being that one letter is capitalized, or that one letter is changed?  The CS
>people have produced something unambiguous for the machine, but hard for the
>human to understand.


Don't blame the CS people for this. It's an infectious disease they
caught from the mathematicians. Or, perhaps you've never seen a 
prof who uses "m" and "M" on the same blackboard panel, making them both
look alike...   Or i, I and 1...


>>4) The notation used in any particular book is often, at least in part,
>>   unique to that book. This is probably also true of the type-setting rules.
>
>This is partly unavoidable.  It happens also in setting up the conventions
>by #defines, #include files, etc., in the HLLs.  It is not something which
>separates mathematics from computer languages.

Yeah, but it is MOSTLY avoidable, if people could be convinced to leave
their egos at the door.

>>PS Experiences mainly from from statistics books, and the fundamental
>>problems seem to be implicit multiplication and subliminal bracketing. 

Yup.

>Are these mathematical statistics books, or the more common applied 
>statistics books intended for those who cannot understand mathematics
>and mathematical notation anyhow?  1/2 :-)
                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is a Cheap shot: I have actually known a few statisticians who
knew something
about mathematics. 


Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada