220 11320 article Path: news.gmane.org!not-for-mail From: Bengt Gustafsson Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Comments on n3976 (array_view) Date: Sat, 14 Jun 2014 03:35:35 -0700 (PDT) Lines: 160 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_48_11403427.1402742135919" X-Trace: ger.gmane.org 1402742146 12290 80.91.229.3 (14 Jun 2014 10:35:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Jun 2014 10:35:46 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCRIRSPDTQIRB6GK6COAKGQES7WJK7I@isocpp.org Sat Jun 14 12:35:39 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f197.google.com ([209.85.213.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WvlJC-0001iC-M5 for gclcip-std-proposals@m.gmane.org; Sat, 14 Jun 2014 12:35:38 +0200 Original-Received: by mail-ig0-f197.google.com with SMTP id a13sf4971571igq.4 for ; Sat, 14 Jun 2014 03:35:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=MwxASdB3Z73KIyYEICwerUawaHiPGvRgVN1kPGcuvhs=; b=NPfjTfT1VI1RQdY2xdFwYWb7HryEh03olfTIB0yxnLqx1MQShzdg9gt4xcsLGANR1f aPA9MG7aUEohwFl2zSZG7+mnt1loKdzSA0GPK/bMl1VzuP3eCTsmO9C4APw1QbBB900+ NWrOHtqw8Nq3oKsRil1/Fwc/HT7CkOLLFjo1nDcvHxU13UcK2dk0hJjoxLoIMdK1xxGO QjVo2m9o11/MAwwkliyqKQf7kO1jVSZbD8ZHnI9svqtV52Twr4aakjggstjdrml9hCf4 dlBs4wl+2PZ5+w8l5SRqOdXw4RE11Nk6Bzvg8T732/38KqjPz473NIjLjNlKWbfyG+GO K6Jw== X-Gm-Message-State: ALoCoQkBVAUt82XVYSzkPsx5wlszcaAzhV52LH40lvsucGji+Aa8uct88VsXSYJcQBcpZ2f4w1+Y X-Received: by 10.182.29.1 with SMTP id f1mr3718845obh.23.1402742137341; Sat, 14 Jun 2014 03:35:37 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.24.181 with SMTP id 50ls3777069qgr.92.gmail; Sat, 14 Jun 2014 03:35:36 -0700 (PDT) X-Received: by 10.140.109.199 with SMTP id l65mr1404qgf.32.1402742136607; Sat, 14 Jun 2014 03:35:36 -0700 (PDT) In-Reply-To: X-Original-Sender: bengt.gustafsson@beamways.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:11320 Archived-At: ------=_Part_48_11403427.1402742135919 Content-Type: text/plain; charset=UTF-8 I would like array_view to cater for the case that one or more dimensions is fixed size. This can improve performance by a lot and also provies additional documentation value for functions requiring its data to actually have a certain bound in a particular dimension. I think that the bounds representation used by Eigen could work for array_view too: static const size_t var_dim = -1; template class array_view; The interpretation of this being that for a n dimensional array_view you mention n sizes as template parameters, any of which may be the marker value var_dim which indicates a variable dimension and activates a specialization of the template. I have suggested this system as an extension of the current array<> template to n dimensions previously, see thread https://groups.google.com/a/isocpp.org/forum/#!topicsearch/bengt$20gustafsson/std-proposals/hW2QAvmboqU. As easily seen the current one dimensional, fixed size case fits nicely under this umbrella. The idea was that the variable size specializations of array<> would use a new VLA feature whenever that enters C++. but use the heap in the meantime. Part of the motivation for this upgrade of array was that the std:: namespace is becoming quite cluttered with different "array like" data types, we already have vector, valarray and array and were very close to getting a dynarray recently...and then we still don't have a proper 2 or n-d matrix type. The same reasoning applies to range/view type of classes where there are numerous such non-owning classes being suggested: string_view, array_view, iterator_range etc. If we could restrain ourselves to one or two of these I think this would be a great benefit in the future. array_views with fixed bounds in some dimensions would be (implcitly, anynoe?) convertible to array_views with more variable dimensions. This caters for the case where a non-templated function taking a variable size array_view is called with a fixed size view that maybe was previsouly used to call a template function (making use of teh fixed dimensions). Another comment would be that maybe we could get rid of the strided_array_view variant by tagging one or none dimensions as the "unit stride" dimension (typically but not always the last). So far I haven't figured out how to do this with the "some fixed dimensions" idea I presented myself but for the original proposal it would be quite simple to add another template parameter denoting the unit stride dimension or -1 for none, defaulting to -1 creating a strided_array_view by default, or maybe to 0 for the current behaviour, altough this limits the set of data structures that can be passed to a function with a "naive" parameter type. The lack of a (mathematical) vector type with suitable operations could possibly be solved by applying the above var_dim possibility to valarray: template class valarray; template class valarray; // The current valarray is the specialization for var_dim. valarray provides memberwise operations as well as operations to one scalar T already. More math stuff can be added as functions of course: dot product, length or whatever. I would also prefer if there were specializations for 2 and 3 dimensions where the elements are named x, y and z (for instance using a union with the array). -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_48_11403427.1402742135919 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would like array_v= iew to cater for the case that one or more dimensions is fixed size. This c= an improve performance by a lot and also provies additional documentation v= alue for functions requiring its data to actually have a certain bound in a= particular dimension. I  think that the bounds representation used by= Eigen could work for array_view too:

