220 32718 article Path: news.gmane.org!.POSTED!not-for-mail From: Bengt Gustafsson Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Why do we include a Matrix and Vector class into the proposed 2D Graphics Library? Date: Sat, 10 Jun 2017 09:02:45 -0700 (PDT) Lines: 383 Approved: news@gmane.org Message-ID: References: <7e3ee19d-f758-4d38-a015-0c474424073d@isocpp.org> <20170609115017.5132345.91153.30981@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1837_1094770179.1497110565946" X-Trace: blaine.gmane.org 1497110571 24692 195.159.176.226 (10 Jun 2017 16:02:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 10 Jun 2017 16:02:51 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCRIRSPDTQIRBJVQ6DEQKGQED4D75YA@isocpp.org Sat Jun 10 18:02:43 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f72.google.com ([209.85.218.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dJiqZ-0005wY-EG for gclcip-std-proposals@m.gmane.org; Sat, 10 Jun 2017 18:02:43 +0200 Original-Received: by mail-oi0-f72.google.com with SMTP id e1sf22440985oig.12 for ; Sat, 10 Jun 2017 09:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=J2I1LHHR9l3x3vS5eVgX9aNoMUOtgrynJZJkxHQKQJo=; b=nHiPsCIRq3jd3aScGfEbCwl5yl1CFcknzgL2Uh7h4S8y8lELnc4vnxImSBmEb+zl2I hbHlyAKa+ekAcqDFAyYgzxk9wixA1OVJ5+FTLrYgvKqzTXSrzkIIsck0gQljauiOLxcU kLOytbq3CpOJlxBAynHlHvz5+HPHPTpU+1kRBaAjcpDXim9EPoy/frmfoeEdIoHkAq93 QkN3nFsOonaIrtBVNCjBwpqav23K/LkcB0A5hEp8Ug2ocG/l9bdHfsEzgwBjqpbKekmH jUa2Zcuf7cUfRp4jj+A6GG6f3L+JV+Iek8+dkmEAIHWeEqAzYvk3MkHwyBy4O42uLKXh PrHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=J2I1LHHR9l3x3vS5eVgX9aNoMUOtgrynJZJkxHQKQJo=; b=VyGCkfmhB7is8ebwMp7ag2T5ep0oHFZXkoQa15UUT5Pe/F9TSfxWiiRsTWe827SjMY v84bor/C7Q6iDO2sK4HiFGT96D9ps42Y7belbmedS//iil+j+osAfgHkeEfxoJQFMJKa I5AY0fWc0fyjISRnmkozpNt3/mGYM9F3nz4sQ7ZKznsv7WTxF0uV3DvjkT9vGXBSJKzW XFyOahsOw3ElswtbTB+IQkH2TreIzBHdQqs5hjA9FYlDqMpneiOi6oVEdKxSiGAhrPH6 ZpG9BCBL1nUZbwltGC9rq5SZtgAFo4FzxOuPhKp/XVopXA4+XvWNd2u9HU5YBMMQs7Hb Yc0Q== X-Gm-Message-State: AODbwcCELxXMkoMloTlzP+8a/FFn83KALbVTrSbrZFXPZIkL/ha2b/wK qIpdJMvp1wDnZB06 X-Received: by 10.157.29.180 with SMTP id y49mr23859165otd.95.1497110568288; Sat, 10 Jun 2017 09:02:48 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.14.242 with SMTP id 105ls11643890otj.0.gmail; Sat, 10 Jun 2017 09:02:46 -0700 (PDT) X-Received: by 10.157.24.54 with SMTP id b51mr1003015ote.14.1497110566749; Sat, 10 Jun 2017 09:02:46 -0700 (PDT) In-Reply-To: <20170609115017.5132345.91153.30981@gmail.com> 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:32718 Archived-At: ------=_Part_1837_1094770179.1497110565946 Content-Type: multipart/alternative; boundary="----=_Part_1838_926903007.1497110565946" ------=_Part_1838_926903007.1497110565946 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable @Jakob: I had the same feeling when reading this proposal: These types=20 should not be part of a graphics library, but instances of a general=20 vocabulary matrix type. There are a couple of requirements to bring back=20 from the 2D graphics proposal: - A vector/matrix type must be possible to instantiate with fixed size. - A 2 element vector should have members named x and y. To my knowledge the closest to a matrix type that has been formally=20 proposed was the array_view template, where N is a rank, so it does= =20 not support fixed sizes. The performance penalty for the non-fixed size=20 would be quite large for a 3x3 matrix, and in addition there was no=20 accompanying type which provided storage in that proposal. This proposal=20 also suffers from the same problem as the 2D graphics proposal: To index=20 and size the matrix it contains its own 1-d types index and bounds. What I would like to see is something similar to Eigen, but more modern.=20 Eigen matrices are templated on the x and y size with a special marker=20 value indicating "variable size" in the respective dimensions. As this=20 library predates variadic templates it supports only vectors and=20 2D-matrices. Still, vectors are matrices with 1 row or column. I argee that a good place to start would be to define some concepts around= =20 this. It is going to be interesting to see if a Concept can be defined that= =20 forces an indexing operator() to take as many integer indices as the rank= =20 of the type under test. Off the top of my head I don't see how to do this,= =20 but then I'm not an expert on concepts. Maybe I will come back with a=20 writeup on this later on, based on the matrix implementation indicated=20 below. -------- I have made a matrix template which fulfills these requirements and I was= =20 contemplating proposing it, but there is still a lot of work to do on this,= =20 for instance how to create views and slices when the fixed or variable size= =20 of both the original matrix bounds and the view bounds complicate how the= =20 indexing calculation is to be optimized. The other question regards if a vocabulary vector type could have named=20 members x, y, (z, ...). This can be done by specialization and I have given= =20 this idea a try. I don't like the idea of having to call a function to get= =20 the indivdual values when the object "feels" like a simple struct. I know= =20 that there are different opinions on this, and this is mine: Keep it simple= =20 to do simple things. The problem is that, although it "works" on decent=20 compilers it seems impossible to get named data members and simultaneously= =20 no-overhead access via an operator[]. Options include an union between=20 scalars and an array and taking the address of x and index off of it, but I= =20 believe that formally these are both UB. (Correct me if I'm wrong!). To fix= =20 this we could a) rewrite the rules of unions/struct member placement to=20 make that behaviour defined, introduce "properties" with hidden=20 setters/getters or introduce a member data aliasing ability such as "using= =20 x =3D _data[0]". Example: union { struct { T x; T y; // Is this guaranteed to be at the same address as _data[1]? }; T _data[2]; }; =20 Den fredag 9 juni 2017 kl. 13:50:21 UTC+2 skrev Tony V E: > > That Matrix class shouldn't be called Matrix at all=E2=80=8E. It should b= e called=20 > something like Transform or affine_transform. It is barely a matrix.=20 > > Vector would be more friendly as 'point' or 'point2D' etc.=20 > > They should all be in a sub namespace, not directly in std, so that we ca= n=20 > make 'real' matrix and vector classes later.=20 > > In my opinion.=20 > > Sent from my BlackBerry portable Babbage Device > *From: *Jakob Riedle=E2=80=8E > *Sent: *Friday, June 9, 2017 7:15 AM > *To: *ISO C++ Standard - Future Proposals > *Reply To: *std-pr...@isocpp.org > *Subject: *[std-proposals] Why do we include a Matrix and Vector class=20 > into the proposed 2D Graphics Library? > > Hello Folks, > > concerning Proposal P0267R1-4=20 > (th= e=20 > proposed 2D Graphics extension): > > Recently stated the question, whether there is any interest in something= =20 > like a matrix/vector/tensor class extension. > The Consensus there was, that because we are confronted with the opinions= =20 > of a bunch of different stakeholders, > we should first approach the concept of Matrices from a "conceptional"=20 > perspective before we even think about a specific implementation. > > That means, we should first come up with a set of *Concepts *that provide= =20 > interfaces for the idea of multidimensional Arrays. > > > Now what is being done in P0267R1-4=20 > is= =20 > the exact opposite of that: > Come up with an arbitrary, highly context dependent Matrix class that is= =20 > not reusable for anyone but the few people that want to work with 2D=20 > Graphics. > > > I have the strong feeling that this is absolutely not desirable from a=20 > standpoint of standardization: > *We want a C++ standard Library that is consistent in itself and does not= =20 > reinvent the wheel for every specific extension it gets.* > > > Please let me know your opinions on this! > > Cheers and have a nice weekend, > Jakob > > --=20 > You received this message because you are subscribed to the Google Groups= =20 > "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to std-proposal...@isocpp.org . > To post to this group, send email to std-pr...@isocpp.org . > To view this discussion on the web visit=20 > https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7e3ee19d-f75= 8-4d38-a015-0c474424073d%40isocpp.org=20 > > . > > --=20 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 e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/b53ee06e-9284-4e82-ab16-6f732ee8e18f%40isocpp.or= g. ------=_Part_1838_926903007.1497110565946 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
@Jakob: I had the same feeling when reading this proposal:= These types should not be part of a graphics library, but instances of a g= eneral vocabulary matrix type. There are a couple of requirements to bring = back from the 2D graphics proposal:

