Added validate_input_sizes function to Model class

[tarplmic]

Added a validate_input_sizes function to the Model class. This loops through every input_field for the class (on init) and checks that the size of each input is the same for the class definition and the instance of that class. If there are differences, it tells the user what the name and type of the input is, the desired shape, and input shape.

[sixpearls]

Can you add a test that shows it is catching an invalid input? pytest has a context manager for an expected exception.

[sylvesterkaczmarek]

This breaks tuple inputs that used to work. flatten_value() already accepts generic array-like values by converting non-arrays with np.array(), but the new validator only normalizes int/float/ndarray/list. A vector passed as (5.0, 2.0, 1.0) now reaches input_value.shape as a tuple and raises AttributeError before the existing conversion. Could this use np.asarray/generic array-like handling and add a tuple regression?

[sixpearls]

Good catch on the tuple. It may work to change the condition isinstance(input_value, (int, float, np.ndarray, list)) to not isinstance(input_value, backend.symbol_class)

[sylvesterkaczmarek]

Yes, I think using the symbolic versus non-symbolic boundary is cleaner here. flatten_value already treats anything that is not a backend symbol as array-like by converting it through NumPy, so doing the same before shape validation would keep tuples and other numeric array-likes compatible without maintaining a separate hard-coded type list. I would still add the tuple regression from my review, plus the invalid-size exception test you requested, so both compatibility and the new validation behavior are pinned.

[sixpearls]

Looks good. After tests pass, @ixjlyons can merge if he approves

[sylvesterkaczmarek]

Rechecked current 03d2f01a. The tuple compatibility issue I raised is resolved: non-symbolic values now go through np.atleast_2d before shape validation, so tuple/list/ndarray inputs share the same normalization path instead of tuple values reaching .shape directly.

The new test covers tuple success, ndarray/backend-symbol success, and invalid tuple/array/symbol shapes. The full CI matrix is green across supported Python versions and platforms. No remaining issue from my earlier review; the current maintainer comments are test-organization/assertion refinements rather than correctness blockers.