Hi,
On Fri, Aug 23, 2013 at 1:38 PM, Matthew Brett wrote:
> Hi,
>
> On Fri, Aug 23, 2013 at 1:32 PM, Russell E. Owen wrote:
>> In article
>> ,
>> Matthew Brett wrote:
>>
>>> Hi,
>>>
>>> On Thu, Aug 22, 2013 at 12:14 PM, Russell E. Owen wrote:
>>> > In article
>>> > ,
>>> > Ralf Gommers wrot
Hi experts!
I wrote an algorithm for study stick percolation (i.e.: networks between line
segments that intersect between them). In my algorithm N sticks (line segments)
are created inside a rectanglar box of sides 'b' and 'h' and then, one by one,
the algorithm explores the intersection between
Hi,
On Fri, Aug 23, 2013 at 1:32 PM, Russell E. Owen wrote:
> In article
> ,
> Matthew Brett wrote:
>
>> Hi,
>>
>> On Thu, Aug 22, 2013 at 12:14 PM, Russell E. Owen wrote:
>> > In article
>> > ,
>> > Ralf Gommers wrote:
>> >
>> >> Hi all,
>> >>
>> >> Building binaries for releases is current
In article
,
Matthew Brett wrote:
> Hi,
>
> On Thu, Aug 22, 2013 at 12:14 PM, Russell E. Owen wrote:
> > In article
> > ,
> > Ralf Gommers wrote:
> >
> >> Hi all,
> >>
> >> Building binaries for releases is currently quite complex and
> >> time-consuming. For OS X we need two different mach
On 23 August 2013 16:59, Benjamin Root wrote:
> A lot of the code you have here can be greatly simplified. I would start
> with just trying to get rid of appends as much as possible and use
> preallocated arrays with np.empty() or np.ones() or the likes.
Also, if you don't know beforehand the fin
On Fri, Aug 23, 2013 at 8:15 AM, Charles R Harris
wrote:
> I use 'bBhHiIlLqQ' for the C types. Long varies between 32 & 64 bit,
> depending on the platform and 64 bit convention chosen. The C int is always
> 32 bits as far as I know.
Well, not in the spec, but in practice, probably. Maybe not on
On Fri, Aug 23, 2013 at 8:11 AM, Sebastian Berg
wrote:
>> So this is giving us a 64 bit int--not a bad compromise, but not a
>> python long--I've got to wonder why the alias is there at all.
>>
> It is there because you can't remove it :).
sure we could -- not that we'd want to
>> So while n
On Fri, Aug 23, 2013 at 8:59 AM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:
> On Aug 22, 2013, at 11:57 PM, David Cournapeau wrote:
>
> npy_long is indeed just an alias to C long,
>
>
> Which means it's likely broken on 32 bit platforms and 64 bit MSVC.
>
> np.long is an alias to
On Fri, 2013-08-23 at 07:59 -0700, Chris Barker - NOAA Federal wrote:
> On Aug 22, 2013, at 11:57 PM, David Cournapeau
> wrote:
>
>
>
> > arch -32 python -c "import numpy as np; print np.dtype(np.int);
> > print np.dtype(np.long)"
> > int32
> > int64
>
>
> So this is giving us a 64 bit int--
On Aug 22, 2013, at 11:57 PM, David Cournapeau wrote:
npy_long is indeed just an alias to C long,
Which means it's likely broken on 32 bit platforms and 64 bit MSVC.
np.long is an alias to python's long:
But python's long is an unlimited type--it can't be mapped to a c type at
all.
arch -32
On Fri, Aug 23, 2013 at 10:34 AM, Francesc Alted wrote:
> Hi José,
>
> The code is somewhat longish for a pure visual inspection, but my advice
> is that you install memory profiler (
> https://pypi.python.org/pypi/memory_profiler). This will help you
> determine which line or lines are hugging t
Hi José,
The code is somewhat longish for a pure visual inspection, but my advice is
that you install memory profiler (
https://pypi.python.org/pypi/memory_profiler). This will help you
determine which line or lines are hugging the memory the most.
Saludos,
Francesc
On Fri, Aug 23, 2013 at 3:58
On Fri, Aug 23, 2013 at 6:29 AM, Nathaniel Smith wrote:
> Probably the thing to do for reliable behaviour is to decide on the
> behaviour we want and then implement it "by hand". I.e., either clear the
> FP flags inside the ufunc loop (if we decide that log shouldn't raise a
> warning), or else c
Probably the thing to do for reliable behaviour is to decide on the
behaviour we want and then implement it "by hand". I.e., either clear the
FP flags inside the ufunc loop (if we decide that log shouldn't raise a
warning), or else check for nan and set the invalid flag ourselves.
(Checking for nan
On 8/22/2013 10:32 PM, Warren Weckesser wrote:
> Christoph
> reported that this code:
>
> ```
> import numpy as np
>
> data = np.array([-0.375, -0.25, 0.0])
> s = np.log(data)
> ```
>
> does not generate two RuntimeWarnings when it is run with numpy 1.7.1
> in a 32 bit Windows 8 environment (numpy
These things may depend on how the compiler implements various calls. Some
errors went the other way with Julian's SIMD work, i.e., errors getting set
that were not set before. I'm not sure what can be done about it.
On Thu, Aug 22, 2013 at 8:32 PM, Warren Weckesser <
warren.weckes...@gmail.com>
16 matches
Mail list logo
