Why do we include a Matrix and Vector class into the proposed 2D Graphics Library?

[Jakob Riedle]

Hello Folks,

concerning Proposal P0267R1-4 (the proposed 2D Graphics extension):

Recently stated the question, whether there is any interest in something like a matrix/vector/tensor class extension.

The Consensus there was, that because we are confronted with the opinions of a bunch of different stakeholders,

we should first approach the concept of Matrices from a "conceptional" perspective 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 P0267R1-4 is the exact opposite of that:

Come up with an arbitrary, highly context 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 standpoint of standardization:

We want a C++ standard Library that is consistent in itself and does not reinvent the wheel for every specific extension it gets.

Please let me know your opinions on this!

Cheers and have a nice weekend,

Jakob

[Tony V E]

That Matrix class shouldn't be called Matrix at all‎. It should be called something like Transform or affine_transform. It is barely a matrix. 

Vector would be more friendly as 'point' or 'point2D' etc. 

They should all be in a sub namespace, not directly in std, so that we can make 'real' matrix and vector classes later. 

In my opinion.

Sent from my BlackBerry portable Babbage Device

From: Jakob Riedle‎ 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 into the proposed 2D Graphics Library?

--
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-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.

[Bengt Gustafsson]

@Jakob: I had the same feeling when reading this proposal: These types should not be part of a graphics library, but instances of a general vocabulary matrix type. There are a couple of requirements to bring back 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 proposed was the array_view<T, N> template, where N is a rank, so it does not support fixed sizes. The performance penalty for the non-fixed size would be quite large for a 3x3 matrix, and in addition there was no accompanying type which 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 more modern. Eigen matrices are templated on the x and y size with a special marker value indicating "variable size" in the respective dimensions. As this library predates variadic templates it supports only vectors and 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 indices 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 will come back with a writeup on this later on, based on the matrix implementation indicated below.

--------

I have made a matrix template which fulfills these requirements and I was contemplating proposing it, but there is still a lot of work to do on this, for instance how to create views and 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 optimized.