- A vector/matrix ty= pe must be possible to instantiate with fixed size.
- A 2 element= vector should have members named x and y.

To my k= nowledge the closest to a matrix type that has been formally proposed was t= he array_view<T, N> template, where N is a rank, so it does not suppo= rt fixed sizes. The performance penalty for the non-fixed size would be qui= te large for a 3x3 matrix, and in addition there was no accompanying type w= hich provided storage in that proposal. This proposal also suffers from the= same problem as the 2D graphics proposal: To index and size the matrix it = contains its own 1-d types index<N> and bounds<N>.
What I would like to see is something similar to Eigen, but mo= re modern. Eigen matrices are templated on the x and y size with a special = marker value indicating "variable size" in the respective dimensi= ons. As this library predates variadic templates it supports only vectors a= nd 2D-matrices. Still, vectors are matrices with 1 row or column.

I argee that a good place to start would be to define some = concepts around this. It is going to be interesting to see if a Concept can= be defined that forces an indexing operator() to take as many integer indi= ces as the rank of the type under test. Off the top of my head I don't = see how to do this, but then I'm not an expert on concepts. Maybe I wil= l come back with a writeup on this later on, based on the matrix implementa= tion indicated below.


--------<= /div>


I have made a matrix template which= fulfills these requirements and I was contemplating proposing it, but ther= e is still a lot of work to do on this, for instance how to create views an= d slices when the fixed or variable size of both the original matrix bounds= and the view bounds complicate how the indexing calculation is to be optim= ized.

