Raise informative error for exponentiation to negative power (see #3024)

[timholy]

No description provided.

[ivarne]

@JuliaBackports :)

[nalimilan]

Is there any chance the message could be made even more explicit? Less skilled users are the ones which are going to find this behavior unexpected, and for them I think the message you added is quite difficult to understand. Technically, would it be possible to print something like "use 2.0^-2" when the user typed 2^-2 at the command line?

[timholy]

This doesn't have access to the values themselves, and of course if it was a function with x^n then substituting in the values wouldn't really help change the code.

But I agree with the overall concern. Would

To take an integer x to a negative power -n, try 1/x^n, float(x)^-n, or (x//1)^-n.

be an improvement?

[nalimilan]

This doesn't have access to the values themselves, and of course if it was a function with x^n then substituting in the values wouldn't really help change the code.

Yeah, I was suspecting that. Your new proposal looks like an improvement to me, but maybe it would be even better to mention somewhere the fact that writing 2.0 instead of 2 also works. Not sure how to express that in all generality. Maybe this?

Cannot raise an integer x to a negative power -n. Make x a float by adding
a zero decimal (e.g. 2.0^-n instead of 2^-n), or write 1/x^n, float(x)^-n, or (x//1)^-n.

[timholy]

Seems like a fine suggestion to me. I'll let this sit a bit and see if anyone else chimes in with further suggestions.

[simonbyrne]

Why couldn't this go in the error itself, similar DimensionMistmatch?

[timholy]

Can't remember for sure, but I think it has to do with GC frames and/or inlining.

[nalimilan]

Yeah, that's really unfortunate, as explicit errors everywhere make a language much nicer to user, especially for newcomers (and they are the ones that make your user base grow...).

[StefanKarpinski]

It may be possible at some point to read values straight from the stack instead of forcing them to be heap-allocated, which would allow access to values without a performance hit.

[timholy]

Adopted @nalimilan's suggested wording.

I will be away for a couple days; if this turns green and anyone is in a hurry, just hit merge. Or just wait until I get back.

Also, I only belatedly noticed that this (and the similar handling of other DomainErrors, like sqrt(-4)) doesn't work if the error is inside a function---it's REPL-only. That is indeed a little unfortunate.

[StefanKarpinski]

For some reason I don't see this even in the REPL on OS X. I just get the normal old DomainError:

julia> 2^-10
ERROR: DomainError
 in power_by_squaring at /Users/stefan/projects/julia/usr/lib/julia/sys.dylib
 in ^ at intfuncs.jl:104
 in process_options at ./client.jl:221
 in _start at ./client.jl:362
 in _start at /Users/stefan/projects/julia/usr/lib/julia/sys.dylib

[ivarne]

The decoded bt cames back as

(symbol("???"),symbol("???"),4555450214,true,4555450214)
(symbol("???"),symbol("???"),4555450377,true,4555450377)
(:power_by_squaring,symbol("/Users/ivarne/dev/julia/usr/lib/julia/sys.dylib"),-1,false,4588770674)

So I tried with f05660e and it seems to work. Any reason @timholy didn't attach this to the power_by_squaring function?

[tkelman]

@ivarne I think he's going to be offline for a few days. Guessing he may have just assumed the DomainError was coming directly from a method of the ^ operator and forgot about power_by_squaring? Though it looks like power_by_squaring might throw a DomainError for some non-integer x in x^y where the message would be inaccurate. We can try your change and see whether it causes any false alarms?

Edit: nevermind, on Linux where Tim presumably tested this, his version works and yours doesn't. Some platform-dependent inlining or something going on?

[ivarne]

I noticed, but you happened to have a reasonable guess also 😄, and he will be back . power_by_squaring is only for Integer exponents (?), so I don't think it is really misleading.

[tkelman]

Sorry for my compulsive post-editing, if you haven't hit refresh. Your method works on Mac, Tim's method works on Linux. Dunno why it's different. Check for either case and issue the same message?

[timholy]

Maybe there's another email I haven't yet gotten to about a fix for this, but this looks like it's not due to a difference in dispatch, it's due to a difference in backtraces. Someone on a Mac will probably have to fix & test. (Preferably, someone with access to both Mac & Linux.)

[stevengj]

I suppose we could just do || code[1] == :power_by_squaring to handle both cases.

[ivarne]

Backported for both Linux and Mac in 201c916