Re: CI setup

--===============8331827077560655909==
Content-Type: multipart/alternative; boundary="000000000000c2885c056b3e9f1a"

--000000000000c2885c056b3e9f1a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> Yes try to fork from https://github.com/uBLAS/ublas
>> We have our own repository for ublas development.
>>
>> But what about https://github.com/BoostGSoC18
>

=E2=80=8BThis one is for the students to push their code.
To be honest, after talking with Stefan, we are going to do the development
of ublas directly from the boostorg repository instead of having multiple
github repositories. I think it will simplify the development.
=E2=80=8B

> Silly questions: can we have right from the beginning a fixed dimensions
>> tensors on top of the regular tensor ?
>>
>
> Yes we can have. I would like to start with runtime variable parameters
> though. On top of that we might add a tensor template class with static
> dimensions for static memory allocation. There is one library supporting
> tensors with static rank/order (number of dimensions) and static dimeniso=
ns
> https://github.com/romeric/Fastor with optimizations.
> If I recall correctly, Eigen, Blitz and other libraries set the order/ran=
k
> as a compile time parameter.
> However, some applications with graphical interfaces creating / invoking
> tensors at runtime might need the order to be a dynamic parameter.
> Boost could be one of the few libraries to support these type of
> applications.
>

=E2=80=8BThis sounds excellent to me.
=E2=80=8B

> Yes for small tensor sizes there is a benefit. The compiler is able to
> optimize much better. However, for larger tensor sizes designing tensor
> algorithms with high spatial and temporal data locality is the key design
> criteria to my mind.
> Supporting two or even three versions would be the best option. If we do
> not focus on small tensors, I would first start with the most flexible
> version. Once that is finished ( GSOC) we could continue on turning runti=
me
> variable parameters into static ones.
>

=E2=80=8BAwesome !

--000000000000c2885c056b3e9f1a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small"><br></div><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small">Yes try to fork fro=
m=C2=A0<a href=3D"https://github.com/uBLAS/ublas" target=3D"_blank">https:/=
/github.com/uBLAS/<wbr>ublas</a></div><div style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small">We have our own repository for ublas devel=
opment.</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size=
:small"><br></div></div></blockquote></span><div>But what about <a href=3D"=
https://github.com/BoostGSoC18" target=3D"_blank">https://github.com/BoostG=
SoC18</a></div></div></div></div></blockquote><div><br></div><div class=3D"=
gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all">=E2=80=8BThis one is for the students to push their code.</div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small">To be honest, after talking with Stefan, we are going to do the=
 development of ublas directly from the boostorg repository instead of havi=
ng multiple github repositories. I think it will simplify the development.<=
/div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small">=E2=80=8B<span style=3D"font-family:arial,sans-seri=
f">=C2=A0</span></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small">Silly questions: can w=
e have right from the beginning a fixed dimensions tensors on top of the re=
gular tensor ?</div></div></blockquote><br></span>Yes we can have. I would =
like to start with runtime variable parameters though. On top of that we mi=
ght add a tensor template class with static dimensions for static memory al=
location. There is one library supporting tensors with static rank/order (n=
umber of dimensions) and static dimenisons <span style=3D"font-size:10pt;fo=
nt-family:Ubuntu;color:rgb(0,0,128);background-color:transparent;font-weigh=
t:300;font-style:normal;font-variant:normal;text-decoration:underline;verti=
cal-align:baseline;white-space:pre-wrap" id=3D"m_5434120758529609225gmail-d=
ocs-internal-guid-815675ec-15c4-1934-a038-2e3a248bd925"><a href=3D"https://=
github.com/romeric/Fastor" target=3D"_blank">https://github.com/romeric/<wb=
r>Fastor</a></span> with optimizations.<br></div><div class=3D"gmail_quote"=
><div>If I recall correctly, Eigen, Blitz and other libraries set the order=
/rank as a compile time parameter.<br></div><div>However, some applications=
 with graphical interfaces creating / invoking tensors at runtime might nee=
d the order to be a dynamic parameter. <br>Boost could be one of the few li=
braries to support these type of applications.<br></div></div></div></div><=
/blockquote><div><br></div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small">=E2=80=8BThis sounds excellen=
t to me.</div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small">=E2=80=8B</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<div>Yes for small tensor sizes there is a benefit. The compiler is able to=
 optimize much better. However, for larger tensor sizes designing tensor al=
gorithms with high spatial and temporal data locality is the key design cri=
teria to my mind. <br></div><div>Supporting two or even three versions woul=
d be the best option. If we do not focus on small tensors, I would first st=
art with the most flexible version. Once that is finished ( GSOC) we could =
continue on turning runtime variable parameters into static ones. <br></div=
></div></div></div></blockquote><div><br></div><div class=3D"gmail_default"=
 style=3D"font-family:arial,helvetica,sans-serif;font-size:small">=E2=80=8B=
Awesome !</div></div></div></div>

--000000000000c2885c056b3e9f1a--

--===============8331827077560655909==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline