Thanks Nathan,
That makes sense (compile using the oldest version of NumPy
we wish to support).
The information on https://github.com/MacPython/numpy-wheels
will probably be very useful too (I've been meaning to try out
appveyor at some point for Windows builds/testing).
Regards,
Peter
O
ld we use?
Thanks
Peter
On Thu, Nov 17, 2016 at 11:24 PM, Matti Picus wrote:
> Congrats to all on the release.Two questions:
>
> Is there a guide to building standard wheels for NumPy?
>
> Assuming I can build standardized PyPy 2.7 wheels for Ubuntu, Win32 and
> OSX64, how can
it is probably justified.
>>
It works for me. I can't *think* of a case where you could have a
np.diff on a string array and 'first' could be confused with an
element, since you're not allowed diff on strings in the present numpy
a
ier, i.e. you would have something in your np.diff like:
if keep_left:
if to_begin is None:
to_begin = np.take(a, [0], axis=axis)
else:
raise ValueError(‘np.diff(a, keep_left=False, to_begin=None)
can be used with either keep_left or to_begin, but not both.’)
Generally I
n the multidimensional case you have the somewhat unwieldy:
>>> np.diff(a, axis=axis, to_begin=np.take(a, 0, axis=axis))
rather than
>>> np.diff(a, axis=axis, keep_left=True)
which of course could just be an option upon what you already have.
Best,
Peter
__
the error on
users and just throw a warning for a couple of releases, along the
lines of:
WARNING int**int -> int is going to be deprecated in favour of
int**int->float in Numpy 1.16. To avoid seeing this message, either
use “from numpy import __future_float_power__” or explicitly
many options) which are numerically very heavy.
With this approach I usually wrap each method in python to check the
inputs for contiguity, pass in the sizes etc. and allocate the numpy
array for the result.
Peter
___
NumPy-Discussion mailing list
NumPy-Di
e],
[ True, False, True],
[ True, True, False]], dtype=bool)
>>> numpy.dot(A,A)
array([[ True, False, True],
[ True, True, False],
[ True, True, True]], dtype=bool)
>>>
Regards,
Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
function name suggests a correspondence that is
in practice not that helpful. With a time machine I’d suggest a
separate function for positive integer powers, however...
(ii) I think that ship has sailed, and particularly with e.g. a**3 the
numpy conventions are backed up by quit
On Sun, Apr 3, 2016 at 2:11 AM, Matthew Brett wrote:
> On Fri, Mar 25, 2016 at 6:39 AM, Peter Cock wrote:
>> On Fri, Mar 25, 2016 at 3:02 AM, Robert T. McGibbon
>> wrote:
>>> I suspect that many of the maintainers of major scipy-ecosystem projects are
>>>
ago I wrote a C-code with ctypes to do this sort of
mirroring trick on an (N,N,N) numpy array of fft weights (where you
can exploit the 48-fold symmetry of using interchangeable axes), which
was pretty useful since I had N^3 >> 1e9 and the weight function was
quite expensive. Obviously the (N,M) case doesn't allow quite so much
optimization but if it could be interesting then PM me.
Best,
Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
a general availability of wheels in the numpy-ecosystem :)
In the case of Travis CI, their VM images for Python already have a version
of NumPy installed, but having the latest version of NumPy and SciPy etc
available as Linux wheels would be very nice.
Peter
P.S.
As an aside, PyPI seems to be
On Thu, Mar 24, 2016 at 6:37 PM, Nathaniel Smith wrote:
> On Mar 24, 2016 8:04 AM, "Peter Cock" wrote:
>>
>> Hi Nathaniel,
>>
>> Will you be providing portable Linux wheels aka manylinux1?
>> https://www.python.org/dev/peps/pep-0513/
>
> Matthew B
use within automated
testing frameworks like TravisCI where currently having to
install NumPy (and SciPy) from source is an unreasonable
overhead.
Many thanks to everyone working on this,
Peter
On Tue, Mar 15, 2016 at 11:33 PM, Nathaniel Smith wrote:
> Hi all,
>
> Just a heads-up tha
ce I’d be
prepared to write something more ugly.
I don’t mind geomspace(), but if you are brainstorming
>>> linlogspace(start, end) # i.e. ‘linear in log-space’
is ok for me too.
Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
l taken and I am quite mistaken. If you
pick some values like uniform(low, low * (1+2**-52)) then you can hit
your endpoints pretty easily. I am out of practice making
pathological tests for double precision arithmetic.
I guess my suggestion would be to add the deprecation warning and
change the docst
ble-precision arithmetic, you are going to have to make several
petabytes of random data before you hit an endpoint...
Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
lready sorted.
>>> from iccpy.utils import match
>>> print match(A,B)
[ 1 2 0 -1]
Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
essage after and addressed the problem in a different
way to your suggestion (passing in a flag instead). It'd be great to
have your input on the PR though (maybe github or pm me, to avoid
flooding the mailing list).
Best,
Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
>> > assert_almost_equal
>> > TypeError: Cannot cast array data from dtype('complex128') to
>> dtype('float64') according to the rule 'safe'
>>
>>
>
> Hi Peter, that error is unrelated to assert_almost_equal. What hap
hould be (complex
or no complex allowed). Should my test be changed or the
assert_almost_equal?
Best,
Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
eans we don't have any comparable download metrics
to gauge 32 bit vs 64 bit Windows usage, but personally I'm
quite happy for NumPy to phase out their 32 bit Windows
installers (and then we can do the same).
I hope we can follow NumPy's lead with wheel distribution etc.
Thanks,
Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
> >
> > from itertools import chain
> > def fromiter_awesome_edition(iterable):
> > elem = next(iterable)
> > dtype = whatever_numpy_does_to_infer_dtypes_from_lists(elem)
> > return np.fromiter(chain([elem], iterable), dtype=dtype)
> >
> > I think this would be a huge win for usability.
lent improvement and you should submit a PR
> implementing it :-).
>
> "The interp fix" in question though is a regression in 1.10 that's blocking
> 1.10.2, and needs a quick minimal fix asap.
>
Good answer - as soon as I hit 'send' I wondered how many bu
rather than
>>> y = interp(mu, theta, m.real) + 1.0j*interp(mu, theta, m.imag)
which *sounds* like it might be simple and more (Num)pythonic.
Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
ut a dtype
(float64) that it silently promoted to, rather than the dtype that the
user provided, which generally seems like a bad idea. Could Numpy
somehow complain about the original dtypes in this case? Or at least
give a warning about the first promotion (e.g. loss of precision)?
Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
+= array([1],dtype=int64)
TypeError: Cannot cast ufunc add output from dtype('float64') to
dtype('uint64') with casting rule 'same_kind'
Where does the 'float64' come from?!?!
Peter
PS Thanks for all the great work guys, numpy is a fant
ons of the official releases:
http://sourceforge.net/blog/gimp-win-project-wasnt-hijacked-just-abandoned/
We would not want the same thing to happen to NumPy, but on
the other hand deleting all the old releases on SourceForge
would break a vast number of installation scripts/recipes.
Peter
On Thu, Ma
opose to push my
> master branch to https://github.com/numpy/numpy-vendor and remove the
> current https://github.com/numpy/vendor repo.
>
> I'll do this in a couple of days, unless there are objections by then.
>
> Ralf
Can you not just rename the repository on GitHub?
Pete
xt = '\n'.join(complete_log)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 72:
ordinal not in range(128)
Have any of you encountered a similar problem before?
Thanks in advance,
-Peter
The
om older versions of Biopython.
Accidental breakages aside, I personally would not use pickle for long
term storage. Domain specific data formats or something simple like
tabular data, or JSON seems safer.
Peter
___
NumPy-Discussion mailing list
NumPy-Dis
If it is GPL code that would be a problem, but in terms of scope it might
fit under Biopython given how much De Bruijn graphs are used in
current sequence analysis.
Regards,
Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
First, sorry for not responding to your other replies, there was a jam
in Thunderbird and I did not receive your answers.
The bits() seem to stay alive after deleting the image:
from PySide import QtGui
image = QtGui.QImage('/home/peter/code/pyTools/sandbox/images/faceDemo.jpg')
a =
Btw, I just wanted to file a bug at PySide, but it might be alright at
their end, because I can do this:
from PySide import QtGui
image = QtGui.QImage('/home/peter/code/pyTools/sandbox/images/faceDemo.jpg')
a = image.bits()
del image
a
#
On 11/26/2013 09:37 PM, Peter Rennert
myArray():
def __init__(self, shape, bits, strides):
self.__array_interface__ = \
{'data': bits,
'typestr': '
del image
b
# booom #
On 11/26/2013 08:12 PM, Peter Rennert wrote:
> Brilliant thanks, I will try out the "little clas
Brilliant thanks, I will try out the "little class" approach.
On 11/26/2013 08:03 PM, Nathaniel Smith wrote:
> On Tue, Nov 26, 2013 at 11:54 AM, Peter Rennert
> wrote:
>> Hi,
>>
>> I as the title says, I am looking for a way to set in python the base of
>
Hi,
I as the title says, I am looking for a way to set in python the base of
an ndarray to an object.
Use case is porting qimage2ndarray to PySide where I want to do
something like:
In [1]: from PySide import QtGui
In [2]: image =
QtGui.QImage('/home/peter/code/pyTools/sandbox/i
d state management as an exercise to the
scientist/analyst.
FWIW, I have CCed the Bokeh discussion list, which is perhaps a more
appropriate list for further discussion on this topic. :-)
-Peter
___
NumPy-Discussion mailing list
NumPy-Discussion
o/sharing/bundle/pwang/cars)
Our immediate short-term priorities for 0.3 are improving the layout
mechanism, incorporating large data processing into the plot server, and
investigating basic interop with Matplotlib objects.
-Peter
___
NumPy-Discussion mailing
f your data
is large, then the notebook will also get pretty big. (We will be working
on more efficient encodings in a future release.)
-Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Thu, Oct 24, 2013 at 7:39 AM, Jason Grout wrote:
> On 10/23/13 6:00 PM, Peter Wang wrote:
> >
> > The project website (with interactive gallery) is at:
> > http://bokeh.pydata.org
>
> Just a suggestion: could you put the source below each gallery image,
> like ma
DOM.
The full blog post announcement is here:
http://continuum.io/blog/bokeh02
The project website (with interactive gallery) is at:
http://bokeh.pydata.org
And the Git repo is:
https://github.com/ContinuumIO/bokeh
Cheers,
Peter
___
NumPy-Discussion ma
On Mon, Sep 23, 2013 at 10:53 PM, Charles R Harris
wrote:
> On Mon, Sep 23, 2013 at 3:18 PM, Charles R Harris wrote:
>> On Mon, Sep 23, 2013 at 2:42 PM, Peter Cock wrote:
>>>
>>> Hi Chuck,
>>>
>>> Could you clarify how we'd know if this is a prob
e'd know if this is a problem in a large package?
i.e. Is it just Python imports I need to double check, or also C level?
Thanks!
Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
d
against the NumPy C API (and the people doing this
probably will only have access to free compilers).
Regards,
Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
doesn't seem pressing.
-1 on removing old releases, sometimes they can be useful
for tracing an old bug or repeating an old analysis. They
still have some small value - and don't cost much to leave
online.
Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
can get to know (i) a way to read the footer lines (ii)
> to sort out the operation of os.system and subprocess.call output
> processing.
Don't use os.system, instead you should use subprocess:
http://docs.python.org/2/library/subprocess.html
The standard library module commands would
On Fri, May 24, 2013 at 3:02 PM, Warren Weckesser
wrote:
> On 5/24/13, Peter Cock wrote:
>>Warren wrote:
>>> Two more data points:
>>> On Ubuntu 12.04, using 64 bit builds of Python 2.7.4 (from Anaconda
>>> 1.5.0), and numpy built from source: numpy 1.6.1 giv
On Fri, May 24, 2013 at 2:47 PM, Warren Weckesser
wrote:
>
>Peter wrote:
>> ---
>> Successes
>> ---
>>
>> 64 bit Linux:
>>
>> $ python2.6
>> Python 2.6.6 (r266:842
On Fri, May 24, 2013 at 2:15 PM, Robert Kern wrote:
> On Fri, May 24, 2013 at 9:12 AM, Peter Cock wrote:
>> On Fri, May 24, 2013 at 1:59 PM, Emanuele Olivetti
>> wrote:
>>> Interesting. Anyone able to reproduce what I observe?
>>>
>>> Emanuele
>>
np.eye(2),
>>> size=1))
[[-0.57757621 1.09307893]]
>>> print(np.random.multivariate_normal(mean=np.zeros(2), cov=np.eye(2),
>>> size=np.int64(1)))
Traceback (most recent call last):
File "", line 1, in
File "mtrand.pyx", line 4161, in
mtrand.Rando
the archive my email seems to have gotten lost.
I noticed this from a manuscript in proof when the copy editor
pointed out http://numpy.scipy.org wasn't working.
As http://numpy.scipy.org used to be a widely used URL for
the project, and likely appears in many printed references
Hello all,
http://numpy.scipy.org is giving a GitHub 404 error.
As this used to be a widely used URL for the project,
and likely appears in many printed references, could
it be fixed to point to or redirect to the (relatively new)
http://www.numpy.org site please?
Thanks,
Peter
On Wed, Feb 20, 2013 at 11:23 PM, Robert Kern wrote:
> On Wed, Feb 20, 2013 at 11:21 PM, Peter Cock wrote:
>> On Wed, Feb 20, 2013 at 8:27 PM, Todd wrote:
>>>
>>> I am looking at documentation now, but a couple things from what I seen:
>>>
>>> Are you
still around that gave
you a different impression?
Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Wed, Feb 6, 2013 at 3:46 AM, Ondřej Čertík wrote:
> On Tue, Feb 5, 2013 at 12:22 PM, Ralf Gommers wrote:
>> On Tue, Feb 5, 2013 at 3:01 PM, Peter Cock
>> wrote:
>>>
>>> Hello all,
>>>
>>> Will the numpy 1.7.0 'final' be binary c
1.7 will be
the first release to support that. For older versions of Python I
can use NumPy 1.6 instead.
Thanks,
Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
the default compiler for Python 3,
by creating C:\Python33\Lib\distutils\distutils.cfg containing:
[build]
compiler=mingw32
Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Fri, Jan 4, 2013 at 12:49 AM, Nathaniel Smith wrote:
> On 4 Jan 2013 00:39, "Peter Cock" wrote:
>> I agree with Dag rather than Andrew, "Explicit is better than implicit".
>> i.e. What Nathaniel described earlier as the apparent consensus.
>>
>
On Fri, Jan 4, 2013 at 12:39 AM, Peter Cock wrote:
>> Since I've actually used NumPy arrays with specific low memory
>> types, I thought I should comment about my use case if case it
>> is helpful:
>>
>> I've only used the low precision types like np.uint8
(type
promotion overriding my deliberate memory management) are nice.
My preferences here would be for an exception, so I knew right away.
The other use case which comes to mind is dealing with low level
libraries and/or file formats, and here automagic type promotion
would probably be unwelcome.
Regards,
Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Tue, Nov 27, 2012 at 9:25 PM, Anthony Scopatz wrote:
> On Tue, Nov 27, 2012 at 2:08 PM, Fernando Perez
> wrote:
>>
>> On Thu, Nov 22, 2012 at 1:30 AM, Peter Cock
>> wrote:
>>
>> > Perhaps http://numfocus.org/ could take them on, or the PSF?
>>
and NumPy under Python 3.2 and 3.3
is still in progress. See:
https://github.com/travis-ci/travis-cookbooks/issues/48
https://github.com/travis-ci/travis-cookbooks/issues/89
This "ValueError: underlying buffer has been detached" was
one of the issues the TravisCI team had faced.
Pete
nsfer them than let them go to a domain squatter.
>
> Basically, if you want them, they're yours to have as of 12/3/12.
>
> Cheers,
>
> f
Perhaps http://numfocus.org/ could take them on, or the PSF?
(even if they don't have a specific use in mind immediatel
On Fri, Nov 16, 2012 at 10:08 AM, Christoph Gohlke wrote:
> On 11/16/2012 1:28 AM, Peter Cock wrote:
>> On Thu, Nov 15, 2012 at 6:15 PM, Christoph Gohlke wrote:
>>>
>>> Naturally the file would be named msvc10compiler.py but the name may be
>>> kept for comp
about the
Windows build system than I do)?
If it will be fixed in Python itself, then perhaps a manual hack like
this will be enough for NumPy in the short term. Otherwise, maybe
numpy needs to include its own copy of msvc9compiler.py (or
msvc10compi
On Wed, Nov 14, 2012 at 7:35 PM, Christoph Gohlke wrote:
>> ...
>> RuntimeError: Broken toolchain: cannot link a simple C program
>>
>> It appears a similar issue was raised before:
>> http://mail.scipy.org/pipermail/numpy-discussion/2012-June/062866.html
>&
Changing title to reflect the fact this thread is now about using
the Microsoft compiler rather than mingw32 as in the old thread.
On Sat, Nov 10, 2012 at 11:04 PM, Peter Cock wrote:
> On Sat, Nov 10, 2012 at 5:47 PM, Ralf Gommers wrote:
>>
>>
>>
>> On Tue, Nov 6,
ussion/2012-August/063597.html
If so, then under Windows (32 bit at least) where the Python.org
provided Python 3.3 is compiled with MSCV 2010 there are some
problems - see: https://github.com/numpy/numpy/pull/2726
Should an issue be filed for this?
Thanks,
Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Tue, Nov 13, 2012 at 12:36 AM, Peter Cock wrote:
>
> I've not yet run the numpy tests yet, but I think this means
> my github branches are worth merging:
>
> https://github.com/peterjc/numpy/commits/msvc10
>
Hi Ralf,
Pull request filed, assuming this gets applied to th
aining:
[build]
compiler=mingw32
Now I don't have to give a compiler switch and distutils will
default to using mingw32 with Python 3.3, and build and
install seem to work.
I've not yet run the numpy tests yet, but I think this means
my github branches are wo
On Sun, Nov 11, 2012 at 11:20 PM, Peter Cock wrote:
> On Sun, Nov 11, 2012 at 9:05 PM, Ralf Gommers wrote:
>>
>> Those changes look correct, a PR would be great.
>>
>
> I'll do that later this week - but feel free to do it yourself immediately
> if more con
s of the version number. Presumably
I can just use the values from the msvcr100.dll on my machine?
Thanks,
Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Sat, Nov 10, 2012 at 11:24 PM, Peter Cock wrote:
>
> I think part of the problem could be in numpy/distutils/misc_util.py
> where there is no code to detect MSCV 10,
>
> def msvc_runtime_library():
> "Return name of MSVC runtime library if Python was built with M
I meant to click on "save" not "send", anyway:
On Sat, Nov 10, 2012 at 11:13 PM, Peter Cock wrote:
>>
>> Either MSVC or MinGW 3.4.5. For the latter see
>> https://github.com/certik/numpy-vendor
>>
>> Ralf
>
> I was trying with mingw32 v
On Sat, Nov 10, 2012 at 5:47 PM, Ralf Gommers wrote:
> On Tue, Nov 6, 2012 at 6:49 PM, Peter Cock wrote:
>>
>> Dear all,
>>
>> Since the NumPy 1.7.0b2 release didn't include a Windows
>> (32 bit) installer for Python 3.3, I am considering compiling it
>>
On Sat, Nov 10, 2012 at 5:47 PM, Ralf Gommers wrote:
>
>
>
> On Tue, Nov 6, 2012 at 6:49 PM, Peter Cock
> wrote:
>>
>> Dear all,
>>
>> Since the NumPy 1.7.0b2 release didn't include a Windows
>> (32 bit) installer for Python 3.3, I am consider
Dear all,
Since the NumPy 1.7.0b2 release didn't include a Windows
(32 bit) installer for Python 3.3, I am considering compiling it
myself for local testing. What compiler is recommended?
Thanks,
Peter
___
NumPy-Discussion mailing list
f the November, per
Stephen's slides. It's taken a while to get some of the fundamentals
hashed out to a point that we were happy with, and that could form a solid
core to iterate on.
Cheers,
Peter
___
NumPy-Discussion mailing list
Nu
d sponsors. If your company or
organization would like some visibility in front of a few hundred
Python data hackers, please visit our sponsor information page:
http://nyc2012.pydata.org/sponsors/becoming/
Thanks,
Peter
___
NumPy-Discussion mailing
nd follow @PyDataConf on Twitter. Early registration ends in just
a few weeks, so register today!
http://pydata.eventbrite.com/
See you there!
-Peter Wang
Organizer, PyData NYC 2012
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http:
is matter? Having just official NumPy 64bit Windows packages
would still be very welcome.
Is the problem that whatever route NumPy goes down will have
potential implications/restrictions for how SciPy could proceed?
Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
s a big difference whether an
organization sees code as a means to an end, or an ends unto itself.
-Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ling or external contributions than
on the numpy-discussion and scipy-user lists.
Still, I hope you are able to make some contributions to numpypy,
because so far I've also found PyPy's numpy implementation too
limited for my usage.
Regards,
Peter
__
taking patches without them is risky.
I've been subscribed to the pypy-dev list for a while, but I
don't recall seeing you posting there. Have you tried to submit
any of your work to PyPy yet? Perhaps you should have
sent this message to pypy-dev instead?
(I am trying to be construc
On Tue, May 22, 2012 at 9:27 AM, Nathaniel Smith wrote:
> So starting in Python 2.7 and 3.2, the Python developers have made
> DeprecationWarnings invisible by default:
> http://docs.python.org/whatsnew/2.7.html#the-future-for-python-2-x
> http://mail.python.org/pipermail/stdlib-sig/2009-Novembe
t;
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of NumPy-Discussion digest..."
>
>
> Today's Topics:
>
> 1. physics simulation (Peter Plantinga)
> 2. Re: physics simulation (Tim
e 23, in
from numpy.linalg import lapack_lite
ImportError: libaf90math.so: cannot open shared object file: No such file
or directory
It looks like f2py cannot find libaf90math.so, located in
/opt/absoft10.1/shlib. How can I tell f2py where af90math is?
Thanks for the help!
Peter Plantinga
__
funded mandate, so it's perfectly possible we may get
a one-liner like "make Python scientific computing awesome." :-)
-Peter
Disclaimer: I work with Travis at Continuum.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
developing Numpy again, and that hardly seems scary.
-Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Sending this again (sorry Robert, this will be the second time
for you) since I sent from a non-subscribed email address the
first time.
On Sun, Jan 15, 2012 at 7:12 PM, Robert Kern wrote:
> On Sun, Jan 15, 2012 at 19:10, Peter wrote:
>> Hello all,
>>
>> Is there a recommend
ython, if
there is any sound in the files I don't care about it.
I had a look at OpenCV which has Python bindings,
http://opencv.willowgarage.com/documentation/python/index.html
however I had no joy compiling this on Mac OS X
with QuickTime support. Is this the best bet?
Than
Hi Armando,
No comment on the Java thing ;-)
However,
http://www.opengda.org/documentation/manuals/Diamond_SciSoft_Python_Guide/8.18/contents.html
is more up-to-date and we are on github too:
https://github.com/DiamondLightSource
Peter
On 9 December 2011 13:05, Vicente Sole wrote:
> Quot
You'd get a tuple
back from struct.unpack(...) which you can turn into
a numpy array if you need to.
Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Fri, Sep 16, 2011 at 10:49 AM, Peter
wrote:
> On Thu, Sep 15, 2011 at 11:34 AM, Peter
> wrote:
>> This may not be the best place to ask, but how should a
>> python script (e.g. setup.py) distinguish between real NumPy
>> and micronumpy? Or should I instead be lookin
e of? Is
ndarray.__mul__ supposed to work with sparse matrices? AFAIK scipy
does not provide a scipy.sparse.dot function and spmatrix.dot only
allows for "multiplication from the rhs" (ok.. one could directly call
__rmul__ but that's ugly).
best,
A = np.random.rand(10, 10)
S = sp.csr_matrix(A)
_ = np.dot(A, A) # this works OK
_ = np.dot(S, S) # this segfaults!
thanks,
Peter
--
Peter Prettenhofer
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/lis
reason does not sound very appealing :)
>
> Thoughts ?
Does this make any difference for producing 64bit Windows
installers?
Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
est 15 is a loop based version of 16, where Python wins. Test 18
is a loop based version of 19 (log), where the difference is small.
So in terms of numpy speed, your question just seems to be
about numpy.roll and how else one might achieve this result?
Peter
__
On Thu, Sep 15, 2011 at 11:34 AM, Peter
wrote:
> This may not be the best place to ask, but how should a
> python script (e.g. setup.py) distinguish between real NumPy
> and micronumpy? Or should I instead be looking to distinguish
> PyPy versus another Python implementation?
1 - 100 of 257 matches
Mail list logo
