<div class="gmail_quote">On Thu, Jun 9, 2011 at 5:21 PM, Ralf Gommers <span dir="ltr"><<a href="mailto:ralf.gommers@googlemail.com">ralf.gommers@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div class="im">On Thu, Jun 9, 2011 at 11:54 PM, Mark Wiebe <span dir="ltr"><<a href="mailto:mwwiebe@gmail.com" target="_blank">mwwiebe@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div>On Thu, Jun 9, 2011 at 4:27 PM, Ralf Gommers <span dir="ltr"><<a href="mailto:ralf.gommers@googlemail.com" target="_blank">ralf.gommers@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div>On Thu, Jun 9, 2011 at 10:58 PM, Mark Wiebe <span dir="ltr"><<a href="mailto:mwwiebe@gmail.com" target="_blank">mwwiebe@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">On Thu, Jun 9, 2011 at 3:41 PM, Christopher Barker <span dir="ltr"><<a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a>></span> wrote:<div><br></div></div>
</blockquote></div><div>Your branch works fine for me (OS X, py2.6), no failures. Only a few deprecation warnings like:<br>/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py:336: DeprecationWarning: DType strings 'O4' and 'O8' are deprecated because they are platform specific. Use 'O' instead<br>
callableObj(*args, **kwargs)<br></div></div></blockquote><div><br></div></div><div>It looks like there are some '|O4' dtypes in 'lib/tests/test_format.py', testing the .npy file format. I'm not sure why I'm not getting this warning though.</div>
<div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">
<div>Mark Wiebe wrote:<br>> Because of the nature of datetime and timedelta, arange has to be<br>> slightly different than with all the other types. In particular, for<br>> datetime the primary signature is np.arange(datetime, datetime, timedelta).<br>
><br>> I've implemented a simple extension which allows for another way to<br>> specify a date range, as np.arange(datetime, timedelta, timedelta).<br><br></div></blockquote></div></div></blockquote></div><div>
Did you think about how to document which of these basic functions work with datetime? I don't think that belongs in the docstrings, but it may then be hard for the user to figure out which functions accept datetimes. And there will be no usage examples in the docstrings.<br>
</div></div></blockquote><div><br></div></div><div> I think documenting it in a 'datetime' section of the arange documentation would be reasonable. The main datetime documentation page would also mention the functions that are most useful.</div>
<div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>Besides docs, I am not sure about your choice to modify functions like arange instead of writing a module of wrapper functions for them that know what to do with the dtype. If you have a module you can group all relevant functions, so they're easy to find. Plus it's more future-proof - if at some point numpy grows another new dtype, just create a new module with wrapper funcs for that dtype.<br>
</div></div></blockquote><div><br></div></div><div>The facts that datetime and timedelta are related in a particular way different from other data types, and that they are parameterized types, both contribute to them not fitting naturally the current structure of NumPy. I'm not sure I understand the module idea, </div>
</div></blockquote></div><div><br>
Basically, use np.datetime.arange which understand the dtype, then calls np.arange under the hood. Or is just its own function, like the dtrange() Robert just suggested. It's pretty much the same as for the ma module, which reimplements or wraps many numpy functions that do not understand masked arrays.<br>
</div></div></blockquote><div><br></div><div>I'm not a big fan of the way the ma module works, it doesn't integrate naturally and orthogonally with all the other features of NumPy. It's also an array subtype, quite different from a dtype. We don't have np.bool.arange, np.int8.arange, etc, and the abstraction used by arange built into the custom data type mechanism is too weak too support the needs of datetime. I'd like to use the requirements of datetime as a guide to molding the future design of the data type system, and if we make datetime a second-class citizen because it doesn't behave like a float, we're not going to be able to discover the possibilities.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div class="gmail_quote"><div>I would rather think that since it's a built-in NumPy data type, it should work with the regular NumPy functions wherever that makes sense. </div>
</div></blockquote></div><div><br>That doesn't make sense to me. Being a dtype that happens to be shipped with numpy doesn't make it more special than other dtypes. <br></div></div></blockquote><div><br></div><div>
This isn't making it more special, it's just conforming the natural NumPy way to how datetime/timedelta operates. If overloading the 'stop' parameter to support a relative stop based on the type system is going a step too far, that's easy to pull back, and I support Robert's idea of adding the deltarange function.</div>
<div><br></div><div>Cheers,</div><div>Mark</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div><br>Ralf<br><br></div></div>
<br>_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
<br></blockquote></div><br>