RFC: address issue #20882 #20889

ajkeller34 · 2017-03-04T07:47:16Z

This is exploratory (i.e. Friday night entertainment) and meant to demonstrate a proof-of-concept for how I might fix #20882, keeping the new Val type optimizations, while also making it much less confusing for average users. It is quite possible I overlooked something but I think this could be a nice solution.

After this PR:

julia> type T
    x
    end

julia> ^(t::T, b) = t.x + b
^ (generic function with 2 methods)

julia> T(2)^3
5

and if you import Base.^:

julia> import Base: ^

julia> type T
              x
              end

julia> ^(t::T, b) = t.x + b
^ (generic function with 52 methods)

julia> T(2)^3
ERROR: MethodError: ^(::T, ::Int64) is ambiguous. Candidates:
  ^(x, p::Integer) in Base at intfuncs.jl:196
  ^(t::T, b) in Main at REPL[3]:1
Stacktrace:
 [1] internal_pow(::T, ::Type{Val{3}}, ::Base.#^) at ./intfuncs.jl:206

julia> ^(t::T, b::Integer) = t.x + b
^ (generic function with 53 methods)

julia> T(2)^3
5

which is pretty much a recovery of the behavior you'd expect. Sure, internal_pow appears in the stack trace, so there may still be lingering concerns about referential transparency, but now the average user only has to reason about ^ as was the case in Julia 0.5. So, I think the concern becomes much more academic.

Some comments:

Base.internal_pow takes three arguments, the third being the function that was called to get there, which could either be Base.^ or a different function named ^ defined in a module that did not import Base.^.
The optimizations for raising HWNumber to integer literal powers 0, 1, 2, 3 are only applied if Base.^ is the operator, not if the user defines ^ without importing it. In this way, even if ^ is defined in a module, we will get predictable behavior for HWNumber types using a literal integer power:

julia> ^(x::Int, y::Int) = 7
^ (generic function with 52 methods)
julia> 2^0
7

The only downside of this PR that I can think of is that if the user is a type pirate and tries to override methods in Base, then they will discover that they cannot dodge the Val optimizations so easily:

julia> import Base: ^

julia> ^(x::Int, y::Int) = 7
^ (generic function with 52 methods)

julia> 2^0
1

We still maintain our Val type optimizations for HWNumbers, which I infer from the fact that it does repeated multiplications for powers 1, 2, 3:

julia> import Base: *

julia> *(::Float64, ::Float64) = 2.0
WARNING: Method definition *(Float64, Float64) in module Base at float.jl:375 overwritten in module Main at REPL[2]:1.
* (generic function with 177 methods)

julia> 2.0^3
2.0

however, I don't really understand why @code_lowered then reports:

julia> @code_lowered 2.0^3
CodeInfo(:(begin 
        nothing
        nothing
        return x ^ (Base.Math.Float64)(y)
    end))

which is clearly not what is happening.

To take advantage of the lowering operation for optimizations, you need to specialize Base.internal_pow, not Base.^. I don't consider this a problem personally, because only experts will need this specialization. I have not yet updated the tests to reflect this, so these lines need changing for the PR 20530 tests to pass. (edit: but otherwise, the tests should pass)
No clue if there is a performance penalty, but I don't think I've introduced any type instabilities.

stevengj · 2017-03-04T12:47:15Z

src/julia-syntax.scm

@@ -2057,7 +2057,7 @@

                 ((and (eq? f '^) (length= e 4) (integer? (cadddr e)))
                  (expand-forms
-                   `(call ^ ,(caddr e) (call (core apply_type) (top Val) ,(cadddr e)))))
+                   `(call (|.| Base (quote internal_pow)) ,(caddr e) (call (core apply_type) (top Val) ,(cadddr e)) ^)))


We should probably call it literal_pow in this case

Yes, that does seem like a better name now that it's used this way.

tkelman · 2017-03-05T01:59:39Z

test/numbers.jl

@@ -2904,8 +2904,11 @@ end

 import Base.^
 immutable PR20530; end
+immutable PR20889; x; end


these should be struct

vtjnash · 2017-03-05T04:34:59Z

src/julia-syntax.scm

@@ -2057,7 +2057,7 @@

                 ((and (eq? f '^) (length= e 4) (integer? (cadddr e)))
                  (expand-forms
-                   `(call ^ ,(caddr e) (call (core apply_type) (top Val) ,(cadddr e)))))
+                   `(call (|.| Base (quote literal_pow)) ,(caddr e) (call (core apply_type) (top Val) ,(cadddr e)) ^)))


Use 'top' instead of 'Base.'

It'll essentially resolve to the same thing, but lets us avoid hard coding the name Bade in here, and let's someone override the default function (by calling a special function to declare their module also 'top')

Great, thanks. I figured there might be some issue with the way I did that... I'll try it out.

ajkeller34 · 2017-03-05T05:27:25Z

That’s right. By passing ^, we now opt out of the specializations for powers 0, 1, 2, 3 if we find that ^ != Base.^. See my comment beginning “The optimizations for raising `HWNumber`…” in the Github conversation for this PR. It is now considerably harder to come up with surprising behavior. I can’t find your comments on Github, even though I see everyone else’s, so I hope this reply by e-mail gets to you.

…

On Mar 4, 2017, at 6:39 PM, Steven G. Johnson ***@***.***> wrote: @stevengj commented on this pull request. In NEWS.md <#20889 (comment)>: > @@ -74,8 +74,8 @@ Language changes `Vector{T} = Array{T,1}` or a `const` assignment. * Experimental feature: `x^n` for integer literals `n` (e.g. `x^3` - or `x^-3`) is now lowered to `x^Val{n}`, to enable compile-time - specialization for literal integer exponents ([#20530]). + or `x^-3`) is now lowered to `Base.literal_pow(x, Val{n}, ^)`, to enable I guess for cases where ^ != Base.^? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#20889 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG0I-XX1EwnOBTLPj1zB52kYyPhL8p6jks5riiBTgaJpZM4MTA33>.

StefanKarpinski · 2017-03-05T16:50:34Z

I feel like literal_pow should probably take ^ as its first argument – by convention we have function arguments first and in this case it seems more intuitive to have ^ as the first argument. You could call it ^ locally as well, which might make some of the code clearer – or more confusing since that's a local that shadows the global ^, but since it's passed in anyway, you need to be aware that there can be multiple meanings of ^ from different contexts anyway.

StefanKarpinski · 2017-03-05T17:33:26Z

Yes, that looks much better. Thanks!

ajkeller34 · 2017-03-05T19:09:41Z

I think the test failure may be unrelated? Also, there are a few spots in documentation where I say that we lower to Base.literal_pow(...) when we're now using top in julia-syntax.scm, but I'm not sure what the proper rewording is since I don't fully understand the top mechanism.

stevengj · 2017-03-05T20:40:15Z

I think there are some ^(x, ::Val{p}) methods that can now be deleted (in irrationals.jl, mpfr.jl, and gmp.jl). (Actually, they could have been deleted after the HWNumber change.)

StefanKarpinski · 2017-03-06T00:36:01Z

@stevengj: shall we just do that in a separate PR since it's unrelated to this?

stevengj · 2017-03-06T00:47:06Z

sure

pabloferz · 2017-03-06T15:23:42Z

test/numbers.jl

+module M20889 # do we get the expected behavior without importing Base.^?
+    struct PR20889; x; end
+    ^(t::PR20889, b) = t.x + b
+    Base.Test.@test PR20889(2)^3 == 5


There's no need for the Base.Test. here.

I have to put these tests in a different module than the other tests because I'm explicitly testing for what happens when I do not import Base.^. Since they are in a different module, I shouldn't get Base.Test.@test automatically, since I haven't done using Base.Test.

Oh, right. Don't mind me then.

ajkeller34 · 2017-03-08T05:20:58Z

This is good to merge as far as I'm concerned, though perhaps someone might want to retrigger CI or run benchmarks. (However, does anyone understand why @code_lowered reports what it does as described in the first comment in this thread?)

As we saw in #20882, some view the current behavior as odd enough to be considered a bug, so I hope this PR makes it into 0.6.0.

StefanKarpinski

LGTM, this should have @stevengj's sign-off and be merged if it looks good.

JeffBezanson · 2017-03-09T01:27:58Z

Nice. I think this is a really clever solution.

pabloferz · 2017-03-09T01:46:04Z

base/intfuncs.jl

 # We mark these @inline since if the target is marked @inline,
 # we want to make sure that gets propagated,
 # even if it is over the inlining threshold.
-@inline ^(x, p) = internal_pow(x, p)
-@inline internal_pow{p}(x, ::Type{Val{p}}) = x^p
+@inline literal_pow{p}(^, x, ::Type{Val{p}}) = ^(x,p)


Shouldn't this be @inline literal_pow{p}(::typeof(^), x, ::Type{Val{p}}) = ^(x,p)?

This generic fallback covers many situations, including the case where a user defines a function ^ without importing it from Base. In that case, if we restricted the type of the first argument, there would be no applicable method for literal_pow. Keep in mind that the ^ on the right-hand side is really the ^ passed as the first argument to literal_pow, not necessarily Base.:^.

maybe it should just be called f then ?

Right, then pow, f or something like it, instead of ^, would be better here in my opinion.

I think I originally called it y, but Stefan suggested we change it to ^ earlier in this thread. I am fine with either but can change it to whatever the powers that be decide (pun intended)

AFAICT f is commonly used for this kind of argument, so I'd vote for it.

Changed to f, since I think these comments indicate that it was confusing. Should be good to go after CI passes.

StefanKarpinski · 2017-03-10T14:33:32Z

Failure is the usual inability of AppVeyor to load packages from GitHub.

nalimilan · 2021-10-02T18:30:35Z

base/intfuncs.jl

+@inline literal_pow(::typeof(^), x::HWNumber, ::Type{Val{3}}) = x*x*x



Is there a particular reason to stop at 3 rather than e.g. 4? Of course there's virtually no limit, but 4 seems like a common power (much more than 5 and above I'd say). This could help with things like JuliaStats/HypothesisTests.jl#238.

There's an increasing loss of accuracy at higher powers. This definition for 3 is already inaccurate by a noticeable bit in some cases, so 4+ will potentially be progressively worse from there (though (x*x)^2 seems pretty well-compensated due to the symmetric shape, as these things go).

OK, thanks. So are you suggesting we should add a definition using (x*x)^2?

ajkeller34 added 2 commits March 3, 2017 22:30

Try to improve x^y Val lowering

35b0543

Merge branch 'master' into val_lowering

08c6ccd

stevengj reviewed Mar 4, 2017

View reviewed changes

Update tests, docstring, NEWS, rename internal_pow to literal_pow

75c33fa

tkelman reviewed Mar 5, 2017

View reviewed changes

Use struct instead of immutable in tests.

e228123

vtjnash reviewed Mar 5, 2017

View reviewed changes

Use top instead of Base.

09e5b1b

literal_pow takes ^ as first argument.

032a0af

ajkeller34 changed the title ~~WIP: address issue #20882~~ RFC: address issue #20882 Mar 6, 2017

pabloferz reviewed Mar 6, 2017

View reviewed changes

ararslan added compiler:lowering Syntax lowering (compiler front end, 2nd stage) maths Mathematical functions labels Mar 6, 2017

StefanKarpinski approved these changes Mar 8, 2017

View reviewed changes

pabloferz reviewed Mar 9, 2017

View reviewed changes

ajkeller34 added 2 commits March 8, 2017 18:50

Fix an outdated code comment. [skip ci]

07bc45f

Change argument name from ^ to f for clarity.

e703ae4

stevengj approved these changes Mar 9, 2017

View reviewed changes

StefanKarpinski merged commit 75c2e72 into JuliaLang:master Mar 10, 2017

ajkeller34 deleted the val_lowering branch March 10, 2017 17:27

rdeits mentioned this pull request Mar 14, 2017

@which and @code_warntype don't show ^Val{p} lowering #21014

Closed

ajkeller34 mentioned this pull request Mar 20, 2017

Make @fastmath aware of Base.literal_pow #21099

Closed

stevengj mentioned this pull request Mar 30, 2017

Fix bugs for x^Val and add tests #21226

Merged

nalimilan reviewed Oct 2, 2021

View reviewed changes

nalimilan mentioned this pull request Oct 2, 2021

Fix machine error negative values on m2 JuliaStats/HypothesisTests.jl#238

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

RFC: address issue #20882 #20889

RFC: address issue #20882 #20889

ajkeller34 commented Mar 4, 2017 •

edited

Loading

stevengj Mar 4, 2017

StefanKarpinski Mar 4, 2017

tkelman Mar 5, 2017

vtjnash Mar 5, 2017

ajkeller34 Mar 5, 2017

ajkeller34 commented Mar 5, 2017 via email

StefanKarpinski commented Mar 5, 2017

StefanKarpinski commented Mar 5, 2017

ajkeller34 commented Mar 5, 2017

stevengj commented Mar 5, 2017 •

edited

Loading

StefanKarpinski commented Mar 6, 2017

stevengj commented Mar 6, 2017

pabloferz Mar 6, 2017

ajkeller34 Mar 6, 2017

pabloferz Mar 6, 2017

ajkeller34 commented Mar 8, 2017

StefanKarpinski left a comment

JeffBezanson commented Mar 9, 2017

pabloferz Mar 9, 2017

ajkeller34 Mar 9, 2017

tkelman Mar 9, 2017

pabloferz Mar 9, 2017

ajkeller34 Mar 9, 2017

pabloferz Mar 9, 2017

ajkeller34 Mar 9, 2017

StefanKarpinski commented Mar 10, 2017

nalimilan Oct 2, 2021

vtjnash Oct 2, 2021

nalimilan Oct 2, 2021

		@inline literal_pow(::typeof(^), x::HWNumber, ::Type{Val{3}}) = xxx

RFC: address issue #20882 #20889

RFC: address issue #20882 #20889

Conversation

ajkeller34 commented Mar 4, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ajkeller34 commented Mar 5, 2017 via email

StefanKarpinski commented Mar 5, 2017

StefanKarpinski commented Mar 5, 2017

ajkeller34 commented Mar 5, 2017

stevengj commented Mar 5, 2017 • edited Loading

StefanKarpinski commented Mar 6, 2017

stevengj commented Mar 6, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ajkeller34 commented Mar 8, 2017

StefanKarpinski left a comment

Choose a reason for hiding this comment

JeffBezanson commented Mar 9, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

StefanKarpinski commented Mar 10, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ajkeller34 commented Mar 4, 2017 •

edited

Loading

stevengj commented Mar 5, 2017 •

edited

Loading