Power as vector rather than a value

New to Julia
1

Can we solve something like this ?

10^[1, 2, 3, 4]

Is there any way ?

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

I tried it but without space and got error :sweat_smile:

like this

10.^[1, 2, 3]

Thank you

4

Me too (:smile:), 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
5

how you got this ?

6

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

EDIT: sorry, correction, Julia 1.10dev

7

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:.

1 Like
8

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
9

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

1 Like
10

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
11

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 yth 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.
12

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
13

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.

14

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.