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
Functions that currently require matU, matF, ... arguments should also accept objects of class CompadreM, automatically parsing the matrix components or failing (with a helpful error) when a necessary component is missing.
Maybe best to write function generics with methods for the manual entry vs. com(p)adre database objects?
The text was updated successfully, but these errors were encountered:
wpetry
changed the title
allow functions to accept CompadreM and ComadreM classes
allow functions to accept CompadreM and CompadreData classes
Jan 10, 2018
wpetry
changed the title
allow functions to accept CompadreM and CompadreData classes
allow functions to accept CompadreM class
Jan 10, 2018
Yes, the idea was to overload the functions so that they can be used with separate matrix components (which don't necessarily have to originate from COMPADRE) or with the new CompadreM objects.
Functions that currently require
matU
,matF
,...
arguments should also accept objects of classCompadreM
, automatically parsing the matrix components or failing (with a helpful error) when a necessary component is missing.Maybe best to write function generics with methods for the manual entry vs. com(p)adre database objects?
The text was updated successfully, but these errors were encountered: