Deprecate vectorized abs methods in favor of compact broadcast syntax

[Sacha0]

This PR deprecates all (?) remaining vectorized abs methods in favor of compact broadcast syntax. Ref. #16285, #17302, #18495, #18512, and #18513. Best!

[tkelman]

is there an abs(A::AbstractArray) method somewhere?

[Sacha0]

Worth noting: Unlike with float, real, etc., the remaining vectorized abs methods never alias their inputs. This PR should be less controversial than #18495, #18512, and #18513 as a result.

is there an abs(A::AbstractArray) method somewhere?

The broader vectorized abs methods were macro generated and hence deprecated in #17302. Best!

[kshyatt]

@tkelman is this good to go?

[tkelman]

Actually these are all susceptible to the issue in #18590 (comment), where fusing will change the semantics and there isn't a great way of asking specifically for the structure-preserving version of this operation. So I think aliasing isn't the only controversial part about this whole set of PR's.

[Sacha0]

Actually these are all susceptible to the issue in #18590 (comment), where fusing will change the semantics and there isn't a great way of asking specifically for the structure-preserving version of this operation. So I think aliasing isn't the only controversial part about this whole set of PR's.

Agreed. I should be able to dedicate some time to experimenting with more general structure-preserving broadcast methods for sparse and structured matrix types in the next few days. Perhaps revert this merge and put the rest of these PRs on hold till we've better explored such methods? Thanks!

[pabloferz]

I've been trying to find a way of dealing with that issue and the only solution I can think of, would require the new type system in place.

[tkelman]

If you'd like to revert this, that might make sense. Though it would de-conflict your set of other related PR's, which you might want to leave on hold until we figure out a plan here.

[Sacha0]

I've been trying to find a way of dealing with that issue and the only solution I can think of, would require the new type system in place.

@pabloferz, I would love to hear your thoughts. Perhaps in #18590? Best!

[tkelman]

This was the only one of these we merged before realizing the issue, right? To refresh my memory it was roughly that abs.(A) and abs.(identity.(A)) would return different types due to fusing? That's fixed now by your more general sparse broadcast implementation, correct?

[Sacha0]

This was the only one of these we merged before realizing the issue, right?

IIRC, correct.

To refresh my memory it was roughly that abs.(A) and abs.(identity.(A)) would return different types due to fusing?

IIRC, roughly yes: The issue was that fusion largely defeats broadcast specializations for particular function/type combinations, causing fused broadcast operations to fall back to dense broadcast for e.g. sparse and structured objects. (A separate issue impacts the vectorized big, float, complex, real, and conj methods, discussed in #18495.)

That's fixed now by your more general sparse broadcast implementation, correct?

For combinations of sparse matrices, yes. I also have code handling combinations of sparse matrices and scalars, unfortunately impacted by this issue described on discourse (but perhaps good enough as a functionality stopgap). Not being certain how to proceed on that front (whether to wait for the issue in that thread to improve, or instead pursue the other approach I mention there), my present focus is extending the preceding work to sparse vectors. More information in this discourse post. Best!

[martinholters]

Did I mention somewhere that the output type should not be derived from inference results? I think that would make the issue you are having for the mixed sparse/scalar go away, no?