Skip to content

Conversation

@araujoms
Copy link
Collaborator

Closes #930

@codecov
Copy link

codecov bot commented Oct 15, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.90%. Comparing base (52c41f7) to head (86bc9c9).
⚠️ Report is 2 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1475      +/-   ##
==========================================
- Coverage   93.90%   93.90%   -0.01%     
==========================================
  Files          34       34              
  Lines       15930    15937       +7     
==========================================
+ Hits        14959    14965       +6     
- Misses        971      972       +1     

☔ View full report in Codecov by Sentry.
📢 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.

@ViralBShah
Copy link
Member

ViralBShah commented Oct 21, 2025

I assume that the _lucopy and copy_similar will not make copies in the cases where there is no need to promote the type. It appears to be the case on a quick look - but just want to make sure.

@araujoms
Copy link
Collaborator Author

Sorry, no, they always copy. I'm just reusing the implementations of lu and qr, so I'm not making any more copies than before, though.

src/generic.jl Outdated
return UpperTriangular(A) \ B
end
return lu(A) \ B
return _lu(_lucopy(A, T)) \ B
Copy link
Member

@jishnub jishnub Oct 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the idea of this generic method is to dispatch to an optimized lu method for a custom AbstractArray, if one exists. Using the internal _lu here would bypass such dispatches. E.g.: SparseMatrixCSC has an optimized lu implementation.

We may add special cases for StridedMatrixes, if this helps with type stability.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. What's the solution, though? lu(copy_similar(A, T))? That would create yet another copy.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can just do a hack maybecopy(A, ::Type{T}) where {T} = eltype(A) <: T ? A : copy_similar(A, T), but surely there must be a better way to do it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you change the UpperTriangular case instead?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why? That case is working correctly.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I've used a slightly better version of the hack, I think it's fine, it doesn't affect the dispatch, and only copies when necessary.

@araujoms
Copy link
Collaborator Author

I've also fixed the specialized vector methods, because even though they were not type unstable they were returning an answer of the incorrect type. Luckily this involved less copying, not more.

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

Successfully merging this pull request may close these issues.

Matrix{Int} \ Vector{Float32} is type-unstable

4 participants