emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Calc: `*' binds more strongly than `/'


From: Christian Schlauer
Subject: Re: Calc: `*' binds more strongly than `/'
Date: Wed, 18 Apr 2007 23:55:14 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.98 (gnu/linux)

Hello Jay and others,

thanks for discussing this.

Jay Belanger <address@hidden> writes:

[...]

> Really?  If I saw A*B/C*D, the main thing I'd be thinking is "Gee, I
> wish parentheses were put in."  

You write `saw' here, I'll come back to that later...

[...]

> I just tried out 2*3/4*5 on a TI-86 and HP48; they both gave me 7.5.

So does my Casio fx-115, and so did my previous Casio bought around
1990.

> I don't have a TI myself, so I used a student's. There were several
> grad students around, most of whom will eventually teach high
> school. When I asked them what "2*3/4*5" should mean, I had a hard
> time getting an answer. They kept saying "You're missing
> parentheses" or "what are you trying to write?"

I think you found a very good example: it's about what one /writes/
and /sees/ on paper and, on the other hand, what one /types/ on a
pocket calculator (or in a spreadsheet). Writing 2*3/4*5 might be
unclear when written on paper, but that is exactly what I'd _type_ in
the calculator when I write/see on paper

2 * 3
----- * 5
  4

and when I write on paper

2 * 3
-----
4 * 5

I _know_ I have to enter it as 2*3/(4*5), because my Casio and your HP
and the TIs (and OpenOffice.org's spreadsheet...) evaluate from left
to right. M-x quick-calc is made for such small calculations, but »M-x
quick-calc RET 2*3/4*5 RET« gives

Result: 2 3 / 4 5 => 0.3

which, interestingly, skips the `*' and thus looks exactly like what
Stefan called the `juxtaposition notation':

,----
| Your point is valid when you use the juxtaposition notation rather
| than *: A B / C D is indeed (A*B)/(C*D).
`----

So does quick-calc try to give a hint here to the user what it has
done by omitting the `*'? I'm not sure I would understand that hint.

> But I think writing A*B/C*D when you mean A*(B/C)*D is poor
> notation.

Writing on paper, yes, but typing it in a pocket calculator, it is
okay. I'm not sure how I'd write it in a spreadsheet program, for
legibility reasons. But if I'd encounter it in someone else's code I
knew how to `parse' it, from left to right. And so do the spreadsheet
programs. And that is the heavy argument in my opinion: spreadsheets
treat * and / equal and evaluate from left to right.

> I also think writing A*B/C*D when you mean (A*B)/(C*D) is poor
> notation, but a couple of people have said that it's a convenient
> shortcut that saves the trouble of typing in parentheses.

But then I say that writing A/B*C and interpreting it like (A/B)*C
saves me the trouble of typing in parentheses and moreover, Calc would
behave like the OpenOffice.org spreadsheet, Gnumeric, Excel, MATLAB,
... simply the things most people nowadays are used too.

I didn't know that Calc has been around for a long time. I'm just
curious how both `sides' could get their favourite behaviour (after
the release): you mentioned that this could be made configurable --
what should be the default behaviour then? Compatibility with the old
behaviour, or `behave as spreadsheets do'? I guess for safety reasons
it should be compatibility ...

Regards,

Christian Schlauer





reply via email to

[Prev in Thread] Current Thread [Next in Thread]