Another Julian option for response functions would be to have something like:
abstract AbstractDrivingFunction immutable StepType <: AbstractDrivingFunction end immutable ImpulseType <: AbstractDrivingFunction end Step = StepType() Impulse = ImpulseType() Then you could have people call response(sys::LTISystem, Step) or response(sys::LTISystem, Impulse) to get the step response or the impulse response for the system. On Monday, January 12, 2015 at 3:20:10 PM UTC-8, Jason Merrill wrote: > > Not sure if this is very helpful, but I think `roots` would be a great > name to use instead of `zero`. > > You could maybe use `stepresponse` instead of `step`, but it's a little > hard to parse with Julia's squishedcase convention. > > On Monday, January 12, 2015 at 11:09:54 AM UTC-8, James Crist wrote: >> >> I'm currently writing a control theory package for Julia. The MATLAB >> control theory toolbox has been around forever, and is *the standard* >> grammar for the field. Almost all control theory packages in other >> languages just replicate the same set of functions, with the same names. >> The function names are so hardcoded into me, that I'm reluctant to change >> them. >> >> That said, several of them conflict with Julia base function names. For >> example: >> >> `zero(sys::LTISystem)` would compute the zeros of the system in MATLAB, >> but in Julia this should create the "zero-valued" system >> >> `step(sys::LTISystem)` computes the step-response, but in julia it gives >> the step for a range >> >> There are others as well. I see two options here: >> >> 1.) I begrudgingly rename them, and attempt to retrain my muscle-memory >> when writing code :/ >> 2.) Some functions don't do what they do in julia base for these types >> >> #1 probably is for the best, but I'm wondering what the community >> response is to this? I come from a heavy Python background, and without >> namespaces, I'm not sure how to handle function name-clashing best. >> >
