Number syntax

ampersand maybe?

El 15/12/2010 11:18, D Yuniskis escribió:

or

or

(unless some of the above interpret "(" or the equivalent as "x")

or

(unless you support also comparison operators)

or

(I bet you don't use *that* operator)

..

Your parser (as you explain above) can parse mixed fractions like 2 1/2 as well as implied products like 2 pi. That sounds OK to me. If you parser handles input like 2 1/2 pi as (2 + 1/2) * pi then why change anything?

Number syntax is easy. It's expression syntax where it gets complicated. And just to clarify: 2 pi is not a number, it's an expression combining 2 numbers.

In mathematical expressions written by hand, people express implicit grouping by horizontal space, vertical position and other things that a linear representation can't faithfully match. It begins with fractions and exponents being represented the wrong way:

and it essentially never ends. The information that was lost by breaking vertical placement into the horizontal direction has to be replaced by _something_ else.

Just look at the examples you started out with: you're already using the same representation of to mean to wildly different things: plus , or times . There's really no way to keep that up without some additional explicit grouping, i.e. parentheses.

And since you're going to need parentheses anyway, might as well use them for this, too.

But it's necessary.

Principle of least surprise is a nice goal --- but sometimes you just can't avoid it other than by not letting people enter stuff in the first place that would unavoidably cause surprise later.

Casio calculators use :

where _] are the bottom and right bottom segments... and go to decimal when the denominator reaches 1000

Gerardus

Well, you might decide to implement a tight binding + operator to solve that one problem. For example, &

So, 2&1/2 might be okay?

It may require some consideration of the / operator parsing, in the presence of & (vs without it.) I haven't thought much more about it than to suggest the thought. That is, if that's the only problem you need to solve for now.

How do you handle complex numbers and unit expressions?

Jon

I think it is too "unintuitive" (exotic?) for folks to accept it. I've been looking over various things that I and others have written (usually handwritten) with an eye towards identifying how folks *expect* to see these things expressed. Recipes are perhaps the most common place where they are encountered, etc.

The "space between" seems the most common -- by a great margin. Note that very rarely do I see fractions written "up and down" (except *published* recipes where "1/2", etc. is an actual glyph or a pair of characters specifically typeset AS IF a single glyph).

I note that recipes that I have emailed to people have used the "2-1/2" notation instead of "2 1/2" -- though I can't fathom why I opted for that form. :-/

They're all kind of clumsy. And, would confound my treatment of multiplicative operators.

What I am hoping for is something that "feels" natural -- yet, a mechanical model that makes parsing deterministic.

Actually, that's "feet" or "minutes", depending on context. :-(

The problem comes with things like:

all being equivalent. Consider:

I think the solution is to have a second "additive" operator that binds more tightly than "+" *implied* between "strings of numbers/quantities".

So, the above would be interpreted (correctly) as ((2 * ft) & (6 * in)) * (25.4 * cm) where "&" is used to illustrate this new additive binding. (i.e., the user never *types* that).

Then, "2 1/2" can be (silently) regarded as: ((2 * unity) & ((1/2) * unity))

Let me think to see if this fixes my problem and still is consistent with the "expected" expression syntax...

Correct. But people think of "2 ft 6 inches" *as* "2.5 ft" or "30 in" (not as the expression "2 ft + 6 in")

But, my informal survey of handwritten fractions and mixed numbers shows the latter to be more prevalent than the former. I suspect because, having left "grade school" and moved on to fine-lined paper, we no longer have the vertical space to even *handwrite* fractions in that way (recall learning fractions on wide-ruled paper and/or *unlined* "math paper"). Electronic communications, etc. has only made this worse.

But *people* have no problem interpreting these things. I only write "2 * pi" when writing code; all other times its "2 pi". Likewise, "2 1/2" instead of "2 + 1/2". The syntax of our programming languages differs from that which we use in day-to-day transactions.

I am confused. The "units" are separated from the "fraction" with the same delimiter that is used to separate the fraction's numerator from its denominator?

Yes, I think that's the answer -- but, it is an *invisible* operator. E.g., something like

::= + |

::= |

(this isn't intended to be complete -- just illustrative)

Units: see above. Complex: as tuples (otherwise handling a negative imaginary component becomes difficult to disambiguate from an "expression")

Exactly !

It is an easy way to enter the value using only digits and _] (one key). Simple fractions only need one press; when you have an integer part, two presses.

See

Gerardus

It will, considered you do it the right way ;-)

As an example, see how wolframalpha interprets each of your inputs above...

I think I get the idea. By "invisible" you mean that if a number is followed by a number (and only in that case) you'd bind them tightly with implied addition that supercedes everything else, including raising to a power.

