hi,
i have installed numpy (1.6.0) and scipy (0.9). , nose version is 1.0
i have intel cluster toolkit installed on my system. (11/069 version and
mkl 10.3). i have machine having intel xeon processor and rhel 5.2 x86_64
platform. i have installed it with intel compilers.
when i execute numpy.test
On Sun, Oct 30, 2011 at 7:18 AM, David Cournapeau wrote:
> On Thu, Oct 27, 2011 at 5:19 PM, Ralf Gommers
> wrote:
>> Hi David,
>>
>> On Thu, Oct 27, 2011 at 3:02 PM, David Cournapeau
>> wrote:
>>>
>>> Hi,
>>>
>>> I was wondering if we could finally move to a more recent version of
>>> compilers
30.10.2011 21:48, mark florisson kirjoitti:
> First, I'd like to report a bug. It seems ndarray does not implement
> tp_traverse or tp_clear, so if you have a reference cycle in an
> ndarray with dtype object none of those objects will ever be
> collected.
Indeed, this is missing. http://projects.
Hello,
First, I'd like to report a bug. It seems ndarray does not implement
tp_traverse or tp_clear, so if you have a reference cycle in an
ndarray with dtype object none of those objects will ever be
collected.
Secondly, please bear with me, I'm not a NumPy expert, but would it be
possible to ha
Hi,
On Sun, Oct 30, 2011 at 12:24 PM, Ralf Gommers
wrote:
>
>
> On Sat, Oct 29, 2011 at 11:55 PM, Matthew Brett
> wrote:
>>
>> Hi,
>>
>> On Sat, Oct 29, 2011 at 2:48 PM, Ralf Gommers
>> wrote:
>> >
>> >
>> > On Sat, Oct 29, 2011 at 11:36 PM, Matthew Brett
>> >
>> > wrote:
>> >>
>> >> Hi,
>> >>
Hi,
On Sun, Oct 30, 2011 at 11:37 AM, Chris Barker wrote:
> On 10/29/11 2:59 PM, Charles R Harris wrote:
>
>> I'm much opposed to ripping the current code out. It isn't like it is
>> (known to be) buggy, nor has anyone made the case that it isn't a basis
>> on which build other options. It also s
On Sat, Oct 29, 2011 at 11:55 PM, Matthew Brett wrote:
> Hi,
>
> On Sat, Oct 29, 2011 at 2:48 PM, Ralf Gommers
> wrote:
> >
> >
> > On Sat, Oct 29, 2011 at 11:36 PM, Matthew Brett >
> > wrote:
> >>
> >> Hi,
> >>
> >> On Sat, Oct 29, 2011 at 1:48 PM, Matthew Brett >
> >> wrote:
> >> > Hi,
> >> >
On 10/29/11 2:59 PM, Charles R Harris wrote:
> I'm much opposed to ripping the current code out. It isn't like it is
> (known to be) buggy, nor has anyone made the case that it isn't a basis
> on which build other options. It also smacks of gratuitous violence
> committed by someone yet to make a
On 10/29/11 2:48 PM, Ralf Gommers wrote:
> That's true, but I am hoping that the difference between - say:
>
> a[0:2] = np.NA
>
> and
>
> a.mask[0:2] = False
>
> would be easy enough to imagine.
>
>
> It is in this case. I agree the explicit ``a.mask`` is clearer.
Interesting
On Sun, Oct 30, 2011 at 11:38 AM, Matthieu Brucher
wrote:
> Hi David,
>
> Is every GPL part GCC related? If yes, GCC has a licence that allows to
> redistribute its runtime in any program (meaning the program's licence is
> not relevant).
Good point, I should have specified the dll in question:
Hi David,
Is every GPL part GCC related? If yes, GCC has a licence that allows to
redistribute its runtime in any program (meaning the program's licence is
not relevant).
Cheers,
Matthieu
2011/10/30 David Cournapeau
> Hi,
>
> While testing the mingw gcc 3.x -> 4.x migration, I realized that s
Hi,
While testing the mingw gcc 3.x -> 4.x migration, I realized that some
technical requirements in gcc 4.x have potential license implications.
In short, it is more difficult now than before to statically link
gcc-related runtimes into numpy/scipy. I think using the DLL is safer
and better, but
On Thu, Oct 27, 2011 at 5:19 PM, Ralf Gommers
wrote:
> Hi David,
>
> On Thu, Oct 27, 2011 at 3:02 PM, David Cournapeau
> wrote:
>>
>> Hi,
>>
>> I was wondering if we could finally move to a more recent version of
>> compilers for official win32 installers. This would of course concern
>> the next
Hi,
On Sun, Oct 30, 2011 at 2:38 AM, Berthold Höllmann
wrote:
> Matthew Brett writes:
>
>> Hi,
>>
>> Can anyone think of a good way to set a float128 value to an
>> arbitrarily large number?
>>
>> As in
>>
>> v = int_to_float128(some_value)
>>
>> ?
>>
>> I'm trying things like
>>
>> v = np.float
Matthew Brett writes:
> Hi,
>
> Can anyone think of a good way to set a float128 value to an
> arbitrarily large number?
>
> As in
>
> v = int_to_float128(some_value)
>
> ?
>
> I'm trying things like
>
> v = np.float128(2**64+2)
>
> but, because (in other threads) the float128 seems to be going t
A quick and dirty cython code is attached
Use:
>> import Float128
>> a = Float128.Float128('1E500')
array([ 1e+500], dtype=float128)
or
>> b = np.float128(1.34) * np.float128(10)**2500
>> b
1.3400779e+2500
Maybe there is also a way to do it in a pure python code via ctypes?
N
Hi,
On Sat, Oct 29, 2011 at 11:19 PM, Travis Oliphant
wrote:
Thanks again for your email, I'm sure I'm not the only one who
breathes a deep sigh of relief when I see your posts.
> I appreciate Nathaniel's idea to pull the changes and I can respect his
> desire to do that. It seemed like ther
17 matches
Mail list logo