Currently, NaT (not a time) does not have any special treatment when used
in comparison with datetime64/timedelta64 objects.
This means that it's equal to itself, and treated as the smallest possible
value in comparisons, e.g., NaT == NaT and NaT < any_other_time.
To me, this seems a little crazy
On Sun, Oct 11, 2015 at 12:57 AM, Bryan Van de Ven
wrote:
> Bokeh also uses TravisCI, and we automatically build deploy docs on "dev"
> builds and releases, using encrypted Travis variables to store the
> necessary credentials. In case any of that sounds useful, most of the
> machinery is in thes
Hi Nils,
I think performance will actually be better than I indicated, especially
for larger arrays, since `r.real**2 + r.imag**2` makes a quite unnecessary
intermediate arrays. With a `ufunc`, this can be done much faster. Indeed,
it should be no slower than `np.square` (which does more operation
Hey,
I use complex numbers a lot and obviously need the modulus a lot. However,
I am not sure if we need a special function for _performance_ reasons.
At 10:01 AM 9/20/2015, you wrote:
It is, but since that involves taking sqrt, it is *much* slower. Even now,
```
In [32]: r = np.arange(1)*(1
