From: "Patrick Andries" <[EMAIL PROTECTED]>
> I'm looking for two mathematical characters.
> 2) An angle operator (combining mark ?) looking like this _| , where
>
> a )
> n| a ) n occurrences of a
> a ¯ means a )
>
> n|
> obviously a ¯ should all be written on a single line.
Suppose we note the operator with a functional syntax:
n|
fxp(a, n) = a ¯
This function can also be written using the functional notation
of the power binary operation:
n
pow(a, n) = a
So that:
fxp(a, n) = pow(a, fx(n))
= pow(a, pow(a, pow(a, ...))) ;(with n applications of pow)
So we have, for n > 1:
log fxp(a, n) = a . pow(a, pow(a, ...)); (with n-1 applications of pow)
a
= a . fxp(a, n - 1)
And thus fxp(a, n) = pow(a, a . fxp(a, n - 1))
Or using the operator notation:
n - 1|
n| ( a . a¯¯¯¯¯ )
a ¯ = a
It seems clear that the fx(n) function introduced above acts as a
functor, which could be noted as a unary operator _|, that modifies
the argument n that follows it. I do not see it as a combining
character, even if its glyph appears on the right side of its
parameter n, as in fact it also has a left side where the
exponent operator is used.
It cannot be rendered the same way as textual characters because it
implies a begin and end, and thus some sort of parenthesing, that
requires a complex mathematical layout.
If it was used with a linear text layout, one would write it like:
a _| n, or: a _| (n - 1)
which could be then possibly rendered as the following in HTML
to remove the implied parentheses:
a<sup>_| n</sup>, or: a<sup>_| n - 1</sup>
With some rich layout (MathML-like) markup, it would be something like:
<bin-op><param>a</param>
<operator>_|</operator>
<param>n</param>
</bin-op>
The placement of the operator is then not relevant for the Unicode
semantic, and it is clearly not combining the same way as combining
diacritics on letters.
Also, the existing "power-n" characters are unified in Unicode using
a compatibility decomposition into "<sup>n</sup>" where "<sup>" is
considered as a layout markup used to replace a semantic binary
operator "^" that should be present if such markup is removed.
So the question is only its identification as a character "_|"
that could be encoded for MathML usage, or in linear text.
The exact rendering in a 2D layout would put it on the right and
below a full expression, but in a linear text, we cannot encode
2D properties.
If there such character "_|" in Unicode ? Yes.
With mathematical properties? Yes.
With the correct semantic? No.
The existing semantic of this mathematical character means "not",
and it is a unary character that will not be layout in MathML
correctly by extending its glyph below and to the right of its
arbitrarily long second argument.
What could be its representatie glyph in the Unicode chart?
it would be similar to representatie glyphs used for mathematical
radicals or summations, ignoring the specific placement and
layout constraints, so I think it should be something like "_|"
aligned on the descent line of Latin/Greek letters, probably with
a "m"-width, and an ascent line similar to the lowercase letters
l and k. This glyph would be appropriate for use in linear plain
text, and additional markup could give it a more specific layout
while preserving visually its "mathematical-combining" semantic
usable for generic notations.
If this character is introduced for a notation, I think that
other characters should be introduced as well for several types
of surroundings: above, below, left, right, and their
combinations. The isolated left and right are already encoded
as a single mathemetical character "|".
Other surrounding notations exist in some languages such as in
Egyptian hieroglyphic "cartouches" (sorry this is the French word,
there may exist another appropriate word in English), or in musical
notations, using special BEGIN and END character pairs, acting as
special parentheses (and that could be *rendered* in a 1D linear layout
with "[" and "]" characters, possibly with an additional notation
like "[Rahmes](cartouche)".)
The specific layout of your proposed mathemetical operator cannot
be specified by Unicode: it must go to the markup language
specification, and Unicode will only show a representation
appropriate for usage and encoding in plain text, and will leave
the specific layout specification to MathML, if it accepts this
character with its additional layout properties.
-- Philippe.
