Re: Deciding on tensor parameters
Cem Bassoy via ublas <[email protected]> Thu, 13 Sep 2018 21:44:24 +0200
| Newsgroups | gmane.comp.lib.boost.ublas |
|---|---|
| Message-ID | <CADrR+Fsx5wh9rSRBYSFqZv8iqS+zBnPZAEf_gRuHi=Cy24Lzjg@mail.gmail.com> |
--===============6911647827605993652== Content-Type: multipart/related; boundary="000000000000dfaa650575c5efed" --000000000000dfaa650575c5efed Content-Type: multipart/alternative; boundary="000000000000dfaa630575c5efec" --000000000000dfaa630575c5efec Content-Type: text/plain; charset="UTF-8" Am Do., 13. Sep. 2018 um 20:35 Uhr schrieb Stefan Seefeld via ublas < [email protected]>: > On 2018-09-13 02:06 PM, Cem Bassoy via ublas wrote: > > > > Am Do., 13. Sep. 2018 um 18:12 Uhr schrieb Stefan Seefeld via ublas < > [email protected]>: > >> >> On 2018-09-13 11:34 AM, Cem Bassoy via ublas wrote: >> >> We would only need to specify and implement one data structure ' tensor ' >> and if needed provide optimized functions for matrices. This simplifies >> the maintenance. >> > >> A big advantage (which has been my main motivation for pushing for this >> solution) is that such a scenario would be fully in line with the existing >> Boost.uBLAS API, so your work becomes a natural extension of what we >> already have. >> > > I think, just the contrary is the case. There would be no extension to the > old dense matrix class template, as the new alias template would replace > the old one because we cannot have the identifier in the same namespace. In > the above case, we need to port all vector and matrix functions for the new > tensor type. The vector and matrix class templates are not alias templates > but are distinct class templates. If I am not mistaken, adding the tensor > as a class template as it is right now would be the uBLAS way. > > > I think I may have expressed myself poorly. Yes, I agree: with your > approach you would introduce new "matrix" and "vector" types (as template > aliases). It is my hope however that we could use those as drop-in > replacements for the old matrix and vector classes, i.e. I would like to > simply replace those (assuming of course that they are sufficiently > API-compatible to make this possible). In that case, no other code (such as > stand-alone functions / operators taking vector and matrix arguments) would > need to change. > Yes. I think it would be mostly adjusting the free functions the alias template. > > Of course, if we need to port code over, it's a sign that the old and new > types aren't API-compatible, so this becomes a bigger question (as it also > affects users). Again, my assumption was that we could come up with a new > API that was backward-compatible. > Hmmm, backward compatibility could be a bit more difficult in this case. There are so many iterators inside those classes. We do not need them. At least only, not on this level I think. So if we agree on tensor class template with a static rank using alias templates for matrix and vector, means that we would provide a new api with the same functionality but better usability? > > > >> >> Alternatively, if you keep the rank a runtime parameter, you are >> basically proposing an entirely new API, which means that Boost.uBLAS users >> will have to decide whether to use the old or the new API, which I'm afraid >> will result in a fragmentation of the community. Likewise, many existing >> operations only support existing vector and matrix types, so maintainers >> will have more work to do to support both APIs. >> >> That, to me as library maintainer, is a very high cost, so I'm reluctant >> to such a change, even if the proposed API with runtime ranks is otherwise >> sound. >> > > Yes agree with you on that point. > > > Glad to hear that ! :-) > So I will wait for more opinions before continuing to adjust the tensor class template. Cheers C --000000000000dfaa630575c5efec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">Am Do.= , 13. Sep. 2018 um 20:35=C2=A0Uhr schrieb Stefan Seefeld via ublas <<a h= ref=3D"mailto:[email protected]">[email protected]</a>>:<br></di= v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:= 1px #ccc solid;padding-left:1ex"> =20 =20 =20 <div text=3D"#000000" bgcolor=3D"#FFFFFF"> <p>On 2018-09-13 02:06 PM, Cem Bassoy via ublas wrote:<br> </p> <blockquote type=3D"cite"> =20 <div dir=3D"ltr"><br> <br> <div class=3D"gmail_quote"> <div dir=3D"ltr">Am Do., 13. Sep. 2018 um 18:12=C2=A0Uhr schrieb Stefan Seefeld via ublas <<a href=3D"mailto:[email protected]= t.org" target=3D"_blank">[email protected]</a>>:<br> </div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-left:1px #ccc solid;padding-left:1ex"> <div dir=3D"ltr"><br> <div class=3D"m_-811226276391749916m_2777987025696287046moz-c= ite-prefix">On 2018-09-13 11:34 AM, Cem Bassoy via ublas wrote:<br> </div> <br> <div dir=3D"auto"><font size=3D"2">We would only need to specify and implement one data structure ' tensor = 9; and if needed =C2=A0provide optimized functions for matrices. This simplifies the maintenance. <br> </font></div> </div> </blockquote> </div> </div> </blockquote> <blockquote type=3D"cite"> <div dir=3D"ltr"> <div class=3D"gmail_quote"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-left:1px #ccc solid;padding-left:1ex"> <div text=3D"#000000" bgcolor=3D"#FFFFFF"> <blockquote type=3D"cite"> </blockquote> <br> A big advantage (which has been my main motivation for pushing for this solution) is that such a scenario would be fully in line with the existing Boost.uBLAS API, so your work becomes a natural extension of what we already have.<br> </div> </blockquote> <div><br> </div> <div>I think, just the contrary is the case. There would be no extension to the old dense matrix class template, as the new alias template would replace the old one because we cannot have the identifier in the same namespace. In the above case, we need to port all vector and matrix functions for the new tensor type. The vector and matrix class templates are not alias templates but are distinct class templates. If I am not mistaken, adding the tensor as a class template as it is right now would be the uBLAS way.<br> </div> </div> </div> </blockquote> <br> I think I may have expressed myself poorly. Yes, I agree: with your approach you would introduce new "matrix" and "vector&qu= ot; types (as template aliases). It is my hope however that we could use those as drop-in replacements for the old matrix and vector classes, i.e. I would like to simply replace those (assuming of course that they are sufficiently API-compatible to make this possible). In that case, no other code (such as stand-alone functions / operators taking vector and matrix arguments) would need to change.<br></div></blockquote><div>= <br></div><div>Yes. I think it would be mostly adjusting the free functions= the alias template.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x"><div text=3D"#000000" bgcolor=3D"#FFFFFF"> <br> Of course, if we need to port code over, it's a sign that the old and new types aren't API-compatible, so this becomes a bigger question (as it also affects users). Again, my assumption was that we could come up with a new API that was backward-compatible.<br></div>= </blockquote><div><br></div><div>Hmmm, backward compatibility could be a bi= t more difficult in this case. There are so many iterators inside those cla= sses. We do not need them. At least only, not on this level I think. So if = we agree on tensor class template with a static rank using alias templates = for matrix and vector, means that we would provide a new api with the same = functionality but better usability?<br></div><div><br></div><div>=C2=A0</di= v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:= 1px #ccc solid;padding-left:1ex"><div text=3D"#000000" bgcolor=3D"#FFFFFF"> <br> <blockquote type=3D"cite"> <div dir=3D"ltr"> <div class=3D"gmail_quote"> <div>=C2=A0</div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-left:1px #ccc solid;padding-left:1ex"> <div text=3D"#000000" bgcolor=3D"#FFFFFF"> <br> Alternatively, if you keep the rank a runtime parameter, you are basically proposing an entirely new API, which means that Boost.uBLAS users will have to decide whether to use the old or the new API, which I'm afraid will result in a fragmentation of the community. Likewise, many existing operations only support existing vector and matrix types, so maintainers will have more work to do to support both APIs.<br> <br> That, to me as library maintainer, is a very high cost, so I'm reluctant to such a change, even if the proposed API with runtime ranks is otherwise sound.<br> </div> </blockquote> <div><br> </div> <div>Yes agree with you on that point.<br> </div> </div> </div> </blockquote> <br> Glad to hear that=C2=A0 ! :-)<br></div></blockquote><div><br></div><div= >So I will wait for more opinions before continuing to adjust the tensor cl= ass template.<br></div><div><br></div><div>Cheers</div><div>C<br></div></di= v></div> --000000000000dfaa630575c5efec-- --000000000000dfaa650575c5efed Content-Type: image/png; name="signature.png" Content-Disposition: inline; filename="signature.png" Content-Transfer-Encoding: base64 Content-ID: <165d46e30fd61a917f31> X-Attachment-Id: 165d46e30fd61a917f31 iVBORw0KGgoAAAANSUhEUgAAAEkAAAAtCAYAAADiFkaQAAAABHNCSVQICAgIfAhkiAAAAAlwSFlz AAAVhwAAFYcBshnuugAAABl0RVh0U29mdHdhcmUAd3d3Lmlua3NjYXBlLm9yZ5vuPBoAAAVDSURB VGiB5dpprF1TFMDx33u0iqpWW6LmqWpIVUkoNVbM81ShiJifIakgxAc1VEzxwRiC8EHwgaAilBhC g6BClJIYaqohSM1t6fVh7afXfffcd+55d8I/uXnvnL3PWuvus/daa699+e8xCFfhlnYb0qkMw40o 4dA229KRDMLL+AnvYYX2mtOZXIj5+B4HttmWjmQkfsCreLDNtnQsV+ErfIsxbbalI1kDi/AnTm6z LR3LpSKazUJXm23JRauNHIyF+ByjWqy7boagB59gGR4QIbnZHCeW2Z4t0DUgNsXh4k2Owxti+l/e At0vt0jPgNgUn2FC2b2NsFjkK81M6E4UDntYE3UMmC6Rl9xUpW2WmE2bNUn3OPzsX7A/OxC/q+4w rxGDtE3GszvgmIJ6h+CtJH/7gjJaxiO4P6PtSvEltqjStifmYXhBvXeJAPF2wedbxmgswd4Z7bfg R30j3Dr4FFsV1HsmZmMOpheU0TJ6hE9YKaN9Hm6vuNeF53F+QZ2T8IFYYouxZkE5LeNhPJHRNgXf iVlTzikiPeguoG8UFmBXkWE/WkBGS+kWg1Btuo/AXOxRcX8kvhFfsl668BhmpusPMK2AnJaytXDK k7EyrhNlihfFbnztKs/chocK6jsbLwn/Nl5E1NULymoZ08RWYDUMxUE4UiSR1dhQVAuL5EwrieDQ u0QvEzlYx3M93q+j/724oUG638UJDZLVVJ4SPiIPY8XWYa0G6N1cpB0jGiCrLsojTVY4r2QTEWny MBN34Ot6jKqgt/xyFF4Q/i8vQ3EA9jHAMs5kkaCtmqNvt8hRLsjRdwJ+U92R52VHvCPqRq/In0Cu hRl4Uszk0gDt8Jr8kWdMUnh0P/0GiS3LPem6W/6Z2st2+CPpW08Ei81z6D1HnLn16pulAc5+cR1C Jgmjd8honyAG/QvhP8aLrcSjWLFOuw5PuhYLZ/1hP/3XFfWliWX3dhKuoTKxrYsVxQnDdmLNlvrp v376+1VG+0TLd+ZLcRZOFVP/jzpt+65MzvH+meEPFynHJtg2fcaLlzM39dkYV4sN9Rd16u7DfWJw ds/R99zUd5WM9mmpvYTTsH/6v6eAXd2Wl0RK4mXOw0d4M9k9XfjU4cKhl8SW6XSRgBbdSPdhryR8 do6+M/FLjfapSdYPIhs/IF3fnUN2t76llddFhr1ELPWRNZ7fUpRRFogl2ju4S8TJ7tQcNtTkpSRw t3763SlqOVkcmeTcmq5HikH9DTvXeG6UOL+vjJofJ3lz+rGrl/KUZpQo+l2UZCxUvIYFdhGnHO+J yl8Wj4m3m8WpyaD9yu71pHuLxCBUJoMjhO86Xd/606/p2Stqm98vTyc5P+FxcXjQgyPEpnuc2t/7 b25Pgq6t0efVpCSLGUnG1hX3DxP5Tkk48Hl4VuQ+9wunW8kIy5fMQI+MBos95hUiLXlCROEFYpaX RIrxsUiHTpZxjjcsdVomsttqfCky6CzmiEHIeisbill2lCin1DpQ3CoZv1S+RLcoXdgA+4qKxvyk 92dR1egTpCakxl+EoyxniBjt8zKUjU7t8xtgOLGVKKm9vJtBFw62fLAqK6yIJG6pWL97ld3fMT00 JUP4viJMZ7XXy0lJX7Ujq1YwRHYNH+HQlojwe7FwqOeJyDY445nR4hcejeISMUjHNlBmw9ldnM6W ROn1OdUdbLO4WXMPOBvGajgDh2j9L0YeFr6xyMHB/4bX0qftdPJb2kjkU22nUwdpmNjS5K2ANpVO HaSx6e/CtlqR6NRB6q0GfN5WKxKdOkhjRF72TLsNgb8Aty4jMPtjABcAAAAASUVORK5CYII= --000000000000dfaa650575c5efed-- --===============6911647827605993652== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline