fix: use AbstractVector in jacobian type assertions

[ChrisRackauckas-Claude]

Summary

• Fix TypeError when calling jacobian with non-Vector inputs like SVector
• Change Vector to AbstractVector in type checks and assertions in the jacobian function

Problem

The jacobian function at src/diff.jl:649-656 used Vector in type assertions:

if ops isa Vector{Num}
    ops = unwrap.(ops)::Vector{SymbolicT}

However, vec(scalarize(ops)) can return other AbstractVector subtypes (e.g., SVector), causing a TypeError: in typeassert, expected Vector{Num}, got a value of type SVector{2, Num}.

Solution

Replace Vector with AbstractVector in all type checks and assertions within the function to properly support all AbstractVector subtypes.

Test

using Symbolics
using StaticArrays

@variables x y
ops = SVector(x^2 + y, x*y)
vars = SVector(x, y)

J = Symbolics.jacobian(ops, vars)
# Now works correctly, returning:
# 2×2 Matrix{Num}:
#  2x  1
#   y  x

Fixes #1691

🤖 Generated with Claude Code

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 0% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 21.94%. Comparing base (9177273) to head (ff1b23e).
⚠️ Report is 21 commits behind head on master.

Files with missing lines	Patch %	Lines
src/diff.jl	0.00%	7 Missing ⚠️
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

❗ There is a different number of reports uploaded between BASE (9177273) and HEAD (ff1b23e). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (9177273)	HEAD (ff1b23e)
	5	4

Additional details and impacted files

@@             Coverage Diff             @@
##           master    #1697       +/-   ##
===========================================
- Coverage   79.80%   21.94%   -57.86%     
===========================================
  Files          55       55               
  Lines        5159     5117       -42     
===========================================
- Hits         4117     1123     -2994     
- Misses       1042     3994     +2952     

☔ 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.

[ChrisRackauckas]

@AayushSabharwal why are there so many type assertions in the first place?

[AayushSabharwal]

Type stability, it helps with the benchmarks quite a bit.

[ChrisRackauckas]

Because unwrap can return numbers?

[AayushSabharwal]

Because scalarize doesn't infer, so vec(scalarize(..)) infers to Any, which means everything after that doesn't infer at all.

[ChrisRackauckas]

Why wouldn't scalarize infer?

[AayushSabharwal]

Given just BasicSymbolic there's nothing in the type which can tell the compiler whether scalarize returns a scalar or an array.

[ChrisRackauckas]

Seems like it could be useful if scalarizing gave length 1 vectors?

[AayushSabharwal]

Not really. collect uses scalarize under the hood and we want symbolic matrices to collect to matrices. I also can't imagine the amount of code that breaks from doing this 😅

[AayushSabharwal]

I can (probably) turn scalarize into a different function called stable_scalarize which does what you suggest, and have scalarize just reshape the result. It might also help MTK. The function itself will have lots of dynamic dispatch because we need to call Term.f, but that's nothing new and unavoidable.

[ChrisRackauckas]

Yeah because if this needs to asset Vector for type-stability, then it can't be abstracted. So it might need that utility at least for the differentiation functions.