I suspect you'd want to define things in such way that it wouldn't work, over and over, so that "5 1/2 1/4" wouldn't be interpreted as 5.75 but instead as 5.5 followed, inappropriately, by 1/4. Or perhaps you want that; I can't guess about it.

Also, you may wish to not permit "5 3" as 8. Might be better to provide an error. Also, "5 3*4" may not be permitted, while "5 3/4" is. So some careful crafting of the production rules seems appropriate. Would like to see them when you get done. Are you planning right-recursive form? Or does your parser not require it? (I note you may have used a left-recursive form, above, though it is hard to say for sure given the "illustrative, not complete" form you gave.) I'm curious on that point, too.

Now, do you have a syntax for supporting continued fractions, too? :) Very useful, at times. Better yet if you support operations that retain them. ;)

okay.

Jon

AFAICS that only applies to people brought up in that silly imperial system of units. OUt here in the metric world, people will _say_ "two and a half kilos", but they'll still write 2.5 kg.

Was that a survey of numbers, or of expressions? Numbers in recipes, which you mentioned elsewhere, usually stand entirely on their own. There's no calculation, thus no need to worry about notation. As I said, numbers on their own are not where the problem lies.

Call me biased by having read hundreds of pages of university students' homework in my time, but I don't see that. The usual paper around here is 5mm square gridded A4. Most people use two rows of squares for ordinary text, and three or more for maths. That leaves the necessary room for proper fractions and exponents, among other things.

Even those that do use a diagonal divider for the fraction, will still put the numbers at least somewhat higher and lower, i.e.

or something like that.

And there's a very good reason for that: because in the long run it's the only viable way of representing things clearly and unambiguously. People can much more easily afford to be ambiguous when communicating directly with other people than they can, or should expect to be able, with computers. We're about 50 years into the history of computers, so just about everybody knows that by now.

Just to add another really nasty case: how do you decide whether

means 30 inches or 144 square inches? And is

two square feet, or four?

Yes. Note that there are two issues, here. One is the mechanics of the actual parser. But the other, more important, is the model that the user can "fall back on" (hopefully intuitively) in understanding how *I* am interpreting his input.

I will need to think hard about the actual syntax supported. Note that your example, expressed another way: "5 oz 1 T 1 t" *is* something I would support! (e.g., 5 1/2 1/6)

Yes -- though the equivalent "as units of measure" might have some validity.

As I said, the syntax has to be carefully reviewed and not "blindly" applied (as humans, we are inconsistent; the software should cater to that but *only* in a rational way)

Correct. In the latter example, the '/' is "technically" a division operator -- but is actually being used as a "fraction indicator" (despite the fact that fractions imply division).

I was just trying to show the types of expression that you would have to support (e.g., "6 miles 2 furlongs 3 yards 1 ft 2 inches")

I use arbitrary precision, decimal "rationals". It's not perfect but it handles a lot of "sins" that "floating point" math would otherwise commit.

Understood. I'm interested in how both wind up.

Yes. I see that. So my example might be dimensionless under this kind of view and acceptable on that basis? I'm curious.

Back to that point, of course. It will be interesting to see how you finalize all this. If you do prepare productions, I'd like a chance to see them.

;)

Yup.

I know. Doesn't change the fact that I'm still curious if you require right-recursive form, or not.

Sometimes, I imagine developing an engine to handle a large number of irrationals, accurately. Then I set down with pencil and paper (and articles and books others have written) and work out that I don't really want to bother. At first, operations on continued fractions look almost okay. Then it gets bad in some places. Then some hope dawns. Then despair again.

So, yeah, I like your approach.

Jon

I have to think it through to see if there are any ambiguous cases. E.g., if you consider fundamental constants (pi, etc.) as "", then things like "2 pi" give you the wrong interpretation (2 + pi). So, you treat pi like "".

But, that's a hack. How will folks perceive other such "symbols" in other contexts? What if you allow new symbols to be defined -- including some innocuous ones like "MemoryRegister3"... how can you rationally describe the interpretation of "2 MemoryRegister3"?

Etc.

I.e., there can be subtle ramifications to this sort of thing that paint you into a corner down the road... (necessitating the equivalent of "escape characters" to alter the default interpretation of symbols, etc.)

I can't really go much beyond the simple "" "" grammar because everything is driven from tables -- which can vary over time as well as context. E.g., ''' is feet when dealing with distance but minutes when dealing with time, angular measure, etc.

It makes it easier for folks to evaluate an expression without having to consider the order of operations, mathematical precision, etc. Especially financial calculations.

If folks find it acceptable to burn CPU cycles watching animated icons... :-)