From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Wed Dec 31 2003 - 06:04:11 EST
From: "Mirek" <midge@wp.pl>
> Użytkownik Markus Scherer napisał:
> > Mirek wrote:
> >
> >> Dnia 2003-12-30 15:26, Użytkownik Patrick Andries napisał:
> >>
> >>> Do you have any reference as to the modernity of this V-like notation
?
> >>
> >>
> >> I made some investigations, when you asked about references and I
> >> found, that V and inverted V symbols are not common, they are probably
> >> typicaly polish :-). WHat is more there are more different conventions
> >> for those symbols :-(
> >
> >
> > These V-shape symbols are certainly not just polish. I learned them in
> > both high school (1980s) and university (1990s), in Germany.
>
> I learned them in high school, and they are still used in Poland, but at
> the University all used A,E. What is interesting I haven't found those
> V-like symobls in Comprehensive LaTeX Symbols List (that's strange,
> isn't it?).
>
> Probably they are used only in Europe.
This is not a question of area of use: in mathematics, they are used as a
way to create assertion expressions that are solved for proving theorems,
using a complete and interesting arithmetic. So there's a need to work on
this arithmetic and make a distinction between the quantified assertion
expressions and the classic notation for theorems and assertions realated to
these assertions. When this occurs, we need to make a distinction between
the object of the demonstration and the notation used to solve and work on
these expressions.
So it needs a separate "meta-notation". The choice was performed by keeping
the classic reversed-A or reversed-E quantificators for meta-expressions and
demonstrations, but using separate V-like operators for assertion
expressions that are part of the studied logical arithmetic. The use of
V-like operator is purely arbitrary here, and one could have used other
operator shapes for these logical expressions, that also need other
operators like "not", "implies", "is equivalent to", is implied by", "and",
"or"... My feeling is that V-shaped quantification operators are not the
best choice because there's a need to work also on logical expressions that
contain "and" or "or" operators.
I have seen other notations for quantifiers in logical expressions that used
the standard reversed-A or reversed-E shapes within a enclosing circle, or
noted as diacritics above a symbol like an asterisk, or written in the
center of a Q letter (meaning quantifier), or in indice or power of a small
delta or nabla operator. I have even seen small and capital delta used to
note these two quantifiers.
The large V-shaped symbols are just easy and fast to write to create long
expressions in equations using them. They are not ambiguous when there's no
other use or need to represent the classical logical "and" or "or" operators
from which their shape was borrowed.
Mathemetics use arbitrary notations, that are very defined in the context
where they are used. If the notation is arbitrary and not widely known, it
is mandatory to define them before usage, and keep that convention coherent
throughout the text using that convention.
So my feeling is that V-shaped quantifiers are not variants of the classic
reversed-A/E quantifiers, but really variants of the mathematical "and"/"or"
operators. Mathemetical notation uses glyphs to associate a semantic in
context. In Unicode, it is important to preserve this semantic and thus
allow encoding these mathematical glyphs, without trying to infer which
semantic may be associated with them (as this semantic may be arbitrary and
defined in context by the author). So for me we don't need V-shaped
mathematical quantifiers, as we can already use the V-shaped logical
"and"/"or" operators.
I would like to wish that any character that has a "Sm" general category in
Unicode has a nearly mandatory glyph (which can sometimes allow very few or
no variation in fonts) which is the glyph displayed in the Unicode charts.
If possible, there should only exist ONE font on systems to represent
mathematical symbols (more fonts are only required to support to support
alternate formats or multiple sizes if using unscalable bitmaps).
This archive was generated by hypermail 2.1.5 : Wed Dec 31 2003 - 06:59:24 EST