> > Alternatively, Julia has namespaces; I'm not sure why you think it doesn't. >
I know it does, but the main mode of operation seemed to be adding methods to existing functions in Base, to allow everything to work seemlessly. Defining `zero` to do something other than what `Base.zero` does for my custom types would then prevent functionality in Base that uses `zero` from working on my types. > That being said, the Julian style function is to only use the Base names > for functions that are conceptually similar to the Base function. If your > function is conceptually different from Base.zero(x), then it would be more > idiomatic to give it a different name. > This is what I was looking for. I wasn't sure if there was any precedence for adding methods to those in Base that behave different than those in Base. Looks like I'll have to come up with different names. @Jason Merril I'm not a big fan of `roots`, as the poles of the system could also be thought of as roots of the denominator polynomial. Perhaps a qualifier on `zero`, such as `ltizero` and `ltipole`? I'd prefer an underscore in there, but this goes against the style guide (I think?). The `response` idea is interesting though. Would a type be the best way to go about this? Currently all my code uses Symbols as options, so I'd write it like: y, t, x = response(sys, :step) y, t, x = response(sys, :impulse) Is a custom type better for this? I suppose that would allow the dispatch to work, rather than handling the diversity in the function itself. On Mon, Jan 12, 2015 at 5:32 PM, Jason Merrill <[email protected]> wrote: > 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. >>> >>
