Symbol storage

[tjstienstra]

A lot of models of course use symbols to define there models. It would be ideal if there was a consistent way of storing the symbols. MoSCoW is used to prioritize the requirements:

• Must: this feature must be implemented.
• Should: this feature should be implemented, but if there is no time it can be left out.
• Could: this feature could be implemented, so it would be nice. It is however not that much of a problem if it is not implemented.
• Won't: this feature won't be implemented.

The following requirements exist:

• Several types of symbols must be stored (M):
  • Symbol for constant values.
  • Function, because that can also be useful, just think about the fact that someone may have a model with a time-varying input force.
  • Generalized coordinates (dynamicsymbols), which should be accessed separately may have a model with a time-varying input force.
  • Generalized speeds(dynamicsymbols), which should be accessed separately
• The user must be able to retrieve a description of a symbol (M)
  • Otherwise you'll really have to use extremely clear names for everything, which makes things only more difficult.
  • A difficulty is that symbols might be changed, changes of symbols defining a body, can be changed within a body.
• It would be nice if the user is able to change the symbol name (C)
  • Problem is however that some symbols already get used in the init. Possible fix is to only support it for some
• The user should be able to retrieve what symbols are being used (S)
  • Would allow for some free_symbols function or something, though would this also contain functions?
• There should be a consistent storage/retrieval method across all models (S)
• The symbols must be defined in define_objects (M)
• It could be nice if a user is able to also specify values, which can automatically be extracted if one were to implement a fancy lambdify helper function or something (W, at least not for now).
• There could be some autochecking after define_kinematics, whether all generalized coordinates and speeds have been added to the system (C).

There are several approaches:

• For generalized coordinates and speeds, just use a q and u matrix, mutable or immutable depending on whether changes are allowed and such.
• One can for example use a protected dictionary or tuple to store some of the symbols and to be able to retrieve them. While using a descriptions property to actually list all of the symbols as keys (retrieving the of the objects if necessary) and give a description for each as value.
• The above approach can also be adopted by introducing one more general name, which uses a mutable storage type like a dictionary.
• The most flexible approach would be to add a property like symbols, which returns a SymbolsStorage instance or something, which can either use internal SymbolDescriptor's or just tuples or dictionaries.

[tjstienstra]

I'm quite leaning towards creating a separate object as, that would allow a better future proof solution. This object will have the following requirements:

• It must be iterable (M)
• A user must be able to easily retrieve a symbol by name (M)
  • Option would be to either automatically set them as attributes, would be dynamic though.
  • Use __getitem__ to have dictionary like behaviour
• Have a get_description method, which can either take a symbol or a string.

I'm actually shooting this idea, as one can replace the symbols of a body easily. Making a connection between this class and that happening, would make it a SymbolTracker, which seems over complicated.

Maybe I'm actually going for a SymbolCatalog which has a compositional relation towards ModelBase. The SymbolCatalog itself composes of SymbolDescriptor objects, which have a name, full_name, symbol, description and used attributes. It also has a method change_symbol, which is only allowed if the symbol has not been used yet. Here are some quick user stories:

symbols = SymbolCatalog(model_name)
symbols.add_symbol(name, description)  # -> None
symbols.get_symbol_descriptor(name).used  # -> False
symbols.change_symbol(name, new_symbol)
symbols[name]  # -> Symbol(f'{model_name}_{name}')
symbols.get_symbol_descriptor(name).used  # -> True
symbols.change_symbol(name, new_symbol)  # -> raise ValueError("Symbol ... has already been used")
symbols.get_description(name)  # -> description
symbols.get_description(symbol)  # -> description
symbols.get_description(unknown)  # -> None
# How should one add functions and coordinates and speeds

Oh wait, Descriptor would actually be rather confusing.

[tjstienstra]

While nice catalog handling would be nice, there are just too many complication due to trees and inheritance. Therefore, the approach is to go minimal and flexible. This means using normal objects like dictionaries. Classes are a bit free in what they like to use. The main approach will be to keep the hard code descriptions property which retrieves symbols and add the descriptions (strings) as values. Other then that it is recommended to use easily accessible stuff like dictionaries: q, u, symbols. Though one is free to also use a matrix or list. For q and u it is sensible to just use matrix, assuming one just uses numbering.