# Power as vector rather than a value

Can we solve something like this ?

``````10^[1, 2, 3, 4]
``````

Is there any way ?

``````julia> 10 .^[1, 2, 3, 4]
4-element Vector{Int64}:
10
100
1000
10000
``````
4 Likes

I tried it but without space and got error

like this

``````10.^[1, 2, 3]
``````

Thank you

Me too (), but got help

``````julia> 10.^[1, 2, 3, 4]
ERROR: ParseError:
# Error @ REPL[78]:1:1
10.^[1, 2, 3, 4]
└─┘ ── ambiguous `.` syntax; add whitespace to clarify (eg `1.+2` might be `1.0+2` or `1 .+ 2`)
``````
2 Likes

how you got this ?

Probably the Julia version. I’m using 1.9.0 here.

EDIT: sorry, correction, Julia 1.10dev

In `julia-1.9.1` it was good enough,

``````julia> 10.^[1, 2, 3, 4]
ERROR: syntax: invalid syntax "10.^"; add space(s) to clarify
``````

but I like the new message even better .

1 Like

I wish this was solved by just disallowing the `10.` notation for floats. Too late, of course, but this is really annoying for `.^`, since `10.^(1:3)` is so natural, while `10 .^(1:3)` is awkward.

(I also really dislike the trailing or leading dot-notation for floats in general.)

3 Likes

The most readable version in my opinion is `10 .^ (1:3)`. Whitespaces should show visually the logical grouping of the operations.

1 Like

For `+`, `*`, etc (with and without dots) I agree, but not for power, that should be without space. I belive most style guides say the same thing.

1 Like

I would skip the spaces in a more complicated expression, to highlight operator precedence, but I would keep them If the `.^` is the main operation on a line of code (possibly with an assignment). I believe that’s what most style guides suggest, but that’s a matter of interpretation.

The Julia manual here uses:

`x ^ y` | power | raises `x` to the `y`th power

(note that there are spaces!) and notes that:

(By convention, we tend to space operators more tightly if they get applied before other nearby operators. For instance, we would generally write `-x + 2` to reflect that first `x` gets negated, and then `2` is added to that result.)

As for style guides, the most detailed one seems BlueStyle. It says:

Surround most binary operators with a single space on either side: assignment (`=`), updating operators (`+=`, `-=`, etc.), numeric comparisons operators (`==`, `<`, `>`, `!=`, etc.), lambda operator (`->`). Binary operators that may be excluded from this guideline include: the range operator (`:`), rational operator (`//`), exponentiation operator (`^`), optional arguments/keywords (e.g. `f(x=1; y=2)`).

but note the “may”. And in my opinion this falls under another specification:

• Use whitespace to make the code more readable.

This is just to highlight the operation itself.

The above supports my view. I find `-x + 2` to be the analogue of `2 + x^2`, while `2 + x ^ 2` would be similar to `- x + 2`.

This is why I don’t use spaces around `^`, it helps readability.

Ultimately, it’s a matter of taste, which is why it’s unfortunate that `.^` parsing prevents that, and also causes inconsistent formatting. But I would be in favor of removing `1.` and `.5` on its own terms.

3 Likes

OK, I agree. Why do you disagree with `10 .^ (1:3)` then? Isn’t this another instance of the same principle? More space around the operator that is applied later.

Here you use parentheses to denote order, I’m not following your reasoning. And `^` anyway has higher presedence than `:`

This is about convention, and personal preference. I never use space around `^` (and this is also the common convention), having to use it around `.^` is jarring.

In fact, personally, I don’t even think of `^` as an operator, `^2` is an operator to me. In mathematics you would write x^2, and `^2` is ascii art for superscript, which gives you an idea why exponentiation has different anesthetics than + or *.

In the end it’s a personal choice, and I have made mine and want to stick with it.