Dan Goodman thesamovar.net> writes:
...
> I got around 5x slower. Using numexpr 'dumbly' (i.e. just putting the
> expression in directly) was slower than the function above, but doing a
> hybrid between the two approaches worked well:
>
> def timefunc_numexpr_smart(
Julian Taylor googlemail.com> writes:
>
> On 01.12.2013 22:59, Dan Goodman wrote:
> > Julian Taylor googlemail.com> writes:
> >> your sin and exp calls are loop invariants, they do not depend on the
> >> loop iterable.
> >> This allows to move the
Julian Taylor googlemail.com> writes:
> your sin and exp calls are loop invariants, they do not depend on the
> loop iterable.
> This allows to move the expensive functions out of the loop and only
> leave some simple arithmetic in the body.
A! I feel extremely stupid for not realising this!
Julian Taylor googlemail.com> writes:
> can you show the code that is slow in numpy?
> which version of gcc and libc are you using?
> with gcc 4.8 it uses the glibc 2.17 sin/cos with fast-math, so there
> should be no difference.
In trying to write some simple code to demonstrate it, I realised i
, maybe it would be worth adding as a feature for future
versions?
Thanks,
Dan Goodman
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On 06/10/2012 18:17, Ralf Gommers wrote:
> Do you mean scalars or arrays? For me set_printoptions only affects
> arrays and not scalars. Both float32 and float64 arrays work as advertised:
Yep, I mean scalars (although as Warren noted, it also affects e.g.
array(1.23456789)).
Dan
__
Hi,
numpy.set_printoptions(precision=...) doesn't affect single floats, even
if they are numpy floats rather than Python floats. Is this a bug or is
there some reason for this behaviour? I ask because I have a class that
derives from numpy.float64 and adds some extra information, and I'd like
On 22/05/2012 18:20, Nathaniel Smith wrote:
> I don't know of anything that the docs are lacking in particular. It's
> just that subclassing in general is basically a special form of
> monkey-patching: you have this ecosystem of cooperating methods, and
> then you're inserting some arbitrary change
mp;r=a6117f5e81ec00abcfb037f0f9da2937bb2ea47f
The author of original version is Dan Goodman
# FAST FRACTALS WITH PYTHON AND NUMPY
Thanks Sebastian. This one is much faster 2.7s on my laptop with
the same dimensions/iterations.
It uses a better datastructures -- it only keeps track of points that
still need t
Dag Sverre Seljebotn wrote:
> Well, such a mechanism would mean that your code could not be reused
> reliably by other code (because, what if two different codebases sets
> different defaults...). So requiring any such mechanism would make it
> easier to write non-reusable code, which is general
Robert Kern wrote:
> On Fri, Jun 26, 2009 at 03:39, Christian K. wrote:
>> John Schulman caltech.edu> writes:
>>
>>> I'm trying to reduce the memory used in a calculation, so I'd like to
>>> switch my program to float32 instead of float64. Is it possible to
>>> change the numpy default float size,
David Warde-Farley wrote:
> On 29-Apr-09, at 5:49 PM, Dan Goodman wrote:
>
>> Thanks David, that's nice but unfortunately that Python loop will kill
>> me. I'm thinking about some simulation code I'm writing where this
>> operation will be carried out m
Stéfan van der Walt wrote:
> 2009/4/29 Dan Goodman :
>> Here's the problem I want to write vectorised code for. I start with an
>> array of indices, say I=array([0,1,0,2,0,1,4]), and I want to come up
>> with an array C that counts how many times each index has been
Robert Kern wrote:
> On Wed, Apr 29, 2009 at 16:19, Dan Goodman wrote:
>> Robert Kern wrote:
>>> On Wed, Apr 29, 2009 at 08:03, Daniel Yarlett
>>> wrote:
>>>
>>>> As you can see, Current is different in the two cases. Any ideas how I
>>>
David Warde-Farley wrote:
> On 29-Apr-09, at 5:06 PM, Dan Goodman wrote:
>
>> Here's the problem I want to write vectorised code for. I start with
>> an
>> array of indices, say I=array([0,1,0,2,0,1,4]), and I want to come up
>> with an array C that counts
Robert Kern wrote:
> On Wed, Apr 29, 2009 at 08:03, Daniel Yarlett
> wrote:
>
>> As you can see, Current is different in the two cases. Any ideas how I
>> can recreate the behavior of the iterative process in a more numpy-
>> friendly, vectorized (and hopefully quicker) way?
>
> Use bincount().
Hi all,
Here's the problem I want to write vectorised code for. I start with an
array of indices, say I=array([0,1,0,2,0,1,4]), and I want to come up
with an array C that counts how many times each index has been seen so
far if you were counting through the array from the beginning to the
end,
> As you can see, Current is different in the two cases. Any ideas how I
> can recreate the behavior of the iterative process in a more numpy-
> friendly, vectorized (and hopefully quicker) way? And possibly also
> about why my intuitions concerning the semantics of the vectorized
> code are
Thanks Chris and Stefan,
In the end, I'm going to take both your advice and not do this after
all. Actually I worked out another way to do the same thing.
Essentially, rather than store a pointer I store a reference to the
array, and an array of indices in that array. Much safer and the things
Hi all,
I have a slightly strange idea for something I would like to do with
numpy which I guess probably doesn't exist, but I may be wrong. What I
want to do, essentially, is to have two arrays of equal size, say X and
Y, of pointers to doubles say. Then I want to do (in C notation) *x +=
*y
Can anyone explain the results below? It seems that for small matrices
dot(x,y) is outperforming dgemm(1,x,y,0,y,overwrite_c=1), but for larger
matrices the latter is winning. In principle it seems like I ought to be
able to always do better with inplace rather than making copies?
From looking
use C code to do this?
Many thanks in advance,
Dan Goodman
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Hi Anne,
Thanks for your reply. As you say there are a few different problems in here.
The first is about implementing a system of physical quantities with units. I
reviewed various options for this including the ones you mentioned (unum and
ScientificPython), but they all had some important featu
earch for relevant
information but nothing much came up. Plenty about how to do subclassing of
numpy array's, but that's not really my problem here - it's more specific than
that.
Many thanks in advance,
--
Dan Goodman
http://thesamovar.net/contact
Hi all,
I think this is a bug (I'm running Numpy 1.0.3.1):
>>> from numpy import *
>>> def f(x): return False
>>> all(f(x) for x in range(10))
True
I guess the all function doesn't know about generators?
Dan
___
Numpy-discussion mailing list
Numpy-d
25 matches
Mail list logo