The other question regards if a vocabulary 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 "feels" like a simple struct. I know that there are different opinions on this, and this is mine: Keep it simple to do simple things. The problem is that, although it "works" on decent compilers it seems impossible to get named data members and simultaneously no-overhead access via 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 these are both UB. (Correct me if I'm wrong!). To fix this we could a) rewrite the rules of unions/struct member placement to make that behaviour defined, introduce "properties" with hidden setters/getters or introduce a member data aliasing ability such as "using x = _data[0]". Example:

union {

    struct {

        T x;

        T y;   // Is this guaranteed to be at the same address as _data[1]?

    };

    T _data[2];

};

[Nicol Bolas]

On Saturday, June 10, 2017 at 12:02:46 PM UTC-4, Bengt Gustafsson wrote:

@Jakob: I had the same feeling when reading this proposal: These types should not be part of a graphics library, but instances of a general vocabulary matrix type. There are a couple of requirements to bring back 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.

The problem with all this is that, from the perspective of the graphics library, generalizing these things is essentially irrelevant and pointless. Sure, it makes those types more useful for other things, but it doesn't make them more useful for the graphics library.

Having to get a full-fledged vector/matrix library through the committee is a lot harder than just saying, "here's a few types that exist for a narrow purpose". You'd essentially be delaying the standardization of the graphics library for things that have nothing to do with graphics.

Now granted, I don't think the graphics library should be standardized at all, but if it's going to happen, I'd rather not see it delayed due to issues that are tangential to that library's needs.

The only generic issues I think need to be accounted for is the ability to transform these types into `span`s (and therefore defining them explicitly to contain arrays). But that's contingent on standardizing `span` itself.

[Bengt Gustafsson]

Here I think you are totally wrong. A lack of common vocabulary types is in my view a major deterrant from using C++. By providing vocabulary types like a (mathematical) vector and matrix we offer the possibility

for third party library vendors to create libraries that can be used together seamlessly. If C++ had come with a more complete set of vocabulary types long ago we wouldn't have had CString, QString and wxString nor would we have QPoint, wxPoint, eigen::vector2i, osg::vec2d all with the same contents but incompatible. This would have been very helpful to us who use lots of third part libraries to perform complex tasks.

So on this point I say: Better late than never.

As for the graphics2d library I agree that it is too tangential to be standardized but vectors and matrices (preferrably as one n-dimensional template class) are not. With it third party libraries for 2D graphics, 3D graphics, data analysis, image processing, and what not can be used together with less pain, reducing the need to standardize the libraries themselves (possibly with separate sets of such vocabulary types).

[Tony V E]

I don't think there is a disagreement here. We have

1. (Nicol) General vector and matrix should not (or need not) be done within the graphics library

2. (you)‎ General vector and matrix is more important than the graphics library 

OK, so someone needs to propose a general matrix and vector library. 

And that can be looked at separately from the graphics library. 

LEWG might even prioritize it over the graphics library, or, more likely, LEWG will look at both in due process. 

If you are trying to say"'the author(s) of the graphics library should instead spend their time on general matrix and vector", well you are free to suggest that to them, but we are all volunteers - people tend to work on what they feel is important, not what others think is important (rightly or wrongly).

Tony

Sent from my BlackBerry portable Babbage Device

From: Bengt Gustafsson Sent: Saturday, June 10, 2017 2:42 PM

To: ISO C++ Standard - Future Proposals Reply To: std-pr...@isocpp.org

Subject: Re: [std-proposals] Why do we include a Matrix and Vector class into the proposed 2D Graphics Library?

--

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-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/d71c480f-bcd2-4051-9f92-523e3e6fc563%40isocpp.org.

[Nicol Bolas]

On Saturday, June 10, 2017 at 2:42:21 PM UTC-4, Bengt Gustafsson wrote:

Here I think you are totally wrong. A lack of common vocabulary types is in my view a major deterrant from using C++. By providing vocabulary types like a (mathematical) vector and matrix we offer the possibility

for third party library vendors to create libraries that can be used together seamlessly. If C++ had come with a more complete set of vocabulary types long ago we wouldn't have had CString, QString and wxString

C++98 had std::string. That stopped precisely nobody from making those other string types. C++ users have proven that having a "vocabulary type" will stop nobody from making their own. No matter how good that type is, "not invented here" syndrome is strong among us.

That's not to say that we shouldn't have good types. It's just that we shouldn't expect that having good types will prevent people from writing their own.

nor would we have QPoint, wxPoint, eigen::vector2i, osg::vec2d all with the same contents but incompatible. This would have been very helpful to us who use lots of third part libraries to perform complex tasks.

So on this point I say: Better late than never.

Mandatory XKCD. Being late never helps.

Giving standard C++ a good 2D vector type will not cause all of those types to vanish, nor will it cause users of those types to adopt them. Giving C++ a good Unicode string type will not stop people from rolling their own.

Yes, that doesn't mean we shouldn't have them. But we need to have realistic expectations of the results of such things.

[FrankHB1989]

在 2017年6月11日星期日 UTC+8上午9:06:47，Nicol Bolas写道：

On Saturday, June 10, 2017 at 2:42:21 PM UTC-4, Bengt Gustafsson wrote:

Here I think you are totally wrong. A lack of common vocabulary types is in my view a major deterrant from using C++. By providing vocabulary types like a (mathematical) vector and matrix we offer the possibility

for third party library vendors to create libraries that can be used together seamlessly. If C++ had come with a more complete set of vocabulary types long ago we wouldn't have had CString, QString and wxString

C++98 had std::string. That stopped precisely nobody from making those other string types. C++ users have proven that having a "vocabulary type" will stop nobody from making their own. No matter how good that type is, "not invented here" syndrome is strong among us.

That's not to say that we shouldn't have good types. It's just that we shouldn't expect that having good types will prevent people from writing their own.

The type std::string is not provided as a "vocabulary type" at first. It is an instance of std::basic_string. It is already abused for a long time where it is merely expected as a vocabulary type, e.g. in initializing objects of standard exception classes. That can be hard to fix in reality due to ABI compatibility, etc. So, be cautious to introduce new ones, whatever good enough or not. (BTW, std::string is not good enough for many reasons, but most of them come from std::basic_string, which is not relevant here.)

nor would we have QPoint, wxPoint, eigen::vector2i, osg::vec2d all with the same contents but incompatible. This would have been very helpful to us who use lots of third part libraries to perform complex tasks.

So on this point I say: Better late than never.

Mandatory XKCD. Being late never helps.

At least, less troubles to regret, before being widespread.

Giving standard C++ a good 2D vector type will not cause all of those types to vanish, nor will it cause users of those types to adopt them. Giving C++ a good Unicode string type will not stop people from rolling their own.

Yes, that doesn't mean we shouldn't have them. But we need to have realistic expectations of the results of such things.

You still can't guarantee you will have them. In the case of graphics library, such "vocabulary types" are essentially out of the scope. And it can be more difficult to make them "good" as strings, giving users more excuses to reinvent the wheel.

Instead of preventing NIH by adding mandatory types, specify requirements of those types may be more appropriate (except for potential code bloat).

[Dejan Milosavljevic]

This may be considered as off topic!

> OK, so someone needs to propose a general matrix and vector library.

He is one possible vector definition:

 namespace std::_space_to_be_named_

  {

    template< class T,  std::size_t N>

     using vector = std::array<T,N>; // Fixed length vector

  }

This has to be combined with strong typedefs ( when they arrive ), and additional requirements for T ( concepts ).

For matrix things are similar. First we need appropriate container(s) and then typedef(s) in same manner.

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-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d71c480f-bcd2-4051-9f92-523e3e6fc563%40isocpp.org.

--
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-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20170610193134.5132345.14750.31022%40gmail.com.

[Jakob Riedle]

First of all, thank you for all the feedback on this!

I think we can identify consensus on the following problem statement:

• Including something like matrix_2d, vector_2d into the Standard (that is within the namespace std::io2d::*) as proposed by the Graphics 2D Library Extension is rather undesirable.

The solution to this problem however has many variations:

1. Rename matrix_2d to something like affine_transform and vector_2d to something like point_2d.
   Advantages: Graphics 2D LE (Library Extension) is not withheld to be standardized, at least not in the discussed sence. Whether it should be standardized at all is not in scope of this thread.
   Disadvantages: In case a general purpose Matrix/Vector Library should be adpoted at later time,
   we have a significant amount of redundancy between modules. This of course is only the case, given that the general purpose matrix/vector Library
   is expected to represent a strikt superset in functionality of what matrix_2d and vector_2d offer. I think we can expect the latter.
   
   
2. Leave them in the namespace std::io2d::* and deprecate them when the 'real' matrix/vector types arrive.
   I don't think 2D Graphics is that important that we need to introduce this amount of redundancy even if only for a limited amount of time (just IMHO).
   Advantages: We can standardize Graphics 2D as it is (surely only concerning the contents discussed in this thread).
   Disadvantages: We need to deprecate and rewrite also all the methods that now depend upon those types. This is alot of work and a lot of "spam" in future C++ Standard Drafts.
   This also encourages people to use those types. Users should not begin to use something that is expected to deprecate in the next major revision of the standard.
   
   
3. Restrict the Graphics 2D LE to the functionality that doesn't depend on those types.
   Especially vector_2d is tighly coupled with many algorithms and data structures presented in the proposal. I don't think this makes sence.
   Disadvantages: Nothing to reasonably standardize...
   
   
4. Restrict the Graphics 2D LE to the functionality that doesn't depend on matrix_2d.
   Now that could potentially work, but we would need a universal (algebraic) vector functionality first. vector_2d is not universal enough.
   [Note start --
   We could potentially resurrect std::valarray for that since it has pretty similar semantics on its operators. We could give it a purpose again ;-)
   We would have to equip it with .x, .y, and .z members and optional fixed size dimensions. Potential Way to do that:
   
   std::valarray<int> /* becomes shorthand for */ std::valarray<int[]> // Note implicit/dynamic extent
   std::valarray<int[3]> // is a fixed-size valarray
   std::valarray<int[3][3]> // could be disallowed by now. Extendable in the future to be a matrix and so on...
   Then we could standardize e.g.
   
   template<typename T>
   using point2d = std::valarray<T[2]>;
   template<typename T>
   

   using point3d = std::valarray<T[3]>;
   -- Note end]
   Advantages: The 2D Graphics Library can be standardized in the parts that don't depend upon matrix_2d.
   Providing a (algebraic) vector functionality is easier than specifying a whole matrix library, but 
   Disadvantages: we need to keep open the option to extend this vector class to matrixes (and tensors?). That also means, only a part of the Graphics 2D LE can be standardized by now.
   
   
