* 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.
>>
>>
