On Sun, Nov 14, 2010 at 1:29 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Sun, Nov 14, 2010 at 12:21 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
Good point. I was trying to keep the fpeclear in front of the code to be
tested.
Yeah, I hadn't considered that possibility too
On Sat, Nov 13, 2010 at 7:41 PM, Charles R Harris charlesr.har...@gmail.com
wrote:
Hi All,
This is in reference to numpy ticket
#1671http://projects.scipy.org/numpy/ticket/1671and the comments on pull
request 13 https://github.com/numpy/numpy/pull/13. The original problem
was that the gcc
On Sat, Nov 13, 2010 at 6:41 PM, Charles R Harris charlesr.har...@gmail.com
wrote:
Hi All,
This is in reference to numpy ticket
#1671http://projects.scipy.org/numpy/ticket/1671and the comments on pull
request 13 https://github.com/numpy/numpy/pull/13. The original problem
was that the gcc
On Sun, Nov 14, 2010 at 7:07 AM, Charles R Harris charlesr.har...@gmail.com
wrote:
Another possible solution is like so:
static __attribute__ ((noinline)) int
fpecheck(int *status)
{
*status = PyUFunc_getfperr();
return 0;
}
static __attribute__ ((noinline)) int
fpeclear(int
On Sun, Nov 14, 2010 at 1:09 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Sun, Nov 14, 2010 at 7:07 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
Another possible solution is like so:
static __attribute__ ((noinline)) int
fpecheck(int *status)
{
*status =
On Sun, Nov 14, 2010 at 12:21 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
Good point. I was trying to keep the fpeclear in front of the code to be
tested.
Yeah, I hadn't considered that possibility too seriously. Hopefully as long
as the compiler doesn't see a reason to reorder,
Hi All,
This is in reference to numpy ticket
#1671http://projects.scipy.org/numpy/ticket/1671and the comments on
pull
request 13 https://github.com/numpy/numpy/pull/13. The original problem
was that the gcc compiler was reordering the instructions so that the
floating point flags were tested