5. Come up with a Matrix/Vector Extension first
   Advantages: Consistency at least across modules of the Standard Library!
   Disadvantages: This takes time and probably delays the 2D Graphics Extension significantly.
   
   
6. Templatize the Graphics Library to use arbitrary vector_2d/wsPoint/eigen::vector2i/osg::vec2d as long as they provide .x and .y
   Templatize the Graphics Library to use arbitrary matrix_2d/eigen::matrix2i/... with the array_ref (P0009r3) proposal
   Disadvantages: Probably a lot of code bloat within the library? Maybe we want to encourage people to use the C++ standard vocabular in favor of their own invented wheels, that is something like a future std::algebraic::matrix/std::algebraic::vector.
   Advantages: We delay the problem of having to provide a vocabulary matrix/vector type to a point in time where we can handle it. Graphics 2D can therefore be partially standardized.

What do you think? Do you want to add something?

I'm personally ok with 5, 6 and 4 (in order of decreasing preference).

Jakob

[Thiago Macieira]

On Monday, 12 June 2017 01:54:52 PDT Dejan Milosavljevic wrote:
> He is one possible vector definition:
>
> namespace std::_space_to_be_named_
> {
> template< class T, std::size_t N>
> using vector = std::array<T,N>; // Fixed length vector
> }
>
> This has to be combined with strong typedefs ( when they arrive ), and
> additional requirements for T ( concepts ).
>
> For matrix things are similar. First we need appropriate container(s) and
> then typedef(s) in same manner.

Where is operator+ for this type going to be defined?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[Dejan Milosavljevic]

> Where is operator+ for this type going to be defined?

Global name space. 'string operator+ (const string& lhs, const string& rhs);' is situated in it.

But this question is for library designers.

My point is: reuse exiting ( or add new if necessary ) containers and make vector/matrix to be strong typedefs.

--
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-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2818656.ZnHkfKFBaa%40tjmaciei-mobl1.

[Thiago Macieira]

On Monday, 12 June 2017 13:22:31 PDT Dejan Milosavljevic wrote:
> Global name space. 'string operator+ (const string& lhs, const string&
> rhs);' is situated in it.
> But this question is for library designers.
>
> My point is: reuse exiting ( or add new if necessary ) containers and make
> vector/matrix to be strong typedefs.

Well, we don't have strong typedefs.

I also don't think it should be a typedef. I think it needs to be a concrete
class that provides extra members. For example, a 2D vector should have
members .x() and .y(). Compare:

auto x = v.x();
auto y = v.y();
some_other_lib_function(x, y, ...);

versus:

auto x = v[0];
auto y = v[1];
some_other_lib_function(x, y, ...);

The second case hardcodes that the x coordinate must come first. It may seem
sensible to you, but there were systems in the past that had a y,x order (the
same way that RGB and BGR exist) and it could make sense for the
implementation to be compatible with that.

Another reason is hardware acceleration: a 3D vector could have 4 elements
instead of 3 and just keep one unused. It also facilitates interoperation with
a 4D vector. See [1] for an example of just such a class.

[1] https://codereview.qt-project.org/#/c/190477/1/src/core/transforms/
vector3d_sse_p.h

[Vishal Oza]

I would like to add another point this discussion.
I think we need 2d-vectors and 2d-matrix classes because they simplifies the mathematical operations involved with 2d graphics. While we rename the 2d-vector as a point, I think this could lead novice users to add 2 point together and get a new point but the mathematical geometry doesn't make sense. This should not replace 2d graphics APIs unlike the stream libraries, but rather a starting point for new C++ user to program 2d and 3d graphics.

[Jakob Riedle]

Vishal Oza:

I would like to add another point this discussion.
I think we need 2d-vectors and 2d-matrix classes because they simplifies the mathematical operations involved with 2d graphics.

Yes, this is part of the problem that we face here.

While we rename the 2d-vector as a point, I think this could lead novice users to add 2 point together and get a new point but the mathematical geometry doesn't make sense.

So do you think renaming vector_2d to point_2d is a bad thing? Please explain yourself a little more in detail, you are depending on a few allusions that you don't explicite. Please do so.

 

This should not replace 2d graphics APIs unlike the stream libraries, but rather a starting point for new C++ user to program 2d and 3d graphics.

Sorry, what has graphics 2D to do with stream libraries, what analogy do you allude to?

Dejan Milosavljevic: 

This may be considered as off topic!

Thiago Macieira:

Where is operator+ for this type going to be defined? 

 

Yes, I would consider this as off topic...  Your part of the conversation is not relevant to what we should do w.r.t issue "Graphics 2D Library Extension".

[Note: I'm not saying it is irrelevant in general]

For me, this thread is about coming up with a set of opinions and conclusions on what should be done with the discussed part of the Graphics 2D Proposal,

NOT to primarily discuss how a Matrix/Vector Library should be implemented (for now at least!).

My Approach is, to first mail the outcomes in this thread to the proposers of the Graphics 2D LE.

If this is not enough, I will try to write a proposal that suggests to rethink the Graphics 2D LE.

What I would like to know is, what solution you would prefer of the ones I proposed 5 messages ago.

Cheers,

Jakob

PS: I know, people - including me - tend to get very creative with the discussions in a particular thread and hence start proposing many Ideas on how we could extend C++ in this and that way,

rather than focusing only on the topic discussed in a particular thread.

In this case, I invite you to do the latter.

[Dejan Milosavljevic]

> What I would like to know is, what solution you would prefer of the ones I proposed 5 messages ago.

Obviously, I am for solution 5 (five).

--
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-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/89116eeb-c58b-4158-aa52-05735b21f9f5%40isocpp.org.

[Matthew Woehlke]

On 2017-06-10 12:58, Nicol Bolas wrote:
> Having to get a full-fledged vector/matrix library through the committee is
> a lot harder than just saying, "here's a few types that exist for a narrow
> purpose". You'd essentially be delaying the standardization of the graphics
> library for things that have nothing to do with graphics.

If we standardize the graphics library as-is, then later introduce
general linear algebra types, we'll end up with people wanting to know
'why the ___ doesn't the graphics API use the standard types?!'.

> Now granted, I don't think the graphics library should be standardized *at
> all*

Yeah. That too :-).

--
Matthew

[Matthew Woehlke]

On 2017-06-10 21:06, Nicol Bolas wrote:
>> If C++ had come with a more complete set of vocabulary types long
>> ago we wouldn't have had CString, QString and wxString
>

> C++98 had std::string. That stopped precisely *nobody* from making those

> other string types. C++ users have proven that having a "vocabulary type"
> will stop nobody from making their own. No matter how good that type is,
> "not invented here" syndrome is strong among us.

While I don't disagree with that, I think that with std::string there
are mitigating factors. Particularly, that C++ core *still* has very
lacking support for i18n (i.e. Unicode). Certainly a major reason for
QString's creation was to have strong support for multilingual text.
These days with most sane platforms defaulting to UTF-8, the situation
isn't *as* bad as before, but remember that QString was created back in
the bad days of having to care about local character sets (or worse,
people assuming ISO-8859 a.k.a. Latin-1).

> Mandatory XKCD <https://xkcd.com/927/>. Being late never helps.

True, but if the recent churn re: Qt's containers is at all meaningful,
there *is* some automatic pressure to gravitate toward the C++-core
standard.

--
Matthew

[Vishal Oza]

Yes I think it is a bad thing rename at least 2dvector to point breaks the math. A point in 2d space (but also in 3d space) is simple a set of coordinates. I think that this could lead to garabage models with no type safety like in C. What does it means to only ad a group of points together without diving the them by a total numbers of point added. That is just a garabage model.

[Thiago Macieira]

A point is identified by a vector and the origin of coordinate.

[Tony V E]

On Tue, Jun 13, 2017 at 1:11 PM, Thiago Macieira <thi...@macieira.org> wrote:

On terça-feira, 13 de junho de 2017 09:55:53 PDT Vishal Oza wrote:
> Yes I think it is a bad thing rename at least 2dvector to point breaks the
> math. A point in 2d space (but also in 3d space) is simple a set of
> coordinates. I think that this could lead to garabage models with no type
> safety like in C. What does it means to only ad a group of points together
> without diving the them by a total numbers of point added. That is just a
> garabage model.

A number is both a position on the number line and a measure (ie distance).

That isn't a garbage model.

Yes, it sometimes makes things ambiguous.  Sometimes you should use wrappers.

A good units library would be nice.

 

A point is identified by a vector and the origin of coordinate.

And since the origin is (almost always) known, point == vector.

[Thiago Macieira]

On terça-feira, 13 de junho de 2017 10:31:40 PDT Tony V E wrote:
> > A point is identified by a vector and the origin of coordinate.
>
> And since the origin is (almost always) known, point == vector.

It's usually implicit, but if we wanted to be pedantic it could be a template
argument, in the same way that std::chrono::time_point is attached to a
specific clock.

[Matthew Woehlke]

On 2017-06-12 07:57, Jakob Riedle wrote:
> [Note start --
> We could potentially resurrect std::valarray for that since it has
> pretty similar semantics on its operators. We could give it a purpose again
> ;-)
> We would have to equip it with .x, .y, and .z members and optional fixed
> size dimensions. Potential Way to do that:
> std::valarray<int> /* becomes shorthand for */ std::valarray<int[]> //
> Note implicit/dynamic extent
> std::valarray<int[3]> // is a fixed-size valarray
> std::valarray<int[3][3]> // could be disallowed by now. Extendable in
> the future to be a matrix and so on...
> Then we could standardize e.g.
> template<typename T>
> using point2d = std::valarray<T[2]>;
> template<typename T>
> using point3d = std::valarray<T[3]>;
> -- Note end]

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

> *Templatize the Graphics Library to use arbitrary

> vector_2d/wsPoint/eigen::vector2i/osg::vec2d as long as they provide .x and
> .y

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

auto [x, y] = vec;

Of course, this means enforcing order, which as some noted we'd rather
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 algorithms,
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.)

--
Matthew

[Chet]

Existing practice is inconsistent with the ordering. 

 

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

 

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

-- Chet.

[Matthew Woehlke]

On 2017-06-13 15:19, Chet wrote:
> Existing practice is inconsistent with the ordering.
>
> Example: Northing and Easting, although sometimes reversed, world
> coordinates are often presented with Northing first. Northing being Y and
> Easting being X, however this can differ in different geographic regions.

Geodesy is *weird* :-). (And I don't just mean the habit of ordering
point values "backwards".)

On a note of amusing coincidence, I committed
https://github.com/Kitware/kwiver/commit/5680fd16db4349e37f1f94896e385b2ab8a22b32
only 19 days ago. (Executive summary: kwiver::vital::geo_point specifies
Easting, Northing storage.)

The previous geo-point type I wrote was not an array, and had members
"northing" and "easting". (Granted, they were in that order.)

IMO, as soon as you have something that can be accessed like an array,
you're going to have users expecting that `p[0]` is the "x" value.

--
Matthew

[FrankHB1989]

在 2017年6月12日星期一 UTC+8下午7:57:33，Jakob Riedle写道：

I'm personally ok with 5, 6 and 4 (in order of decreasing preference).

Jakob

+1.

[FrankHB1989]

