From: "Mirek" <[EMAIL PROTECTED]> > 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).
