[Rd] [R] scalable < > delimiters in plotmath

[David Winsemius]

On Sep 12, 2010, at 11:38 PM, Paul Murrell wrote:

> Hi
>
> [shifting to r-devel]
>
> On 13/09/2010 8:43 a.m., David Winsemius wrote:
>>
>> On Sep 12, 2010, at 4:11 PM, Paul Murrell wrote:
>>
>>> Hi
>>>
>>> On 13/09/2010 7:57 a.m., baptiste auguie wrote:
>>>> Oh, right I see. I was completely off then. Maybe it's not so  
>>>> easy to
>>>> add<>   delimiters after all, I'll have to look at the list of  
>>>> symbol
>>>> pieces to see if these can be constructed too.
>>>
>>> The plotmath stuff assumes a font with an Adobe Symbol encoding.
>>> The characters we have to play with are shown at http://www.stat.auckland.ac.nz/~paul/R/CM/AdobeSym.pdf
>>> .
>>> You can see the components of "growable" delimiters on the bottom
>>> two rows.
>>
>> Hello Paul;
>>
>> Both Baptiste and I have looked at the plotmath.c code and it appears
>> that only a few of those delimiters are supported. We specifically
>> have tried to use the angle brackets:
>>
>>  >  plot(1,1,
>> xlab=expression(bgroup(symbol(0xe1),atop(x,y),symbol(0xf1))))
>> Error in bgroup(symbol(225), atop(x, y), symbol(241)) :
>>    invalid group delimiter
>>
>> The supported delimiters appear to each be built up from three parts
>> that are then assembled within a bounding box and as far as I can
>> determine are limited to "|", "||", "[", "{", "(", ")", "}",and  
>> "}". I
>> needed to download the full source to find a copy, but I'm fairly  
>> sure
>> a guRu of your standing needs no help finding the code that handles
>> the bgroup display inside plotmath.c. I am not at my machine where I
>> was looking at it, but the code that I just found in expanded form on
>> the Internet bore your name as a copyright holder.
>>
>> So I guess my feature request would be:
>> ---add option for using scalable single character delimiters such as
>> Symbol(0xe1) and Symbol(0xe1).
>
Meant to type e1 and f1.

> Unfortunately, I don't think this is trivial.  How are these  
> supposed to scale?  Just get drawn bigger?  (which is unlikely to  
> produce nice results because the lines will get thicker).

My thought was thought was that these were unlikely to be called into  
play when they were going to be surrounding multiple lines of text so  
would not be expected to scale up as might matrix brackets, but would  
rather be used in situations where they represented either means or   
physical quantities. In statistical mechanics angle-brackets are the  
time averages of quantities like pressure, while in quantum mechanics  
physical quantities are the probabilities resulting from wave/matrix  
equations involving products of bra's, "<(.)|", and kets, "|(.)>",  
representing complex conjugates possibly with a function in between  
"<  | | >". I would think that including the Symbol(0xf1) and  
Symbol(0xe1) simply as "drawn bigger" would be one approach. I would  
think another approach could be to increase the height by a greater  
ratio than the width, say 1.5 to 1. I don't know what complications  
arise in doing so, but would imagine that these would be no worse than  
the scaling problems arising with the Greek Sigma.

a) http://en.wikipedia.org/wiki/Bra-ket_notation

b) Table VIII of"Reviews of Modern Physics Style Guide":
    http://www.rmp.aps.org/files/rmpgui15.pdf

c) http://www.physics.unlv.edu/~bernard/phy721_99/tex_notes/node8.html


>
>> I'm guessing that the reason three-component delimiters were chosen  
>> is
>> that it was easier to expand the middle section while not expanding
>> the ends as much but that's just the guess of someone who is perusing
>> without really being able to fully grasp the intricacies of what is
>> being done.
>
> That's about right.  This is all modelled on TeX's equation  
> formatting algorithms.  The Computer Modern fonts have this kind of  
> extendable components for very large delimiters, but for angled  
> brackets it looks like the TeX solution is just to offer various  
> "big" versions.  For example, try the following TeX document ...
>
> \documentclass{article}
> \begin{document}
>
> \[ \left\{
>     \begin{array}{ccc}
>      a & b & c \\
>      a & b & c \\
>      a & b & c \\
>      a & b & c \\
>      a & b & c \\
>      a & b & c \\
>      a & b & c \\
>      d & e & f \end{array}
>     \right\} \]
>
> \[ \left\langle
>     \begin{array}{ccc}
>      a & b & c \\
>      a & b & c \\
>      a & b & c \\
>      a & b & c \\
>      a & b & c \\
>      a & b & c \\
>      a & b & c \\
>      d & e & f \end{array}
>     \right\rangle \]
>
> \end{document}
>

I see the problem with that construction, although as I said above, I  
don't think the angle brackets would be used very much in enclosing 8  
line constructs. Is there no way to scale the \langle and \rangle by a  
factor of three before prefixing and postfixing a grouped array?

(.... and plotmath doesn't really support grouped arrays anyway, does  
it? My other request was going to be for an array construct such as  
above, since it was rather difficult to get good results with arrays  
having a number of rows that is not an even power of two using atop().  
Or is there an array function in plotmath that I missed?)

I had been thinking that "triple height" "<" or ">" ( using  
Symbol(\0xe1 | \0xf1)) could substitute for the three part  
construction of scalable square, flat,  and rounded brackets that I am  
seeing in the plotmath.c code.

-- 
David.

> Paul
> -- 
> Dr Paul Murrell
> Department of Statistics
> The University of Auckland
> Private Bag 92019
> Auckland
> New Zealand
> 64 9 3737599 x85392
> paul at stat.auckland.ac.nz
> http://www.stat.auckland.ac.nz/~paul/

David Winsemius, MD
West Hartford, CT