在 2017年6月12日星期一 UTC+8下午7:57:33，Jakob Riedle写道：

I'm personally ok with 5, 6 and 4 (in order of decreasing preference).

Jakob

+1.

[FrankHB1989]

在 2017年6月14日星期三 UTC+8上午3:19:04，Chet写道：

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

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

Or simply prefer standardizing the method to specify the order instead.

-- Chet.

[FrankHB1989]

在 2017年6月14日星期三 UTC+8下午12:34:44，FrankHB1989写道：

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

:( typo, I meant almost never.

[Jakob Riedle]

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

Yeah, that's true, at least not for matrices. But valarray is TMK expected to be used with a non-array type T (although not explicitely stated in the standard).

My Idea was simple to alter the semantics of operator* in case type T is a two-dimensional Array Type (e.g. int[3][3]) to represent matrix multiplication.

[Klaim - Joël Lamotte]

On 13 June 2017 at 19:31, Tony V E <tvan...@gmail.com> wrote:

 

A point is identified by a vector and the origin of coordinate.

And since the origin is (almost always) known, point == vector.

If you have a Point and want a translated Point from this original point,

you need an origin and a vector to do the translation. Even when

the first point is implicitely considered the origin, you still need a vector

to describe the translation. The vector does not represent a point.

Assuming that point == vector is like assuming that a physical position is also a physical momentum.

It's just incorrect (like time_point is not a duration).

Joël Lamotte

[Tony V E]

It is not incorrect. Mathematicians have been doing it for hundreds of years. 

It can, however, lead to incorrect code, if used incorrectly. 

But there are also advantages to it. 

It's a trade off.

Sent from my BlackBerry portable Babbage Device

From: Klaim - Joël Lamotte Sent: Friday, June 16, 2017 11:06 AM To: std-pr...@isocpp.org Reply To: std-pr...@isocpp.org Subject: Re: [std-proposals] Re: Why do we include a Matrix and Vector class into the proposed 2D Graphics Library?

--
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-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/CAOU91OOMYLL%2BhriPpGF_Py6AQ4gX2i6%3DjkL5kRR4URM7Aj1Xgg%40mail.gmail.com.

[Dejan Milosavljevic]

> It's just incorrect (like time_point is not a duration).

Excellent example.

Vector(mathematics) can be defined as set(mathematics) of oriented line segments which have same direction and length.

See: https://en.wikipedia.org/wiki/Euclidean_vector.

For easy manipulation we use one represent from this set. This represent can be presented by using same data structure( c++ ) as point.

point=vector+point; //!< OK

point=point+vector; //!< OK

vector=vector+vector; //!< OK

???=point+point; //!< Nonsense

On Sat, Jun 17, 2017 at 12:42 PM, Tony V E <tvan...@gmail.com> wrote:

It is not incorrect. Mathematicians have been doing it for hundreds of years. 

It can, however, lead to incorrect code, if used incorrectly. 

But there are also advantages to it. 

It's a trade off.

Sent from my BlackBerry portable Babbage Device

From: Klaim - Joël Lamotte Sent: Friday, June 16, 2017 11:06 AM To: std-pr...@isocpp.org Reply To: std-pr...@isocpp.org Subject: Re: [std-proposals] Re: Why do we include a Matrix and Vector class into the proposed 2D Graphics Library?

On 13 June 2017 at 19:31, Tony V E <tvan...@gmail.com> wrote:

 

A point is identified by a vector and the origin of coordinate.

And since the origin is (almost always) known, point == vector.

If you have a Point and want a translated Point from this original point,

you need an origin and a vector to do the translation. Even when

the first point is implicitely considered the origin, you still need a vector

to describe the translation. The vector does not represent a point.

Assuming that point == vector is like assuming that a physical position is also a physical momentum.

It's just incorrect (like time_point is not a duration).

Joël Lamotte

--
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-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91OOMYLL%2BhriPpGF_Py6AQ4gX2i6%3DjkL5kRR4URM7Aj1Xgg%40mail.gmail.com.

--
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-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20170617104237.5132345.12582.31348%40gmail.com.