* I use this to think about inter&intra type relationships -- and wrote it above, ymmv ymwv!*
* read{T<:Scope}(scope::T{Tektronix}) = ...* On Sunday, March 27, 2016 at 7:21:19 PM UTC-4, Jeffrey Sarnoff wrote: > > Glad to know you are up to speed ... > Try this in v0.4 and in v0.5-dev: length( methods(Base.call) ) v0.4 > gives 1000, v0.5 gives 1 (deprecated) > So, Julia is known to work with 1000-fold signatured methods. The fact > that v0.5 is better groomed suggests its worthwhile to consider approaching > your same outcome more parsimoniously or with greater subspecificity .. > lifting some largely clustered highly overlapping signature-driven doings > and letting ... all the oscilloscopes be so scoped, all the multimeters be > multiply metered ... so what you think about as a single method with > signatures everywhichway, is realized as subspecializations of a > [partially] shared abstractions. > > abstract Device > abstract Scope <: Device > abstract Meter <: Device > > @enum vendor Tektronix, Fluke > > type LogicAnalyzer{vendor} <: Scope > ... > end > > type Multimeter{vendor} <: Meter > ... > end > > TLA7000 = LogicAnalyzer{Tektronix}( ... ) > Hydra2638A = Mutimeter{Fluke}( ... ) > > handshake{T<:Device}(anyDevice::T) = ... > read{T<:Scope}(scope::T) = .. > read{T<:Scope}(scope::T{Tektronix}) = .. > > read{T<:Meter}(meter::T) = .. > > > On Sunday, March 27, 2016 at 6:03:11 PM UTC-4, Oliver Schulz wrote: >> >> Hi Jeffrey, >> >> On Sunday, March 27, 2016 at 3:51:18 PM UTC+2, Jeffrey Sarnoff wrote: >>> >>> Assuming your handshaking and signal management is keeping information >>> available in some easy to discern and decode manner and you are not pushing >>> latency issues, Julia should be a good platform for that. >>> >> >> I have no doubt of that. :-) Both in terms of execution speed, and other >> features (native coroutines, etc.) Julia is an excellent platform for this. >> I used to do this in Scala (using Akka actors), which was fine, but I >> believe it can be done even better in Julia (at least given certain >> requirements and boundary conditions). >> >> >>> Compilation time usually is not a concern -- and you can make your >>> package autoprecompile [...] pay attention to the general guidelines here >>> performance >>> tips <http://docs.julialang.org/en/release-0.4/manual/performance-tips/> >>> [...] and use the Devectorize package >>> <https://github.com/lindahua/Devectorize.jl> >>> >> >> Yes, I will certainly use precompilation as far as possible (well, not >> for actual user measurements scripts, etc. but for the device >> implementations), and I am familiar with the Julia performance tips and >> memory management recommendations. My question rather revolved around >> whether Julia's dispatch will be happy with O(1000) (or more) methods for a >> functions. >> >>