Coatimundi wrote:
> I have the latest cygwin environment and am using gcc 3.4.4. to build numpy.
>
> Configure works:
>
> python setup.py configure --compiler=mingw32
>
> Build fails:
>
> python setup.py build --compiler=mingw32
What Python are you using? It looks like you built Python
I have the latest cygwin environment and am using gcc 3.4.4. to build numpy.
Configure works:
python setup.py configure --compiler=mingw32
Build fails:
python setup.py build --compiler=mingw32
While building numpy.random.mtrand I get this:
_configtest.c:7:2: #error No _WIN32
an
Francesc Altet wrote:
>I see. Thanks for the explanation.
>
>
You deserve the thanks for the great testing of less-traveled corners of
NumPy. It's exactly the kind of thing needed to get NumPy ready for
release.
-Travis
---
Hello.
Starting from a freshly installed cygwin, I have built Python 2.5, ATLAS and
LAPACK all from source using gcc 3.4.4 (cygming special) for both the C and
f77 compilers.
Now I am trying to build NumPy from SVN. I have edited site.cfg so that
python setup.py config --compiler=mingw32
Francesc Altet wrote:
> Hi,
>
>
> However, for string values, numpy seems to work in a strange way.
> The numarray have an expected behaviour, IMO:
>
> In [100]: numarray.strings.array(buffer="a\x00b"*4, itemsize=4, shape=3)
> Out[100]: CharArray(['a', '', 'ba'])
>
>
I'm not sure why you thin
Francesc Altet wrote:
> Hi,
>
> I'm writing this here because the numpy Trac seems down:
>
> {{{
> Oops...
>
> Trac detected an internal error: The Trac Environment needs to be upgraded.
> Run trac-admin /home/scipy/trac/numpy upgrade"
> }}}
It's back up.
--
Robert Kern
"I have come to beli
Travis Oliphant wrote:
> Tim Hochberg wrote:
>
>> Francesc Altet wrote:
>>
>> It's not that the it's being built from ndarray, it's that the buffer
>> that you are passing it is read only.
>>
> This is correct.
>
>> In fact, I'd argue that allowing
>> the writeable flag to be set t
Tim Hochberg wrote:
> Francesc Altet wrote:
>
> It's not that the it's being built from ndarray, it's that the buffer
> that you are passing it is read only.
This is correct.
> In fact, I'd argue that allowing
> the writeable flag to be set to True in this case is actually a bug.
>
It's a
A Divendres 29 Setembre 2006 18:12, Tim Hochberg va escriure:
> It's not that the it's being built from ndarray, it's that the buffer
> that you are passing it is read only. In fact, I'd argue that allowing
> the writeable flag to be set to True in this case is actually a bug.
>
> Consider this sli
Francesc Altet wrote:
> Hello,
>
> Is the next a bug a feature?
>
> In [102]: f4=numpy.ndarray(buffer="a\x00b"*4, dtype="f4", shape=3)
>
> In [103]: f4
> Out[103]: array([ 2.60561966e+20, 8.94319890e-39, 5.92050103e+20],
> dtype=float32)
>
> In [104]: f4[2] = 2
> -
Hello,
Is the next a bug a feature?
In [102]: f4=numpy.ndarray(buffer="a\x00b"*4, dtype="f4", shape=3)
In [103]: f4
Out[103]: array([ 2.60561966e+20, 8.94319890e-39, 5.92050103e+20],
dtype=float32)
In [104]: f4[2] = 2
---
Hi,
I'm trying to build-up numpy arrays coming from buffers, and I'm getting a
somewhat unexpected result.
First, for numeric values, everything seems ok (i.e. the NULL character is
correctly interpretated), and works equally for both numarray and numpy:
In [98]: numarray.array("a\x00b"*4, dty
Hi,
I'm writing this here because the numpy Trac seems down:
{{{
Oops...
Trac detected an internal error: The Trac Environment needs to be upgraded.
Run trac-admin /home/scipy/trac/numpy upgrade"
}}}
Well, it seems that there are inconsistencies on creating arrays coming from
negative values
Travis Oliphant wrote:
> David Cournapeau wrote:
>
>> Hi,
>>
>>
>> What are the rules concerning storage with numpy ?
>>
> The rule is that a numpy array has "strides" which specify how many
> bytes to skip to get to the next element in the array. That's the
> internal model. There ar
14 matches
Mail list logo
