Re: [GSOC2020][Boost.uBLAS] C++20-ification of uBLAS

--===============3172326379281343722==
Content-Type: multipart/alternative; boundary="0000000000003f67ae05a1474f2f"

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

Am Do., 19. M=C3=A4rz 2020 um 18:36 Uhr schrieb Ashar via ublas <
[email protected]>:

>
>
>>    1. (not part as gsoc) make a final decision about yapp
>>
>>    2. stablilize and improve the code from the previous gsoc
>>    implementation (static rank and extents, subtensor)
>>    3. improve code quality using advanced and modern toolchains like
>>    cmake, clang-static-analyzer, clang-tidy, etc.
>>    4. improve code quality by enhancing the code-covarge percentage for
>>    tensor only
>>    5. improve the constexpr-ness of tensor and subtensor (finalization
>>    with C++17)
>>    6. prepare a matrix and vector data structures as an instance of
>>    tensor<T,rank=3D2> and tensor<T,rank=3D1>
>>
>>    7. using a different branch, improve code quality using c++20
>>    contracts and attributes for tensor, using (expects,ensure,assert)
>>    contract
>>    <https://www.modernescpp.com/index.php/c-core-guidelines-a-detour-to-=
contracts>
>>    8. prepare for concepts
>>
>> Hey Cem,
>
> Are you sure to add contracts in uBLAS. Contracts was proposed for C++17
> and did not made it up to C++20 and I have no idea when it will come to b=
ut
> there are some implementation of contracts TS draft by some third party
> compiler hackers who implement things, So I will have to compile the
> compiler with contract support and then test it during development. I hav=
e
> no problems doing it, I can see all the great places it will be used.
>
> Will it be worth doing something that can't be directly used by other?
>

you are right about contracts.


>
> In addition to the above, I was thinking of also having complete compile
> time tensor. c++20 has new and delete marked constexpr, so we can use
> std::vector container which is now compile-time and modify current to hav=
e
> a complete compile time tensor class. With examples and how to use it, th=
is
> will be easy, if I use Amit's static extents. This is I believe an
> extension to the list of ideas you presented above.
>

yes. doumenting and stablizing the software and preparing it for matrix and
vector templates would be the number one priority.


>
> I still need your view on if I should go ahead with the contracts?
> Concepts are okay and So is constexpr thing!
>

for now, I would like to put concepts at the very end of the


> Also I believe eventually if I follow up your list of ideas tensor<2,
> rank> can be matrix and tensor<1, rank> can become a vector and in a long
> run it can replace the specially designed matrix and vector of ublas.
> (backward compatibility could be provided thought).
>

yes. according to the list that is the way we should go.


> We will have one expression template (YAP), C++17 or 20 everywhere, it
> will also make maintaining the library easy because currently tensor is a
> separate things and matrix and vector of ublas are separator thing.
>

agree.


> This will also eventually give us many performance boost that David was
> talking about from modern paradigms of C++.
>
> Regards
> Ashar
>
>> _______________________________________________
> ublas mailing list
> [email protected]
> https://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: [email protected]
>

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

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">Am Do., 19. M=C3=A4rz 2020 um 18:36=
=C2=A0Uhr schrieb Ashar via ublas &lt;<a href=3D"mailto:[email protected]=
rg">[email protected]</a>&gt;:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"><br></div><div class=
=3D"gmail_quote" dir=3D"auto"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><ol><li>(not part as gsoc)=
 make a final decision about yapp<br><br></li><li>stablilize and improve th=
e code from the previous gsoc implementation (static rank and extents, subt=
ensor)<br></li><li>improve code quality using advanced and modern toolchain=
s like cmake, clang-static-analyzer, clang-tidy, etc.<br></li><li>improve c=
ode quality by enhancing the code-covarge percentage for tensor only<br></l=
i><li>improve the constexpr-ness of tensor and subtensor (finalization with=
 C++17)</li><li>prepare a matrix and vector data structures as an instance =
