Re: Deciding on tensor parameters
Stefan Seefeld via ublas <[email protected]> Thu, 13 Sep 2018 14:34:14 -0400
| Newsgroups | gmane.comp.lib.boost.ublas |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============2680480859588026591== Content-Type: multipart/alternative; boundary="------------CDACC66EB9B6955BA5430E05" Content-Language: en-US This is a multi-part message in MIME format. --------------CDACC66EB9B6955BA5430E05 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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] <mailto:[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. 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. > > 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 ! :-) [...] Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin... --------------CDACC66EB9B6955BA5430E05 Content-Type: multipart/related; boundary="------------10669544F7C5460D922E58E3" --------------10669544F7C5460D922E58E3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <p>On 2018-09-13 02:06 PM, Cem Bassoy via ublas wrote:<br> </p> <blockquote type="cite" cite="mid:CADrR+FuKdZhgRwm9tpzWrq6m3ZC=1sUHJab7ddcVmfgr4vOYag@mail.gmail.com"> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <div dir="ltr"><br> <br> <div class="gmail_quote"> <div dir="ltr">Am Do., 13. Sep. 2018 um 18:12 Uhr schrieb Stefan Seefeld via ublas <<a href="mailto:[email protected]" moz-do-not-send="true">[email protected]</a>>:<br> </div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir="ltr"><br> <div class="m_2777987025696287046moz-cite-prefix">On 2018-09-13 11:34 AM, Cem Bassoy via ublas wrote:<br> </div> <br> <div dir="auto"><font size="2">We would only need to specify and implement one data structure ' tensor ' and if needed provide optimized functions for matrices. This simplifies the maintenance. <br> </font></div> </div> </blockquote> </div> </div> </blockquote> <blockquote type="cite" cite="mid:CADrR+FuKdZhgRwm9tpzWrq6m3ZC=1sUHJab7ddcVmfgr4vOYag@mail.gmail.com"> <div dir="ltr"> <div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div text="#000000" bgcolor="#FFFFFF"> <blockquote type="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" 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> <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> <br> <blockquote type="cite" cite="mid:CADrR+FuKdZhgRwm9tpzWrq6m3ZC=1sUHJab7ddcVmfgr4vOYag@mail.gmail.com"> <div dir="ltr"> <div class="gmail_quote"> <div> </div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div text="#000000" bgcolor="#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 ! :-)<br> <br> [...]<br> <br> Thanks,<br> <div class="moz-signature"><br> <div class="moz-signature"><img moz-do-not-send="false" src="cid:[email protected]" alt="Stefan" width="73" height="45"><br> <pre>-- ...ich hab' noch einen Koffer in Berlin... </pre> </div> </div> </body> </html> --------------10669544F7C5460D922E58E3 Content-Type: image/png; name="signature.png" Content-Transfer-Encoding: base64 Content-ID: <[email protected]> Content-Disposition: inline; filename="signature.png" iVBORw0KGgoAAAANSUhEUgAAAEkAAAAtCAYAAADiFkaQAAAABHNCSVQICAgIfAhkiAAAAAlw SFlzAAAVhwAAFYcBshnuugAAABl0RVh0U29mdHdhcmUAd3d3Lmlua3NjYXBlLm9yZ5vuPBoA AAVDSURBVGiB5dpprF1TFMDx33u0iqpWW6LmqWpIVUkoNVbM81ShiJifIakgxAc1VEzxwRiC 8EHwgaAilBhCg6BClJIYaqohSM1t6fVh7afXfffcd+55d8I/uXnvnL3PWuvus/daa699+e8x CFfhlnYb0qkMw40o4dA229KRDMLL+AnvYYX2mtOZXIj5+B4HttmWjmQkfsCreLDNtnQsV+Er fIsxbbalI1kDi/AnTm6zLR3LpSKazUJXm23JRauNHIyF+ByjWqy7boagB59gGR4QIbnZHCeW 2Z4t0DUgNsXh4k2Owxti+l/eAt0vt0jPgNgUn2FC2b2NsFjkK81M6E4UDntYE3UMmC6Rl9xU pW2WmE2bNUn3OPzsX7A/OxC/q+4wrxGDtE3GszvgmIJ6h+CtJH/7gjJaxiO4P6PtSvEltqjS tifmYXhBvXeJAPF2wedbxmgswd4Z7bfgR30j3Dr4FFsV1HsmZmMOpheU0TJ6hE9YKaN9Hm6v uNeF53F+QZ2T8IFYYouxZkE5LeNhPJHRNgXfiVlTzikiPeguoG8UFmBXkWE/WkBGS+kWg1Bt uo/AXOxRcX8kvhFfsl668BhmpusPMK2AnJaytXDKk7EyrhNlihfFbnztKs/chocK6jsbLwn/ Nl5E1NULymoZ08RWYDUMxUE4UiSR1dhQVAuL5EwrieDQu0QvEzlYx3M93q+j/724oUG638UJ DZLVVJ4SPiIPY8XWYa0G6N1cpB0jGiCrLsojTVY4r2QTEWnyMBN34Ot6jKqgt/xyFF4Q/i8v Q3EA9jHAMs5kkaCtmqNvt8hRLsjRdwJ+U92R52VHvCPqRq/In0CuhRl4Uszk0gDt8Jr8kWdM Unh0P/0GiS3LPem6W/6Z2st2+CPpW08Ei81z6D1HnLn16pulAc5+cR1CJgmjd8honyAG/Qvh P8aLrcSjWLFOuw5PuhYLZ/1hP/3XFfWliWX3dhKuoTKxrYsVxQnDdmLNlvrpv376+1VG+0TL d+ZLcRZOFVP/jzpt+65MzvH+meEPFynHJtg2fcaLlzM39dkYV4sN9Rd16u7DfWJwds/R99zU d5WM9mmpvYTTsH/6v6eAXd2Wl0RK4mXOw0d4M9k9XfjU4cKhl8SW6XSRgBbdSPdhryR8do6+ M/FLjfapSdYPIhs/IF3fnUN2t76llddFhr1ELPWRNZ7fUpRRFogl2ju4S8TJ7tQcNtTkpSRw t3763SlqOVkcmeTcmq5HikH9DTvXeG6UOL+vjJofJ3lz+rGrl/KUZpQo+l2UZCxUvIYFdhGn HO+Jyl8Wj4m3m8WpyaD9yu71pHuLxCBUJoMjhO86Xd/606/p2Stqm98vTyc5P+FxcXjQgyPE pnuc2t/7b25Pgq6t0efVpCSLGUnG1hX3DxP5Tkk48Hl4VuQ+9wunW8kIy5fMQI+MBos95hUi LXlCROEFYpaXRIrxsUiHTpZxjjcsdVomsttqfCky6CzmiEHIeisbill2lCin1DpQ3CoZv1S+ RLcoXdgA+4qKxvyk92dR1egTpCakxl+EoyxniBjt8zKUjU7t8xtgOLGVKKm9vJtBFw62fLAq K6yIJG6pWL97ld3fMT00JUP4viJMZ7XXy0lJX7Ujq1YwRHYNH+HQlojwe7FwqOeJyDY445nR 4hcejeISMUjHNlBmw9ldnM6WROn1OdUdbLO4WXMPOBvGajgDh2j9L0YeFr6xyMHB/4bX0qft dPJb2kjkU22nUwdpmNjS5K2ANpVOHaSx6e/CtlqR6NRB6q0GfN5WKxKdOkhjRF72TLsNgb8A ty4jMPtjABcAAAAASUVORK5CYII= --------------10669544F7C5460D922E58E3-- --------------CDACC66EB9B6955BA5430E05-- --===============2680480859588026591== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline