This is the mail archive of the gsl-discuss@sourceware.org mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GSL 2.0 roadmap (one man's view)


On Mon, 2009-09-07 at 16:06 +0100, Brian Gough wrote:
> At Thu, 27 Aug 2009 17:15:39 -0600,
> Gerard Jungman wrote:
> >   The important notion of slicing is (partially) implemented in GSL
> >   in terms of the "view" concept. One can construct submatrices as
> >   views of given matrices, change the stride of vector data by
> >   creating vector views, etc. But there are clear flaws in the
> >   design. The design does not express the obvious idea that
> >   a "view" is itself a "thing", simply because the view classes
> >   do not have an inheritance relationship to the main classes.
> 
> I agree that the scheme is not as elegant as it could be in other
> languages.  The view types are forced by the nature of const in C --
> it's not possible to place the views and vectors/matrices on an equal
> footing and preserve constness, unfortunately.  If there is a way
> round that, I'm not aware of it.

> Originally a view was essentially a vector with another name, but
> there was no barrier to writing expressions which discarded constness
> without any complaint from the compiler.  To prevent that in C, the
> type had to be "wrapped" in a struct which is why one has to write
> &view.vector or &view.matrix to access it.


I really don't understand this. In my head, I can see a solution
which has nothing to do with const-ness issues. I think it would
just work. I could type it in and we could look at it. It definitely
involves changing the way vector and matrix are done, but I don't
think it would be a big hairy deal.


On Mon, 2009-09-07 at 14:21 -0400, Robert G. Brown wrote:
>
> The biggest issue would/will probably be rationalizing the views of
> vector and matrix so they are sufficiently portable and easy to e.g.
> pass in and out of ODE solvers and everything else consistently.

This is right to the point. It's exactly what I'm getting at.
There is just something brain-damaged about the way it is done now.

--
G. Jungman



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]