of tensor&lt;T,rank=3D2&gt; and tensor&lt;T,rank=3D1&gt;<br><br></li><li>us=
ing a different branch, improve code quality using c++20 contracts and attr=
ibutes for tensor, using (expects,ensure,assert) <a href=3D"https://www.mod=
ernescpp.com/index.php/c-core-guidelines-a-detour-to-contracts" target=3D"_=
blank">contract</a></li><li>prepare for concepts </li></ol></div></div></bl=
ockquote></div><div dir=3D"auto"><div dir=3D"auto" style=3D"font-family:san=
s-serif">Hey Cem,</div><div dir=3D"auto" style=3D"font-family:sans-serif"><=
br></div><div dir=3D"auto" style=3D"font-family:sans-serif">Are you sure to=
 add contracts in uBLAS. Contracts was proposed for C++17 and did not made =
it up to C++20 and I have no idea when it will come to but there are some i=
mplementation of contracts TS draft by some third party compiler hackers wh=
o implement things, So I will have to compile the compiler with contract su=
pport and then test it during development. I have no problems doing it, I c=
an see all the great places it will be used.</div><div dir=3D"auto" style=
=3D"font-family:sans-serif"><br></div><div dir=3D"auto" style=3D"font-famil=
y:sans-serif">Will it be worth doing something that can&#39;t be directly u=
sed by other?</div></div></div></blockquote><div><br></div><div>you are rig=
ht about contracts. <br></div><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"><div dir=3D"auto"=
 style=3D"font-family:sans-serif"><br></div><div dir=3D"auto" style=3D"font=
-family:sans-serif">In addition to the above, I was thinking of also having=
 complete compile time tensor. c++20 has new and delete marked constexpr, s=
o we can use std::vector container which is now compile-time and modify cur=
rent to have a complete compile time tensor class. With examples and how to=
 use it, this will be easy, if I use Amit&#39;s static extents. This is I b=
elieve an extension to the list of ideas you presented above.</div></div></=
div></blockquote><div><br></div><div>yes. doumenting and stablizing the sof=
tware and preparing it for matrix and vector templates would be the number =
one priority.=C2=A0 </div><div>=C2=A0</div><blockquote 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"auto"><div dir=3D"auto"><div dir=3D"auto" sty=
le=3D"font-family:sans-serif"><br></div><div dir=3D"auto" style=3D"font-fam=
ily:sans-serif">I still need your view on if I should go ahead with the con=
tracts? Concepts are okay and So is constexpr thing! </div></div></div></bl=
ockquote><div><br></div><div>for now, I would like to put concepts at the v=
ery end of the <br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"><div dir=3D"auto" styl=
e=3D"font-family:sans-serif">Also I believe eventually if I follow up your =
list of ideas tensor&lt;2, rank&gt; can be matrix and tensor&lt;1, rank&gt;=
 can become a vector and in a long run it can replace the specially designe=
d matrix and vector of ublas. (backward compatibility could be provided tho=
ught). </div></div></div></blockquote><div><br></div><div>yes. according to=
 the list that is the way we should go.<br></div><div>=C2=A0</div><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"auto"><div dir=3D"auto=
"><div dir=3D"auto" style=3D"font-family:sans-serif">We will have one expre=
ssion template (YAP), C++17 or 20 everywhere, it will also make maintaining=
 the library easy because currently tensor is a separate things and matrix =
and vector of ublas are separator thing.=C2=A0</div></div></div></blockquot=
e><div><br></div><div>agree.</div><div> <br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"><div dir=3D"au=
to" style=3D"font-family:sans-serif"><br></div><div dir=3D"auto" style=3D"f=
ont-family:sans-serif">This will also eventually give us many performance b=
oost that David was talking about from modern paradigms of C++.</div><div d=
ir=3D"auto" style=3D"font-family:sans-serif"><br></div><div dir=3D"auto" st=
yle=3D"font-family:sans-serif">Regards</div><div dir=3D"auto" style=3D"font=
-family:sans-serif">Ashar</div></div><div class=3D"gmail_quote" dir=3D"auto=
"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div></div>
_______________________________________________<br>
ublas mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]=
t.org</a><br>
<a href=3D"https://lists.boost.org/mailman/listinfo.cgi/ublas" rel=3D"noref=
errer" target=3D"_blank">https://lists.boost.org/mailman/listinfo.cgi/ublas=
</a><br>
Sent to: <a href=3D"mailto:[email protected]" target=3D"_blank">cem.bass=
[email protected]</a><br>
</blockquote></div></div>

--0000000000003f67ae05a1474f2f--

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