1. Helder Correia Avatar Helder Correia
  2. Untitled project
  3. speedcrunch
  4. Issues

introduce implicit multiplication

Issue #538 closed
Former user created an issue

Originally reported on Google Code with ID 538

Many mathematical tools offer this notation simplification, and it is very handy :)

Instead of writing 3*pi one could write 3pi etc...

Reported by oversc0re on 2014-11-13 08:05:57

Comments (19)

  1. Former user Account Deleted

    Reported by helder.pereira.correia on 2014-11-28 17:16:04 - Labels added: Type-Enhancement

  3. Pol Welter

    I edited the title to properly name what the OP wanted to express.

    With the introduction of units, implied multiplication is going to happen. Quite a few discussions have been had on this subject (issues #19, #34, #54, #226, #301), none of whicj I was part of, and all of which I skillfully ignored when implementing this feature :)

    I would like to use this place to discuss possible shortcomings and enhancements to my implementation. Let me first describe how it works.

    • Adapting the parser to include the new rule was reasonably straight forward. The tokenizer was left unchanged, only the 'compiler' was modified to treat the rule identifier identifier as a multiplication. Implicit multiplication is always treated with the same precedence as its explicit counterpart. Adding an asterisk * should not modify the order of operations in any case. Examples:
      • a/b c = a/b*c,
      • 5x^2 = 5*(x^2).
    • Obviously if the user wants to express 0 * x5, but types 0x5, the result will be parsed as a hexadecimal number. The same goes for other bases. Still, I don't see this as a problem.
    • The right hand operand of the IM must currently be an identifier (e.g. a variable), but not a literal constant (e.g. '5'). This is results in the following behavior:
      • 5a -> 5*a,
      • a 5 -> invalid,
      • ab -> value of the variable ab
      • x x -> x^2 (not the value of xx),
      • 3 3 -> 33 (thirty three),
      • 2(a+1) -> 2*(a+1),
      • (3)(3) -> invalid,
      • 2 arcsin(sqrt(2)/2) -> invalid, but 2 sin(pi/3) is ok.

    I would love some feedback. I think it is clear that some of these are not ideal. At the time I did not put overly much thought into it and went with a conservative approach (one that often yields invalid expression). I am confident that any decision could be implemented easily (read: without too much trouble).

  7. Pol Welter

    3 sin(pi) is working just fine. Only a literal number is currently not allowed, e.g. 3 sin(2).

    I think I remember why I chose to do it this way. IIRC, I'd get weird things like 0b104 = 8 (interpreted as 0b10 * 4), so I preferred not to allow implicit multiplication of two literals. Still, I agree it could be done better, but it is kinda hard with the parser at hand (it only knows 'constant' and 'identifier', so I worked with those).

  8. Helder Correia repo owner

    Yes, it's a bit strange for an user that "3 sin(3 pi)" works but "3 sin(3)" doesn't.

  10. Pol Welter

    No it's not. It is a side effect of intended behaviour. Doing it properly will either require a mid-sized change of the parser (not the full blown stuff we have been discussing) or a change of the tokenizer.

    I fear that any 'fix' for this will merely be a hack. So I no longer fully agree with my former self when writing that it can be done easily.

    Feel free to prove me wrong! :)

  13. Pol Welter

    IIRC I tried that one, but I can't remember why I rejected it....

    We might also do this with parentheses, so that 2(2+3) is allowed.

    Either way, good job!

    EDIT: Builds? I don't think we are releasing just yet :)

  20. Log in to comment
Assignee
Type
enhancement
Priority
minor
Status
closed
Component
parser
Milestone
0.12
Version
0.11
Votes
0
Watchers
0
Jira: the preferred issue tracker for Bitbucket. Join the team!