Make the output a vector of values for each time step.
Make the output a n x m matrix where n is the number of time steps and m is the number of calls to each @log during that step.
The first one seems a little more intuitive and can handle situations where @log is called a different number of times for each time step. The problem is that sometimes someone might want to actually log a vector and I feel like that will get confusing when both styles of logging have the same type of output. The second one is much easier to implement, has a stronger sense of the difference between multiple calls to the same @log and a single call that logs a vector, and plotting will already work without changing anything.
I'm leaning toward the second for now, at least to get something working quickly. Sure it can't handle the case of different numbers of calls in each time step, but I think that's fine for now. Maybe the long-term solution is to make an array wrapper type so we can do 1. without the confusing it a vector-valued signal.
There are two ways I think this could be handled:
@logduring that step.The first one seems a little more intuitive and can handle situations where
@logis called a different number of times for each time step. The problem is that sometimes someone might want to actually log a vector and I feel like that will get confusing when both styles of logging have the same type of output. The second one is much easier to implement, has a stronger sense of the difference between multiple calls to the same@logand a single call that logs a vector, and plotting will already work without changing anything.I'm leaning toward the second for now, at least to get something working quickly. Sure it can't handle the case of different numbers of calls in each time step, but I think that's fine for now. Maybe the long-term solution is to make an array wrapper type so we can do 1. without the confusing it a vector-valued signal.