Hi,
I have couple beginners questions about numscons. What is the
preferred build system for numpy now, is it numscons? The README
doesn't mention numscons, so I am a bit confused what the future plan
is.
Also by doing:
$ python setupscons.py install
Running from numpy source directory.
Tracebac
On Thu, 05 Feb 2009 22:17:54 -0600
Travis Oliphant wrote:
> Gael Varoquaux wrote:
> > On Thu, Feb 05, 2009 at 05:08:49PM -0600, Travis E. Oliphant wrote:
> >
> >> I've been fairly quiet on this list for awhile due to work and family
> >> schedule, but I think about how things can improve regu
On Fri, Feb 6, 2009 at 6:11 PM, Darren Dale wrote:
> On Fri, Feb 6, 2009 at 5:18 PM, Pierre GM wrote:
>
>>
>> On Feb 6, 2009, at 4:25 PM, Darren Dale wrote:
>>
>> >
>> > I've been looking at how ma implements things like multiply() and
>> > MaskedArray.__mul__. I'm surprised that MaskedArray.__m
> I'm not going to modify the upstream source and risk introducing bugs.
BTW, there is a 64-bit version of the reference mersenne twister
implementation available [1].
Mike
[1] http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/VERSIONS/C-LANG/mt19937-64.c
_
On Fri, Feb 6, 2009 at 5:18 PM, Pierre GM wrote:
>
> On Feb 6, 2009, at 4:25 PM, Darren Dale wrote:
>
> >
> > I've been looking at how ma implements things like multiply() and
> > MaskedArray.__mul__. I'm surprised that MaskedArray.__mul__ actually
> > calls ma.multiply() rather than calling
> >
> I'm not going to modify the upstream source and risk introducing bugs.
I agree, its not worth risking it to save 2k of memory.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
On Fri, Feb 6, 2009 at 16:57, Michael S. Gilbert
wrote:
> Ok, so isn't this a slight waste of memory then (a doubling on 64-bit
> platforms)? Of course the tradeoff is whether you want to maintain two
> codebases for 32- and 64-bit or just one. The advantages of a single
> codebase probably o
Ok, so isn't this a slight waste of memory then (a doubling on 64-bit
platforms)? Of course the tradeoff is whether you want to maintain two
codebases for 32- and 64-bit or just one. The advantages of a single codebase
probably outweight an increase in memory usage since we're only talking abo
On Feb 6, 2009, at 4:25 PM, Darren Dale wrote:
>
> I've been looking at how ma implements things like multiply() and
> MaskedArray.__mul__. I'm surprised that MaskedArray.__mul__ actually
> calls ma.multiply() rather than calling
> super(MaskedArray,self).__mul__().
There's some under-the-
On Fri, Feb 6, 2009 at 3:30 PM, Robert Kern wrote:
> On Fri, Feb 6, 2009 at 03:22, Stéfan van der Walt
> wrote:
> > Hi Robert
> >
> > 2009/2/6 Robert Kern :
> >>> This could be implemented but would require adding information to the
> >>> NumPy array.
> >>
> >> More than that, though. Every func
On Fri, Feb 6, 2009 at 03:22, Stéfan van der Walt wrote:
> Hi Robert
>
> 2009/2/6 Robert Kern :
>>> This could be implemented but would require adding information to the
>>> NumPy array.
>>
>> More than that, though. Every function and method that takes an axis
>> or reduces an axis will need to b
On Sun, Feb 1, 2009 at 7:39 PM, Darren Dale wrote:
> On Sun, Feb 1, 2009 at 7:33 PM, Pierre GM wrote:
>
>>
>> On Feb 1, 2009, at 6:32 PM, Darren Dale wrote:
>> >
>> >
>> > Is there an analog to __array_wrap__ for preprocessing arrays on
>> > their way *into* a ufunc? For example, it would be nic
On Fri, Feb 6, 2009 at 15:24, Michael S. Gilbert
wrote:
> In numpy/random/mtrand/randomkit.c on line 159, the initial mersenne twister
> key (populated from /dev/urandom) gets bit-wise and'ed with 0x. I'm
> just curious as why this is done. A bit-wise and with all ones should just
> g
In numpy/random/mtrand/randomkit.c on line 159, the initial mersenne twister
key (populated from /dev/urandom) gets bit-wise and'ed with 0x. I'm
just curious as why this is done. A bit-wise and with all ones should just
give you your original quantity back, right? I don't think there
On Fri, Feb 6, 2009 at 09:31, Bruce Southey wrote:
> Hi,
> +1 on the idea but how will this work with other numpy methods?
>
> suppose *arr* is a structured array with dtype:
>
> [('name', 'S25'),
> ('height', float),
> ('age', int),
> ('gender', 'S8')
> ]
>
>
> Would you be able to first defin
On Fri, Feb 6, 2009 at 13:24, Suchindra Sandhu wrote:
> Hi,
>
> I accidently stumbled upon this odd behavior by numpy.any. The following
> code leaks memory -
>
> for i in xrange(1000):
> print N.any({'whatever': N.arange(1000)})
>
> Ofcourse, I called "any" on a dict object by acc
Hi all,
Just curious. Is it possible to use xblas with numpy ?
http://www.netlib.org/xblas/
Nils
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Hi Folks,
I wonder if there's a way to fill an existing array from an iterator
without creating a temporary array. That is, I'm looking for something
that has the effect of
>>> target = np.array(xrange(9), dtype = float)
>>> target[:] = np.fromiter(repeat(3.14159, 9), dtype=float)
withou
Hi,
I accidently stumbled upon this odd behavior by numpy.any. The following
code leaks memory -
for i in xrange(1000):
print N.any({'whatever': N.arange(1000)})
Ofcourse, I called "any" on a dict object by accident, but it should not
really leak memory.
I am running numpy versi
On Fri, Feb 6, 2009 at 12:09 PM, Christopher Barker
wrote:
> Darren Dale wrote:
> > I have a package (nearly ready to
> > submit to this list for request for comment) that uses a dict subclass
> > to describe the dimensionality of a quantity, like {m:1, s:-1}.
>
> I'm looking forward to that -- yo
Darren Dale wrote:
> I have a package (nearly ready to
> submit to this list for request for comment) that uses a dict subclass
> to describe the dimensionality of a quantity, like {m:1, s:-1}.
I'm looking forward to that -- you may have just saved me a bunch of coding!
-Chris
--
Christopher
I ended up solving my problem in SWIG, so I might as well post it
here. I just made my own 'array' and 'zeros' functions with floating
point precision as follows:
%pythoncode %{
from numpy import array as np_array
def array (n, type='float32'):
return(np_array(n, type))
from numpy impor
A Friday 06 February 2009, Francesc Alted escrigué:
> Hi,
>
> We would like to use the numpy.distutils machinery for numexpr and
> I'd like to add different compiler flags depending on the compiler
> used. Anbody knows a simple way to do this with numpy.distutils (ore
> plain distutils)?
I've figu
Hi,
We would like to use the numpy.distutils machinery for numexpr and I'd
like to add different compiler flags depending on the compiler used.
Anbody knows a simple way to do this with numpy.distutils (ore plain
distutils)?
Thanks,
--
Francesc Alted
Hi,
+1 on the idea but how will this work with other numpy methods?
suppose *arr* is a structured array with dtype:
[('name', 'S25'),
('height', float),
('age', int),
('gender', 'S8')
]
Would you be able to first define a list of columns such as
cols=['height', 'age']
arr[cols]
This woul
On Fri, Feb 6, 2009 at 4:22 AM, Stéfan van der Walt wrote:
> Hi Robert
>
> 2009/2/6 Robert Kern :
> >> This could be implemented but would require adding information to the
> >> NumPy array.
> >
> > More than that, though. Every function and method that takes an axis
> > or reduces an axis will ne
Hi Robert
2009/2/6 Robert Kern :
>> This could be implemented but would require adding information to the
>> NumPy array.
>
> More than that, though. Every function and method that takes an axis
> or reduces an axis will need to be rewritten. For that reason, I'm -1
> on the proposal.
Are you -1
Hi Travis
2009/2/6 Travis Oliphant :
> Thus newarr = arr[['name', 'age']].copy() would be exactly the same
> size as arr because elements are copied wholesale and each "row" is a
> single element in the NumPy array.Some infrastructure would have to
> be implemented at a fundamental level to
On Fri, Feb 06, 2009 at 12:20:37AM -0600, Robert Kern wrote:
> On Fri, Feb 6, 2009 at 00:13, Christopher Barker
> wrote:
> > Travis Oliphant wrote:
> >> What do people think
> >> about adding a default dictionary to every instance of a NumPy array.
> > It sound kind of heavyweight to me. I ten
On Thu, Feb 05, 2009 at 10:29:42PM -0600, Robert Kern wrote:
> >> I have no opinion on the above, as I don't have this use case. However, as
> >> you are talking about implementing something, I jump on the occasion to
> >> suggest another gadget, slightly related: I would like named axis.
> >> Supp
30 matches
Mail list logo
