Type inference problem in color conversions

[timholy]

The following code allocates memory when it seems like it shouldn't:

using Color

import Base.uint32

function uint32(c::ColorValue, n)
    s = uint32(0)
    for i = 1:n
        cr = 255.0*c.r
        ci = iround(Uint32, cr)
        cis = ci << 16
        s += ci
    end
    s
end

c = RGB(rand(),rand(),rand())
uint32(c, 10^7)

[timholy]

@JeffBezanson, if you'd like I can start a test/inference.jl file and start putting examples such as these inside a giant@allocated check.

[JeffBezanson]

Actually the problem is that Uint32+Uint32 gives a Uint64. I do sometimes
wonder about that decision. If you want s to be a Uint32, the best approach
is "s::Uint32 = 0". Then you would only need to write the type once. For
some reason this syntax has not been that popular.
On Aug 11, 2013 6:52 PM, "Tim Holy" notifications@github.com wrote:

@JeffBezanson https://github.com/JeffBezanson, if you'd like I can
start a test/inference.jl file and start putting examples such as these
inside a giant@allocated check.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4020#issuecomment-22467148
.

[timholy]

Indeed that fixes it, thanks!

Actually the problem is that Uint32+Uint32 gives a Uint64. I do sometimes
wonder about that decision.

I do too, especially since Float32+Float32 = Float32.

the best approach is "s::Uint32 = 0" ... For some reason this syntax has not been that popular.

It's quite popular with me :-). I had in fact put such declarations on cr and ci (deleted while writing the issue text), but had not thought to do s. When I'm solving such problems I don't have a systematic way of figuring out which variable is causing the problem, so in general I sprinkle them everywhere I notice (but I don't always quickly notice the important spot, like here). Any tips? Do you just work your way through the disassembly? I am still not sufficiently fluent to make that easy on bigger functions, although I probably should have done that for this one.

What are the odds of writing a tool to help identify such problems? For example,

julia> boxedvars(uint32, (ColorValue, Int))
/tmp/uint32test.jl, line 11: s

Over the past few days in my own coding I've probably spent ~15% of my time chasing down such issues, so I'm not entirely causal in asking about this. (Oh no, I can see another Profile-scale job coming...)

[JeffBezanson]

I believe @astrieanna has been working on a tool for identifying things like this.

[timholy]

Awesome!