Ah yes, this looks like a good solution (if one cares about the read
property of arrays...)
Am Donnerstag, 14. August 2014 12:44:47 UTC+2 schrieb Tim Holy:
>
> I think mine is the same as his: he suggested implementing a function fn
> like
> this:
>
> function fn(a::AbstractArray{Int,1})
> a = readonly(a)
> ...
> end
>
> which does that wrapping inside the function itself. I was just pointing
> out
> that you need only one new type to wrap any AbstractArray, not one new
> wrapper
> per AbstractArray type.
>
> Naturally, in that proposal "a = readonly(a)" destroys type stability, but
> the
> standard Julian solution
>
> function fn(a::ReadOnlyArray{Int,1})
> # implement the real fn
> end
> fn(a::AbstractArray) = fn(readonly(a))
>
> solves this, while also having the advantage of advertising the existence
> of a
> direct read-only implementation.
>
> --Tim
>
>
> On Thursday, August 14, 2014 03:31:58 AM Tobias Knopp wrote:
> > I second that I knew a lot more people doing scientific computing with
> > Matlab/Python.
> > And of those few that use C++ only a minority knows (and cares) how to
> > write const aware code...
> >
> > To your solution, Tim: I think Steve wants to hide this in the function
> so
> > that regular arrays can be passed. In your version a Wrapper type has to
> be
> > created before calling the function.
> >
> > Cheers,
> >
> > Tobi
> >
> > Am Donnerstag, 14. August 2014 11:54:15 UTC+2 schrieb Tim Holy:
> > > For any algorithm that accepts AbstractArrays, can't you just just
> define
> > >
> > > immutable ReadOnlyArray{T,N,AT<:AbstractArray} <: AbstractArray{T,N}
> > >
> > > data::AT
> > >
> > > end
> > > ReadOnlyArray{AT<:AbstractArray}(A::AT) =
> > > ReadOnlyArray{eltype(A),ndims(A),typeof(A)}(A)
> > >
> > > and then define the pass-through methods you want to support? That way
> can
> > > wrap
> > > any array type.
> > >
> > >
> > > Also, you could easily create your own package that does this. I don't
> see
> > > any
> > > particular requirement to have it in base.
> > >
> > >
> > > One nit: can you really support your assertion that C++ and Fortran
> are
> > > the
> > > two major languages of scientific computing? In my world, Matlab is
> used
> > > by
> > > about 20x (maybe 50x) as many people as C++. I suspect there's a major
> > > divide
> > > depending on field. Science is a big place.
> > >
> > > --Tim
> > >
> > > On Wednesday, August 13, 2014 03:19:36 PM [email protected]
> > >
> > > <javascript:> wrote:
> > > > Dear Julia colleagues,
> > > >
> > > > In June, I wondered on this newsgroup why Julia lacks an 'inarg'
> > > > specification for functions. The two major languages used nowadays
> for
> > > > scientific programming, namely Fortran and C++, both provide
> mechanisms
> > >
> > > to
> > >
> > > > declare that a function argument is read-only by the function.
> Indeed,
> > > > this was added to Fortran late in its life, so one assumes that
> there is
> > > > some bitter experience underlying the decision to include it in
> Fortran.
> > > >
> > > > (Matlab has only inargs, at least until you get to relatively
> advanced
> > > >
> > > > programming techniques, so this is not an issue.)
> > > >
> > > > Stefan Karpinski provided a convincing explanation for why inarg and
> > >
> > > outarg
> > >
> > > > specifications have been omitted from the Julia core. Now that I am
> > > > slightly more familiar with Julia, I would like to make a proposal
> for
> > > > inarg that would not require changes to the core language. The
> proposal
> > > > would, however, entail substantial additional code, so it is
> intended
> > >
> > > for
> > >
> > > > some version of Julia in the future.
> > > >
> > > > Here is the proposal: suppose fn is a function that takes an array
> input
> > > > "a" and wants to declare it to be read-only. Then at the beginning
> of
> > >
> > > the
> > >
> > > > function before any of the arguments gets used, there would be an
> > > > assignment statement like this:
> > > >
> > > > function fn(a::AbstractArray{Int,1})
> > > > a = readonly(a)
> > > >
> > > > The way this would work is as follows: Julia would have new types,
> > >
> > > mostly
> > >
> > > > invisible to the user, like ReadOnlyArray which would have a
> setindex!
> > > > method that would throw an error, Then there would be methods like
> > > > readonly{T.N}(a::Array{T,N}) that would use 'reinterpret' to change
> the
> > > > Array to a ReadOnlyArray. A programmer who wanted to write a
> function
> > >
> > > that
> > >
> > > > could take either arrays or readonlyarrays as inputs would have to
> > >
> > > declare
> > >
> > > > abstract argument types like DenseArray or AbstractArray. The user
> > >
> > > would
> > >
> > > > not, in general, have to worry about the read-only types; the
> situation
> > > > when a user would have to worry about them is if he/she wants to
> develop
> > >
> > > a
> > >
> > > > read-only version of his/her own data structure that internally uses
> the
> > > > standard containers.
> > > >
> > > > This proposal has several advantages:
> > > >
> > > > (1) The above mechanism enforces the read-only property of a since
> fn no
> > > > longer has access to the initial (writeable) definition of a.
> > > >
> > > > (2) The above mechanism, if adopted as an idiom, could be easily
> spotted
> > >
> > > by
> > >
> > > > program analysis tools that could then make optimizations based on
> the
> > >
> > > fact
> > >
> > > > that a is read-only.
> > > >
> > > > (3) There is hardly any performance penalty for this mechanism.
> > > >
> > > > But obviously there is one big disadvantage:
> > > >
> > > > (1) For each of the standard containers, a new read-only version
> would
> > >
> > > have
> > >
> > > > to be written. Furthermore, there would also have to be an abstract
> > >
> > > type
> > >
> > > > to serve as a common parent. E.g. there is currently no abstract
> parent
> > > > for Set (although there is an open discussion about that matter on
> > >
> > > github).
> > >
> > > > and a second minor disadvantage
> > > >
> > > > (2) The enforcement of read-only would probably would not work
> > >
> > > recursively,
> > >
> > > > e.g., if a were an array of arrays. In fact C++ has a similar gap
> in
> > >
> > > its
> > >
> > > > 'const' mechanism.
> > > >
> > > > -- Steve Vavasis
>
>
