(x)(y) should just multiply x and y

[Johan Thelin]

Originally reported on Google Code with ID 19 ``` Shawn Sharpe reports:

"on normal calculators when you do for example (6)(6) it will treat it as multiplication but I get an error in SpeedCrunch... this not working is a pain when I'm dealing with longer formulas, I know I could just put the * in between but since it seems to be standard practace on calculators I'd reccomend SpeedCrunch do it to." ```

Reported by `e8johan` on 2006-12-19 20:14:27

[Former user]

``` This seems strange to me. Which calculator actually does things like this ? ```

Reported by `ariya.hidayat` on 2007-04-21 14:44:27

[Former user]

``` Fix the title ```

Reported by `ariya.hidayat` on 2007-04-21 14:44:44

[naught101]

``` agree, also, if I set n to 10, and enter "3n" it should return "30" ```

Reported by `naught101` on 2007-04-30 07:09:13

[Former user]

``` Although my Casio calculator does not recognize such an expression and don't know of any PC-based which does, I agree that it should be a valid expression. Accepting and marking as low-priority enhancement.

Regarding naught101's sugestion, I agree even more and am going to add and issue for it myself. ```

Reported by `helder.pereira.correia` on 2007-05-12 00:32:14 - Status changed: `Accepted` - Labels added: Priority-Low - Labels removed: Priority-Medium

[Former user]

``` I disagree with this. (x)(y) does not seem to be a valid expression in any programming language and I'm sure there's a reason for that. I have the feeling that if we allow this construct, sooner or later we'll hit some problems with expression tokenizing and/or parsing.

As such, I wonder: which calculator exactly does this kind of thing? So far I never heard of any. ```

Reported by `ariya.hidayat` on 2007-05-15 07:06:04

[Former user]

``` After reading your post and thinking a while on it, I must say I totally agree. This syntax must be kept away. Rejecting the issue. ```

Reported by `helder.pereira.correia` on 2007-05-15 09:16:37 - Status changed: `Invalid`

[Former user]

``` No, this should not be rejected. I think most advanced/scientific software calculators understand such input. Examples: Derive from Texas Instruments and Maple. And most pocket calculators. But most important: Everyone understands this when written by hand on a sheet of paper... I expect the following rules: - A number followed by something else should treat (or replace) the separation as a multiplication: "3sin 4" is "3*sin(4)" - Same applies to parenthesis: "(x)(y)" is "(x)*(y)", "x(a+b)" is "x*(a+b)" - And to spaces: "4 5" is "4*5", "x sin y" is "x*sin(y)" That "x sin y" must not be interpreted as "x*sin*y" can be found in checking whether sin is a function/needs a parameter. And that x in "x(a+b)" is no function can be found the same way, by checking the current definition of x. This should at least be implemented as a kind of auto completion, since the syntax is not ambiguous (assuming the symbols are known). Also succeeding numbers could be interpreted as multipliers in case the symbol with the number is not defined yet and not beeing defined: "n5" is "n*5" in case n5 is not defined but "n5 = 3" sets the new variable "n5". ```

Reported by `fabianvss` on 2008-12-29 05:38:58

[Former user]

``` such short cuts compete with other interpretations. For example, a space could well be used for user friendly input of long numbers: 3.14159 26535 89793 23846 26433 83279 50288 41971 69399 37511 a long standing wish of users, who get confused when entering more than a few digits. Now imagine this is silently evaluated as a product of 10 numbers... A '*' is easily reachable on most keyboards, so the price for typing it is quite low, compared to miscalculations introduced by ambigious grammar rules. The only way to introduce that is by a configurable grammar relaxation, but this is actually not on my 'pressing issues' list, sorry. ```

Reported by `wolf.lammen` on 2008-12-29 22:54:15

[Former user]

``` OK, I there may be a problem with spaces between numbers in future. But not between variables. And the other suggestions are also not affected. And if all that is realized as a smart correction feature, the user sees what happend with his input (but I would prefer to see the short version in the history anyway). I think that would be a very good and handy feature, not only for me. And the price for typing '*' is high, I have to hold the shift key, especially if I use functions (the hand is not on the num pad, if there even is one). And without that character, long formulas are quicker to apprehend. Things like "(2k+1)pi/2" - why should "Speed"Crunch not understand that? No book prints the '*' character! That are no ambigious grammar rules, that is all clear. Anybody understands that and I'm sure the majority tries to type without that character. If the input cannot be kept simple and by intuition, there is no reason to use a light weight calculator, right? ```

Reported by `fabianvss` on 2008-12-30 16:59:39

[Former user]

