04.11.2011 19:59, Pauli Virtanen kirjoitti:
[clip]
This makes inline binary ops
behave like Nn. Reductions are N. (Assignment: dC, reductions: N, binary
ops: PX, unary ops: PC, inline binary ops: Nn).
Sorry, inline binary ops are also PdX, not Nn.
--
Pauli Virtanen
; the payload of the RHS is neglected,
# the assigned value has the original LHS
# as the payload
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo
.
However, doesn't this have the issue that Nathaniel brought up earlier:
commutativity
unignore(x + y) != unignore(y + x)
As the definition concerns only what happens on assignment, it does not
have problems with commutativity.
--
Pauli Virtanen
change the masked data:
a[:] = b
which changes also masked values in `a`. That may be a bug.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
04.11.2011 23:29, Pauli Virtanen kirjoitti:
[clip]
As the definition concerns only what happens on assignment, it does not
have problems with commutativity.
This is of course then not really true in a wider sense, as an example
from T J shows:
a = 1
a += IGNORE(3)
# - a := a + IGNORE(3
operations rather than having it in binary ops.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
values?
Is there a real-word need to have (a) be true?
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
]` unchanged if it's ignored, and
having ignored values propagate creates the problem.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
23.11.2011 15:01, Fabrice Silva kirjoitti:
Hi folks,
how should I specify a PEP3118 buffer format that could be understand by
numpy as the following dtype:
dtype = [('t11', '|f8'), ('t22', '|f8'), ('t33', '|f8'),
('t23', '|f8'), ('t13', '|f8'), ('t12', '|f8')]
so that I can
the glossary list from `glossary.py` to
`doc/source/glossary.txt` in place of `automodule:: numpy.doc.glossary`
If that doesn't help, then something in the formatting of the glossary
list that makes Sphinx to choke (and it's certainly then a Sphinx bug).
--
Pauli Virtanen
01.12.2011 03:31, josef.p...@gmail.com kirjoitti:
[clip]
I thought np.dot is Lapack based and favors fortran order, but if the
second array is fortran ordered, then dot takes twice as long.
It uses C-LAPACK, and will make copies if the arrays are not in C-order.
--
Pauli Virtanen
docstring, especially `axis` and `shape`
are very common.
However, an example with the axis keyword could be useful.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
against MKL (check the build log), then one
possible reason could be different threading options passed to MKL.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
]
Since Numpy version 1.5, the new buffer protocol is supported.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
really know what is supposed to happen if the new
buffer protocol is supported by some class named say Foo. Could I then
do
x=Foo([1,2,3])
numpy.array([2,2,2])+x
and such operations?
Yes. You can try it out with Python's builtin memoryview class.
--
Pauli Virtanen
19.01.2012 18:21, Travis Oliphant kirjoitti:
I think the problem here is one of delegation and information.
I'm not even sure how the web-pages get updated at this point.
Does anyone on this list know? I think it would be a great idea
to move to github pages for the NumPy project at least.
is not a bug, but a documented feature that has
been around probably already since Numeric.
However, adding a new function could be possible.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo
Hi,
06.02.2012 20:41, Ralf Gommers kirjoitti:
[clip]
I've created https://github.com/scipy/scipy.github.com and gave you
permissions on that. So with that for the built html and
https://github.com/scipy/scipy.org-new for the sources, that should do it.
On the numpy org I don't have the
Hi,
08.02.2012 11:22, Scott Sinclair kirjoitti:
[clip]
I see that you've added the CNAME file. Now numpy.github.com is being
redirected to numpy.scipy.org (the old site).
As I understand it, whoever controls the scipy.org DNS settings needs
point numpy.scipy.org at numpy.github.com so that
the heuristics in place for elementwise operations.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
11.02.2012 20:44, Travis Oliphant kirjoitti:
How to people feel about moving the issue tracking for NumPy to Github?
It looks like they have improved their issue tracking quite a bit and
the workflow and integration with commits looks quite good from what I
can see.
The lack of
11.02.2012 22:02, Jason Grout kirjoitti:
[clip]
Are there any good github trac plugins? For example:
http://davglass.lighthouseapp.com/projects/21212/home
http://trac-hacks.org/wiki/GitPlugin (git, not github, but still maybe
useful)
The Numpy Scipy Trac is currently running on this:
-api.array.html#import_array
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
, as
i = arange(n)
a[i].shape == i.shape
It's probably possible to cut the overhead, though.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi,
15.02.2012 14:59, Ognen Duzlevski kirjoitti:
[clip]
Alright, it will happen sometime today and I will post a message announcing
so.
Ognen
Great! Once you have changed the records, we can adjust [1] the
numpy.github.com page [1] to deal with the new virtual host name.
Thanks,
Pauli
[1]
rounding error.
See http://www.nccs.nasa.gov/images/FloatingPoint_consistency.pdf
That would explain why the pattern you see is quasi-deterministic. The
other explanation would be using uninitialized memory at some point, but
that seems quite unlikely.
--
Pauli Virtanen
16.02.2012 14:14, josef.p...@gmail.com kirjoitti:
[clip]
We had other cases of several patterns in quasi-deterministic linalg
before, but as far as I remember only in the final digits of
precision, where it didn't matter much except for reducing test
precision in my cases.
In the random
16.02.2012 14:54, josef.p...@gmail.com kirjoitti:
[clip]
If I interpret you correctly, this should be a svd ticket, or an svd
ticket as duplicate ?
I think it should be a multivariate normal ticket.
Fixing SVD is in my opinion not sensible: its only guarantee is that A
= U S V^H down to
Hi,
16.02.2012 18:00, Nathaniel Smith kirjoitti:
[clip]
I agree, but the behavior is still surprising -- people reasonably
expect something like svd to be deterministic. So there's probably a
doc bug for alerting people that their reasonable expectation is, in
fact, wrong :-).
The problem
Hi,
16.02.2012 23:39, Travis Oliphant kirjoitti:
[clip]
* NumPy 1.8 to come out in July which will have as many ABI-compatible
feature enhancements as we can add while improving test coverage and code
cleanup. I will post to this list more details of what we plan to address
with it
with it is not that much fun.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
19.02.2012 05:38, Travis Oliphant kirjoitti:
[clip]
Sure. This list actually deserves a long writeup about that.
First, there wasn't a Cython-refactor of NumPy. There was a
Cython-refactor of SciPy. I'm not sure of it's current status.
I'm still very supportive of that sort of thing.
of the work in Numpy implementation is not actually in numerics,
but in figuring out the correct operation to dispatch the computations
to. So, this is one reason why Fortran is not considered.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy
and Scipy don't use VML.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
loading.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
27.02.2012 19:07, Alan G Isaac kirjoitti:
On 2/27/2012 1:00 PM, Paulo Jabardo wrote:
First of all '.' isn't international notation
That is in fact a standard designation.
http://en.wikipedia.org/wiki/Decimal_mark#Influence_of_calculators_and_computers
ISO specifies comma to be used in
the conversion script in the public sounds good. We could
perhaps also consider applying hosting for the Scipy tracker, too.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy
the size specified by the subtype.
A workaround is probably to specify a suitable tp_alloc routine yourself:
PyType_GenericAlloc,/* tp_alloc */
unitArray_new, /* tp_new */
_PyObject_Del /* tp_free */
--
Pauli Virtanen
breakpoints to relevant routines in your class and inside Numpy, and
then step through the execution with (c)gdb.
Automatic memory leak detection tools maybe don't help so much here, as
the problem is likely in wrong reference counting.
--
Pauli Virtanen
09.03.2012 21:05, Sameer Grover kirjoitti:
subroutine union ()
write(*,*)'Hello from Fortran90!!!'
end subroutine union
f2py is unable to wrap this function. Changing the name of the
subroutine from 'union' to something else works. I understand that
problems like these have been
10.03.2012 23:19, Sturla Molden kirjoitti:
[clip]
If the intention is to avoid Fortran dependency in NumPy, I am not sure
why this is better than a dependency on CBLAS and LAPACKE.
The CBLAS parts aren't compiled if the library is not available --- in
that case Numpy just falls back to a
foo.bar using the np.ctypeslib.ndpointer approach always fails
with a ctypes.ArgumentError:
In [5]: foo = ctypes.CDLL('foo.dll')
In [6]: foo.bar.argtpes = [np.ctypeslib.ndpointer(dtype=np.float64,
ndim=1, flags='C_CONTIGUOUS')]
Typo: argtpes - argtypes
Probably not Windows-specific :)
--
Pauli
accumulates the cost of passing objects through the emulation layer.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
14.03.2012 14:28, Pierre GM kirjoitti:
[clip]
Alas, the RuntimeError doesn't look like it's passed back to the interpreter,
which still crashes. (Adding a Py_Exit(-1) at the end of pyraise_runtime at
least let the interpreter do some extra cleaning after the fortran code
stopped,
but
Hi,
I moved projects.scipy.org Tracs to run on mod_python (instead of CGI),
in order to try to combat the present performance issues. Let's see if
this helps with the database is locked problem.
Please drop me a message if something stops working.
Pauli
Hi,
02.04.2012 22:47, Travis Oliphant kirjoitti:
The plan is use a different issue tracker.
We are trying out YouTrack right now and hope to
export the Trac database into YouTrack.
Certainly, I'm aware :)
However, was the plan to also migrate the Scipy Trac? I understood the
answer to
06.04.2012 00:57, Whitcomb, Mr. Tim kirjoitti:
[clip]
Did something go wrong with a build?
Seems so. As a workaround, you can read the documentation of the
released versions.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion
10.04.2012 06:52, Travis Oliphant kirjoitti:
[clip]
4) I'm still not sure about whether the IGNORED
concept is necessary or not. I really like the separation
that was emphasized between implementation (masks versus
bit-patterns) and operations (propagating versus non-propagating).
Pauli
Hi,
18.04.2012 19:57, Alan G Isaac kirjoitti:
http://docs.scipy.org/doc/numpy/reference/routines.matlib.html#module-numpy.matlib
promises a list of functions that does not appear (at the moment, anyway).
This doesn't seem to be due to a technical reason, but rather than
because nobody has
12.04.2012 18:43, Ralf Gommers kirjoitti:
[clip]
My current list of preferences is:
1. Redmine (if admin overhead is not unreasonable)
2. Trac with performance issues solved
3. Github
4. YouTrack
5. Trac with current performance
Redmine seems pretty nice, apparently has all the features
01.05.2012 08:52, Travis Oliphant kirjoitti:
[clip]
3. No attachments for issues (screenshots, supporting documents, etc.).
Having API access to data won't help you here.
Using gists and references to gists can overcome this. Also using an
attachment service like http://uploading.com/ or
01.05.2012 11:14, David Froger kirjoitti:
Excerpts from Travis Oliphant's message of mar. mai 01 01:39:26 +0200 2012:
If you have particular reasons why we should choose a particular CI service,
please speak up and let your voice be heard. There is still time to
make
a difference in what
01.05.2012 21:34, Ralf Gommers kirjoitti:
[clip]
The main problem with Github (besides the issues/PRs thing and no
attachments, which I can live with) is that to make it work we'll have
to religiously label everything. And because users aren't allowed to
attach labels, it will require a larger
01.05.2012 21:34, Ralf Gommers kirjoitti:
[clip]
At this point it's probably good to look again at the problems we want
to solve:
1. responsive user interface (must absolutely have)
Now that it comes too late: with some luck, I've possibly hit on what
was ailing the Tracs (max_diff_bytes
26.04.2012 03:11, Travis Oliphant kirjoitti:
[clip]
It would be nice if every pull request created a message to this list.
Is that even possible?
Unidirectional forwarding is possible, for instance using Github's API,
https://github.com/pv/github-pull-request-fwd
Github itself doesn't
05.05.2012 22:53, Ralf Gommers kirjoitti:
[clip]
would be great to get it done by end of June.To Charles' list
and Ralf's suggestions, I would add setting up a server that can
relay pull requests to the mailing list.
Don't know if you saw this, but it looks like Pauli is
11.05.2012 17:54, Frédéric Bastien kirjoitti:
In Theano we use a view, but that is not relevant as it is the
compiler that tell what is inplace. So this is invisible to the user.
What about a parameter to diagonal() that default to return a view not
writable as you said. The user can then
]
The backtrace looks like it does not use ACML. Does
from numpy.core._dotblas import dot
work?
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
/src/multiarray/multiarraymodule.c:847
This is also not using ACML. You'll need to adjust things until the line
from numpy.core._dotblas import dot
works. CBLAS is indeed needed.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy
://github.com/pv/scipy-build-makefile
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
fall into
a region where the floating point numbers are dense.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
01.06.2012 20:45, Jeremy Lecoeur kirjoitti:
I have been using the sparse matrix tools for a while to do all sort of
things and, using the same code that was working just fine, I now
encounter a problem when trying . I do have very large sparse matrices
and when i multiplying them the number
misleading ---
since 2008, many of the documentation edits went in the online way, and
these only show up in a single large commit, usually before releases.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org
Benjamin Root ben.root at ou.edu writes:
[clip]
a[sl] and a[3:5, 5:14] is equivalent to
sl = (slice(3, 5), slice(5, 14))
a[sl]
[clip]
which is also equivalent to
sl = np.s_[3:5, 5:14]
___
NumPy-Discussion mailing list
, complex64, complex128, float64, ...
et al. are types that represent scalar numbers, not arrays. That you get
an array out from `float64(some_array)` rather than a ValueError is
un-Pythonic. Happens to work, but probably for the wrong reasons.
--
Pauli Virtanen
to correct this, it needs a real restart of the
process.)
Longer term solution is to move out of mod_python (mod_wsgi likely, going to CGI
will create other performance problems), or to transition the stuff there to a
more beefy server.
--
Pauli Virtanen
on the point of clumsy administration.
This however leaves the other services still on the machine, although
after dropping Trac, the juice probably is enough for them.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http
that. Do I need to reinstall numpy from scratch everytimes
or is there a better way to do that?
Reinstallation is needed, but this is reasonably simple to automate,
check git bisect run. For instance like so:
https://github.com/pv/scipy-build-makefile/blob/master/bisectrun.py
--
Pauli Virtanen
27.09.2012 15:46, David Cournapeau kirjoitti:
[clip]
Ok, so scipy.org was down again because of trac. Unfortunately, the
machine on which scipy.org lives is the same as trac, and is a bit
messy.
Trac runs on new.scipy.org, which AFAIK *is* a different machine from
scipy.org.
Pauli
27.09.2012 21:45, Pauli Virtanen kirjoitti:
27.09.2012 15:46, David Cournapeau kirjoitti:
[clip]
Ok, so scipy.org was down again because of trac. Unfortunately, the
machine on which scipy.org lives is the same as trac, and is a bit
messy.
Trac runs on new.scipy.org, which AFAIK
Hi,
I'd like to link both C++ and Fortran code into a single
Python extension, using numpy.distutils (for scipy.special).
But it seems the distutils-based tools actually cannot do this?
Does someone know if there's a way to work around this?
--
Pauli Virtanen
Charles R Harris charlesr.harris at gmail.com writes:
On Sun, Oct 14, 2012 at 11:53 AM, Pauli Virtanen pav at iki.fi wrote:
Hi,
I'd like to link both C++ and Fortran code into a single
Python extension, using numpy.distutils (for scipy.special).
But it seems the distutils-based tools
/attachment/ticket/36/numpy-6-norm-change-
default.diff
Seems like the chances of learning the reason why this change was done
are pretty slim.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman
with missing select
module when compiling Python.
Apparently the machine you are using is not a standard Redhat installation,
but something on it is strange.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org
:
http://continuum.io/downloads.html
http://www.enthought.com/products/epd.php
as suggested earlier in this thread.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
clusters.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
format files inside
them, so you should be able to build them up by stuffing files saved
by np.save() into a zipfile.ZipFile.
However, a better option could be to use a another data format such
as hdf5.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
type(data)
numpy.ndarray
Maybe you have NaNs in the array? (i.e. np.isnan(data) is True)
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Larry Paltrow larry.paltrow at gmail.com writes:
[clip]
np.all(~np.isnan(data))
False
Seems to be all non-nan
No, it means you have NaNs in your data.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http
identical results from MATLAB (R2011b), Octave, Numpy, and
Scipy. Can you give an example matrix which behaves differently?
Note that Numpy and Scipy return exactly what LAPACK's *GEQRF routines
give, and Octave seems also to do this.
--
Pauli Virtanen
with it is somehow strange.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
)).
Not documented in the Python wrapper, though.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Bob Dowling rjd4+numpy at cam.ac.uk writes:
[clip]
I'm guessing that numpy.where() is evaluating the complete arccos and
arccosh arrays and therefore getting invalid arguments.
Now, I can turn off the warnings with numpy.seterr(invalid='ignore') but
that's not what I would regard as good
(..) or np.ndarray(...). It contains whatever that happens to be
at that location. It just happens that typical memory content when
viewed in floating point often looks like that.
[*] Except that the OS zeroes new memory pages given to the process.
Processes however reuse the pages they are given.
--
Pauli
potential users towards Github.
Cheers,
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
having compiled code, you can relatively easily wrap the
LAPACK routine you need using f2py.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
/master/scipy/special/specfun/specfun.f#L1091
It does not have asymptotic expansions for dealing with parts of
the complex plane where the computation via the recurrence does not
work.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion
are not
complete, and do not cover the whole complex plane (or the real axis).
Other functions (the more common ones), however, have very good
implementations.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http
)
This should solve the problem.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
://mail.scipy.org/mailman/listinfo/scipy-user
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
numpydoc raises errors..
Could this be fixed or am I doing something wrong?
Numpydoc hasn't been ported to Python 3 so far. This probably
wouldn't a very large amount of work --- patches are accepted!
--
Pauli Virtanen
___
NumPy-Discussion mailing
Jaakko Luttinen jaakko.luttinen at aalto.fi writes:
The files in numpy/doc/sphinxext/ and numpydoc/ (from PyPI) are a bit
different. Which ones should be modified?
The stuff in sphinxext/ is the development version of the package on
PyPi, so the changes should be made in sphinxext/
--
Pauli
of worms.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
and distribution infra is in place for Scipy,
putting it in scipy.linalg makes it more easily available for a larger
number of people than some random 3-rd party module.
We already ship low-level f2py bindings, so I don't see a reason for not
shipping Cython ones too.
--
Pauli Virtanen
. providing
the whole of Scipy :)
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
explanations are that either the routine called is
different in the two cases, or, the benchmark if somehow faulty.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
messing with the C API. The backwards
compatibility issue is also just a documentation issue, so nothing drastic.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
datetime type. A naive datetime is sort of datetime64[D] plus
HH:MM:SS, but not quite.
***
I think your point about using current timezone in interpreting user
input being dangerous is probably correct --- perhaps UTC all the way
would be a safer (and simpler) choice?
--
Pauli Virtanen
.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
1 - 100 of 995 matches
Mail list logo
