On 11 Oct 2011, at 00:35, Philippe Verdy wrote: > 2011/10/7 Hans Aberg <[email protected]>: >> On 7 Oct 2011, at 22:22, Murray Sargent wrote: >> >>> In the linear format of UTN #28, 1/2/3/4 builds up as ((1/2)/3)/4 as in >>> computer languages like C. >> >> OK. I looked through the paper again, and could not find a description of >> that. >> >>> The notation actually started with C semantics and then added a larger set >>> of operators, and finally adopted the full Unicode set of mathematical >>> operators. >> >> In view of the problems of C semantics, as C++ shows, I am actually >> reviewing it. > > I've seen various interpretations, but the ASCII solidus is > unambiguously used with a strong left-to-right associativity, and the > same occurs in classical mathematics notations (the horizontal bar is > another notation but even where it is used, it also has the equivalent > top-to-bottom associatity). > > For me 1/2/3/4 means unambiguously ((1/2)/3)/4, i.e. 1/(2*3*4) when > working with integer, rational, real or complex numbers with an > infinite precision. Yes there are some notations of rationals using an > additive space operator between the integer part and the fractional > part, but it is not meant for being used in maths formulas, but only > in common notations (notably in economy for stocks, or gaming, or some > other pricings), and not in C or C++ or almost all programming > languages.
This is the normal interpretation in computer languages, though in math, it is desirable to disambiguate by some technique (some graphical representation of parenthesizes). But if 1/2/3/4 binds left, then it is not possible to use "/" to tokenize rational numbers, as it will parsed as 1/2 / 3/4. So for for rational number tokenization, some other character must be used, and ⁄ U+2044 FRACTION SLASH is a candidate. Expressions like a/b/c and a/b/c/d can be disambiguated by making one operator different, indicating lower precedence. In math, that would be larger, as the ÷ is not really used. So ∕ U+2215 DIVISION SLASH is a candidate, which in fact is larger in the STIXGeneral font. > Anyway, programming languages are another piece of text, it is not > really plain-text and most Unicode algorithms do not apply to > programming languages, that have much stricter constraints independant > of what the TUS could attempt to standardize, plus very strong > requirements on the preservation of "legacy" notations that are part > of the lexical and syntaxic definitions of these languages (it is not > tolerated to have multiple interpretations, even if they would seem > more "evident" or intuitive by casual readers: you don't program with > the same freedom in those languages like when you write a humane > language). I had no particular standardization in mind here, but just figuring of traditional use of the Unicode characters might be. Hans
