<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 2, 2017 at 2:39 PM, Marten van Kerkwijk <span dir="ltr"><<a href="mailto:m.h.vankerkwijk@gmail.com" target="_blank">m.h.vankerkwijk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Josef,<br>
<br>
Indeed, for some applications one would like to have different units<br>
for different parts of an array. And that means that, at present, the<br>
quantity implementations that we have are no good at storing, say, a<br>
covariance matrix involving parameters with different units, where<br>
thus each element of the covariance matrix has a different unit. I<br>
fear at present it would have to be an object array instead; other<br>
cases may be a bit easier to solve, by, e.g., allowing structured<br>
arrays with similarly structured units. I do note that actually doing<br>
it would clarify, e.g., what the axes in Vandermonde (spelling?)<br>
matrices mean.<br></blockquote><div><br></div><div>(I have problems remembering the spelling of proper names)</div><div>np.vander and various polyvander functions/methods</div><div><br></div><div>One point I wanted to make is that the units are overhead and irrelevant in the computation. It's the outcome that might have units.</div><div>Eg. polyfit could use various underlying polynomials, e.g. numpy.polynomial.chebyshev.chebvander(...) and various linear algebra and projection versions, and the output would still be the same units.</div><div><br></div><div>aside: I just found an interesting</div><div><a href="http://docs.astropy.org/en/latest/api/astropy.stats.biweight.biweight_midcovariance.html">http://docs.astropy.org/en/latest/api/astropy.stats.biweight.biweight_midcovariance.html</a></div><div>is pairwise, but uses asanyarray</div><div><br></div><div>e.g. using asarray (for robust scatter)</div><div><a href="https://github.com/statsmodels/statsmodels/pull/3230/files#diff-8fd46d3044db86ae7992f5d817eec6c7R473">https://github.com/statsmodels/statsmodels/pull/3230/files#diff-8fd46d3044db86ae7992f5d817eec6c7R473</a><br></div><div>I guess I would have problems replacing asarray by asanyarray.</div><div><br></div><div>one last related one</div><div>What's the inverse of a covariance matrix? It's just sum, multiplication and division (which I wouldn't remember), but for the computation is just np.linalg.inv or np.linalg.pinv which is a simple shortcut.</div><div><br></div><div><br></div><div>Josef</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
That said, there is truly an enormous benefit for checking units on<br>
"regular" operations. Spacecraft have missed Mars because people<br>
didn't do it properly...<br></blockquote><div><br></div><div><a href="https://twitter.com/search?q=2%20unit%20tests.%200%20integration%20tests">https://twitter.com/search?q=2%20unit%20tests.%200%20integration%20tests</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
All the best,<br>
<br>
Marten<br>
<br>
p.s. The scipy functions should indeed be included in the ufuncs<br>
covered; there is a fairly long-standing issue for that in astropy...<br>
<div class="gmail-HOEnZb"><div class="gmail-h5">______________________________<wbr>_________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/numpy-<wbr>discussion</a><br>
</div></div></blockquote></div><br></div></div>