[CarloLucibello]

Closes #718.

ProjectTo(::BFloat16) fell back to ProjectTo{Real}. A Float32 cotangent reaching a bf16 array was therefore not converted back, and the whole backward pass of a bf16 model was promoted to Float32. This defines ProjectTo(::Core.BFloat16) = ProjectTo{Core.BFloat16}() on Julia ≥ 1.11, matching the existing Float16/Float32/Float64 methods. The existing AbstractFloat → convert methods do the rest.

BFloat16s.jl uses Core.BFloat16 as its BFloat16 where LLVM supports bf16 (x86_64 with LLVM ≥ 15, aarch64 with LLVM ≥ 19). On other platforms, and on Julia 1.10, it defines its own type, which is left to a ChainRulesCore extension in BFloat16s.jl.

Bumps the version to 1.26.4.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.41%. Comparing base (a1dbf0e) to head (6739074).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #719   +/-   ##
=======================================
  Coverage   93.40%   93.41%           
=======================================
  Files          15       15           
  Lines        1001     1002    +1     
=======================================
+ Hits          935      936    +1     
  Misses         66       66           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[devmotion]

LGTM. I guess the only remaining question is: Should this be part of ChainRulesCore or BFloat16s? I'm leaning a bit towards BFloat16s since the general policy of ChainRules and ChainRulesCore has been to require packages to define their derivative rules in extensions and only define rules for stdlibs in ChainRules and ChainRulesCore itself.

[CarloLucibello]

I also would lean toward having it on BFloat16s, but I fear it would take months there to get merged... Since it fixes a pretty serious issue, i would prefer to have it merged soon.

[devmotion]

but I fear it would take months there to get merged

Why is that? Tim seems to be one of the maintainers. Maybe open a PR in BFloat16s and let's see if you receive a timely response.

[CarloLucibello]

Also, bfloat16 support has moved to base on recent Julia versions, so it actually makes more sense to have the extension here

[devmotion]

Support for Base types and functions should be in ChainRulesCore/ChainRules, but an extension for a non-stdlib probably shouldn't.

If I also understood your comment above correctly, Base does only support bfloat16 on some architecture whereas BFloat16s supports all (standard) architectures?

[CarloLucibello]

Maybe the best way forward is to have a no-extension PR here and another PR in BFloat16.jl. Claude agrees:

Core.BFloat16 is defined on every architecture since Julia 1.11, but Base gives it no conversions or arithmetic. BFloat16s.jl uses it as its BFloat16 only where LLVM supports bf16 (x86_64 with LLVM ≥ 15, aarch64 with LLVM ≥ 19). Everywhere else, and on all of Julia 1.10, it defines its own BFloat16s.BFloat16.

So I'll split it:

• here: ProjectTo(::Core.BFloat16) = ProjectTo{Core.BFloat16}() in src, under @static if isdefined(Core, :BFloat16), with no extension or weakdep. This covers x86_64 on Julia ≥ 1.11.
• in BFloat16s.jl: a ChainRulesCore extension for its own type, defined only when BFloat16 !== Core.BFloat16 so that the two packages never define the same method.

[CarloLucibello]

thanks David!