Background

In my workflow, I encountered an inconsistency where using reshape(range(...)) produces an array of type Base.ReshapedArray{Float32, 2, StepRangeLen{Float32, Float64, Float64, Int64}, Tuple{}}, while the test cases typically use ConcretePJRTArray{Float32, 2, 1}. Example code:

y_data = reshape(range(1f0, 10f0, step=k_STEP), 1, EVAL_POINTS)
y_data = y_data |> xdev

This results in a Base.ReshapedArray{Float32, 2, StepRangeLen{Float32, Float64, Float64, Int64}, Tuple{}}. My code previously compiled (albeit slowly), but now it seems to hit a problem that the test cases miss due to the use of concrete arrays.

From https://discourse.julialang.org/t/slow-reactant-compilation-for-modified-deeponet/135133/8

Suggestion

Add logic to convert AbstractRange types into a concrete type that can then be safely passed downstream and converted to the respective traced type. This will help support more general array usage, consistent with regular Julia workflows, and ensure the test cases match real-world usage.