On Wed, Nov 21, 2012 at 3:44 AM, David Cournapeau courn...@gmail.com wrote:
It is rather simple, in that it expects a different, full installer
for each new combination. I would rather not complicate things too
much there, as it is working well for its purpose and is not easy to
modify. We
On Thu, Nov 22, 2012 at 6:20 AM, Francesc Alted franc...@continuum.io wrote:
As Nathaniel said, there is not a difference in terms of *what* is
computed. However, the methods that you suggested actually differ on
*how* they are computed, and that has dramatic effects on the time
used. For
On Nov 29, 2012, at 11:25 AM, Russell E. Owen ro...@uw.edu wrote:
P.S. the difference is:
- 10.6 (which requires MacOS X 10.6 or later) is 64-bit and requires
Slight clarification -- the 10.6 build is 32 and 64 bit Intel.
-Chris
___
Raul,
Thanks for doing this work -- both the profiling and actual
suggestions for how to improve the code -- whoo hoo!
In general, it seem that numpy performance for scalars and very small
arrays (i.e (2,), (3,) maybe (3,3), the kind of thing that you'd use
to hold a coordinate point or the
How about dropping support for python 2.5 also?
Im still dumfounded that people are working on projects where they
are free to use the latest an greatest numpy, but *have* to use a
more-than-four-year-old-python:
Python 2.6 (final) was released on October 1st, 2008.
so +1 on moving forward!
On Thu, Dec 13, 2012 at 3:01 PM, Bradley M. Froehle
brad.froe...@gmail.com wrote:
Yes, but the point was that since you can live with an older version on
Python you can probably live with an older version of NumPy.
exactly -- also:
How likely are you to nee the latest and greatest numpy but
Ralf,
Do these licenses allow fully free distribution of binaries? And are those
binaries themselves redistributive? I.e. with py2exe and friends?
If so, that could be nice.
-Chris
On Dec 14, 2012, at 1:01 PM, Ralf Gommers ralf.gomm...@gmail.com wrote:
Hi all,
Intel has offered to provide
On Sun, Dec 16, 2012 at 7:48 AM, klo klo...@gmail.com wrote:
NumPy 1.5 Beginner's Guide, Ivan Idris,
http://www.packtpub.com/numpy-1-5-using-real-world-examples-beginners-guide/book
Some reviews on first title:
http://gael-varoquaux.info/blog/?p=161
On Thu, Dec 27, 2012 at 8:44 AM, Nikolaus Rath nikol...@rath.org wrote:
I have an array that I know will need to grow to X elements. However, I
will need to work with it before it's completely filled.
what sort of work with it do you mean? -- resize() is dangerous if
there are any other views
On Sun, Dec 30, 2012 at 3:41 AM, Happyman bahtiyor_zohi...@mail.ru wrote:
nums=32
rows=120
cols=150
for k in range(0,nums):
for i in range(0,rows):
for j in range(0,cols):
if float ( R[ k ] [ i ] [ j ] ) ==
0.0:
why the
On Tue, Jan 1, 2013 at 6:50 AM, Schönberger Johannes
hannesschoenber...@gmail.com wrote:
I recently opened a new pull request which adds the functionality to
convert between degrees and degrees, minutes and seconds
(https://github.com/numpy/numpy/pull/2869).
The discussion is about whether
On Sun, Dec 30, 2012 at 6:40 PM, Happyman bahtiyor_zohi...@mail.ru wrote:
Again the same problem here I want to optimize my codes in order to avoid
Loop as well as to get quick response as much as possible. BUT, it seems
really confusing, would be great to get help from Python programmers !!!
On Sun, Jan 6, 2013 at 2:04 AM, Ralf Gommers ralf.gomm...@gmail.com wrote:
Which exact Python do we need to use on Mac? Do we need to use the
binary installer from python.org?
Yes, the one from python.org.
Or can I install it from source?
you could install from source using the same method
On Mon, Jan 7, 2013 at 5:31 AM, Matthew Brett matthew.br...@gmail.com wrote:
I updated my fork of bdist_mpkg with Python 3k support. It doesn't
have any tests that I could see, but I've run it on python 2.6 and 3.2
and 3.3 on one of my packages as a first pass.
Have you been in communication
On Thu, Jan 3, 2013 at 10:29 PM, Mike Anderson
mike.r.anderson...@gmail.com wrote:
In the Clojure community there has been some discussion about creating a
common matrix maths library / API. Currently there are a few different
fledgeling matrix libraries in Clojure, so it seemed like a
On Mon, Jan 7, 2013 at 10:19 AM, Robert Lupton the Good
r...@astro.princeton.edu wrote:
I am sympathetic with this attitude (Avoid using system Python for
anything), but I don't think it's the right one. For example, the project
I'm working on (HSC/LSST for astrofolk) is using python/C++ for
On Mon, Jan 7, 2013 at 6:09 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote:
Is it possible to install the dmg images without root access from the
command line?
I've never tried, but it looks like you can:
On Mon, Jan 7, 2013 at 10:23 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote:
http://www.commandlinefu.com/commands/view/2031/install-an-mpkg-from-the-command-line-on-osx
This requires root access. Without sudo, I get:
$ installer -pkg /Volumes/Python\ 2.7.3/Python.mpkg/ -target ondrej
On Tue, Jan 8, 2013 at 12:43 PM, Alan G Isaac alan.is...@gmail.com wrote:
New users don't use narrow-width dtypes... it's important to remember
1. I think the first statement is wrong.
Control over dtypes is a good reason for
a new use to consider NumPy.
Absolutely.
Because NumPy supports
On Wed, Jan 9, 2013 at 7:09 AM, Nathaniel Smith n...@pobox.com wrote:
This is a general issue applying to data which is read from real-world
external sources. For example, digitizers routinely represent their
samples as int8's or int16's, and you apply a scale and offset to get
a reading in
On Wed, Jan 9, 2013 at 2:35 AM, Mike Anderson
First -- is this a matrix library, or a general use nd-array
library? That will drive your design a great deal.
This is very useful context - thanks! I've had opinions in favour of both an
nd-array style library and a matrix library. I guess it
On Wed, Jan 9, 2013 at 2:57 AM, Mike Anderson
I'm hoping the API will be independent of storage format - i.e. the
underlying implementations can store the data any way they like. So the API
will be written in terms of abstractions, and the user will have the choice
of whatever concrete
Ondřej, Vincent, and Ralf (and others..)
Thank you so much for doing all this -- it's a great service to the
MacPython community.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/ORR(206) 526-6959 voice
7600 Sand Point Way NE (206)
Patrick,
Not a bug but is it a mis-feature?
See the recent thread: Do we want scalar casting to behave as it does
at the moment
In short, this is an complex issue with no easy answer...
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/ORR
On Wed, Jan 16, 2013 at 11:34 PM, Matthieu Brucher
Of course a += b is not the same as a = a + b. The first one modifies the
object a, the second one creates a new object and puts it inside a. The
behavior IS consistent.
Exactly -- if you ask me, the bug is that Python allows in_place
On Thu, Jan 17, 2013 at 6:26 AM, Matthew Brett matthew.br...@gmail.com wrote:
I am starting to wonder if we should aim for making
* scalar and array casting rules the same;
* Python int / float scalars become int32 / 64 or float64;
aren't they already? I'm not sure what you are proposing.
On Thu, Jan 17, 2013 at 5:04 PM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
So in the in the spirit of practicality beats purity -- Id like
accidental upcasting to be hard to do.
and then:
arr = arr + scalar
would yield the same type as:
arr += scalar
so we buy some
On Thu, Jan 17, 2013 at 5:19 PM, Olivier Delalleau sh...@keba.be wrote:
2013/1/16 josef.p...@gmail.com:
On Wed, Jan 16, 2013 at 10:43 PM, Patrick Marsh
patrickmars...@gmail.com wrote:
I could live with an exception for lossy down casting in this case.
I'm not sure what the idea here is --
On Thu, Jan 17, 2013 at 5:34 PM, Olivier Delalleau sh...@keba.be wrote:
Yes, I do understand that. The difference - as I understand it - is
that back in the day, numeric did not have the the float32 etc
scalars, so you could not do:
another_array = my_array * np.float32(4.0)
(please
On Fri, Jan 18, 2013 at 4:39 AM, Olivier Delalleau sh...@keba.be wrote:
Le vendredi 18 janvier 2013, Chris Barker - NOAA Federal a écrit :
If you check again the examples in this thread exhibiting surprising /
unexpected behavior, you'll notice most of them are with integers.
The tricky thing
On Fri, Jan 18, 2013 at 2:22 PM, Matthew Brett matthew.br...@gmail.com wrote:
I personally find 'fill' OK. I'd read:
a = np.empty((10, 10), fill=np.nan)
as
make an empty array shape (10, 10) and fill with nans
+1
simple, does the job, and doesn't bloat the API.
-Chris
--
On Tue, Feb 5, 2013 at 4:32 PM, Matthew Brett matthew.br...@gmail.com wrote:
4) Numpy-MKL requires the Intel runtime DLLs (MKL is linked statically
btw). I ship those with the installers and append the directory
containing the DLLs to os.environ['PATH'] in numpy/__init__.py. This is
a big
On Tue, Feb 5, 2013 at 5:01 PM, Matthew Brett matthew.br...@gmail.com wrote:
easy_install can install into virtualenvs from bdist_wininst
installers, at least the ones I have built...
really? cool! I never thought to try that!
Thanks,
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
I'm trying to weed out the issues here:
1) what should the binary installer for Windows look like:
* bdist_wininst is the obvious choice but apparently has issues
with the newer Windows security stuff -- the real solution is for
distutils to be fixed/use something else/ etc -- but is there
On Wed, Feb 6, 2013 at 3:16 PM, Matthew Brett matthew.br...@gmail.com wrote:
Can you clarify the people you think will get stuck? I think I'm
right in saying that anyone with a C extension should be able to build
them against numpy, by installing the free (as-in-beer) MS tools?
yup -- and
On Thu, Feb 7, 2013 at 11:38 AM, Matthew Brett matthew.br...@gmail.com wrote:
a) If we cannot build Scipy now, it may or may not be acceptable to
release numpy now. I think it is, you (Ralf) think it isn't, we
haven't discussed that. It may not come up.
Is anyone suggesting we hold the whole
On Thu, Feb 14, 2013 at 7:57 AM, Derek Homeier
de...@astro.physik.uni-goettingen.de wrote:
Where did you get the python3.2 from? Building the 1.7.0 release works for me
under 10.8 and Xcode 4.6
both with the system-provided /usr/bin/python2.7
That makes sense, as Apple probably built it with
AM, Steve Spicklemire st...@spvi.com wrote:
Ahhh... I didn't realize that important bit. Thanks... I'll try to see if I
can use xcode3 on 10.8.
thanks,
-steve
On Feb 14, 2013, at 10:58 AM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
On Thu, Feb 14, 2013 at 7:57 AM, Derek Homeier
On Thu, Feb 21, 2013 at 4:16 AM, Matyáš Novák lo...@centrum.cz wrote:
You could also look into OpenBLAS, which is easier to build and
generally faster than ATLAS. (But alas, not supported by NumPy/SciPY AFAIK.)
It look slike OpenBLAS is BSD-licensed, and thus compatible with numpy/sciy.
It
On Mar 1, 2013, at 8:39 AM, Henry Gomersall h...@cantab.net wrote:
On Fri, 2013-03-01 at 17:29
Actually, I buy this could be useful.
Yes, it could.
How about a farange, designed for floating point values -- I
imagine someone smarter than me about for could write one that would
guarantee that
On Fri, Mar 8, 2013 at 8:23 AM, Sergio Callegari
sergio.calleg...@gmail.com wrote:
I have noticed that numpy introduces some unexpected type casts, that are
in some cases problematic.
There has been a lot of discussion about casting on this list in the
last couple months -- I suggest you
On Tue, Mar 12, 2013 at 7:05 AM, Dinesh B Vadhia
dineshbvad...@hotmail.com wrote:
Does that mean numpy won't work with freeze/create_executable type of tools
or is there a workaround?
I've used numpy with py2exe and py2app out of the box with no issues (
actually, there is an issue with too
On Wed, Mar 13, 2013 at 6:56 AM, Matt U mpuec...@mit.edu wrote:
Is it possible to create a numpy array which points to the same data in a
different numpy array (but in different order etc)?
You can do this (easily), but only if the different order can be
defined in terms of strides. A simple
On Thu, Mar 14, 2013 at 1:48 AM, Andrea Cimatoribus
andrea.cimatori...@nioz.nl wrote:
Thanks for all the feedback (on the SSD too). For what concerns biggus
library, for working on larger-than-memory arrays, this is really
interesting, but unfortunately I don't have time to test it at the
On Wed, Mar 20, 2013 at 9:03 AM, Robert Kern robert.k...@gmail.com wrote:
I highly recommend using an existing tool to write this interface, to
take care of the reference counting, etc for you.
Cython is particularly nice.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response
On Fri, Mar 22, 2013 at 2:39 PM, Colin J. Williams
cjwilliam...@gmail.com wrote:
I have updated to numpy 1.7.0 for each of the Pythons 2.7.3, 3.2.3 and
3.3.0.
...
The tests, which are available
here(http://web.ncf.ca/cjw/FP%20Summary%20over%20273-323-330.txt), show that
3.2 is slower, but not
On Mon, Apr 1, 2013 at 10:15 PM, Matthew Brett matthew.br...@gmail.com wrote:
Thank you for the compliment, it's more enjoyable than other potential
explanations of my confusion (sigh).
But, I don't think that is the explanation.
well, the core explanation is these are difficult and
On Tue, Apr 2, 2013 at 2:39 PM, Pauli Virtanen p...@iki.fi wrote:
As far as I understand (more knowledgeable people, please correct me),
Numpy's datetime handling in 1.7 is timezone-agnostic and works in UTC
(which is not a time zone). That is, datetime64 represents an absolute
point in time,
On Wed, Apr 3, 2013 at 6:24 AM, Sebastian Berg
sebast...@sipsolutions.net wrote:
the context where it gets applied. So giving the same strategy two
different names is silly; if anything it's the contexts that should
have different names.
Yup, thats how I think about it too...
me too...
dave.hirschf...@gmail.com wrote:
I found no reasonable way around it other than bypassing the numpy
conversion entirely
Exactly - we have come to the same conclusion. By the way, it's also
consistent -- an ISO string without a TZ is interpreted as a to mean
use the locale, but a datetime
On Wed, Apr 3, 2013 at 11:39 AM, Matthew Brett matthew.br...@gmail.com wrote:
It was not enough for me or the three others who will publicly admit
to the shame of finding it confusing without further thought.
I would submit that some of the confusion came from the fact that with
ravel(), and
On Wed, Apr 3, 2013 at 1:03 PM, Alan G Isaac alan.is...@gmail.com wrote:
On 4/3/2013 3:18 PM, huangkan...@gmail.com wrote:
In my view, the result should be a 1d array,
the same as I.A.dot(x).
But the maintainers wanted operations with matrices to
return matrices whenever possible. So
On Wed, Apr 3, 2013 at 11:53 PM, Dag Sverre Seljebotn
d.s.seljeb...@astro.uio.no wrote:
With top-posting I'm forced to write With respect to what you write
about the GIL issues, Bleh. In fact, in deep technical threads
it's very difficult for me to write top-posting at all, which is why I
On Wed, Apr 3, 2013 at 6:13 PM, Matthew Brett matthew.br...@gmail.com wrote:
We all agree that 'order' is used with two different and orthogonal
meanings in numpy.
well, not entirely orthogonal -- they are the some concept, used in
different contexts, so there is some benefit to their having
On Wed, Apr 3, 2013 at 6:02 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Wed, Apr 3, 2013 at 4:27 PM, Pauli Virtanen p...@iki.fi wrote:
Probably also TAI and UTC/Posix.
Converting from one format to the other is problematic since
all of them (except TAI afaik) require looking things up in
On Thu, Apr 4, 2013 at 11:26 AM, josef.p...@gmail.com wrote:
Before you answer that -- does anyone see a use case for the 'A' and
'K' flags that can't be reasonably easily accomplished with .view() or
asarray() or ???
What order does a[a2] use to create the returned 1-D array?
...
On Sun, Apr 7, 2013 at 6:26 AM, Valentin Haenel valen...@haenel.co wrote:
I am currently working with a C extension that wraps a C library.
The library contains a function that takes, amongst others, a 'void *'
as an argument. Now, I would like for that function to be able to read
the 'data'
On Sun, Apr 7, 2013 at 11:28 AM, Sergio Rojas sergi...@mail.com wrote:
I am using a function which under python 2.2.7 and numpy 1.6.1
returns a list (called d) whose elements are of type
numpy.string_ (see below).
Under python 3.3.0 and numpy 1.7.0 the same function returns the
list as an
On Sun, Apr 7, 2013 at 8:06 AM, Daπid davidmen...@gmail.com wrote:
On 7 April 2013 16:53, Happyman bahtiyor_zohi...@mail.ru wrote:
$pip install numpy # to install package numpy
as a warning, last I checked pip did not support binary installs, and
you really want a binary installer for
On Sun, Apr 7, 2013 at 2:34 PM, Steve Waterbury water...@pangalactic.us wrote:
Point taken -- just didn't want pip to be sold short.
I'm one of those spoiled Linux people, obviously ... ;)
I really like pip -- but it is missing what is really a key feature
for Windows (and to a slighltyl lessoe
Recent discussion has made it clear that the timezone handling in the
current (numpy1.7) version of datetime64 is broken. Below is a
discussion of some possible solutions, hopefully including most of the
comments made on the recent thread on this list.
On Wed, Apr 10, 2013 at 4:21 AM, Colin J. Williams
cjwilliam...@gmail.com wrote:
On Mon, Apr 8, 2013 at 12:24 PM, Chris Barker - NOAA Federal
Recent discussion has made it clear that the timezone handling in the
current (numpy1.7) version of datetime64 is broken. Below is a
discussion of some
On Wed, Apr 10, 2013 at 9:55 AM, Riccardo De Maria
riccardodema...@gmail.com wrote:
The library should handle correctly leap seconds, otherwise using unix time
as a floating point number is already sufficient for many applications.
well, we could have used floating point in datetime64, but
On Fri, Apr 12, 2013 at 9:52 AM, Riccardo De Maria
riccardodema...@gmail.com wrote:
Not related to leap seconds and physically accurate time deltas, I have just
noticed that SQLite has a nice API:
http://www.sqlite.org/lang_datefunc.html
that one can be inspired from. The source contains a
On Tue, Apr 16, 2013 at 9:32 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
Dude, it was the 60's, no one remembers.
I can't say I remember much from then -- but probably because I was 4
years old, not because of too much partying
-Chris
--
Christopher Barker, Ph.D.
On Tue, Apr 16, 2013 at 8:23 PM, Zachary Ploskey zplos...@gmail.com wrote:
The problem does not appear to exist on Linux with numpy version 1.6.2.
datetime64 was re-vampded a fair bit between 1.6 and 1.7
something is up here for sure with 1.7
We can be more dramatic about it:
In [5]:
On Wed, Apr 17, 2013 at 9:04 AM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
On Tue, Apr 16, 2013 at 8:23 PM, Zachary Ploskey zplos...@gmail.com wrote:
I'd say we need some more unit-tests!
speaking of which, where are the tests? I just did a quick poke at
github, and found:
https
On Tue, Apr 16, 2013 at 3:55 PM, Bob Nnamtrop bob.nnamt...@gmail.com wrote:
pss It would be most handy if datetime64 had a constructor of the form
np.datetime64(year,month,day,hour,min,sec) where these inputs were numpy
arrays and the output would have the same shape as the input arrays (but
On Wed, Apr 17, 2013 at 1:09 PM, Bob Nnamtrop bob.nnamt...@gmail.com wrote:
It would seem that before 1970 the dates do not include the time zone
adjustment while after 1970 they do. This is the source of the extra 7
hours.
In [21]: np.datetime64('1970-01-01 00')
Out[21]:
Folks,
I've discovered somethign intertesting (bug?) with numpy scalars ans
savz. If I save a numpy scalar, then reload it, ot comes back as
rank-0 array -- similar, but not the same thing:
In [144]: single_value, type(single_value)
Out[144]: (2.0, numpy.float32)
In [145]: np.savez('test.npz',
a bit more? I've never tried to use timezone
support with datetime, so I have no idea what goes wrong -- but it
looks reasonable to me. though it really punts on the hard stuff, so
maybe no point.
-Chris
Be Well
Anthony
On Fri, Apr 12, 2013 at 2:57 PM, Chris Barker - NOAA Federal
On Thu, Apr 18, 2013 at 4:04 AM, Robert Kern robert.k...@gmail.com wrote:
np.save() and company (and the NPY format itself) are for arrays, not
for scalars. np.save() uses an np.asanyarray() to coerce its input
which is why your scalar gets converted to a rank-zero array.
Fair enough -- so a
On Wed, Apr 17, 2013 at 6:05 PM, Benjamin Root ben.r...@ou.edu wrote:
Aren't we on standard time at Jan 1st? So, at that date, you would have
been -8.
yes, of course, pardon me for being an idiot.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
On Wed, Apr 17, 2013 at 11:27 PM, Joris Van den Bossche
jorisvandenboss...@gmail.com wrote:
Anyone tested this on Windows?
On Windows 7, numpy 1.7.0 (Anaconda 1.4.0 64 bit), I don't even get a wrong
answer, but an error:
In [3]: np.datetime64('1969-12-31 00')
Out[3]:
On Thu, Apr 18, 2013 at 8:31 AM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
Fair enough -- so a missing feature, not bug -- I'll need to look at
the docs and see if that can be clarified -
All I've found is the docstring docs (which also show up in the Sphinx
docs). I suggest
On Apr 18, 2013, at 11:33 PM, Nathaniel Smith n...@pobox.com wrote:
On 18 Apr 2013 01:29, Chris Barker - NOAA Federal chris.bar...@noaa.gov
wrote:
This has been annoying, particular as rank-zero scalars are kind of a
pain.
BTW, while we're on the topic, can you elaborate on this? I tend
On Thu, Apr 18, 2013 at 10:04 PM, K.-Michael Aye kmichael@gmail.com wrote:
On 2013-04-19 01:02:59 +, Benjamin Root said:
So why is there an error in the 2nd case, but no error in the first
case? Is there a logic to it?
When you change a dtype like that in the first one, you aren't
change? I'm trying to decide if this bugs me enough to work on
that.
-Chris
On Fri, Apr 19, 2013 at 8:03 AM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
On Apr 18, 2013, at 11:33 PM, Nathaniel Smith n...@pobox.com wrote:
On 18 Apr 2013 01:29, Chris Barker - NOAA Federal chris.bar
On Fri, Apr 19, 2013 at 8:12 AM, Ondřej Čertík ondrej.cer...@gmail.com wrote:
I'm pleased to announce the availability of the final NumPy 1.7.1 release.
Nice work -- but darn! I was hoping a change/fix to teh datetime64
timezone handlien could get into the next release -- oh well.
When do we
Hi folks,
In [264]: np.__version__
Out[264]: '1.7.0'
I just noticed that deep copying a rank-zero array yields a scalar --
probably not what we want.
In [242]: a1 = np.array(3)
In [243]: type(a1), a1
Out[243]: (numpy.ndarray, array(3))
In [244]: a2 = copy.deepcopy(a1)
In [245]: type(a2), a2
On Fri, Apr 19, 2013 at 8:46 AM, Nathaniel Smith n...@pobox.com wrote:
Nice work -- but darn! I was hoping a change/fix to teh datetime64
timezone handlien could get into the next release -- oh well.
That's probably too big a behavioural chance to go into a point
release in any case...
On Fri, Apr 19, 2013 at 10:21 AM, Robert Kern robert.k...@gmail.com wrote:
On Fri, Apr 19, 2013 at 8:45 PM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
Given that numpy scalars do exist, and have their uses -- I found this
wiki page to remind me:
http://projects.scipy.org/numpy
On Fri, Apr 19, 2013 at 11:31 AM, Nathaniel Smith n...@pobox.com wrote:
On 19 Apr 2013 19:22, Chris Barker - NOAA Federal chris.bar...@noaa.gov
wrote:
Anyway -- going to HDF, or netcdf, or role-your-own really seems like
overkill for this. I just need something fast and simple and it
doesn't
On Thu, Apr 25, 2013 at 8:19 AM, Dave Hirschfeld
dave.hirschf...@gmail.comwrote:
Hi All,I think it is time to start the runup to the 1.8 release. I don't
know of any outstanding blockers but if anyone has a PR/issue that they
feel
needs to be in the next Numpy release now is the time to make
On Mon, Apr 29, 2013 at 12:07 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
It would be good to get the utc-everywhere fix for datetime64 in there if
someone has time to look into it.
+1
I've been on vacation, so haven't written up the various notes and
comments as a NEP yet --
On Mon, Apr 29, 2013 at 12:12 PM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
It would be good to get the utc-everywhere fix for datetime64 in there if
someone has time to look into it.
I'll see if I can open an issue for the easy fix.
DONE: Issue #3290
--
Christopher
of this inconsistency
We've hit this with Iris (a met/ocean analysis package - see github), and
have had to add several workarounds.
On 19 April 2013 16:55, Chris Barker - NOAA Federal chris.bar...@noaa.gov
wrote:
Hi folks,
In [264]: np.__version__
Out[264]: '1.7.0'
I just noticed
On Apr 30, 2013, at 6:37 PM, Benjamin Root ben.r...@ou.edu wrote:
I can not think of any reason not to include these functions in v1.8.
+1
Of course, the documentation for discussed before: np.minmax(). My thinking
is that it would return a 2xN array
How about a tuple: (min, max)?
-Chris
On Wed, May 1, 2013 at 6:52 AM, Benjamin Root ben.r...@ou.edu wrote:
How about a tuple: (min, max)?
I am not familiar enough with numpy internals to know which is the better
approach to implement. I kind of feel that the 2xN array approach would be
more flexible in case a user wants all
On Thu, May 9, 2013 at 1:06 AM, Sudheer Joseph sudheer.jos...@yahoo.comwrote:
Thank you Gomersall,
However writing a formatted out put looks to be bit tricky with
python relative to other programing languages.
this is just plain wrong -- working with text in python is as easy, or
On May 18, 2013, at 1:53 AM, Daπid davidmen...@gmail.com wrote:
On 18 May 2013 07:11, Joe
You probably have a different version installed. Grab Python 2.7 from
python.org and install it;
Make sure you match 32/64 bit. The message is a bit out of date,
you'll get the same error if you try to
On Mon, May 20, 2013 at 8:54 AM, Bakhtiyor Zokhidov
bakhtiyor_zokhi...@mail.ru wrote:
what about the following example:
new_ceil(-0.24, 0.25)
-0.0
ceil rounds toward +inf (and floor towards -inf) -- this is exactly
what you want if you're doing what I think you are...(note that
round() rounds
On Wed, May 22, 2013 at 10:07 AM, Nicolas Rougier
U = np.zeros(1, dtype=[('x', np.float32, (4,4))])
U[0] = np.eye(4)
print U[0]
# output: ([[0.0, 1.875, 0.0, 0.0], [0.0, 0.0, 0.0, 0.0], [0.0, 0.0, 0.0,
1.875], [0.0, 0.0, 0.0, 0.0]],)
I get the same thing. Note:
In [86]: U[0].shape
On Wed, May 22, 2013 at 11:15 AM, eat e.antero.ta...@gmail.com wrote:
FWIW, apparently bug related to dtype of np.eye(.)
sort of -- the issue shows up when assigning a float64 array (default
for eye()) to a rank-0 array with a custom dtype that has a single
object filed that is an
On Thu, May 23, 2013 at 1:44 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
Just seeking some info here. The file stdint.h was part of the C99 standard
and has types for integers of specified width and thus could be used to
simplify some of the numpy configuration. I'm curious as to
On Tue, Jun 11, 2013 at 10:22 AM, Nils Becker n.bec...@amolf.nl wrote:
fwiw, homebrew is not macports. it's a more recent replacement that
seems to be taking over gradually.
And then there is (or was) fink
Anyway, it would be really nice if numpy could work well out-of-the
box with the
I have some code more or less 500 lines, but very messy code. All codes
containing several functions are in one module, besides, without
documentation and testing.
Could anyone give me some advice to organize my messy code in an accurate
style including test function as well?
This is a
On Wed, Jun 12, 2013 at 5:10 AM, Nathaniel Smith n...@pobox.com wrote:
Personally I think that overloading np.empty is horribly ugly, will
continue confusing newbies and everyone else indefinitely, and I'm
100% convinced that we'll regret implementing such a warty interface
for something that
On Wed, Jun 12, 2013 at 11:49 AM, Eric Firing efir...@hawaii.edu wrote:
On 2013/06/12 4:18 AM, Nathaniel Smith wrote:
Now imagine a different new version of this page, if we overload
'empty' to add a fill= option. I don't even know how we document that
on this page. The list will remain:
On Wed, Jun 12, 2013 at 12:00 PM, Phil Hodge ho...@stsci.edu wrote:
On 06/12/2013 02:55 PM, Eric Firing wrote:
I would interpret np.filled as a test, asking whether the array is
filled. If the function is supposed to do something related to
assigning values, the name should be a verb.
or a
1 - 100 of 163 matches
Mail list logo
