220 32770 article Path: news.gmane.org!.POSTED!not-for-mail From: FrankHB1989 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: Tue, 13 Jun 2017 21:34:44 -0700 (PDT) Lines: 242 Approved: news@gmane.org Message-ID: References: <7e3ee19d-f758-4d38-a015-0c474424073d@isocpp.org> <4f11ca6c-d24c-4c56-8297-bdbbbc45a517@isocpp.org> <18d7bd61-8c41-d0e5-9691-6defb0dacb21@gmail.com> <293bb74a-165d-46b2-a567-0561ee0a9dbd@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4577_1217275227.1497414884555" X-Trace: blaine.gmane.org 1497414885 23790 195.159.176.226 (14 Jun 2017 04:34:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 14 Jun 2017 04:34:45 +0000 (UTC) Cc: jakob.riedle@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCTJVBPG3QIBBZPZQLFAKGQEDNRZBPY@isocpp.org Wed Jun 14 06:34:41 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f197.google.com ([209.85.192.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dL00u-0005vz-UU for gclcip-std-proposals@m.gmane.org; Wed, 14 Jun 2017 06:34:41 +0200 Original-Received: by mail-pf0-f197.google.com with SMTP id q78sf87798163pfj.9 for ; Tue, 13 Jun 2017 21:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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=/5PHBve4F1ESkdAxzXXrSuOcAECgj8mnz4zibHGLUT4=; b=RrnL+vTNudng5QdoEElU/wO0noB5j6lqb5e2vCXCDRfO1wi+StmvENK/mBzjBt3H7/ eKFi450HYZHRUgqg3YR2YlQn3i5SHh4XQP9SGIrzJN9MjatgBE+AqD4RIl0uXLlMbJ+Z fNUsujZJfKD01X/aU8CRLbW6J8P/aeg5hgVE60DyEty7lgdUhuthKaoRP37g5TgN5L90 LXHD0Gr8Ou9WNl6wwvwAS6aBzua8FUe9JWws0FtB/XNwc5IVbk0QxavFS4ej/EI08m9o 7XB8DldrRLmT5exzo5kebVCT0ue/j9wfC1hEoCqALFvRqIGbnyhjUaRew24gCZ9uzqZa TgEQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc: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=/5PHBve4F1ESkdAxzXXrSuOcAECgj8mnz4zibHGLUT4=; b=h1kjZguHpHerr6yB/QyF++l6aUALtLbjj9LRdxGywzFQPFzqBQY3RSPTFBq1MxAXGH kMeio7k9sBpgE0ob1M5VGwCWGpl9tQCRN+5g5O2hFsnwMCKEFoFOu3IXbPXZzU2fp7Ez +l2XkqWSfUOuZkyyTBzT7vLEBXTPhK0niswXgZRR+Or1uo+GjOVE3rv4hJu97Zj4KiTf ohsL/W1Co+0bdZCHsTPJPZb19SAYWKpBrhtCWKIsuLlMObfYWk9DmhXxF1Ekwu8CLAkq TL28pZuCalcmVmchPJ4bz757k2n/1XpL80ZcY0GR7FH1EqPeYvN7DieACsTXH2x2ijnI MFcQ== 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:cc: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=/5PHBve4F1ESkdAxzXXrSuOcAECgj8mnz4zibHGLUT4=; b=GxYDREVk+gLkro8L8CfeNtNdgY/JHampyOp3gTGc5OEmO+sDq6S50jjyv0XG8IppC4 GPzqk46bdggjs5n7bzHEPnvjS3YhgXVA2MaoLtyAv04xFfoYrNpbi/jN3+5SmYhuzy4l L7kb3ua3VudJwV34O21T9mXn91IXU07URvczrJbp3ed1j6ZqfqysifsqxTN4fkjRTJVs 2LmhMdMjUgMK7wi8HY3sdK6lowQiypKOf3mWl80nXMpII/bLooydPVnUOE8lU5fQhGIx XcY4sfovfa+VI4uyboAWXLgkWWuAc0Xro1LevEpLb3LBl9ziyq/iiHCDZ4APyd6HxpWu YQxQ== X-Gm-Message-State: AKS2vOz7yW/Ajymt7M54jtOoH9VnkoE+dsy3J+4MyuhdTeU230Z6o0Cx fEUt+DeMLZDyK0zb X-Received: by 10.98.196.3 with SMTP id y3mr4018684pff.23.1497414885880; Tue, 13 Jun 2017 21:34:45 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.48.130 with SMTP id s2ls701658otc.47.gmail; Tue, 13 Jun 2017 21:34:45 -0700 (PDT) X-Received: by 10.157.46.21 with SMTP id q21mr42639otb.11.1497414885097; Tue, 13 Jun 2017 21:34:45 -0700 (PDT) In-Reply-To: <293bb74a-165d-46b2-a567-0561ee0a9dbd@isocpp.org> X-Original-Sender: frankhb1989@gmail.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:32770 Archived-At: ------=_Part_4577_1217275227.1497414884555 Content-Type: multipart/alternative; boundary="----=_Part_4578_1568238999.1497414884556" ------=_Part_4578_1568238999.1497414884556 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =E5=9C=A8 2017=E5=B9=B46=E6=9C=8814=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC= +8=E4=B8=8A=E5=8D=883:19:04=EF=BC=8CChet=E5=86=99=E9=81=93=EF=BC=9A > > > > On Tuesday, 13 June 2017 10:55:45 UTC-7, Matthew Woehlke wrote: >> >> On 2017-06-12 07:57, Jakob Riedle wrote:=20 >> > [Note start --=20 >> > We could potentially resurrect std::valarray for that since it has= =20 >> > pretty similar semantics on its operators. We could give it a=20 >> purpose again=20 >> > ;-)=20 >> > We would have to equip it with .x, .y, and .z members and optional= =20 >> fixed=20 >> > size dimensions. Potential Way to do that:=20 >> > std::valarray /* becomes shorthand for */ std::valarray= =20 >> //=20 >> > Note implicit/dynamic extent=20 >> > std::valarray // is a fixed-size valarray=20 >> > std::valarray // could be disallowed by now. Extendable= =20 >> in=20 >> > the future to be a matrix and so on...=20 >> > Then we could standardize e.g.=20 >> > template=20 >> > using point2d =3D std::valarray;=20 >> > template=20 >> > using point3d =3D std::valarray;=20 >> > -- Note end]=20 >> >> `operator*` for std::valarray is not what you want for linear algebra=20 >> types...=20 >> >> > *Templatize the Graphics Library to use arbitrary=20 >> > vector_2d/wsPoint/eigen::vector2i/osg::vec2d as long as they provid= e=20 >> .x and=20 >> > .y=20 >> >> I don't think this would work for Eigen types. Anyway, I'd probably=20 >> rather it worked with:=20 >> >> auto [x, y] =3D vec;=20 >> >> Of course, this means enforcing order, which as some noted we'd rather= =20 >> not do. (I'm not sure I agree with that, however. First, because a type= =20 >> *should* be ordered in the order its dimensions are naturally expressed.= =20 >> For one, this makes it easier to reason about extending or reducing the= =20 >> type to a different number of dimensions. Note, however, that I don't=20 >> think this has any implications how the data is *laid out in memory* if= =20 >> for some reason that's important. Second, because generic algorithms,=20 >> unpacking, etc. are going to implicitly need to make assumptions about= =20 >> the order, and if we try to avoid that, we make the types less usable.)= =20 >> >> --=20 >> Matthew=20 >> > > Existing practice is inconsistent with the ordering.=20 > > =20 > > Example: Northing and Easting, although sometimes reversed, world=20 > coordinates are often presented with Northing first. Northing being Y and= =20 > Easting being X, however this can differ in different geographic regions. > > =20 > It is actually cultural-specific, e.g. in Chinese, Northing almost always= =20 comes first. > I'm not against standardizing the ordering, but doing so should not be=20 > done lightly. > > > Or simply prefer standardizing the method to specify the order instead. -- Chet. > --=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/dead421b-0a51-4e21-aa97-6f401bda946a%40isocpp.or= g. ------=_Part_4578_1568238999.1497414884556 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=E5=9C=A8 2017=E5=B9=B46=E6=9C=8814=E6=97=A5=E6=98= =9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=883:19:04=EF=BC=8CChet=E5=86=99= =E9=81=93=EF=BC=9A


On Tuesday, 13 June 2017 10:55:45 UTC-7, Matthew Woehlke wrot= e:
On 2017-06-12 07:57, Jakob Riedle= wrote:
> =C2=A0 =C2=A0[Note start --
> =C2=A0 =C2=A0We could potentially resurrect std::valarray for that= since it has=20
> =C2=A0 =C2=A0pretty similar semantics on its operators. We could g= ive it a purpose again=20
> =C2=A0 =C2=A0;-)
> =C2=A0 =C2=A0We would have to equip it with .x, .y, and .z members= and optional fixed=20
> =C2=A0 =C2=A0size dimensions. Potential Way to do that:
> =C2=A0 =C2=A0std::valarray<int> /* becomes shorthand for */ = std::valarray<int[]> //=20
> =C2=A0 =C2=A0Note implicit/dynamic extent
> =C2=A0 =C2=A0std::valarray<int[3]> // is a fixed-size valarr= ay
> =C2=A0 =C2=A0std::valarray<int[3][3]> // could be disallowed= by now. Extendable in=20
> =C2=A0 =C2=A0the future to be a matrix and so on...
> =C2=A0 =C2=A0Then we could standardize e.g.
> =C2=A0 =C2=A0template<typename T>
> =C2=A0 =C2=A0using point2d =3D std::valarray<T[2]>;
> =C2=A0 =C2=A0template<typename T>
> =C2=A0 =C2=A0using point3d =3D std::valarray<T[3]>;
> =C2=A0 =C2=A0-- Note end]

`operator*` for std::valarray is not what you want for linear algebra
types...

> *Templatize the Graphics Library to use arbitrary=20
> =C2=A0 =C2=A0vector_2d/wsPoint/eigen::vector2i/osg::vec2d as = long as they provide .x and=20
> =C2=A0 =C2=A0.y

I don't think this would work for Eigen types. Anyway, I'd prob= ably
rather it worked with:

=C2=A0 auto [x, y] =3D vec;

Of course, this means enforcing order, which as some noted we'd rat= her
not do. (I'm not sure I agree with that, however. First, because a = type
*should* be ordered in the order its dimensions are naturally expressed= ..
For one, this makes it easier to reason about extending or reducing the
type to a different number of dimensions. Note, however, that I don'= ;t
think this has any implications how the data is *laid out in memory* if
for some reason that's important. Second, because generic algorithm= s,
unpacking, etc. are going to implicitly need to make assumptions about
the order, and if we try to avoid that, we make the types less usable.)

--=20
Matthew

<= span style=3D"font-size:10pt;font-family:Arial,sans-serif">Existing practic= e is inconsistent with the ordering.=C2=A0

=C2=A0

Example: Northing and Easting, although sometimes rev= ersed, world coordinates are often presented with Northing first. Northing being Y and Easting being X, however this can differ in different geographic regions.

=C2=A0

It is = actually cultural-specific, e.g. in Chinese, Northing almost always comes f= irst.

I'm not against standardizing the ordering, but doing so should not be done lightly.


Or simply prefer stand= ardizing the method to specify the order instead.

-- Chet.

--
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/dead421b-0a51-4e21-aa97-6f401bda946a= %40isocpp.org.
------=_Part_4578_1568238999.1497414884556-- ------=_Part_4577_1217275227.1497414884555-- .