Have you tried to Pkg.add("Devectorize"). It seems to work for me, and
Julia assumes forward compatibility for packages (even though the rate
deprecation makes that assumption kind of wrong), so the "0.2-" version
simply says it should not be installed on `0.1`. I think the development
rate reflects that the low hanging fruits have been picked and nobody seems
to have ideas for how to solve the more difficult problems.
It seems like nobody has fixed the deprecation for the `array[2:]` yet, so
it does not look like it is used a lot on the master branch.
WARNING: deprecated syntax "x[i:]" at
/Users/ivarne/.julia/Devectorize/src/texpr.jl:493.
Use "x[i:end]" instead.
Ivar
kl. 14:41:28 UTC+2 torsdag 24. april 2014 skrev Tomas Lycken følgende:
>
> I wanted to try to compare these versions with a version based on trapz1
> but using the @devec macro from Devectorize.jl. However, it seems that
> development of Devectorize.jl has sort of stopped, and it's REQUIRE
> specifies Julia 0.2-, so I guess that package isn't really the way to go
> anymore (I'm on the current master...)
>
> Is there a replacement for it somewhere? If so, where?
>
> // T
>
> On Thursday, April 24, 2014 2:02:36 PM UTC+2, Tobias Knopp wrote:
>>
>> Ah yes indeed that is a very good reason when the function is parametric
>> in two different types. Maybe it would be more elgegant to have a zero
>> version that takes multiple arguments and calls promote internally.
>>
>> Am Donnerstag, 24. April 2014 13:05:10 UTC+2 schrieb Alex:
>>>
>>>
>>> The usage of construct like zero(zero(T)*zero(T)) is not really easy to
>>>> understand. I assume you propose this due to the upcasting arithmetic
>>>> integer behavior of non-native integer types (int16, ...), right?
>>>>
>>>> Basically, I wanted to avoid that r changes its type in the loop (this
>>> might be more evident/relevant if the elements of x and y have different
>>> types, say Real and Complex). I don't know if it matters much in this case,
>>> though.
>>>
>>> Best,
>>>
>>> Alex.
>>>
>>
