Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is there any practical benefit of tracing Val? #602

Open
avik-pal opened this issue Jan 24, 2025 · 2 comments
Open

Is there any practical benefit of tracing Val? #602

avik-pal opened this issue Jan 24, 2025 · 2 comments

Comments

@avik-pal
Copy link
Collaborator

Base.@nospecializeinfer function traced_type_inner(
    @nospecialize(VT::Type{<:Val}),
    seen,
    @nospecialize(mode::TraceMode),
    @nospecialize(track_numbers::Type)
)
    if VT isa UnionAll
        return VT
    end
    T = VT.parameters[1]
    if traced_type_inner(typeof(T), seen, mode, track_numbers) == typeof(T)
        return Val{T}
    end
    throw("Val type $(Val{T}) cannot be traced")
end

When we construct while/if we need to track_numbers which in-turn tries to trace through Val (which occurs very commonly inside Lux states), and this eventually errors. If there is no practical applicability, can we remove this?

@wsmoses
Copy link
Member

wsmoses commented Jan 24, 2025

I think it is impossible to use a Val of a traced.

So the question is whether it is helpful to error (eg someone trying to move something through a Val they would’ve expected or error early, or just to fast path return as is

@avik-pal
Copy link
Collaborator Author

Maybe a warning and proceed? Since users can't disable this it makes doing things like

st = (; a = 1, training = Val(true))

Reactant.to_rarray(st; track_numbers=Number)

I would expect a to be tracked and training be left as is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants