<br><br><div class="gmail_quote">On Fri, Jun 10, 2011 at 4:18 PM, Mark Wiebe <span dir="ltr"><<a href="mailto:mwwiebe@gmail.com">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><div></div><div class="h5">On Fri, Jun 10, 2011 at 12:56 AM, 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"><div class="gmail_quote"><div><div><div> </div></div></div><div>Maybe I'm misunderstanding this, and once you make a function work for datetime it would also work for other new dtypes. But my impression is that that's not the case. Let's say I make a new dtype with distance instead of time attached. Would I be able to use it with arange, or would I have to go in and change the arange implementation again to support it?<br>

</div></div></blockquote><div><br></div></div></div><div>Ok, I think I understand the point you're driving at now. We need NumPy to have the flexibility so that external plugins defining custom data types can do the same thing that datetime does, having datetime be special compared to those is undesirable. This I wholeheartedly agree with, and the way I'm coding datetime is driving in that direction.</div>

<div><br></div><div>The state of the NumPy codebase, however, prevents jumping straight to such a solution, since there are several mechanisms and layers of such abstraction already which themselves do not satisfy the needs of datetime and other similar types. Also, arange is just one of a large number of functions which could be extended individually for different types, for example if one wanted to make a unit quaternion data type for manipulating rotations, its needs would be significantly different. Because I can't see the big picture from within the world of datetime, and because such generalization takes a great amount of effort, I'm instead making these changes minimally invasive on the current codebase.</div>

<div><br></div><div>This approach is along the lines of "lifting" in generic programming. First you write your algorithm in the specific domain, and work out how it behaves there. Then, you determine what are the minimal requirements of the types involved, and abstract the algorithm appropriately. Jumping to the second step directly is generally too difficult, an incremental path to the final goal must be used.</div>

<div><br></div><div><a href="http://www.generic-programming.org/about/intro/lifting.php" target="_blank">http://www.generic-programming.org/about/intro/lifting.php</a></div></div>
<br></blockquote></div>Thanks for explaining, this makes sense to me now. <br><br>Ralf<br>