static const size_t var_dim =3D -1;<= /div>
template<typename T, size_t... Ss> class array_view;
<= div>
The interpretation of this being that for a n dimensiona= l array_view you mention n sizes as template parameters, any of which may b= e the marker value var_dim which indicates a variable dimension and activat= es a specialization of the template.

I have sugges= ted this system as an extension of the current array<> template to n = dimensions previously, see thread = https://groups.google.com/a/isocpp.org/forum/#!topicsearch/bengt$20gustafss= on/std-proposals/hW2QAvmboqU. As easily seen the current one dimensiona= l, fixed size case fits nicely under this umbrella. The idea was that the v= ariable size specializations of array<> would use a new VLA feature w= henever that enters C++. but use the heap in the meantime.

Part of the motivation for this upgrade of array was that the std:= : namespace is becoming quite cluttered with different "array like" data ty= pes, we already have vector, valarray and array and were very close to gett= ing a dynarray recently...and then we still don't have a proper 2 or n-d ma= trix type.

The same reasoning applies to range/vie= w type of classes where there are numerous such non-owning classes being su= ggested: string_view, array_view, iterator_range etc. If we could restrain = ourselves to one or two of these I think this would be a great benefit in t= he future.

array_views with fixed bounds in some d= imensions would be (implcitly, anynoe?) convertible to array_views with mor= e variable dimensions. This caters for the case where a non-templated funct= ion taking a variable size array_view is called with a fixed size view that= maybe was previsouly used to call a template function (making use of teh f= ixed dimensions).

Another comment would be that ma= ybe we could get rid of the strided_array_view variant by tagging one or no= ne dimensions as the "unit stride" dimension (typically but not always the = last). So far I haven't figured out how to do this with the "some fixed dim= ensions" idea I presented myself but for the original proposal it would be = quite simple to add another template parameter denoting the unit stride dim= ension or -1 for none, defaulting to -1 creating a strided_array_view by de= fault, or maybe to 0 for the current behaviour, altough this limits the set= of data structures that can be passed to a function with a "naive" paramet= er type.

The lack of a (mathematical) vector type = with suitable operations could possibly be solved by applying the above var= _dim possibility to valarray:

template<typename= T, size_t Sz> class valarray;

template<type= name T> class valarray<T. var_dim>;  // The current valarray = is the specialization for var_dim.

valarray provid= es memberwise operations as well as operations to one scalar T already. Mor= e math stuff can be added as functions of course: dot product, length or wh= atever.

I would also prefer if there were speciali= zations for 2 and 3 dimensions where the elements are named x, y and z (for= instance using a union with the array).







--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_48_11403427.1402742135919-- .