Re: Deciding on tensor parameters
stefan via ublas <[email protected]> Thu, 13 Sep 2018 16:45:45 -0400
| Newsgroups | gmane.comp.lib.boost.ublas |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============7834866026350726178== Content-Type: multipart/alternative; boundary="------------E8313587CA1448BCA19C710A" Content-Language: en-US This is a multi-part message in MIME format. --------------E8313587CA1448BCA19C710A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2018-09-13 03:44 PM, Cem Bassoy via ublas wrote: > > > Am Do., 13. Sep. 2018 um 20:35 Uhr schrieb Stefan Seefeld via ublas > <[email protected] <mailto:[email protected]>>: > > > 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? Yeah. > >> >> 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. OK. Not sure how many people pay attention to this discussion, though. If you don't hear anything within a few days (a week at most, I'd say), I'd just move forward. Stefan -- ...ich hab' noch einen Koffer in Berlin... --------------E8313587CA1448BCA19C710A Content-Type: multipart/related; boundary="------------50ACDAC972246C061B88E69F" --------------50ACDAC972246C061B88E69F 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 03:44 PM, Cem Bassoy via ublas wrote:<br> </p> <blockquote type="cite" cite="mid:CADrR+Fsx5wh9rSRBYSFqZv8iqS+zBnPZAEf_gRuHi=Cy24Lzjg@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 20:35 Uhr schrieb Stefan Seefeld via ublas <<a href="mailto:[email protected]" moz-do-not-send="true">[email protected]</a>>:<br> </div> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div text="#000000" bgcolor="#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 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?<br> </div> </div> </div> </blockquote> <br> Yeah. <br> <blockquote type="cite" cite="mid:CADrR+Fsx5wh9rSRBYSFqZv8iqS+zBnPZAEf_gRuHi=Cy24Lzjg@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"> <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> </div> </blockquote> <div><br> </div> <div>So I will wait for more opinions before continuing to adjust the tensor class template.<br> </div> </div> </div> </blockquote> <br> OK. Not sure how many people pay attention to this discussion, though. If you don't hear anything within a few days (a week at most, I'd say), I'd just move forward.<br> <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> --------------50ACDAC972246C061B88E69F 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= --------------50ACDAC972246C061B88E69F-- --------------E8313587CA1448BCA19C710A-- --===============7834866026350726178== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline