no method view(Array{Float64,1})

[dlfivefifty]

My code broke under the new NumericExtensions, looks like a missing implementation of view

WARNING: unsafe_view is deprecated, use view instead.
in unsafe_view at deprecated.jl:8

ERROR: no method view(Array{Float64,1})
in unsafe_view at deprecated.jl:10

[lindahua]

as of the latest master, you are allowed to write view(a) where a is an array.

However, using this view is equal to directly using the array in terms of performance. So it is more sensible to simply use the array itself.

using view makes sense when you want to create a view of a part of the array.

[dlfivefifty]

I was under the impression that the benefit of unsafe_view was that there was no bounds checking. How is it that using the array directly with bounds checking is as efficient?

Sent from my iPhone

On Jan 30, 2014, at 5:06 AM, Dahua Lin notifications@github.com wrote:

as of the latest master, you are allowed to write view(a) where a is an array.

However, using this view is equal to directly using the array in terms of performance. So it is more sensible to simply use the array itself.

using view makes sense when you want to create a view of a part of the array.

—
Reply to this email directly or view it on GitHub.

[lindahua]

You may now use @inbounds macro to remove bounds checking, as

for i = 1 : n
    @inbounds x[i] = a[i] + b[i]
end

In this way, the bounds checking will be disabled when evaluating the expression. This is the recommended way.

The unsafe_view caches pointer instead of the source array, which may cause subtle problems in cases where the view is passed out of the function and lives longer than the source.

[dlfivefifty]

The @inbounds macros seems to be 2x slower than an unsafe_view.  unsafe_view is presumably fine as long as it is only used locally.

On 30 Jan 2014, at 9:36 am, Dahua Lin notifications@github.com wrote:

You may now use @inbounds macro to remove bounds checking, as

for i = 1 : n
@inbounds x[i] = a[i] + b[i]
end
In this way, the bounds checking will be disabled when evaluating the expression. This is the recommended way.

The unsafe_view caches pointer instead of the source array, which may cause subtle problems in cases where the view is passed out of the function and lives longer than the source.

—
Reply to this email directly or view it on GitHub.