The other question regards if a vocabula= ry vector type could have named members x, y, (z, ...). This can be done by= specialization and I have given this idea a try. I don't like the idea= of having to call a function to get the indivdual values when the object &= quot;feels" like a simple struct. I know that there are different opin= ions on this, and this is mine: Keep it simple to do simple things. The pro= blem is that, although it "works" on decent compilers it seems im= possible to get named data members and simultaneously no-overhead access vi= a an operator[]. Options include an union between scalars and an array and = taking the address of x and index off of it, but I believe that formally th= ese are both UB. (Correct me if I'm wrong!). To fix this we could a) re= write the rules of unions/struct member placement to make that behaviour de= fined, introduce "properties" with hidden setters/getters or intr= oduce a member data aliasing ability such as "using x =3D _data[0]&quo= t;. Example:

union {
=C2=A0 =C2=A0 struc= t {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 T x;
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 T y; =C2=A0 // Is this guaranteed to be at the same address as _= data[1]?
=C2=A0 =C2=A0 };
=C2=A0 =C2=A0 T _data[2];
};


=C2=A0 =C2=A0=C2=A0
=






Den= fredag 9 juni 2017 kl. 13:50:21 UTC+2 skrev Tony V E:
=
T= hat Matrix class shouldn't be called Matrix at all=E2=80=8E. It should = be called something like Transform or affine_transform. It is barely a matr= ix.=C2=A0

Vector would be more friendly as 'point' or 'point2D&= #39; etc.=C2=A0

They should all be in a sub namespace, not directly in std,= so that we can make 'real' matrix and vector classes later.=C2=A0<= /div>

= In my opinion.
= =

= = =
Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2= =A0portable=C2=A0Babbage=C2=A0Device
= = = =
From: Jakob Riedle=E2=80=8E=
Sent: Friday, June 9, 2017 7:15 AM
To: I= SO C++ Standard - Future Proposals
Subject: [std-proposals] Why do we include a Matrix= and Vector class into the proposed 2D Graphics Library?

Hell= o Folks,

concerning Proposal P0267R1-4=C2=A0(the proposed 2D Gr= aphics extension):

Recently stated the question, whether = there is any interest in something like a matrix/vector/tensor class extens= ion.
The Consensus there was, that because we are confronted with= the opinions of a bunch of different stakeholders,
we should fir= st approach the concept of Matrices from a "conceptional" perspec= tive before we even think about a specific implementation.

That means, we should first come up with a set of Concepts = that provide interfaces for the idea of multidimensional Arrays.
=

Now what is being done in=C2=A0P0267R1-4=C2=A0is the= exact opposite of that:
Come up with an arbitrary, highly contex= t dependent Matrix class that is not reusable for anyone but the few people= that want to work with 2D Graphics.


I have the strong feeling that this is absolutely not desirable from a st= andpoint of standardization:
We want a C++ standard Library th= at is consistent in itself and does not reinvent the wheel for every specif= ic extension it gets.


Please le= t me know your opinions on this!

Cheers and have a= nice weekend,
Jakob

--
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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com= /a/isocpp.org/d/msgid/std-proposals/7e3ee19d-f758-4d38-a015-= 0c474424073d%40isocpp.org.

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/b53ee06e-9284-4e82-ab16-6f732ee8e18f= %40isocpp.org.
------=_Part_1838_926903007.1497110565946-- ------=_Part_1837_1094770179.1497110565946-- .