I just did a quick test across all supported EPD platforms:
win-64: float96 No, float128 No
win-32: float96 No, float128 No
osx-64: float96 No, float128 Yes
osx-32: float96 No, float128 Yes
rh3-64: float96 No, float128 Yes
rh3-32: float96 Yes, float128 No
rh5-64: float96 No, float128 Yes
rh5-32: fl
Hi,
On Thu, Mar 15, 2012 at 10:26 PM, Ilan Schnell wrote:
> To be more precise. On both 32-bit and 64-bit Windows
> machines I don't see.float96 as well as np.float128
Do you have any idea why I am seeing float96 and you are not? I'm on
XP with the current sourceforge 1.6.1 exe installer with
To be more precise. On both 32-bit and 64-bit Windows
machines I don't see.float96 as well as np.float128
- Ilan
On Fri, Mar 16, 2012 at 12:22 AM, Matthew Brett wrote:
> Hi,
>
> On Thu, Mar 15, 2012 at 10:17 PM, Ilan Schnell wrote:
>> I'm seeing the same thing on both (64 and 32-bit) Windows
Hi,
On Thu, Mar 15, 2012 at 10:17 PM, Ilan Schnell wrote:
> I'm seeing the same thing on both (64 and 32-bit) Windows
> EPD test machines. I guess Windows does not support 128
> bit floats.
Do you mean there is no float96 on windows 32 bit as I described at
the beginning of the thread?
> I did
I'm seeing the same thing on both (64 and 32-bit) Windows
EPD test machines. I guess Windows does not support 128
bit floats.
I did some tests a few weeks ago, and discovered that also
on the Mac and Linux long long double is not really 128 bits.
If I remember correctly it was 80 bits: 1 (sign) +
Hi,
On Thu, Mar 15, 2012 at 9:41 PM, Val Kalatsky wrote:
> I does look like a joke.
> Here is print np.finfo(np.longdouble)
>
> In [2]: np.__version__
> Out[2]: '1.6.1'
>
> In [3]: np.flo
> np.float np.float32 np.float_ np.floor
> np.float16 np.float64 np.floating
On Thu, Mar 15, 2012 at 11:41 PM, Val Kalatsky wrote:
> I does look like a joke.
> Here is print np.finfo(np.longdouble)
>
> In [2]: np.__version__
> Out[2]: '1.6.1'
>
> In [3]: np.flo
> np.floatnp.float32 np.float_ np.floor
> np.float16 np.float64 np.floating np.
I does look like a joke.
Here is print np.finfo(np.longdouble)
In [2]: np.__version__
Out[2]: '1.6.1'
In [3]: np.flo
np.floatnp.float32 np.float_ np.floor
np.float16 np.float64 np.floating np.floor_divide
In [3]: print np.finfo(np.longdouble)
Machine parameters f
Hi,
On Thu, Mar 15, 2012 at 9:33 PM, Val Kalatsky wrote:
>
> I just happened to have an xp64 VM running:
> My version of numpy (1.6.1) does not have float128 (see more below what I
> get in ipython session).
> If you need to test something else please let me know.
Thanks a lot - that's helpful.
On Thursday, March 15, 2012, Charles R Harris
wrote:
>
>
> On Thu, Mar 15, 2012 at 10:17 PM, David Cournapeau
wrote:
>>
>>
>> On Thu, Mar 15, 2012 at 11:10 PM, Matthew Brett
wrote:
>>>
>>> Hi,
>>>
>>> Am I right in thinking that float96 on windows 32 bit is a float64
>>> padded to 96 bits?
>>
>>
I just happened to have an xp64 VM running:
My version of numpy (1.6.1) does not have float128 (see more below what I
get in ipython session).
If you need to test something else please let me know.
Val
---
Enthought Python Distribution -- www.enthought.com
Python 2.7.2 |EPD 7.2-2 (64-bit)| (defau
Hi,
On Thu, Mar 15, 2012 at 9:24 PM, Charles R Harris
wrote:
>
>
> On Thu, Mar 15, 2012 at 10:17 PM, David Cournapeau
> wrote:
>>
>>
>>
>> On Thu, Mar 15, 2012 at 11:10 PM, Matthew Brett
>> wrote:
>>>
>>> Hi,
>>>
>>> Am I right in thinking that float96 on windows 32 bit is a float64
>>> padded
Hi,
On Thu, Mar 15, 2012 at 9:17 PM, David Cournapeau wrote:
>
>
> On Thu, Mar 15, 2012 at 11:10 PM, Matthew Brett
> wrote:
>>
>> Hi,
>>
>> Am I right in thinking that float96 on windows 32 bit is a float64
>> padded to 96 bits?
>
>
> Yes
>
>>
>> If so, is it useful?
>
>
> Yes: this is what all
On Thu, Mar 15, 2012 at 10:17 PM, David Cournapeau wrote:
>
>
> On Thu, Mar 15, 2012 at 11:10 PM, Matthew Brett
> wrote:
>
>> Hi,
>>
>> Am I right in thinking that float96 on windows 32 bit is a float64
>> padded to 96 bits?
>
>
> Yes
>
>
>> If so, is it useful?
>
>
> Yes: this is what allows yo
On Thu, Mar 15, 2012 at 11:10 PM, Matthew Brett wrote:
> Hi,
>
> Am I right in thinking that float96 on windows 32 bit is a float64
> padded to 96 bits?
Yes
> If so, is it useful?
Yes: this is what allows you to use dtype to parse complex binary files
directly in numpy without having to car
Hi,
Am I right in thinking that float96 on windows 32 bit is a float64
padded to 96 bits? If so, is it useful? Has anyone got a windows64
box to check float128 ?
Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license
On Thu, Mar 15, 2012 at 4:02 PM, Nathaniel Smith wrote:
> I'm not sure what it would even mean to treat this kind of data as
> "flags", since you can't take the bitwise-or of two strings...
This makes a more sense outside of ndarrays, where you would do something like:
enum FLAG0 = 1, FLAG1 = 2,
On Thursday, March 15, 2012, Nathaniel Smith wrote:
> On Wed, Mar 14, 2012 at 1:44 AM, Mark Wiebe wrote:
>> On Fri, Mar 9, 2012 at 8:55 AM, Bryan Van de Ven
>> wrote:
>>>
>>> Hi all,
>>>
>>> I have started working on a NEP for adding an enumerated type to NumPy.
>>> It is on my GitHub:
>>>
>>>
Hi Chuck,
I think I let my frustration get the better of me, and the message
below is too confrontational. I apologize.
I truly would like to understand where you're coming from on this,
though, so I'll try to make this more productive. My summary of points
that no-one has disagreed with yet is h
Hi,
On Thu, Mar 8, 2012 at 3:14 PM, Matthew Brett wrote:
> Hi,
>
> On Wed, Mar 7, 2012 at 4:08 PM, Matthew Brett wrote:
>> Hi,
>>
>> I noticed a casting change running the test suite on our image reader,
>> nibabel:
>> https://github.com/nipy/nibabel/blob/master/nibabel/tests/test_casting.py
>>
On my machines anyway.
Running from numpy source directory.
non-existing path in 'numpy/distutils': 'site.cfg'
F2PY Version 2
numpy/core/setup_common.py:86: MismatchCAPIWarning: API mismatch detected,
the C API version numbers have to be updated. Current C api version is 6,
with checksum eb54c77ff
On Wed, Mar 14, 2012 at 1:44 AM, Mark Wiebe wrote:
> On Fri, Mar 9, 2012 at 8:55 AM, Bryan Van de Ven
> wrote:
>>
>> Hi all,
>>
>> I have started working on a NEP for adding an enumerated type to NumPy.
>> It is on my GitHub:
>>
>> https://github.com/bryevdv/numpy/blob/enum/doc/neps/enum.rst
Submitted the ticket at http://projects.scipy.org/numpy/ticket/2082
On Thu, Mar 15, 2012 at 1:24 PM, Gökhan Sever wrote:
>
>
> On Thu, Mar 15, 2012 at 1:12 PM, Pierre GM wrote:
>
>> Ciao Gökhan,
>> AFAIR, shrink is used only to force a collapse of a mask full of False,
>> not to force the cre
On Thu, Mar 15, 2012 at 1:12 PM, Pierre GM wrote:
> Ciao Gökhan,
> AFAIR, shrink is used only to force a collapse of a mask full of False,
> not to force the creation of such a mask.
> Now, it should work as you expected, meaning that it needs to be fixed.
> Could you open a ticket? And put me in
Ciao Gökhan,
AFAIR, shrink is used only to force a collapse of a mask full of False, not
to force the creation of such a mask.
Now, it should work as you expected, meaning that it needs to be fixed.
Could you open a ticket? And put me in copy, just in case.
Anyhow:
Your trick is a tad dangerous, as
On Thu, Mar 15, 2012 at 12:56 PM, Gökhan Sever wrote:
If not so, how can I return a set of False values if my masking condition
> is not met?
>
Self-answer: I can force the mask to be filled with False's, however unsure
if this is a safe operation.
I50 x = np.array([1, 1.1, 2, 1.1, 3])
I51 y =
Hello,
>From the masked_values() documentation ->
http://docs.scipy.org/doc/numpy/reference/generated/numpy.ma.masked_values.html
I10 np.ma.masked_values(x, 1.5)
O10
masked_array(data = [ 1. 1.1 2. 1.1 3. ],
mask = False,
fill_value = 1.5)
I12 np.ma.masked_values(x, 1.
On Mon, Mar 5, 2012 at 10:17 AM, Asher Langton wrote:
> This is a followup to my post from January
> (http://mail.scipy.org/pipermail/numpy-discussion/2012-January/059801.html)
> and the panel discussion at PyData this weekend. As a few people have
> suggested, a better approach than the MPI-broad
Le 09/03/2012 23:57, Ralf Gommers a écrit :
>
> The buildbot doesn't check the doc build. I've edited a few of the links.
Thanks for checking !
I had not realized that simply using the `numpy.package` notation was
enough to get a link to the package.
Best,
Pierre
signature.asc
Description: Op
Hi,
I'm glad to inform you about new release 0.38 (2012-March-15):
OpenOpt:
interalg can handle discrete variables (see MINLP for examples)
interalg can handle multiobjective problems (MOP)
interalg can handle problems with parameters fixedVars/freeVars
Many interalg improvements and some bug
30 matches
Mail list logo