``` Then, here are some more objections: 1. SpeedCrunch saves and loads variables automatically. A user might well be unaware she some time ago defined a variable 'n5', and when typing 'a+n5' (meaning 'a+n*5'), she will receive surprising results. 2. consistency: you need plain and easy to understand rules for everybody. Silently inserting a * between operands sometimes, sometimes not, is not of that kind. (Besides, a parser becomes really unhandy, when it has to take care of a lot of exceptions) 3. Textbooks often introduce contexts in which formulas are unambiguous. |ab-cd| is quite clear if you know it describes a determinant. Without this context, this is for a machine difficult to read input: is cd a variable, does the | (currently reserved) mean an 'or'?. Simply entering formulas from other sources will occasionally fail to produce a 'what you see is what you get' result anyway.

Don't take lazyness too far, a calculator is not supposed to do magic. Having a simple and well-defined syntax is a value in its own right. And to boot, a reliable result from a clear expression is of worth as well. I'm not going to take this any further at the moment. Some people are astute enough to avoid all possible ambiguities, others are not. Right now, we (at least me) are not able to implement this at low costs anyway. ```

Reported by `wolf.lammen` on 2008-12-30 22:53:12

[Robert Carpenter]

``` Most programming languages do not allow variable names to start with a number to avoid this ambiguity -- not in the parser sense, but in the readability sense. 5numbers is an invalid name while numbers5 is not.

Calculators have pretty strict rules for variable names, for this reason.

Both have a well defined syntax which is designed to be understood naturally by those with experience in mathematics. Good user interface design dictates that the design should follow suit and allow for things to be understood naturally.

Effective software isn't always easy to write but it is always easy to use. Indeed most often effective software is difficult to write.

In reading through this discussion, having been brought here by some other related issue, I see a two fundamental problems in your approach to this software.

First: your goal is unclear. Are you trying to write a calculator program or invent a new programming language for calculations? Specify your goals and design objectives and design your software to achieve what you have set out to achieve. An open ended project is a directionless project and it will soon become difficult to make any progress.

Second: "Don't take laziness to far." Mathematical expressions such as |ab-cd| would be interpreted as abs[ (a*b) - (c*d) ]. Mathematics already has a well defined grammar outside the calculator. Just because it becomes difficult to program a parser when the grammar gets complex doesn't mean that you should rewrite the grammar.

If you want your program to be easy to use, the only time you have the ability to define a specific grammar is when the pre-existing grammar is ambiguous. Throughout most of the general public's math career, single character, letter only variables are the only variables....and many calculators only support this. If you are designing an easy to use, keyboard oriented calculator this might not be a bad choice. If you are designing a programming language for calculations this would be a very bad choice.

To be frank, I wouldn't even be on this discussion page if the error prompts weren't so ambiguous. It took me at least 6 tries to figure out what I had typed wrong with this expression: "5 + 7log e". "Invalid Expression" was all that you could muster?

I put parentheses in all over town before I tried putting in a *.

If you sat down a set of math professors in front of your program how would they expect it to behave? Design your interface for the expectations of you users and you will have a program with minimal learning curve. Where there expectations cannot be met, provide useful and automatic prompts.

Last point: If you sat down a set of computer science professors in front of your program how would they expect it to behave? Part of your design goals should be the audience you intend the program to be used by. As a mathematician I'd want to be able to use || to represent absolute value and < to represent inequality. As a programmer I'd want to be able to use | as binary or and < to represent a Boolean test.

As you say, consistency is key. But documentation is king. ```

Reported by `robacarp` on 2009-08-10 17:04:03

[Former user]

``` Hi robacarp,

Judging from your writing, you are really concerned about how Speedcrunch works, so I am under the impression you are a commited user of it. I really appreciate such a degree of interest.

On the whole (though not in every detail) I understand and support your point of view, from a theoretical standpoint. Unfortunately, the world is in a state far from being well-thought-out, and open source development seems to be no exception to this.

Currently, the most hampering limitation is, that nobody has the time to effectively develop Speedcrunch.

One of the most demanding and long-standing issues in Speedcrunch's history is, indeed, a rewrite of the parser based on something flexible like bison. But doing this would take a few weeks of work in our (my) spare time.

There are some other basic issues like number representation, or a replacement of the engine by something more modern. The estimated work for each of these tasks are roughly in the same order, maybe more.

As you can see, there are quite practical restrictions hanging around, that prevent academical style software development, even though, admittedly, it would be of great value to the project.

And this is, in short, all I can answer. At least, you will find some documentation on Speedcrunch's download sites.

Wolf Lammen ```

Reported by `wolf.lammen` on 2009-08-17 13:53:49