[SciPy-dev] more 64 Bit testing

[Arnd Baecker]

On Thu, 8 Dec 2005, Travis Oliphant wrote:

> Arnd Baecker wrote:

[...]

> >>Presently I see three problems
> >>a) the NAN stuff for cephes
> >>
> >>
> I think this one can be fixed with the right configuration settings.
> Notice in cephes/const.c there is already
> a bit-field definition of NAN and the only way 1.0/0.0 gets tried is if
> UNK is defined.  So, we need to fix-up the cephes setup.py file or
> mconf.h to define the right constants.

I just added  a `defined(__itanium__)` in mconf.h

#elif defined(ns32000) || defined(sun386) || \
    defined(i386) || defined(MIPSEL) || defined(_MIPSEL) || \
    defined(BIT_ZERO_ON_RIGHT) || defined(__alpha__) || defined(__alpha)
|| \
    defined(sequent) || defined(i386) ||  defined(__itanium__) || \
    defined(__ns32000__) || defined(__sun386__) || defined(__i386__)
#define IBMPC 1   /* Intel IEEE, low order words come first */
#define BIGENDIAN 0

It seems it got beyond the criticaly point for cephes ...
(let's wait for the tests ... - hmm don't look too good, more on this
tomorrow).

> Looks like that one is fixed already (thanks David...)

Yep - looks fine - many thanx!!

> >>c) the bunch of test failures
> >>
> >>
> I would like to get to the bottom of these, eventually....  Perhaps its
> just a matter of not doing arithmetic on void * pointers.  The gcc
> default might be different than the icc default (although I would expect
> that to give a segfault and not just give numerical errors).   Or, there
> might be some other subtlety that's been over-looked.
>
> Ideally, of course, scipy core should compile and work with a
> wide-variety of compilers.

Once I get the other compile bits sorted, I will try to
look into that tomorrow ...

> I've just fixed up the records.py module (I think there is some very
> cool functionality that came out of that endeavor) and presently I'm
> working on speeding up the ufunc loop in the BUFFERED case (to avoid all
> the unnecessary copying that is going on and was definitely slowing down
> the klein test unnecessarily).   I have the new algorithm coded but now
> need to get all the bugs out of it.    I'm anxious to see if the new
> approach improves the scipy times in Gerard's klein test (I also fixed
> up the LONG_remainder function to not use floating-point unless there is
> a mismatch in sign --- when C's % and Python's % don't agree).

Great - things are really developing very nicely!!!

>  But,
> all of this will have to wait until after I give the final to my linear
> algebra students later today...

Have fun with that - best, Arnd