Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strange behavior of Julia implicit multiplication #21798

Closed
ronisbr opened this issue May 11, 2017 · 8 comments
Closed

Strange behavior of Julia implicit multiplication #21798

ronisbr opened this issue May 11, 2017 · 8 comments

Comments

@ronisbr
Copy link
Sponsor Member

ronisbr commented May 11, 2017

Hi guys!

I do not know if this was asked before, but I notice a very strange behavior with julia and the implicit multiplication. On the Internet, there has been a lot of conversation about the solution of the following equation:

6/2(2+1)

A Cassio calculator often outputs 1, whether other calculators output 9. From my point of view, the convention states that between a number and a parenthesis, there is an implicit multiplication signal. Hence, we should get:

6/2(2+1) = 6/2*(2+1) = 3*(2+1) = 3*3 = 9

However, if I type this very same equation in julia, I get:

julia> 6/2(2+1)
1.0

Because, as in the Cassio calculator, julia is solving 2(2+1) first as if it was a number. However, for such notation, you must always solve the left-most multiplication / division operation. Is it a real problem or am I missing something?

Notice that if I explicitly put the multiplication signal, then julia computes it fine:

julia> 6/2*(2+1)
9.0

Information about my system:

julia> versioninfo()
Julia Version 0.5.1
Commit 6445c82* (2017-03-05 13:25 UTC)
Platform Info:
  OS: Linux (x86_64-suse-linux)
  CPU: Intel(R) Xeon(R) CPU E5-2687W 0 @ 3.10GHz
  WORD_SIZE: 64
  BLAS: libopenblas (DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas_openmp.so.0
  LIBM: libopenlibm
  LLVM: libLLVM-3.7.1 (ORCJIT, sandybridge)
@ronisbr ronisbr changed the title Stragen behavior of Julia implicit multiplication Strage behavior of Julia implicit multiplication May 11, 2017
@ronisbr ronisbr changed the title Strage behavior of Julia implicit multiplication Strange behavior of Julia implicit multiplication May 11, 2017
@fredrikekre
Copy link
Member

Note that this is only for numeric literals which IIUC basically have a higher precedence, e.g.

julia> a, b = 1, 2;

julia> a/2b
0.25

julia> expand(:(a/2b))
:(a / (2b))

julia> expand(:(a/2*b))
:((a / 2) * b)

@yuyichao
Copy link
Contributor

@ronisbr
Copy link
Sponsor Member Author

ronisbr commented May 11, 2017

Hi @yuyichao,

Don't we need to add more information to that page implying that it is also valid if you have only numbers and not variables? It was not clear, at least for me, why in

6/2(2+1)

the operation 2(2+1) took preference over 6/2, since we do not have any variables here.

@fredrikekre
Copy link
Member

It is pretty clear IMO:

[...] Julia allows variables to be immediately preceded by a numeric literal, implying multiplication. [...] The precedence of numeric literal coefficients is the same as that of unary operators such as negation. [...] Numeric literals also work as coefficients to parenthesized expressions: [...]

@ronisbr
Copy link
Sponsor Member Author

ronisbr commented May 11, 2017

@fredrikekre ,

Precisely, when I read, I thought "the precedence is valid when you have a literal coefficient multiplying a variable". For literals that multiply parenthesis, it was not clear to me, since we have a very well defined convention about that in mathematics. For me, it was only saying that you can also use literals as coefficients for parenthesized expressions.

@ronisbr
Copy link
Sponsor Member Author

ronisbr commented May 11, 2017

I think I will send a PR with the following text just after the example 2(x-1)^2 - 3(x-1) + 1:

Notice that, in this case, the precedence of numeric literal coefficient is still the same as that of the unary operators. Hence, the expression 6/2(2+1) leads to 1 instead of the conventional result 9.

What do you think?

@fredrikekre
Copy link
Member

Improvements to the documentation is always good.

@ronisbr
Copy link
Sponsor Member Author

ronisbr commented May 11, 2017

Done, thanks @fredrikekre and @yuyichao 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants