You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the interest of ZOP #10, Errors should never pass silently, should dxdt() instead raise an error? It feels like returning an empty array instead of failing is an attempt to be cleverly helpful, but beyond the remit of these functions. Callers IMO should be responsible for the
ifx.size:
x_dot=dxdt(...)
Noticed when delving into an error in Derivative.x() in #15. I was refactoring the shape manipulation to be used by both x() and d(), and it gets (minorly) more verbose when handling empty arrays.
The text was updated successfully, but these errors were encountered:
I agree. Raising an exception is better, and I'm even more convinced because this created unnecessary verbosity in #15. Different implementations will have a different understanding of what sizes are too small (basic example is just increasing the order of finite differences), but there's enough of lower edge case when x.size is 1. We can eliminate the empty array while forcing the implementations to handle sizes starting at 1.
From
differentiation.dxdt
:In the interest of ZOP #10, Errors should never pass silently, should
dxdt()
instead raise an error? It feels like returning an empty array instead of failing is an attempt to be cleverly helpful, but beyond the remit of these functions. Callers IMO should be responsible for theNoticed when delving into an error in
Derivative.x()
in #15. I was refactoring the shape manipulation to be used by bothx()
andd()
, and it gets (minorly) more verbose when handling empty arrays.The text was updated successfully, but these errors were encountered: