## SG14 | |

**Subject:** [SG14] Minutes of the Meeting on February 6, 2019 3PM ET

**From:** Jayesh Badwaik (*badwaik.jayesh_at_[hidden]*)

**Date:** 2019-02-06 15:47:41

**Next message:**Matthew Bentley: "[SG14] Vice chair contact details"**Previous message:**Matthieu Brucher: "Re: [SG14] P1385"

Hi,

I have attached the minutes to the meeting.

-- Best Jayesh Badwaik https://jayeshbadwaik.github.io

SG14 SIG Call

Date: February 6, 2019

Time: 21:00 CET

Note Taker: Jayesh Badwaik

Bob lists out the agenda and asks for volunteer to discuss them.

Mentions P1385R1 to be complete by Kona

Asks if someone wants to discuss P1166R0? No takers.

Asks if someone wants to discuss P1416R0? No takers.

Discussion about P1416R0 deferred to Kona face to face meetings.

Asks for volunteers for P1417?

Jayesh talks about Joel's observations about expression templates.

Cem Bassoy mentions how there are two types of expression templates and their

impact on the decision.

Michael Wong mentions that he has his own ET types and will follow up on it.

Cem Bassoy talks about fixing misleading description of matrix operations about

Matlab in the paper.

Nothing more on the paper. The dicussion proceeds to P1385 where Bob starts

describing the paper.

Bob:

By high performance, the paper means: reasonably high performance. Not extreme

high performance.

There are people working in labs are looking for highest possible performance.

For them, ability to tune and customize is key.

And take care to ensure that the tunability and customization

of interface is maintained to ensure that high performance algorithms can be

implemented.

The objective is to provide an interface specification and not an

implementation.

The objective is for the interface to be intuitive, expressive and provide Out

of the box performance (Rivaling calls to Blaze/LAPACK) within 80-90% of the

possible performance range.

It should provide basic build blocks to manage things like layout, access to

memory.

Building blocks could also be used to represent other mathematical things of

interest like Quaternions, Tensors etc, but that is for later.

It should provide straightforward set of facilities for customization.

Bob then describes the notation in the paper to solve ambiguities between

fields of computer science and mathematics and points out definitions which are

different in the two fields.

Cem Bassoy talks about using field as element types. Bob responds that talking

to Casey Carter indicates that using Concepts to do that is extremely

difficult.

Jayesh says that one of the best ways to do it is manually specifying which

type is field, since the actualy float point numbers (as specified by the IEEE

Standards) are not a field due to NaNs and negative and positive zero.

Bob explains 3.2 with special mention to MathObj. He explains how rank for

tensor and matrix are ambigous.

Cem Bassoy: says that rank is also referred to an order and may be that can be used.

Bob then proceeds to overloaded terms and disambiguate the two things.

Bob then proceeds to Layered approach about linear algebra and explains that

the paper is the fundamental services only proposal as listed in 4.1 of the

paper.

Bob then moves onto tensor and explains why to exclude tensors from the design

and not to combine the design. Similar logic for quaternions and octonions.

Cem Bassoy asks a question about quaternions and octonions.

Bob clarifies that the only intent is to separate quaternions completely, and

clarifies that using the example of compledx numbers. Even though complex

number can be represented by the vector, it is not a vector and hence should be

modeled by a different type.

Bob then goes onto the section of design aspects (Section 5.3)

Jeff Hammond notes that Fortran allows any indexing range and says that C++

should go that route for allowing arbitrary indexing. He says there is

tremendous value in having both 0 and 1, and once you are supporting two, you

might as well support arbitrary ones. He gives an example of angular momentum.

Ronan Keryell says that mdspace proposal is very similar. Michael supports the

idea or 0 or 1.

Bob explains his motivation of 1-based indexing, that it's easier for people to

transfer algorithms from book to code directly.

Bob then moves onto Element Type.

Bob asks question about mixed element types (section 5.11) and how to deal with it.

Bob brings up constexpr of linear algebra and requests for ideas on how to make

it work with linear algebra in general.

Cem Bassoy wants some elaboration on parallelism and SIMD.

Bob gives an example of how a multiplication trait can be specialized for a

certain type to give a SIMD implementation of the type multiplication.

Cem Bassoy asks if there has been any thought about execution polcies.

The discussion now moves onto section 6. Even though its an R1 draft, the

interface is R0. No big surprises there. Fundamental design principles are

unchanged. They take a bottom up approach instead of top down. An engine type

is something that is responsible for something managing storage.

The real difference for the dynamic engine is in the methods having to do with

changing the size and capacity.

Jeff Hammond: Says that for complex numbers, its better to have much better to

have more, because Lapack sometimes wants transpose without conjugate,

sometimes without. Jeff asks for a template parameter based engine. Bob says

that it will be possible to do so based on templated engine. And since, engine

knows the element type, it can be then be optimized for it.

Jeff says that part of the thinking in being careful about this is that, the

design should not actively interfering with SIMD as the similar fault exists

with `std::reduce`.

Bob would allow one to create additional engines or at least not preclude one

from getting performance.

Now, we move onto the traits.

Partial specialization of traits in 6.3 traits is suggested to be allowed.

Bob mentions the repo of the paper and the interface code and mentions that in

the repo.

Unfortunately, the standard library does not allow mixed element types in

complex which is the subject of a different paper by Bob.

Promotion traits for negation are trivial.

Bob explains, why have a separate promotion type for engines. The reason to

keep them separate, that way the implementer might to use expression templates

as the result. by not specifying that, the freedom is to the implementer and

this promotion type traits allow that flexibility.

Bob then descirbes the Mathematical Types in Section 6.2

Guy Davidson tells us that he presented the paper on Tuesday on CpponSea and

the reception of encouraging. There is real enthusiasm for the paper.

Bob then closes out the meeting.

- application/pgp-signature attachment: This is a digitally signed message part.

**Next message:**Matthew Bentley: "[SG14] Vice chair contact details"**Previous message:**Matthieu Brucher: "Re: [SG14] P1385"

SG14 list run by sg14-owner@lists.isocpp.org