Date: Tue, 13 Aug 2019 12:38:17 -0400
Hi all, I had made mistakes attributing the correct speakers to the notes.
Thanks to Graham Lopez who helped me with the corrections. All mistakes are
still mine. In general, I am advised to not attribute names anymore to
meeting notes going forward so maintain ISO compliance especially in this
public forum..
These replace the previous minutes. Thanks.
Bob Steagall
Mark Hoemann
Javier Cabezas
Jayesh Badwail
Klaus Iglberger
Mateusz Nowak
Matthew BUtler
Richard Dosselmann
William Tambellini
Michael Wong
Cem Bassoy
Nevin Liber
Graham Lopez
Jens Maurer
BS: discussion with Christian David Jayesh, Bob
had lunch for collaboration
working implementation mdspan and mdarray, and is aiming to create a test
implementation
Guy and Bob feels it is a complimentary proposal
DOE proposal is a layer upon which Bob/Guy one can be
ship vehicle for Bob/Guy aiming for C++23
MH: Mark will want to aim for C++23
public github repo from DOE LA
MH: DOE proposal
LEWGi: come back after exploring concepts and ranges
instead of using concrete type
ranges and lazy evaluation
uncomfortable writing an expression template library
due to caution from Eigen
Mdspan is not owning
expression template hard sell to the committee due to valarray
valarray was abandoned by original author, when David proposed full
expression template treatment for it,
P1674 talked about this
interest in lazy evaluation in ranges style, this can solve problems with
arbitrary arithmetic evaluation witout multiple passes
this solves it for large class Blas-1, but still cannot fuse the matri and
matrix multiply
even if we dont ship expression template library in the future
they build their expression template ontop of blas
KI: scale a vector with an expression template, so where do you set your
boundary, where do you support view? yes we debated this a lot, we just
want to introduce it and see where people go with it
major complaint to Blas is it takes too many arguments
KI:where you draw the line with transforming view: 0 layer is a drop in
replacement for at least what existign Blas has, and not preclude that; but
still need transform and scale to do what existign Blas can do
We were also thining of ways to reduce the number of arguments with BLAS
KI: But in your proposal I think there is one part where you were trying to
do more. What part should we expand? scale with 2 positions ..; yes we
have an alpha nad beta so I think it is there
KI: Is that for matrix vector? Yes, where you can have the plus y at the
end. Yes I thought that was a bit of extending, but I like it; ok it is in
GEMV
The only difference in functionality is that alpha nad beta means different
There would not be ABI problems in future as we are changign the accessor
policy for mdspan
A triangular matrix is not an accessor
BS: Bob/Guy proposal:
returnig temporaries, expression templates, we are neutral on this, provdie
an interface for implementator to decide
our interface can adopt for the future inclusing of expression templates,
MW: what games deveoper do - either proposal will work well to gamer
MW: will solver be part of the proposal: neither will support solver
BS: if you want customized operator, what is the complexity? If allowed
this customization, they may not take the best advantage as possible
Andrew Lumsdaine mentioned that we shoudl think in terms of algorithms,
concepts first, that we should not get ahead of the game
my thinking is to use the imperfect analogy of standard algorithm and
containers, 1673 has wrapper aroudn blas which are algo, mdspan is iterator
to provide access to data, matrix type holds the data
we created mdarray as a view cannot create a matrix, so mdarray, then we
need a way to iterate over them
this is actually a good analogy
single vector type vs row and column vector, havng a seingle vector type is
messy, from c++now and Klaus also mentioned this
wait until LEWG review to decide on this
KI: Klaus believes we can expresss thing better with 2 different vector
types, this keeps it more generic, inner or outer allow people to do more
things
also believe this helps people to debug their code more easily, at compile
you can detect it and 2 vector types helps that
MH: when people do outer product, they are really aiming for a matrix
update,
so its not like you dont need it, but it is a different context for inner
product
GL: What are the situation beside multiplication that you wan tto
differentiate? expand is generic, row vector into a row matrix, or column
to column matrix, 2 different functions is not generic
the more generic the operations are the better I can express the things I
want to have
for multiplication and expand, could impose a cognitive overhead for most
situation (other then these), so this could make it harder to decide which
to use
also dividing the type into row and column does not cover the degeneracy,
now you can describe 2 different kinds of multiplication but I can think of
5 different kinds of multiplication like permutation expand
GL: are you sure in future we dont need 2 different kinds of vectors?
mathematically never need 2 types of vector, can always express with one
type of vector
e.g. a dot product is different then an outer product? yes vectors are
objects and you do operations on them, mathematically are not coupled ways,
I am worry that in math we never talk about row and column vectors
MH: some people talk about covariance and contravariance?
GL: yes but that does
not say much about their orientation in space and in most cases I dont care
about the type differentiation
BS: by imposing 2 different types, we use the language to impose a
specification we want, its like shapes squares and rectangles
??: dont believe this is significant cognitive overload, people are already
exposed to but at advanced level
JM: a slightly more abstract question, both proposals are forwarded to LEWG
both libraries are not small, will they have enough expertise
games use 3-d vectors
B/G proposal: uses fixed sized can be hand coded SSD, while dynamically
sized can be more BLAS like things
1673 has a lot of in out parameters so how is this passe thorugh vector, so
a vector x scalar operation will be done in register
DOE proposal thinks can be done in mdarray, in/out as a reference parameter
may not be current convention, a ref is a ptr to memory internally
What Jens is concerned how many thing you can return in register
MW: can we show same examples with both interface
or qualities comparison (though this could be dangerous)
not trying for a runoff but to support your claim that these are
complimentary and could build on top of each other
mdspan can have more then 2 orders, while B/G proposal has submatrixes with
2 dimensions like a view
MH: left off batch linear algebra
JM: remember the valarray, afraid of having deadcode
1673 is in markdown, should be html or pdf
BS: Michael Parks has a system for creating standards paper, whch starts
with markdown and change to tex and pdf
wg21 document creator
LM: 1673 is an updating matrix vector product, has 2 declarations shown
before going on with requires, why? I forgot to delete the first
declaration, the execution policy should not to be there
all uses of execution policy were for algo, now using matrices or vectors,
can mdspan skip? yes it is polymorphic on the unique layout: mapping from 2
dim to 1 dim is 1-1
symmetric is an example as in if you want to multiply all with scalar
at the end of proposal is a reason for thin blas, this is important for
floating point accuracy, where I use a class scalar template argument.
But if I want a better guarantee, does it tell me it is a scalar type? dot
can have intermediate storage, but does not say the evaluation accuracy
we would like dot and dotc to use ...
If you go for vector and matrix then have a dot product taking a scalar,
i.e.e separate dot product is a good thing: one function that does both in
a single pass
thinks plain C++ wrapper around Blas may not deliver enough
is it really interesting to have the low level as well? Vendors like to
have it this low, vendors want even lower
if this is just to add this bag of LA algorithm, is that still not C++
enough? Yes
yes Mathias Kretz was in SG14 on SIMD question and it may be orthogonal,
then if all else fails then we need
not trying for tensor library
Lewgi also interested multidimensional ranges
see a lot of unconstraint template parameters: new library needs concepts:
But LEWG has not settled on that yet, because once set they are hard to
change.
These Algorithms take concrete types
Runtime parameter of this is bad, we actually have a layout called
transpose view that abstract away so if you intend to call the BLAS that
is what you have to do
Dot product has both conjugated and non conjugated, this is a good example
where you should make a better effort to return things by value instead of
scalar, similar to std:accumulate; but reduce is not order dependent
On Thu, Aug 8, 2019 at 9:34 AM Michael Wong <fraggamuffin_at_[hidden]> wrote:
> Bob Steagall
> Mark Hoemann
> Javier Cabezas
> Jayesh Badwail
> Klaus Iglberger
> Mateusz Nowak
> Matthew BUtler
> Richard Dosselmann
> William Tambellini
> Michael Wong
> Cem Bassoy
> Nevin Liber
> Graham Lopez
> Jens Maurer
>
> BS: discussion with Christian David Jayesh, Bob
> had lunch for collaboration
> working implementation mdspan and mdarray, and is aiming to create a test
> implementation
> Guy and Bob feels it is a complimentary proposal
> DOE proposal is a layer upon which Bob/Guy one can be
> ship vehicle for Bob/Guy aiming for C++23
> MH: Mark will want to aim for C++23
> public github repo from DOE LA
>
> MH: DOE proposal
> LEWGi: come back after exploring concepts and ranges
> instead of using concrete type
> ranges and lazy evaluation
> uncomfortable writing an expression template library
> due to caution from Eigen
> Mdspan is not owning
> expression template hard sell to the committee due to valarray
> valarray was abandoned by original author, when David proposed full
> expression template treatment for it,
> P1674 talked about this
> interest in lazy evaluation in ranges style, this can solve problems with
> arbitrary arithmetic evaluation witout multiple passes
> this solves it for large class Blas-1, but still cannot fuse the matri and
> matrix multiply
> even if we dont ship expression template library in the future
> they build their expression template ontop of blas
> KI: scale a vector with an expression template, so where do you set your
> boundary, where do you support view? yes we debated this a lot, we just
> want to introduce it and see where people go with it
> major complaint to Blas is it takes too many arguments
> KI:where you draw the line with transforming view: 0 layer is a drop in
> replacement for at least what existign Blas has, and not preclude that; but
> still need transform and scale to do what existign Blas can do
> We were also thining of ways to reduce the number of arguments with BLAS
> KI: But in your proposal I think there is one part where you were trying
> to do more. What part should we expand? scale with 2 positions ..; yes we
> have an alpha nad beta so I think it is there
> KI: Is that for matrix vector? Yes, where you can have the plus y at the
> end. Yes I thought that was a bit of extending, but I like it; ok it is in
> GEMV
> The only difference in functionality is that alpha nad beta means different
> There would not be ABI problems in future as we are changign the accessor
> policy for mdspan
> A triangular matrix is not an accessor
>
>
> BS: Bob/Guy proposal:
> returnig temporaries, expression templates, we are neutral on this,
> provdie an interface for implementator to decide
> our interface can adopt for the future inclusing of expression templates,
>
> MW: what games deveoper do - either proposal will work well to gamer
> MW: will solver be part of the proposal: neither will support solver
>
> BS: if you want customized operator, what is the complexity? If allowed
> this customization, they may not take the best advantage as possible
> Andrew Lumsdaine mentioned that we shoudl think in terms of algorithms,
> concepts first, that we should not get ahead of the game
> my thinking is to use the imperfect analogy of standard algorithm and
> containers, 1673 has wrapper aroudn blas which are algo, mdspan is iterator
> to provide access to data, matrix type holds the data
> we created mdarray as a view cannot create a matrix, so mdarray, then we
> need a way to iterate over them
> this is actually a good analogy
> single vector type vs row and column vector, havng a seingle vector type
> is messy, from c++now and Klaus also mentioned this
> wait until LEWG review to decide on this
> KI: Klaus believes we can expresss thing better with 2 different vector
> types, this keeps it more generic, inner or outer allow people to do more
> things
> also believe this helps people to debug their code more easily, at compile
> you can detect it and 2 vector types helps that
> when people do outer product, they are really aiming for a matrix update,
> so its not like you dont need it, but it is a different context for inner
> product
> What are the situation beside multiplication that you wan tto
> differentiate? expand is generic, row vector into a row matrix, or column
> to column matrix, 2 different functions is not generic
> the more generic the operations are the better I can express the things I
> want to have
> for multiplication and expand, could impose a cognitive overhead for most
> situation (other then these), so this could make it harder to decide which
> to use
> also dividing the type into row and column does not cover the degeneracy,
> now you can describe 2 different kinds of multiplication but I can think of
> 5 different kinds of multiplication like permutation expand
> GL: are you sure in future we dont need 2 different kinds of vectors?
> mathematically never need 2 types of vector, can always express with one
> type of vector
> e.g. a dot product is different then an outer product? yes vectors are
> objects and you do operations on them, mathematically are not coupled ways,
> I am worry that in math we never talk about row and column vectors
> MH: some people talk about covariance and contravariance? yes but that
> does not say much about their orientation in space and in most cases I dont
> care about the type differentiation
> by imposing 2 different types, we use the language to impose a
> specification we want, its like shapes squares and rectangles
> GL: dont believe this is significant cognitive overload, people are
> already exposed to but at advanced level
>
> JM: a slightly more abstract question, both proposals are forwarded to LEWG
> both libraries are not small, will they have enough expertise
> games use 3-d vectors
> B/G proposal: uses fixed sized can be hand coded SSD, while dynamically
> sized can be more BLAS like things
> 1673 has a lot of in out parameters so how is this passe thorugh vector,
> so a vector x scalar operation will be done in register
> DOE proposal thinks can be done in mdarray, in/out as a reference
> parameter may not be current convention, a ref is a ptr to memory internally
> What Jens is concerned how many thing you can return in register
>
> MW: can we show same examples with both interface
> or qualities comparison (though this could be dangerous)
> not trying for a runoff but to support your claim that these are
> complimentary and could build on top of each other
> mdspan can have more then 2 orders, while B/G proposal has submatrixes
> with 2 dimensions like a view
> MH: left off batch linear algebra
>
> JM: remember the valarray, afraid of having deadcode
> 1673 is in markdown, should be html or pdf
> BS: Michael Parks has a system for creating standards paper, whch starts
> with markdown and change to tex and pdf
> wg21 document creator
>
> LM: 1673 is an updating matrix vector product, has 2 declarations shown
> before going on with requires, why? I forgot to delete the first
> declaration, the execution policy should not to be there
> all uses of execution policy were for algo, now using matrices or vectors,
> can mdspan skip? yes it is polymorphic on the unique layout: mapping from 2
> dim to 1 dim is 1-1
> symmetric is an example as in if you want to multiply all with scalar
>
> at the end of proposal is a reason for thin blas, this is important for
> floating point accuracy, where I use a class scalar template argument.
> But if I want a better guarantee, does it tell me it is a scalar type? dot
> can have intermediate storage, but does not say the evaluation accuracy
> we would like dot and dotc to use ...
> If you go for vector and matrix then have a dot product taking a scalar,
> i.e.e separate dot product is a good thing: one function that does both in
> a single pass
>
> thinks plain C++ wrapper around Blas may not deliver enough
> is it really interesting to have the low level as well? Vendors like to
> have it this low, vendors want even lower
> if this is just to add this bag of LA algorithm, is that still not C++
> enough? Yes
> yes Mathias Kretz was in SG14 on SIMD question and it may be orthogonal,
> then if all else fails then we need
> not trying for tensor library
> Lewgi also interested multidimensional ranges
> see a lot of unconstraint template parameters: new library needs concepts:
> But LEWG has not settled on that yet, because once set they are hard to
> change.
> These Algorithms take concrete types
> Runtime parameter of this is bad, we actually have a layout called
> transpose view that abstract away so if you intend to call the BLAS that
> is what you have to do
>
> Dot product has both conjugated and non conjugated, this is a good example
> where you should make a better effort to return things by value instead of
> scalar, similar to std:accumulate; but reduce is not order dependent
>
Thanks to Graham Lopez who helped me with the corrections. All mistakes are
still mine. In general, I am advised to not attribute names anymore to
meeting notes going forward so maintain ISO compliance especially in this
public forum..
These replace the previous minutes. Thanks.
Bob Steagall
Mark Hoemann
Javier Cabezas
Jayesh Badwail
Klaus Iglberger
Mateusz Nowak
Matthew BUtler
Richard Dosselmann
William Tambellini
Michael Wong
Cem Bassoy
Nevin Liber
Graham Lopez
Jens Maurer
BS: discussion with Christian David Jayesh, Bob
had lunch for collaboration
working implementation mdspan and mdarray, and is aiming to create a test
implementation
Guy and Bob feels it is a complimentary proposal
DOE proposal is a layer upon which Bob/Guy one can be
ship vehicle for Bob/Guy aiming for C++23
MH: Mark will want to aim for C++23
public github repo from DOE LA
MH: DOE proposal
LEWGi: come back after exploring concepts and ranges
instead of using concrete type
ranges and lazy evaluation
uncomfortable writing an expression template library
due to caution from Eigen
Mdspan is not owning
expression template hard sell to the committee due to valarray
valarray was abandoned by original author, when David proposed full
expression template treatment for it,
P1674 talked about this
interest in lazy evaluation in ranges style, this can solve problems with
arbitrary arithmetic evaluation witout multiple passes
this solves it for large class Blas-1, but still cannot fuse the matri and
matrix multiply
even if we dont ship expression template library in the future
they build their expression template ontop of blas
KI: scale a vector with an expression template, so where do you set your
boundary, where do you support view? yes we debated this a lot, we just
want to introduce it and see where people go with it
major complaint to Blas is it takes too many arguments
KI:where you draw the line with transforming view: 0 layer is a drop in
replacement for at least what existign Blas has, and not preclude that; but
still need transform and scale to do what existign Blas can do
We were also thining of ways to reduce the number of arguments with BLAS
KI: But in your proposal I think there is one part where you were trying to
do more. What part should we expand? scale with 2 positions ..; yes we
have an alpha nad beta so I think it is there
KI: Is that for matrix vector? Yes, where you can have the plus y at the
end. Yes I thought that was a bit of extending, but I like it; ok it is in
GEMV
The only difference in functionality is that alpha nad beta means different
There would not be ABI problems in future as we are changign the accessor
policy for mdspan
A triangular matrix is not an accessor
BS: Bob/Guy proposal:
returnig temporaries, expression templates, we are neutral on this, provdie
an interface for implementator to decide
our interface can adopt for the future inclusing of expression templates,
MW: what games deveoper do - either proposal will work well to gamer
MW: will solver be part of the proposal: neither will support solver
BS: if you want customized operator, what is the complexity? If allowed
this customization, they may not take the best advantage as possible
Andrew Lumsdaine mentioned that we shoudl think in terms of algorithms,
concepts first, that we should not get ahead of the game
my thinking is to use the imperfect analogy of standard algorithm and
containers, 1673 has wrapper aroudn blas which are algo, mdspan is iterator
to provide access to data, matrix type holds the data
we created mdarray as a view cannot create a matrix, so mdarray, then we
need a way to iterate over them
this is actually a good analogy
single vector type vs row and column vector, havng a seingle vector type is
messy, from c++now and Klaus also mentioned this
wait until LEWG review to decide on this
KI: Klaus believes we can expresss thing better with 2 different vector
types, this keeps it more generic, inner or outer allow people to do more
things
also believe this helps people to debug their code more easily, at compile
you can detect it and 2 vector types helps that
MH: when people do outer product, they are really aiming for a matrix
update,
so its not like you dont need it, but it is a different context for inner
product
GL: What are the situation beside multiplication that you wan tto
differentiate? expand is generic, row vector into a row matrix, or column
to column matrix, 2 different functions is not generic
the more generic the operations are the better I can express the things I
want to have
for multiplication and expand, could impose a cognitive overhead for most
situation (other then these), so this could make it harder to decide which
to use
also dividing the type into row and column does not cover the degeneracy,
now you can describe 2 different kinds of multiplication but I can think of
5 different kinds of multiplication like permutation expand
GL: are you sure in future we dont need 2 different kinds of vectors?
mathematically never need 2 types of vector, can always express with one
type of vector
e.g. a dot product is different then an outer product? yes vectors are
objects and you do operations on them, mathematically are not coupled ways,
I am worry that in math we never talk about row and column vectors
MH: some people talk about covariance and contravariance?
GL: yes but that does
not say much about their orientation in space and in most cases I dont care
about the type differentiation
BS: by imposing 2 different types, we use the language to impose a
specification we want, its like shapes squares and rectangles
??: dont believe this is significant cognitive overload, people are already
exposed to but at advanced level
JM: a slightly more abstract question, both proposals are forwarded to LEWG
both libraries are not small, will they have enough expertise
games use 3-d vectors
B/G proposal: uses fixed sized can be hand coded SSD, while dynamically
sized can be more BLAS like things
1673 has a lot of in out parameters so how is this passe thorugh vector, so
a vector x scalar operation will be done in register
DOE proposal thinks can be done in mdarray, in/out as a reference parameter
may not be current convention, a ref is a ptr to memory internally
What Jens is concerned how many thing you can return in register
MW: can we show same examples with both interface
or qualities comparison (though this could be dangerous)
not trying for a runoff but to support your claim that these are
complimentary and could build on top of each other
mdspan can have more then 2 orders, while B/G proposal has submatrixes with
2 dimensions like a view
MH: left off batch linear algebra
JM: remember the valarray, afraid of having deadcode
1673 is in markdown, should be html or pdf
BS: Michael Parks has a system for creating standards paper, whch starts
with markdown and change to tex and pdf
wg21 document creator
LM: 1673 is an updating matrix vector product, has 2 declarations shown
before going on with requires, why? I forgot to delete the first
declaration, the execution policy should not to be there
all uses of execution policy were for algo, now using matrices or vectors,
can mdspan skip? yes it is polymorphic on the unique layout: mapping from 2
dim to 1 dim is 1-1
symmetric is an example as in if you want to multiply all with scalar
at the end of proposal is a reason for thin blas, this is important for
floating point accuracy, where I use a class scalar template argument.
But if I want a better guarantee, does it tell me it is a scalar type? dot
can have intermediate storage, but does not say the evaluation accuracy
we would like dot and dotc to use ...
If you go for vector and matrix then have a dot product taking a scalar,
i.e.e separate dot product is a good thing: one function that does both in
a single pass
thinks plain C++ wrapper around Blas may not deliver enough
is it really interesting to have the low level as well? Vendors like to
have it this low, vendors want even lower
if this is just to add this bag of LA algorithm, is that still not C++
enough? Yes
yes Mathias Kretz was in SG14 on SIMD question and it may be orthogonal,
then if all else fails then we need
not trying for tensor library
Lewgi also interested multidimensional ranges
see a lot of unconstraint template parameters: new library needs concepts:
But LEWG has not settled on that yet, because once set they are hard to
change.
These Algorithms take concrete types
Runtime parameter of this is bad, we actually have a layout called
transpose view that abstract away so if you intend to call the BLAS that
is what you have to do
Dot product has both conjugated and non conjugated, this is a good example
where you should make a better effort to return things by value instead of
scalar, similar to std:accumulate; but reduce is not order dependent
On Thu, Aug 8, 2019 at 9:34 AM Michael Wong <fraggamuffin_at_[hidden]> wrote:
> Bob Steagall
> Mark Hoemann
> Javier Cabezas
> Jayesh Badwail
> Klaus Iglberger
> Mateusz Nowak
> Matthew BUtler
> Richard Dosselmann
> William Tambellini
> Michael Wong
> Cem Bassoy
> Nevin Liber
> Graham Lopez
> Jens Maurer
>
> BS: discussion with Christian David Jayesh, Bob
> had lunch for collaboration
> working implementation mdspan and mdarray, and is aiming to create a test
> implementation
> Guy and Bob feels it is a complimentary proposal
> DOE proposal is a layer upon which Bob/Guy one can be
> ship vehicle for Bob/Guy aiming for C++23
> MH: Mark will want to aim for C++23
> public github repo from DOE LA
>
> MH: DOE proposal
> LEWGi: come back after exploring concepts and ranges
> instead of using concrete type
> ranges and lazy evaluation
> uncomfortable writing an expression template library
> due to caution from Eigen
> Mdspan is not owning
> expression template hard sell to the committee due to valarray
> valarray was abandoned by original author, when David proposed full
> expression template treatment for it,
> P1674 talked about this
> interest in lazy evaluation in ranges style, this can solve problems with
> arbitrary arithmetic evaluation witout multiple passes
> this solves it for large class Blas-1, but still cannot fuse the matri and
> matrix multiply
> even if we dont ship expression template library in the future
> they build their expression template ontop of blas
> KI: scale a vector with an expression template, so where do you set your
> boundary, where do you support view? yes we debated this a lot, we just
> want to introduce it and see where people go with it
> major complaint to Blas is it takes too many arguments
> KI:where you draw the line with transforming view: 0 layer is a drop in
> replacement for at least what existign Blas has, and not preclude that; but
> still need transform and scale to do what existign Blas can do
> We were also thining of ways to reduce the number of arguments with BLAS
> KI: But in your proposal I think there is one part where you were trying
> to do more. What part should we expand? scale with 2 positions ..; yes we
> have an alpha nad beta so I think it is there
> KI: Is that for matrix vector? Yes, where you can have the plus y at the
> end. Yes I thought that was a bit of extending, but I like it; ok it is in
> GEMV
> The only difference in functionality is that alpha nad beta means different
> There would not be ABI problems in future as we are changign the accessor
> policy for mdspan
> A triangular matrix is not an accessor
>
>
> BS: Bob/Guy proposal:
> returnig temporaries, expression templates, we are neutral on this,
> provdie an interface for implementator to decide
> our interface can adopt for the future inclusing of expression templates,
>
> MW: what games deveoper do - either proposal will work well to gamer
> MW: will solver be part of the proposal: neither will support solver
>
> BS: if you want customized operator, what is the complexity? If allowed
> this customization, they may not take the best advantage as possible
> Andrew Lumsdaine mentioned that we shoudl think in terms of algorithms,
> concepts first, that we should not get ahead of the game
> my thinking is to use the imperfect analogy of standard algorithm and
> containers, 1673 has wrapper aroudn blas which are algo, mdspan is iterator
> to provide access to data, matrix type holds the data
> we created mdarray as a view cannot create a matrix, so mdarray, then we
> need a way to iterate over them
> this is actually a good analogy
> single vector type vs row and column vector, havng a seingle vector type
> is messy, from c++now and Klaus also mentioned this
> wait until LEWG review to decide on this
> KI: Klaus believes we can expresss thing better with 2 different vector
> types, this keeps it more generic, inner or outer allow people to do more
> things
> also believe this helps people to debug their code more easily, at compile
> you can detect it and 2 vector types helps that
> when people do outer product, they are really aiming for a matrix update,
> so its not like you dont need it, but it is a different context for inner
> product
> What are the situation beside multiplication that you wan tto
> differentiate? expand is generic, row vector into a row matrix, or column
> to column matrix, 2 different functions is not generic
> the more generic the operations are the better I can express the things I
> want to have
> for multiplication and expand, could impose a cognitive overhead for most
> situation (other then these), so this could make it harder to decide which
> to use
> also dividing the type into row and column does not cover the degeneracy,
> now you can describe 2 different kinds of multiplication but I can think of
> 5 different kinds of multiplication like permutation expand
> GL: are you sure in future we dont need 2 different kinds of vectors?
> mathematically never need 2 types of vector, can always express with one
> type of vector
> e.g. a dot product is different then an outer product? yes vectors are
> objects and you do operations on them, mathematically are not coupled ways,
> I am worry that in math we never talk about row and column vectors
> MH: some people talk about covariance and contravariance? yes but that
> does not say much about their orientation in space and in most cases I dont
> care about the type differentiation
> by imposing 2 different types, we use the language to impose a
> specification we want, its like shapes squares and rectangles
> GL: dont believe this is significant cognitive overload, people are
> already exposed to but at advanced level
>
> JM: a slightly more abstract question, both proposals are forwarded to LEWG
> both libraries are not small, will they have enough expertise
> games use 3-d vectors
> B/G proposal: uses fixed sized can be hand coded SSD, while dynamically
> sized can be more BLAS like things
> 1673 has a lot of in out parameters so how is this passe thorugh vector,
> so a vector x scalar operation will be done in register
> DOE proposal thinks can be done in mdarray, in/out as a reference
> parameter may not be current convention, a ref is a ptr to memory internally
> What Jens is concerned how many thing you can return in register
>
> MW: can we show same examples with both interface
> or qualities comparison (though this could be dangerous)
> not trying for a runoff but to support your claim that these are
> complimentary and could build on top of each other
> mdspan can have more then 2 orders, while B/G proposal has submatrixes
> with 2 dimensions like a view
> MH: left off batch linear algebra
>
> JM: remember the valarray, afraid of having deadcode
> 1673 is in markdown, should be html or pdf
> BS: Michael Parks has a system for creating standards paper, whch starts
> with markdown and change to tex and pdf
> wg21 document creator
>
> LM: 1673 is an updating matrix vector product, has 2 declarations shown
> before going on with requires, why? I forgot to delete the first
> declaration, the execution policy should not to be there
> all uses of execution policy were for algo, now using matrices or vectors,
> can mdspan skip? yes it is polymorphic on the unique layout: mapping from 2
> dim to 1 dim is 1-1
> symmetric is an example as in if you want to multiply all with scalar
>
> at the end of proposal is a reason for thin blas, this is important for
> floating point accuracy, where I use a class scalar template argument.
> But if I want a better guarantee, does it tell me it is a scalar type? dot
> can have intermediate storage, but does not say the evaluation accuracy
> we would like dot and dotc to use ...
> If you go for vector and matrix then have a dot product taking a scalar,
> i.e.e separate dot product is a good thing: one function that does both in
> a single pass
>
> thinks plain C++ wrapper around Blas may not deliver enough
> is it really interesting to have the low level as well? Vendors like to
> have it this low, vendors want even lower
> if this is just to add this bag of LA algorithm, is that still not C++
> enough? Yes
> yes Mathias Kretz was in SG14 on SIMD question and it may be orthogonal,
> then if all else fails then we need
> not trying for tensor library
> Lewgi also interested multidimensional ranges
> see a lot of unconstraint template parameters: new library needs concepts:
> But LEWG has not settled on that yet, because once set they are hard to
> change.
> These Algorithms take concrete types
> Runtime parameter of this is bad, we actually have a layout called
> transpose view that abstract away so if you intend to call the BLAS that
> is what you have to do
>
> Dot product has both conjugated and non conjugated, this is a good example
> where you should make a better effort to return things by value instead of
> scalar, similar to std:accumulate; but reduce is not order dependent
>
Received on 2019-08-13 11:40:30