Julia: Implicit Multiplication oddity

[feierbach]

This may not be a problem, perhaps only a misunderstanding of Implicit multiplication:
julia> a=1; b=2; c=pi/2

julia> z=(a+1)(b+1)sin(c)
ERROR: MethodError: objects of type Int64 are not callable

julia> z=(+1)(b+1)sin(c)
3.0
How can (a+1) be considered a function name or is that what is happening?

[timholy]

Use * as a multiplication operator. Only literal constants don't need *.

[feierbach]

I'd like to reopen this issue:
if "only literal constants don't need * then why does z=(b+1)sin(c) work? b is not a constant and it is a Float64 or Int64 tied to variable.
I can put this in a for loop, incremented b and it runs nicely.
I tried a few more combinations and it doesn't like two parenthetical expressions, one following the other. Thats too bad since there doesn't seem to be a syntactic gotcha. I guess I should be happy that some cases work at all but multiplying two polynomials together you get a lot of this form and more. This form was invented to express polynomials in their native mathematical language and in most cases these "constants" are parameters that change within the context of the program.

[yuyichao]

It's not just constant but the issue is the (). Juxtapose multiplication only take place when it can't be parsed as call so ...(...) is always parsed as function call when it's not literals.

[feierbach]

Thanks. Even though in this case it was (..)(..) ?

[ChristianKurz]

The first set of parentheses could evaluate to a function:

julia> (sin)(1)
0.8414709848078965

Implicit multiplication is ambiguous here.

[feierbach]

Odd that (a+1) in z=(a+1)(b+1)sin(c) would evaluate to a function, but okay. Is this just a limitation of the parser due to design or is there a real logic problem here?
Shorty66, I thought if (sin)(1) works then (sin+cos)(1) and (sin+1)(1) should also. They don't! So what is the point of recognizing parenthetical functions. Shouldn't that be a syntax error?

[yuyichao]

Is this just a limitation of the parser due to design or is there a real logic problem here?

It's not a limitation and it's by design. The first ... in ...(...) I mentioned can be anything and it's only unambiguiously not a function when it's a constant. It's perfectly valid for (a + 1) to be callable.

I thought if (sin)(1) works then (sin+cos)(1) and (sin+1)(1) should also

What is the logic you are following here? (sin) evaluate to sin, (sin + cos) doesn't evaluate to anything so no those should not work.

[JeffBezanson]

To clarify, it would be possible to define + such that (sin + cos) works as a function, we have just decided not to have that definition by default. However function composition, e.g. (sin∘cos)(1), is defined.

There is also a separation of concerns here: the parser decides the structure of the input, but has no opinion about what + means. So we find it simpler to make (...)(...) parse as a function call independent of what's inside the parentheses. I can see the point that making it a syntax error might avoid confusion, though that seems pretty strict to me. I guess it's debatable.

[feierbach]

YuYichao, so you are implying (sin + 1)(1) doesn't evaluate to anything so the (a+1)(...) shouldn't either. And this is because the parser doesn't know that "a" is not a function but it does know that "a+1" is not a function but since "a" could be, it is ill-defined. I think the problem starts with (sin) being evaluated to sin whereas sin and it's arguments should be appended. eg. (sin(...)). Who writes (sin)(...) and why would they do so?

[feierbach]

I failed to read Jeff's comment. That really answers my questions, function composition and the parser having limited knowledge.

[feierbach]

Thanks, I think this can be closed now.

[KristofferC]

It is already closed :)