Sacha Verweij

The sparse higher order functions code takes a similar approach https://github.com/JuliaLang/julia/blob/292a3b4c73b91bcb3dbe2d9d7c56f8d747ce5207/base/sparse/higherorderfns.jl#L31 to provide a uniform interface to sparse vectors and matrices, and perhaps other (e.g. structured) objects as well going...

Cross ref. https://github.com/JuliaLang/julia/issues/31330#issuecomment-473575718 here too :).

> it'd be interesting to see what the performance difference would be were we to emulate sparse APIs for structured and dense matrices instead of converting them to actual AbstractSparseArrays....

> do you agree and if so, could you tackle that? Before expressing an opinion I would like to think this issue through carefully (and possibly play with an implementation)....

Thoughts: The result eltype of sparse `broadcast` should match that of dense `broadcast`. Dense `broadcast` determines result eltype as follows: It retrieves the inferred eltype. If (1) the inferred eltype...

> I think I have found a workaround Cheers, glad to hear :). > On a related note: I agree wholeheartedly that the `(Real[0] + Real[0])::Vector{Real}` versus `broadcast(+, Real[0], Real[0])::Vector{Int}`...

> Maybe we should open a dedicated issue for further discussion? Sounds good! Best!

Tremendous room for improvement in this case, yes :). If memory serves, discussion of this particular shortcoming exists in at least one prior thread, but I cannot find said thread...

> Perhaps [here](https://github.com/JuliaLang/julia/issues/24317#issuecomment-340557041)? Not quite the one I was looking for, somewhat different issue :).

This issue can be substantially improved without changing the overall approach to sparse broadcast. Regarding changing said overall approach, I hope you didn't have any aspirations of getting anything done...