From aarchiba at physics.mcgill.ca  Mon Nov  2 09:50:34 2009
From: aarchiba at physics.mcgill.ca (Anne Archibald)
Date: Mon, 2 Nov 2009 10:50:34 -0400
Subject: [SciPy-dev] Inclusion of Kuiper test in Scipy
Message-ID: <ce557a360911020650h2f6c883crf67f5b808aa4eab8@mail.gmail.com>

Hi,

I have implemented a statistical test from the literature, the Kuiper
test, for my own work, but I think it might be worth including it in
Scipy itself. I'd like to hear other people's opinions, though, both
on what (if anything) should go into scipy, and on whether it needs
modification. The code is at:

http://github.com/aarchiba/kuiper

This code includes a number of things beyond the basic test, some or
all of which may not be worth including in Scipy. What's there:

The Kuiper test - analogous to the Kolmogorov-Smirnov test, this takes
either a sample and a callable CDF or two samples and returns an
abstract score and the probability that a score that large would have
arisen if the two arguments are from the same distribution. This test
is sensitive to somewhat different features of the distribution than
the K-S test, and, importantly, it is invariant under cyclic
permutation: that is, if all the samples and distribution are modulo
(say) 1, then any shift in both arguments leaves the value unaffected.
Thus it is well suited to periodic distributions.

The Z_m^2 test - a test for uniformity on [0,1) based on the first m
Fourier coefficients. Returns a score and the probability of a score
that large.

The H test - a test that uses a data-dependent number of harmonics to
test for uniformity. Returns the score and the probability, and also
the number of harmonics that gave the most significant detection.

fold_intervals - a function to take a series of weighted intervals and
return the total exposure of each phase modulo 1. For testing for
uniformity when you have more data from some phases than others.
cdf_from_intervals - a function to construct a piecewise-linear CDF
from a set of exposures (as returned by the above function).
histogram_intervals - A function to evaluate how much exposure each
histogram bin received, to allow testing for uniformity using a
histogram in the presence of non-uniform exposure.

There are also a couple of handy decorators in the test suite:

seed - set the random seed before running a test
double_check - for randomized tests: run once, and if it fails, run it again.

All have tests and somewhat informative docstrings, but I suspect some
of them may be too specialized to be of much use. The Kuiper test
should have wide applicability; the Z_m^2 test and H test, not so
much, although they are handy when testinf gor periodicity. The last
batch of utility functions I'm not sure are general enough to be very
useful, but I needed them.

What do you think? How much of this would be useful in Scipy?

Thanks,
Anne


From jakevdp at gmail.com  Mon Nov  2 10:29:07 2009
From: jakevdp at gmail.com (Jake VanderPlas)
Date: Mon, 2 Nov 2009 07:29:07 -0800
Subject: [SciPy-dev] Inclusion of Kuiper test in Scipy
In-Reply-To: <ce557a360911020650h2f6c883crf67f5b808aa4eab8@mail.gmail.com>
References: <ce557a360911020650h2f6c883crf67f5b808aa4eab8@mail.gmail.com>
Message-ID: <58df6dc20911020729v1c9db02eqd7f95fdeda91c455@mail.gmail.com>

Anne,
I also recently required a Kuiper test code for my research.  I
adapted an IDL routine for python.  I'd say it is definitely worth
including.  In addition to what you listed, a routine to calculate the
significance of the Kuiper value would be useful.  I have a python
version of that code if you'd like to see it.
   -Jake

On Mon, Nov 2, 2009 at 6:50 AM, Anne Archibald
<aarchiba at physics.mcgill.ca> wrote:
> Hi,
>
> I have implemented a statistical test from the literature, the Kuiper
> test, for my own work, but I think it might be worth including it in
> Scipy itself. I'd like to hear other people's opinions, though, both
> on what (if anything) should go into scipy, and on whether it needs
> modification. The code is at:
>
> http://github.com/aarchiba/kuiper
>
> This code includes a number of things beyond the basic test, some or
> all of which may not be worth including in Scipy. What's there:
>
> The Kuiper test - analogous to the Kolmogorov-Smirnov test, this takes
> either a sample and a callable CDF or two samples and returns an
> abstract score and the probability that a score that large would have
> arisen if the two arguments are from the same distribution. This test
> is sensitive to somewhat different features of the distribution than
> the K-S test, and, importantly, it is invariant under cyclic
> permutation: that is, if all the samples and distribution are modulo
> (say) 1, then any shift in both arguments leaves the value unaffected.
> Thus it is well suited to periodic distributions.
>
> The Z_m^2 test - a test for uniformity on [0,1) based on the first m
> Fourier coefficients. Returns a score and the probability of a score
> that large.
>
> The H test - a test that uses a data-dependent number of harmonics to
> test for uniformity. Returns the score and the probability, and also
> the number of harmonics that gave the most significant detection.
>
> fold_intervals - a function to take a series of weighted intervals and
> return the total exposure of each phase modulo 1. For testing for
> uniformity when you have more data from some phases than others.
> cdf_from_intervals - a function to construct a piecewise-linear CDF
> from a set of exposures (as returned by the above function).
> histogram_intervals - A function to evaluate how much exposure each
> histogram bin received, to allow testing for uniformity using a
> histogram in the presence of non-uniform exposure.
>
> There are also a couple of handy decorators in the test suite:
>
> seed - set the random seed before running a test
> double_check - for randomized tests: run once, and if it fails, run it again.
>
> All have tests and somewhat informative docstrings, but I suspect some
> of them may be too specialized to be of much use. The Kuiper test
> should have wide applicability; the Z_m^2 test and H test, not so
> much, although they are handy when testinf gor periodicity. The last
> batch of utility functions I'm not sure are general enough to be very
> useful, but I needed them.
>
> What do you think? How much of this would be useful in Scipy?
>
> Thanks,
> Anne
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From jakevdp at gmail.com  Mon Nov  2 10:41:48 2009
From: jakevdp at gmail.com (Jake VanderPlas)
Date: Mon, 2 Nov 2009 07:41:48 -0800
Subject: [SciPy-dev] How to include new code (Re: Ball Tree)
Message-ID: <58df6dc20911020741l57c2feex942cf7097a8f4fe3@mail.gmail.com>

Hello,
I have been following the developer's list for a while, and I would
like to start contributing to scipy.  I wrote the list about a Ball
Tree implementation that I would like to include in scipy.spatial.
I've written a python/C++ implementation, and for k-nearest-neighbor
searches in large dimensions (d~1000), it is about 10 times faster
than the current scipy.spatial.cKDTree.  Can someone point me to
instructions on how to start the process of including this in scipy?
I have a local copy of the scipy svn, and my code consists of a few
C++ files and a working setup.py  Thanks!
   -Jake


From ralf.gommers at googlemail.com  Mon Nov  2 12:07:12 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Mon, 2 Nov 2009 18:07:12 +0100
Subject: [SciPy-dev] module docstrings
In-Reply-To: <1cd32cbb0910311328g731d5063n2587545e5a8f1fee@mail.gmail.com>
References: <dde7764a0910250458o55ce374er4105255cba0f63df@mail.gmail.com>
	<e06186140910301821k5902fe0fsf0d2f0e39553162a@mail.gmail.com>
	<dde7764a0910310700w47536edfnad35c6d78c4e1549@mail.gmail.com>
	<loom.20091031T205131-622@post.gmane.org>
	<1cd32cbb0910311328g731d5063n2587545e5a8f1fee@mail.gmail.com>
Message-ID: <dde7764a0911020907l1fa01eeds13f02c7b40761f92@mail.gmail.com>

On Sat, Oct 31, 2009 at 9:28 PM, <josef.pktd at gmail.com> wrote:

> On Sat, Oct 31, 2009 at 4:02 PM, Tom K. <tpk at kraussfamily.org> wrote:
> > Ralf Gommers <ralf.gommers <at> googlemail.com> writes:
> >
> >>
> >>
> >> On Sat, Oct 31, 2009 at 2:21 AM, Charles R Harris
> > <charlesr.harris <at> gmail.com> wrote:
> >> I like routine listings....
> >>
> > MATLAB has a default behavior for documenting a directory on the path
> when
> > you don't have a Contents.m in that directory: it pulls the "H1" line
> (first
> > line of the M-file's help) from each M-file and lists those for you.
> > But the Contents.m usually was nicely formatted and grouped according
> > to function, with a list of each M-file with a 1-line summary.
> > FWIW.
> > I kind of like a listing too, but not all functions in all modules
> warrant
> > listing at the module level - there is an asymmetry problem.
> >
>

This is basically what the reST routines listings do already; one listing
per area of functionality, and pulling the first line of the docstrings. See
for example
http://docs.scipy.org/numpy/docs/numpy-docs/reference/routines.indexing.rst/

Also remember that the contents.m for Matlab is necessary in many cases
because of the one-file-per-function limit, for a Python module in a single
file with __all__ at the top this is not nearly as important.

>
>
> I'm not sure the info files in scipy are kept up to date. Since we
> moved the documentation to the rst files, I haven't looked at info.py
> anymore, except for those packages that have an automodule directive
> and load the info script. (If I'm not mistaken about the import
> mechanism for the docs.)
>

You're not mistaken. I'll look into an easy way to keep the existing info
files updated.

>
> I just rely on dir(modulename) to get the actual listing,
> or better in some cases modulename.__all__  for only the public functions
>
> Yes, you have both of those options, plus most IDE's give you nice
overviews, or taglists in vim and (i assume) emacs.

I created a ticket with a patch to the docstandard,
http://projects.scipy.org/numpy/ticket/1280 (keeping routine listings as an
optional section), and will start working on module docs soon.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091102/e92e69b7/attachment.html>

From charlesr.harris at gmail.com  Mon Nov  2 13:08:11 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Mon, 2 Nov 2009 11:08:11 -0700
Subject: [SciPy-dev] How to include new code (Re: Ball Tree)
In-Reply-To: <58df6dc20911020741l57c2feex942cf7097a8f4fe3@mail.gmail.com>
References: <58df6dc20911020741l57c2feex942cf7097a8f4fe3@mail.gmail.com>
Message-ID: <e06186140911021008q7ea3eb78p61806a3459ea6b12@mail.gmail.com>

On Mon, Nov 2, 2009 at 8:41 AM, Jake VanderPlas <jakevdp at gmail.com> wrote:

> Hello,
> I have been following the developer's list for a while, and I would
> like to start contributing to scipy.  I wrote the list about a Ball
> Tree implementation that I would like to include in scipy.spatial.
> I've written a python/C++ implementation, and for k-nearest-neighbor
> searches in large dimensions (d~1000), it is about 10 times faster
> than the current scipy.spatial.cKDTree.  Can someone point me to
> instructions on how to start the process of including this in scipy?
> I have a local copy of the scipy svn, and my code consists of a few
> C++ files and a working setup.py  Thanks!
>   -Jake
> __


Sounds like the easiest way would be to open a ticket, attach a patch, and
mark it for review. If it doesn't get any attention, complain on the list.
In any case, if the new addition needs maintenance you will probably need
commit privileges in the long run.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091102/4a9fce26/attachment.html>

From peridot.faceted at gmail.com  Mon Nov  2 14:01:18 2009
From: peridot.faceted at gmail.com (Anne Archibald)
Date: Mon, 2 Nov 2009 15:01:18 -0400
Subject: [SciPy-dev] Inclusion of Kuiper test in Scipy
In-Reply-To: <58df6dc20911020729v1c9db02eqd7f95fdeda91c455@mail.gmail.com>
References: <ce557a360911020650h2f6c883crf67f5b808aa4eab8@mail.gmail.com>
	<58df6dc20911020729v1c9db02eqd7f95fdeda91c455@mail.gmail.com>
Message-ID: <ce557a360911021101j370886bdpf195f7e12a5e5868@mail.gmail.com>

2009/11/2 Jake VanderPlas <jakevdp at gmail.com>:
> Anne,
> I also recently required a Kuiper test code for my research. ?I
> adapted an IDL routine for python. ?I'd say it is definitely worth
> including. ?In addition to what you listed, a routine to calculate the
> significance of the Kuiper value would be useful. ?I have a python
> version of that code if you'd like to see it.

Actually, my code has significance calculators for all three tests
(based on Paltani 2004). But I know that the value is somewhat off for
small N - perhaps you could send me yours and I could see if it does
better?

Anne

> ? -Jake
>
> On Mon, Nov 2, 2009 at 6:50 AM, Anne Archibald
> <aarchiba at physics.mcgill.ca> wrote:
>> Hi,
>>
>> I have implemented a statistical test from the literature, the Kuiper
>> test, for my own work, but I think it might be worth including it in
>> Scipy itself. I'd like to hear other people's opinions, though, both
>> on what (if anything) should go into scipy, and on whether it needs
>> modification. The code is at:
>>
>> http://github.com/aarchiba/kuiper
>>
>> This code includes a number of things beyond the basic test, some or
>> all of which may not be worth including in Scipy. What's there:
>>
>> The Kuiper test - analogous to the Kolmogorov-Smirnov test, this takes
>> either a sample and a callable CDF or two samples and returns an
>> abstract score and the probability that a score that large would have
>> arisen if the two arguments are from the same distribution. This test
>> is sensitive to somewhat different features of the distribution than
>> the K-S test, and, importantly, it is invariant under cyclic
>> permutation: that is, if all the samples and distribution are modulo
>> (say) 1, then any shift in both arguments leaves the value unaffected.
>> Thus it is well suited to periodic distributions.
>>
>> The Z_m^2 test - a test for uniformity on [0,1) based on the first m
>> Fourier coefficients. Returns a score and the probability of a score
>> that large.
>>
>> The H test - a test that uses a data-dependent number of harmonics to
>> test for uniformity. Returns the score and the probability, and also
>> the number of harmonics that gave the most significant detection.
>>
>> fold_intervals - a function to take a series of weighted intervals and
>> return the total exposure of each phase modulo 1. For testing for
>> uniformity when you have more data from some phases than others.
>> cdf_from_intervals - a function to construct a piecewise-linear CDF
>> from a set of exposures (as returned by the above function).
>> histogram_intervals - A function to evaluate how much exposure each
>> histogram bin received, to allow testing for uniformity using a
>> histogram in the presence of non-uniform exposure.
>>
>> There are also a couple of handy decorators in the test suite:
>>
>> seed - set the random seed before running a test
>> double_check - for randomized tests: run once, and if it fails, run it again.
>>
>> All have tests and somewhat informative docstrings, but I suspect some
>> of them may be too specialized to be of much use. The Kuiper test
>> should have wide applicability; the Z_m^2 test and H test, not so
>> much, although they are handy when testinf gor periodicity. The last
>> batch of utility functions I'm not sure are general enough to be very
>> useful, but I needed them.
>>
>> What do you think? How much of this would be useful in Scipy?
>>
>> Thanks,
>> Anne
>> _______________________________________________
>> Scipy-dev mailing list
>> Scipy-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From ondrej at certik.cz  Tue Nov  3 14:46:15 2009
From: ondrej at certik.cz (Ondrej Certik)
Date: Tue, 3 Nov 2009 11:46:15 -0800
Subject: [SciPy-dev] [Numpy-discussion] [ANN] For SF Bay Area residents:
	a discussion with Guido at the Berkeley Py4Science seminar
In-Reply-To: <db6b5ecc0911031128o77bb588dn3f68ad6aa3fda12d@mail.gmail.com>
References: <db6b5ecc0911031128o77bb588dn3f68ad6aa3fda12d@mail.gmail.com>
Message-ID: <85b5c3130911031146q172581dbucb33831417c6a3e0@mail.gmail.com>

Hi,

On Tue, Nov 3, 2009 at 11:28 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi folks,
>
> if you reside in the San Francisco Bay Area, you may be interested in
> a meeting we'll be having tomorrow November 4 (2-4 pm), as part of our
> regular py4science meeting series. ?Guido van Rossum, the creator of
> the Python language, will visit for a session where we will first do a
> very rapid overview of a number of scientific projects that use Python
> (in a lightning talk format) and then we will have an open discussion
> with Guido with hopefully interesting questions going in both
> directions. ?The meeting is open to all, bring your questions!
>
> More details on this seminar series (including location) can be found here:
>
> https://cirl.berkeley.edu/view/Py4Science

this sounds exciting. I am thinking of coming (from Reno).

Ondrej

P.S. Just registered my car at DMV today. :)


From fperez.net at gmail.com  Tue Nov  3 14:50:37 2009
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 3 Nov 2009 11:50:37 -0800
Subject: [SciPy-dev] [Numpy-discussion] [ANN] For SF Bay Area residents:
	a discussion with Guido at the Berkeley Py4Science seminar
In-Reply-To: <85b5c3130911031146q172581dbucb33831417c6a3e0@mail.gmail.com>
References: <db6b5ecc0911031128o77bb588dn3f68ad6aa3fda12d@mail.gmail.com> 
	<85b5c3130911031146q172581dbucb33831417c6a3e0@mail.gmail.com>
Message-ID: <db6b5ecc0911031150y114603ei2c05440765786c62@mail.gmail.com>

On Tue, Nov 3, 2009 at 11:46 AM, Ondrej Certik <ondrej at certik.cz> wrote:
> this sounds exciting. I am thinking of coming (from Reno).
>
> Ondrej
>
> P.S. Just registered my car at DMV today. :)

By all means do!  Just don't crash the car :)  It's in the same room
as before, 2pm.

Can you email me *3* slides about sympy?  If you come you can present
them, if not I'll use them in my rapid project overview I'll open the
session with (I was going to include sympy regardless, but even better
if you make the 3 slides :)

Cheers,

f


From ondrej at certik.cz  Tue Nov  3 16:08:27 2009
From: ondrej at certik.cz (Ondrej Certik)
Date: Tue, 3 Nov 2009 13:08:27 -0800
Subject: [SciPy-dev] [Numpy-discussion] [ANN] For SF Bay Area residents:
	a discussion with Guido at the Berkeley Py4Science seminar
In-Reply-To: <db6b5ecc0911031150y114603ei2c05440765786c62@mail.gmail.com>
References: <db6b5ecc0911031128o77bb588dn3f68ad6aa3fda12d@mail.gmail.com>
	<85b5c3130911031146q172581dbucb33831417c6a3e0@mail.gmail.com>
	<db6b5ecc0911031150y114603ei2c05440765786c62@mail.gmail.com>
Message-ID: <85b5c3130911031308t1a953288g8072cc0ed03f9eb6@mail.gmail.com>

On Tue, Nov 3, 2009 at 11:50 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Tue, Nov 3, 2009 at 11:46 AM, Ondrej Certik <ondrej at certik.cz> wrote:
>> this sounds exciting. I am thinking of coming (from Reno).
>>
>> Ondrej
>>
>> P.S. Just registered my car at DMV today. :)
>
> By all means do! ?Just don't crash the car :) ?It's in the same room
> as before, 2pm.

Cool. I'll come for sure, maybe Luke Peterson will come as well.

>
> Can you email me *3* slides about sympy? ?If you come you can present
> them, if not I'll use them in my rapid project overview I'll open the
> session with (I was going to include sympy regardless, but even better
> if you make the 3 slides :)

Ok, I'll do it later today.

Ondrej


From d.l.goldsmith at gmail.com  Wed Nov  4 13:29:02 2009
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Wed, 4 Nov 2009 10:29:02 -0800
Subject: [SciPy-dev] module docstrings
In-Reply-To: <dde7764a0911020907l1fa01eeds13f02c7b40761f92@mail.gmail.com>
References: <dde7764a0910250458o55ce374er4105255cba0f63df@mail.gmail.com>
	<e06186140910301821k5902fe0fsf0d2f0e39553162a@mail.gmail.com>
	<dde7764a0910310700w47536edfnad35c6d78c4e1549@mail.gmail.com>
	<loom.20091031T205131-622@post.gmane.org>
	<1cd32cbb0910311328g731d5063n2587545e5a8f1fee@mail.gmail.com>
	<dde7764a0911020907l1fa01eeds13f02c7b40761f92@mail.gmail.com>
Message-ID: <45d1ab480911041029w5d308e7fo66e9e63be523f1c4@mail.gmail.com>

Thanks, Ralf, et al.

On Mon, Nov 2, 2009 at 9:07 AM, Ralf Gommers <ralf.gommers at googlemail.com>wrote:

> I created a ticket with a patch to the docstandard,
> http://projects.scipy.org/numpy/ticket/1280


So if anyone feels very strongly that this *should not* be optional, make
your case now or "forever hold your piece." ;-)

DG


> (keeping routine listings as an optional section), and will start working
> on module docs soon.
>
> Cheers,
> Ralf
>
>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091104/fbee9b08/attachment.html>

From njs at pobox.com  Wed Nov  4 16:25:12 2009
From: njs at pobox.com (Nathaniel Smith)
Date: Wed, 4 Nov 2009 13:25:12 -0800
Subject: [SciPy-dev] contributing a CHOLMOD wrapper
Message-ID: <961fa2b40911041325l7c73b31bre670a0a37d7bb00@mail.gmail.com>

I've written a fairly complete wrapper for CHOLMOD (the SuiteSparse
library for sparse Cholesky decomposition) in Cython for my own use,
and it occurs that others might benefit as well.

CHOLMOD is GPLed, so I suppose my wrapper must be as well, and is thus
unsuitable for inclusion in Scipy proper -- though scipy.sparse
already has a wrapper for the GPLed UMFPACK, so I guess I might be
wrong? Anyway, is there any interest in such a thing, and any thoughts
on the best way to distribute it?

-- Nathaniel


From gael.varoquaux at normalesup.org  Wed Nov  4 16:28:02 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Wed, 4 Nov 2009 22:28:02 +0100
Subject: [SciPy-dev] contributing a CHOLMOD wrapper
In-Reply-To: <961fa2b40911041325l7c73b31bre670a0a37d7bb00@mail.gmail.com>
References: <961fa2b40911041325l7c73b31bre670a0a37d7bb00@mail.gmail.com>
Message-ID: <20091104212802.GB32598@phare.normalesup.org>

On Wed, Nov 04, 2009 at 01:25:12PM -0800, Nathaniel Smith wrote:
> I've written a fairly complete wrapper for CHOLMOD (the SuiteSparse
> library for sparse Cholesky decomposition) in Cython for my own use,
> and it occurs that others might benefit as well.

Very very nice.

> CHOLMOD is GPLed, so I suppose my wrapper must be as well, and is thus
> unsuitable for inclusion in Scipy proper -- though scipy.sparse
> already has a wrapper for the GPLed UMFPACK, so I guess I might be
> wrong?

I would put the code in BSD, just to make it clear that people are
welcomed to derive work for the code in BSD license, but I would make it
clear that the package itself is contaminated.

> Anyway, is there any interest in such a thing, and any thoughts
> on the best way to distribute it?

Scikit umfpack seems a good idea. Worst case, stick it on a webpage: this
is useful code.

Thanks for offering :)

Ga?l


From robert.kern at gmail.com  Wed Nov  4 16:36:18 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 4 Nov 2009 15:36:18 -0600
Subject: [SciPy-dev] contributing a CHOLMOD wrapper
In-Reply-To: <20091104212802.GB32598@phare.normalesup.org>
References: <961fa2b40911041325l7c73b31bre670a0a37d7bb00@mail.gmail.com> 
	<20091104212802.GB32598@phare.normalesup.org>
Message-ID: <3d375d730911041336j3b0372c8t192d2a7722aa0c7b@mail.gmail.com>

On Wed, Nov 4, 2009 at 15:28, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Wed, Nov 04, 2009 at 01:25:12PM -0800, Nathaniel Smith wrote:

>> CHOLMOD is GPLed, so I suppose my wrapper must be as well, and is thus
>> unsuitable for inclusion in Scipy proper -- though scipy.sparse
>> already has a wrapper for the GPLed UMFPACK, so I guess I might be
>> wrong?

No, you're right. The UMFPACK support there has always been optional.
However, we don't want to add more optional components into scipy and
have been pushing this one out to scikits.umfpack.

> I would put the code in BSD, just to make it clear that people are
> welcomed to derive work for the code in BSD license, but I would make it
> clear that the package itself is contaminated.

I'd probably go the other way. Make it GPLed, but add a note that you
will relicense your parts of the code on request. Having wrappers with
a different license than the library itself is usually just confusing
for very little benefit. The code in the wrapper itself is usually not
very interesting.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From james.bergstra at gmail.com  Wed Nov  4 16:42:43 2009
From: james.bergstra at gmail.com (James Bergstra)
Date: Wed, 4 Nov 2009 16:42:43 -0500
Subject: [SciPy-dev] contributing a CHOLMOD wrapper
In-Reply-To: <3d375d730911041336j3b0372c8t192d2a7722aa0c7b@mail.gmail.com>
References: <961fa2b40911041325l7c73b31bre670a0a37d7bb00@mail.gmail.com>
	<20091104212802.GB32598@phare.normalesup.org>
	<3d375d730911041336j3b0372c8t192d2a7722aa0c7b@mail.gmail.com>
Message-ID: <7f1eaee30911041342h66cce00eo24ebf9a084ae2be8@mail.gmail.com>

There is also a cholmod wrapper in cvxopt.  Not sure what the license
on that is... or what it has to do with scipy exactly.  Just fyi.

http://abel.ee.ucla.edu/cvxopt/userguide/spsolvers.html#positive-definite-linear-equations

On Wed, Nov 4, 2009 at 4:36 PM, Robert Kern <robert.kern at gmail.com> wrote:
> On Wed, Nov 4, 2009 at 15:28, Gael Varoquaux
> <gael.varoquaux at normalesup.org> wrote:
>> On Wed, Nov 04, 2009 at 01:25:12PM -0800, Nathaniel Smith wrote:
>
>>> CHOLMOD is GPLed, so I suppose my wrapper must be as well, and is thus
>>> unsuitable for inclusion in Scipy proper -- though scipy.sparse
>>> already has a wrapper for the GPLed UMFPACK, so I guess I might be
>>> wrong?
>
> No, you're right. The UMFPACK support there has always been optional.
> However, we don't want to add more optional components into scipy and
> have been pushing this one out to scikits.umfpack.
>
>> I would put the code in BSD, just to make it clear that people are
>> welcomed to derive work for the code in BSD license, but I would make it
>> clear that the package itself is contaminated.
>
> I'd probably go the other way. Make it GPLed, but add a note that you
> will relicense your parts of the code on request. Having wrappers with
> a different license than the library itself is usually just confusing
> for very little benefit. The code in the wrapper itself is usually not
> very interesting.
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
> ?-- Umberto Eco
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



-- 
http://www-etud.iro.umontreal.ca/~bergstrj


From dwf at cs.toronto.edu  Wed Nov  4 16:56:11 2009
From: dwf at cs.toronto.edu (David Warde-Farley)
Date: Wed, 4 Nov 2009 16:56:11 -0500
Subject: [SciPy-dev] contributing a CHOLMOD wrapper
In-Reply-To: <7f1eaee30911041342h66cce00eo24ebf9a084ae2be8@mail.gmail.com>
References: <961fa2b40911041325l7c73b31bre670a0a37d7bb00@mail.gmail.com>
	<20091104212802.GB32598@phare.normalesup.org>
	<3d375d730911041336j3b0372c8t192d2a7722aa0c7b@mail.gmail.com>
	<7f1eaee30911041342h66cce00eo24ebf9a084ae2be8@mail.gmail.com>
Message-ID: <699582D2-D1C6-4D3A-BC17-F380CB2152CF@cs.toronto.edu>

On 4-Nov-09, at 4:42 PM, James Bergstra wrote:

> There is also a cholmod wrapper in cvxopt.  Not sure what the license
> on that is... or what it has to do with scipy exactly.  Just fyi.

CVXOPT is GPL (possibly because of CHOLMOD and friends): http://abel.ee.ucla.edu/cvxopt/copyright.html

They also don't use NumPy arrays but rather their own matrix type  
which is Fortran contiguous and always rank 2. They do expose the  
array interface, though, and thus are interoperable.

David


From robertlayton at gmail.com  Wed Nov  4 18:41:26 2009
From: robertlayton at gmail.com (Robert Layton)
Date: Thu, 5 Nov 2009 10:41:26 +1100
Subject: [SciPy-dev] Build issue from svn
Message-ID: <585dc5e20911041541n65dbd1e8sc175f9c4b16f6cf3@mail.gmail.com>

Hello all,

I am having an issue building from the SVN, retrived today (revision 6078).
I haven't had many problems building on this machine before, so I think its
new.
I have built the latest numpy (1.4.0.dev7685) which went fine, and did a
sudo python setup.py install_headers after installing as well.
I am on a Kubuntu 9.04 machine (2.6.28-14-generic #47-Ubuntu SMP Sat Jul 25
00:28:35 UTC 2009 i686 GNU/Linux), with gcc 4.3.3 and python 2.6.2

The error that is occuring after doing "python setup.py build" is:
gcc: scipy/special/cephes/scipy_iv.c
scipy/special/cephes/scipy_iv.c:76: error: expected ?)? before
?__extension__?
scipy/special/cephes/scipy_iv.c:76: error: expected ?;?, ?,? or ?)? before
?double?
scipy/special/cephes/scipy_iv.c: In function ?cephes_iv?:
scipy/special/cephes/scipy_iv.c:127: warning: implicit declaration of
function ?ikv_temme?
scipy/special/cephes/scipy_iv.c:81: warning: unused variable ?vp?
scipy/special/cephes/scipy_iv.c: In function ?iv_asymptotic?:
scipy/special/cephes/scipy_iv.c:140: warning: unused variable ?mup?
scipy/special/cephes/scipy_iv.c: At top level:
scipy/special/cephes/scipy_iv.c:526: error: expected ?)? before
?__extension__?
scipy/special/cephes/scipy_iv.c:526: error: expected ?;?, ?,? or ?)? before
?double?
scipy/special/cephes/scipy_iv.c:76: error: expected ?)? before
?__extension__?
scipy/special/cephes/scipy_iv.c:76: error: expected ?;?, ?,? or ?)? before
?double?
scipy/special/cephes/scipy_iv.c: In function ?cephes_iv?:
scipy/special/cephes/scipy_iv.c:127: warning: implicit declaration of
function ?ikv_temme?
scipy/special/cephes/scipy_iv.c:81: warning: unused variable ?vp?
scipy/special/cephes/scipy_iv.c: In function ?iv_asymptotic?:
scipy/special/cephes/scipy_iv.c:140: warning: unused variable ?mup?
scipy/special/cephes/scipy_iv.c: At top level:
scipy/special/cephes/scipy_iv.c:526: error: expected ?)? before
?__extension__?
scipy/special/cephes/scipy_iv.c:526: error: expected ?;?, ?,? or ?)? before
?double?
error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2
-Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.6
-I/usr/local/lib/python2.6/dist-packages/numpy/core/include
-I/usr/local/lib/python2.6/dist-packages/numpy/core/include -c
scipy/special/cephes/scipy_iv.c -o
build/temp.linux-i686-2.6/scipy/special/cephes/scipy_iv.o" failed with exit
status 1

The last change to this file was quite a while ago (update 5936, 6 weeks
ago), during which time I have built scipy from SVN many times.

Any thoughts?

- Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091105/f3578074/attachment.html>

From charlesr.harris at gmail.com  Wed Nov  4 20:32:16 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Wed, 4 Nov 2009 18:32:16 -0700
Subject: [SciPy-dev] Build issue from svn
In-Reply-To: <585dc5e20911041541n65dbd1e8sc175f9c4b16f6cf3@mail.gmail.com>
References: <585dc5e20911041541n65dbd1e8sc175f9c4b16f6cf3@mail.gmail.com>
Message-ID: <e06186140911041732u162d162bg540b7ecc56c70381@mail.gmail.com>

On Wed, Nov 4, 2009 at 4:41 PM, Robert Layton <robertlayton at gmail.com>wrote:

> Hello all,
>
> I am having an issue building from the SVN, retrived today (revision 6078).
> I haven't had many problems building on this machine before, so I think its
> new.
> I have built the latest numpy (1.4.0.dev7685) which went fine, and did a
> sudo python setup.py install_headers after installing as well.
> I am on a Kubuntu 9.04 machine (2.6.28-14-generic #47-Ubuntu SMP Sat Jul 25
> 00:28:35 UTC 2009 i686 GNU/Linux), with gcc 4.3.3 and python 2.6.2
>
> The error that is occuring after doing "python setup.py build" is:
> gcc: scipy/special/cephes/scipy_iv.c
> scipy/special/cephes/scipy_iv.c:76: error: expected ?)? before
> ?__extension__?
> scipy/special/cephes/scipy_iv.c:76: error: expected ?;?, ?,? or ?)? before
> ?double?
> scipy/special/cephes/scipy_iv.c: In function ?cephes_iv?:
> scipy/special/cephes/scipy_iv.c:127: warning: implicit declaration of
> function ?ikv_temme?
> scipy/special/cephes/scipy_iv.c:81: warning: unused variable ?vp?
> scipy/special/cephes/scipy_iv.c: In function ?iv_asymptotic?:
> scipy/special/cephes/scipy_iv.c:140: warning: unused variable ?mup?
> scipy/special/cephes/scipy_iv.c: At top level:
> scipy/special/cephes/scipy_iv.c:526: error: expected ?)? before
> ?__extension__?
> scipy/special/cephes/scipy_iv.c:526: error: expected ?;?, ?,? or ?)? before
> ?double?
> scipy/special/cephes/scipy_iv.c:76: error: expected ?)? before
> ?__extension__?
> scipy/special/cephes/scipy_iv.c:76: error: expected ?;?, ?,? or ?)? before
> ?double?
> scipy/special/cephes/scipy_iv.c: In function ?cephes_iv?:
> scipy/special/cephes/scipy_iv.c:127: warning: implicit declaration of
> function ?ikv_temme?
> scipy/special/cephes/scipy_iv.c:81: warning: unused variable ?vp?
> scipy/special/cephes/scipy_iv.c: In function ?iv_asymptotic?:
> scipy/special/cephes/scipy_iv.c:140: warning: unused variable ?mup?
> scipy/special/cephes/scipy_iv.c: At top level:
> scipy/special/cephes/scipy_iv.c:526: error: expected ?)? before
> ?__extension__?
> scipy/special/cephes/scipy_iv.c:526: error: expected ?;?, ?,? or ?)? before
> ?double?
> error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2
> -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.6
> -I/usr/local/lib/python2.6/dist-packages/numpy/core/include
> -I/usr/local/lib/python2.6/dist-packages/numpy/core/include -c
> scipy/special/cephes/scipy_iv.c -o
> build/temp.linux-i686-2.6/scipy/special/cephes/scipy_iv.o" failed with exit
> status 1
>
> The last change to this file was quite a while ago (update 5936, 6 weeks
> ago), during which time I have built scipy from SVN many times.
>
> Any thoughts?
>
>
Hmm, I don't see this on ubuntu 9.10 x86_64 and r6078.

I ran into another problem, though. The numpy installed by ubuntu needed to
be removed and reinstalled so get_info would be available. But which numpy
to remove? Turns out I had two versions of python2.6 installed, one in
/usr/lib and the other in /usr/local/lib and the latter was the right one.
Strange.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091104/fcbc3ace/attachment.html>

From charlesr.harris at gmail.com  Wed Nov  4 22:18:01 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Wed, 4 Nov 2009 20:18:01 -0700
Subject: [SciPy-dev] scipy errors
Message-ID: <e06186140911041918p2b303880s9a6596933ed79e82@mail.gmail.com>

I see the following test errors on ubuntu_x86_64 9.10

ERROR: Check linalg works with non-aligned memory
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.6/nose/case.py", line 183, in runTest
    self.test(*self.arg)
  File
"/usr/local/lib/python2.6/dist-packages/scipy/linalg/tests/test_decomp.py",
line 1067, in test_aligned_mem
    eig(z.T, overwrite_a=True)
  File "/usr/local/lib/python2.6/dist-packages/scipy/linalg/decomp.py", line
158, in eig
    geev, = get_lapack_funcs(('geev',),(a1,))
  File "/usr/local/lib/python2.6/dist-packages/scipy/linalg/lapack.py", line
82, in get_lapack_funcs
    raise ValueError("Non-aligned array cannot be passed to LAPACK without
copying")
ValueError: Non-aligned array cannot be passed to LAPACK without copying

======================================================================
ERROR: test_mpmath.test_hyp2f1_real_some_points
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.6/nose/case.py", line 183, in runTest
    self.test(*self.arg)
  File "/usr/local/lib/python2.6/dist-packages/numpy/testing/decorators.py",
line 143, in skipper_func
    return f(*args, **kwargs)
  File
"/usr/local/lib/python2.6/dist-packages/scipy/special/tests/test_mpmath.py",
line 83, in test_hyp2f1_real_some_points
    dataset = [p + (float(mpmath.hyp2f1(*p)),) for p in pts]
TypeError: float() argument must be a string or a number

======================================================================
ERROR: test_mpmath.test_hyp2f1_real_some
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.6/nose/case.py", line 183, in runTest
    self.test(*self.arg)
  File "/usr/local/lib/python2.6/dist-packages/numpy/testing/decorators.py",
line 143, in skipper_func
    return f(*args, **kwargs)
  File
"/usr/local/lib/python2.6/dist-packages/scipy/special/tests/test_mpmath.py",
line 109, in test_hyp2f1_real_some
    except (TypeError, mpmath.libhyper.NoConvergence):
AttributeError: 'module' object has no attribute 'NoConvergence'

----------------------------------------------------------------------
Ran 3989 tests in 31.954s

FAILED (KNOWNFAIL=7, SKIP=29, errors=3)

I suspect the last failure is an mpmath version problem, and maybe the
second also. Is anyone else seeing the other error?

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091104/d51069ac/attachment.html>

From peridot.faceted at gmail.com  Wed Nov  4 22:39:21 2009
From: peridot.faceted at gmail.com (Anne Archibald)
Date: Wed, 4 Nov 2009 22:39:21 -0500
Subject: [SciPy-dev] scipy errors
In-Reply-To: <e06186140911041918p2b303880s9a6596933ed79e82@mail.gmail.com>
References: <e06186140911041918p2b303880s9a6596933ed79e82@mail.gmail.com>
Message-ID: <ce557a360911041939x4e5b3b59yaf84d0fcc449229c@mail.gmail.com>

2009/11/4 Charles R Harris <charlesr.harris at gmail.com>:
> I see the following test errors on ubuntu_x86_64 9.10
>
> ERROR: Check linalg works with non-aligned memory
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> ? File "/usr/lib/pymodules/python2.6/nose/case.py", line 183, in runTest
> ??? self.test(*self.arg)
> ? File
> "/usr/local/lib/python2.6/dist-packages/scipy/linalg/tests/test_decomp.py",
> line 1067, in test_aligned_mem
> ??? eig(z.T, overwrite_a=True)
> ? File "/usr/local/lib/python2.6/dist-packages/scipy/linalg/decomp.py", line
> 158, in eig
> ??? geev, = get_lapack_funcs(('geev',),(a1,))
> ? File "/usr/local/lib/python2.6/dist-packages/scipy/linalg/lapack.py", line
> 82, in get_lapack_funcs
> ??? raise ValueError("Non-aligned array cannot be passed to LAPACK without
> copying")
> ValueError: Non-aligned array cannot be passed to LAPACK without copying
[...]
> I suspect the last failure is an mpmath version problem, and maybe the
> second also. Is anyone else seeing the other error?

This error is related to ticket 794:
http://projects.scipy.org/scipy/ticket/794
Under certain poorly-defined circumstances, passing non-aligned
matrices to ATLAS can cause a segfault. I've posted a support request
on the ATLAS tracker, hoping to find out whether it's supposed to be
able to deal with non-aligned matrices, and in the meantime I have
code to raise exceptions when non-aligned matrices are fed to LAPACK.

I don't know whether the bug occurs at all on 64-bit systems, and I
don't know whether it's the result of us abusing ATLAS or a bug in
ATLAS. If it's a bug in ATLAS, I don't know for sure what triggers it
- in particular, whether alignment actually solves the problem on all
platforms.


One solution would be to annotate all relevant f2py LAPACK wrappers
with the new align8 keyword and hope that cures the problem (by
forcing a copy of all not-sufficiently-aligned arrays on all LAPACK
installations).

Another "solution" would be to simply remove the failing test and tell
people not to feed non-aligned matrices full of outrageous values into
ATLAS on pain of segfaults. (The bug was filed by someone who'd had a
segfault while working with an unpickled array, so it does bite some
people.)

A third option would be to raise ValueErrors any time non-aligned
matrices are supposed to be passed to LAPACK. (This is what happens
now, but the tests fail when this happens; if this were the permanent
decision I would of course fix the tests to expect exceptions.)

It might be possible, though I'm not sure how and it would be
complicated, to trigger all this working-around only when using ATLAS.


I'm not sure how best to deal with this. What do you think?


Anne


From charlesr.harris at gmail.com  Wed Nov  4 22:50:05 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Wed, 4 Nov 2009 20:50:05 -0700
Subject: [SciPy-dev] scipy errors
In-Reply-To: <e06186140911041918p2b303880s9a6596933ed79e82@mail.gmail.com>
References: <e06186140911041918p2b303880s9a6596933ed79e82@mail.gmail.com>
Message-ID: <e06186140911041950k6f4905efwc0d133f35091b7bc@mail.gmail.com>

On Wed, Nov 4, 2009 at 8:18 PM, Charles R Harris
<charlesr.harris at gmail.com>wrote:

> I see the following test errors on ubuntu_x86_64 9.10
>
> ERROR: Check linalg works with non-aligned memory
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/usr/lib/pymodules/python2.6/nose/case.py", line 183, in runTest
>     self.test(*self.arg)
>   File
> "/usr/local/lib/python2.6/dist-packages/scipy/linalg/tests/test_decomp.py",
> line 1067, in test_aligned_mem
>     eig(z.T, overwrite_a=True)
>   File "/usr/local/lib/python2.6/dist-packages/scipy/linalg/decomp.py",
> line 158, in eig
>     geev, = get_lapack_funcs(('geev',),(a1,))
>   File "/usr/local/lib/python2.6/dist-packages/scipy/linalg/lapack.py",
> line 82, in get_lapack_funcs
>     raise ValueError("Non-aligned array cannot be passed to LAPACK without
> copying")
> ValueError: Non-aligned array cannot be passed to LAPACK without copying
>
> ======================================================================
> ERROR: test_mpmath.test_hyp2f1_real_some_points
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/usr/lib/pymodules/python2.6/nose/case.py", line 183, in runTest
>     self.test(*self.arg)
>   File
> "/usr/local/lib/python2.6/dist-packages/numpy/testing/decorators.py", line
> 143, in skipper_func
>     return f(*args, **kwargs)
>   File
> "/usr/local/lib/python2.6/dist-packages/scipy/special/tests/test_mpmath.py",
> line 83, in test_hyp2f1_real_some_points
>     dataset = [p + (float(mpmath.hyp2f1(*p)),) for p in pts]
> TypeError: float() argument must be a string or a number
>
> ======================================================================
> ERROR: test_mpmath.test_hyp2f1_real_some
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/usr/lib/pymodules/python2.6/nose/case.py", line 183, in runTest
>     self.test(*self.arg)
>   File
> "/usr/local/lib/python2.6/dist-packages/numpy/testing/decorators.py", line
> 143, in skipper_func
>     return f(*args, **kwargs)
>   File
> "/usr/local/lib/python2.6/dist-packages/scipy/special/tests/test_mpmath.py",
> line 109, in test_hyp2f1_real_some
>     except (TypeError, mpmath.libhyper.NoConvergence):
> AttributeError: 'module' object has no attribute 'NoConvergence'
>
> ----------------------------------------------------------------------
> Ran 3989 tests in 31.954s
>
> FAILED (KNOWNFAIL=7, SKIP=29, errors=3)
>
> I suspect the last failure is an mpmath version problem, and maybe the
> second also. Is anyone else seeing the other error?
>
>
Installing mpmath 0.13 cures the last two errors, Karmic Koala installs
mpmath-0.12. So I think there is an mpmath version dependency that needs to
be dealt with.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091104/611b5b94/attachment.html>

From charlesr.harris at gmail.com  Wed Nov  4 22:57:45 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Wed, 4 Nov 2009 20:57:45 -0700
Subject: [SciPy-dev] scipy errors
In-Reply-To: <ce557a360911041939x4e5b3b59yaf84d0fcc449229c@mail.gmail.com>
References: <e06186140911041918p2b303880s9a6596933ed79e82@mail.gmail.com>
	<ce557a360911041939x4e5b3b59yaf84d0fcc449229c@mail.gmail.com>
Message-ID: <e06186140911041957h35083ddfj39f398072560124e@mail.gmail.com>

On Wed, Nov 4, 2009 at 8:39 PM, Anne Archibald <peridot.faceted at gmail.com>wrote:

> 2009/11/4 Charles R Harris <charlesr.harris at gmail.com>:
> > I see the following test errors on ubuntu_x86_64 9.10
> >
> > ERROR: Check linalg works with non-aligned memory
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> >   File "/usr/lib/pymodules/python2.6/nose/case.py", line 183, in runTest
> >     self.test(*self.arg)
> >   File
> >
> "/usr/local/lib/python2.6/dist-packages/scipy/linalg/tests/test_decomp.py",
> > line 1067, in test_aligned_mem
> >     eig(z.T, overwrite_a=True)
> >   File "/usr/local/lib/python2.6/dist-packages/scipy/linalg/decomp.py",
> line
> > 158, in eig
> >     geev, = get_lapack_funcs(('geev',),(a1,))
> >   File "/usr/local/lib/python2.6/dist-packages/scipy/linalg/lapack.py",
> line
> > 82, in get_lapack_funcs
> >     raise ValueError("Non-aligned array cannot be passed to LAPACK
> without
> > copying")
> > ValueError: Non-aligned array cannot be passed to LAPACK without copying
> [...]
> > I suspect the last failure is an mpmath version problem, and maybe the
> > second also. Is anyone else seeing the other error?
>
> This error is related to ticket 794:
> http://projects.scipy.org/scipy/ticket/794
> Under certain poorly-defined circumstances, passing non-aligned
> matrices to ATLAS can cause a segfault. I've posted a support request
> on the ATLAS tracker, hoping to find out whether it's supposed to be
> able to deal with non-aligned matrices, and in the meantime I have
> code to raise exceptions when non-aligned matrices are fed to LAPACK.
>
> I don't know whether the bug occurs at all on 64-bit systems, and I
> don't know whether it's the result of us abusing ATLAS or a bug in
> ATLAS. If it's a bug in ATLAS, I don't know for sure what triggers it
> - in particular, whether alignment actually solves the problem on all
> platforms.
>
>
> One solution would be to annotate all relevant f2py LAPACK wrappers
> with the new align8 keyword and hope that cures the problem (by
> forcing a copy of all not-sufficiently-aligned arrays on all LAPACK
> installations).
>
> Another "solution" would be to simply remove the failing test and tell
> people not to feed non-aligned matrices full of outrageous values into
> ATLAS on pain of segfaults. (The bug was filed by someone who'd had a
> segfault while working with an unpickled array, so it does bite some
> people.)
>
> A third option would be to raise ValueErrors any time non-aligned
> matrices are supposed to be passed to LAPACK. (This is what happens
> now, but the tests fail when this happens; if this were the permanent
> decision I would of course fix the tests to expect exceptions.)
>
> It might be possible, though I'm not sure how and it would be
> complicated, to trigger all this working-around only when using ATLAS.
>
>
> I'm not sure how best to deal with this. What do you think?
>
>
I haven't a clue as to what the best thing to do is. Using aligned matrices
might be the best workaround. Were the alignment problems on SPARC? I recall
a thread on the topic but don't remember what all was said.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091104/3a33f91b/attachment.html>

From peridot.faceted at gmail.com  Wed Nov  4 23:04:39 2009
From: peridot.faceted at gmail.com (Anne Archibald)
Date: Wed, 4 Nov 2009 23:04:39 -0500
Subject: [SciPy-dev] scipy errors
In-Reply-To: <e06186140911041957h35083ddfj39f398072560124e@mail.gmail.com>
References: <e06186140911041918p2b303880s9a6596933ed79e82@mail.gmail.com>
	<ce557a360911041939x4e5b3b59yaf84d0fcc449229c@mail.gmail.com>
	<e06186140911041957h35083ddfj39f398072560124e@mail.gmail.com>
Message-ID: <ce557a360911042004p51a0ed44m92c9515d23ad5c5a@mail.gmail.com>

2009/11/4 Charles R Harris <charlesr.harris at gmail.com>:
>
>
> On Wed, Nov 4, 2009 at 8:39 PM, Anne Archibald <peridot.faceted at gmail.com>
> wrote:
>>
>> 2009/11/4 Charles R Harris <charlesr.harris at gmail.com>:
>> > I see the following test errors on ubuntu_x86_64 9.10
>> >
>> > ERROR: Check linalg works with non-aligned memory
>> > ----------------------------------------------------------------------
>> > Traceback (most recent call last):
>> > ? File "/usr/lib/pymodules/python2.6/nose/case.py", line 183, in runTest
>> > ??? self.test(*self.arg)
>> > ? File
>> >
>> > "/usr/local/lib/python2.6/dist-packages/scipy/linalg/tests/test_decomp.py",
>> > line 1067, in test_aligned_mem
>> > ??? eig(z.T, overwrite_a=True)
>> > ? File "/usr/local/lib/python2.6/dist-packages/scipy/linalg/decomp.py",
>> > line
>> > 158, in eig
>> > ??? geev, = get_lapack_funcs(('geev',),(a1,))
>> > ? File "/usr/local/lib/python2.6/dist-packages/scipy/linalg/lapack.py",
>> > line
>> > 82, in get_lapack_funcs
>> > ??? raise ValueError("Non-aligned array cannot be passed to LAPACK
>> > without
>> > copying")
>> > ValueError: Non-aligned array cannot be passed to LAPACK without copying
>> [...]
>> > I suspect the last failure is an mpmath version problem, and maybe the
>> > second also. Is anyone else seeing the other error?
>>
>> This error is related to ticket 794:
>> http://projects.scipy.org/scipy/ticket/794
>> Under certain poorly-defined circumstances, passing non-aligned
>> matrices to ATLAS can cause a segfault. I've posted a support request
>> on the ATLAS tracker, hoping to find out whether it's supposed to be
>> able to deal with non-aligned matrices, and in the meantime I have
>> code to raise exceptions when non-aligned matrices are fed to LAPACK.
>>
>> I don't know whether the bug occurs at all on 64-bit systems, and I
>> don't know whether it's the result of us abusing ATLAS or a bug in
>> ATLAS. If it's a bug in ATLAS, I don't know for sure what triggers it
>> - in particular, whether alignment actually solves the problem on all
>> platforms.
>>
>>
>> One solution would be to annotate all relevant f2py LAPACK wrappers
>> with the new align8 keyword and hope that cures the problem (by
>> forcing a copy of all not-sufficiently-aligned arrays on all LAPACK
>> installations).
>>
>> Another "solution" would be to simply remove the failing test and tell
>> people not to feed non-aligned matrices full of outrageous values into
>> ATLAS on pain of segfaults. (The bug was filed by someone who'd had a
>> segfault while working with an unpickled array, so it does bite some
>> people.)
>>
>> A third option would be to raise ValueErrors any time non-aligned
>> matrices are supposed to be passed to LAPACK. (This is what happens
>> now, but the tests fail when this happens; if this were the permanent
>> decision I would of course fix the tests to expect exceptions.)
>>
>> It might be possible, though I'm not sure how and it would be
>> complicated, to trigger all this working-around only when using ATLAS.
>>
>>
>> I'm not sure how best to deal with this. What do you think?
>>
>
> I haven't a clue as to what the best thing to do is. Using aligned matrices
> might be the best workaround. Were the alignment problems on SPARC? I recall
> a thread on the topic but don't remember what all was said.

I don't know about SPARC, but I was able to trigger them on my
Pentium-M machine using the SSE2 version of ATLAS. (Which means, among
other things, that this problem is going to affect a reasonable number
of users.)

Part of the problem with using aligned matrices is that I'm not
confident I know which routines need aligned matrices: I found
segfaults using eig and svd, but many others were fine - on my
machine. svd was a particular problem because as I understand the
f2py, the matrix is already always copied on input (and adding the
aligned flag didn't help, though aligning the array before I called
svd made the problem go away).

Anne


> Chuck
>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From charlesr.harris at gmail.com  Wed Nov  4 23:15:48 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Wed, 4 Nov 2009 21:15:48 -0700
Subject: [SciPy-dev] scipy errors
In-Reply-To: <ce557a360911042004p51a0ed44m92c9515d23ad5c5a@mail.gmail.com>
References: <e06186140911041918p2b303880s9a6596933ed79e82@mail.gmail.com>
	<ce557a360911041939x4e5b3b59yaf84d0fcc449229c@mail.gmail.com>
	<e06186140911041957h35083ddfj39f398072560124e@mail.gmail.com>
	<ce557a360911042004p51a0ed44m92c9515d23ad5c5a@mail.gmail.com>
Message-ID: <e06186140911042015td666ca4l8d02fc6034688528@mail.gmail.com>

On Wed, Nov 4, 2009 at 9:04 PM, Anne Archibald <peridot.faceted at gmail.com>wrote:

> 2009/11/4 Charles R Harris <charlesr.harris at gmail.com>:
> >
> >
> > On Wed, Nov 4, 2009 at 8:39 PM, Anne Archibald <
> peridot.faceted at gmail.com>
> > wrote:
> >>
> >> 2009/11/4 Charles R Harris <charlesr.harris at gmail.com>:
> >> > I see the following test errors on ubuntu_x86_64 9.10
> >> >
> >> > ERROR: Check linalg works with non-aligned memory
> >> > ----------------------------------------------------------------------
> >> > Traceback (most recent call last):
> >> >   File "/usr/lib/pymodules/python2.6/nose/case.py", line 183, in
> runTest
> >> >     self.test(*self.arg)
> >> >   File
> >> >
> >> >
> "/usr/local/lib/python2.6/dist-packages/scipy/linalg/tests/test_decomp.py",
> >> > line 1067, in test_aligned_mem
> >> >     eig(z.T, overwrite_a=True)
> >> >   File
> "/usr/local/lib/python2.6/dist-packages/scipy/linalg/decomp.py",
> >> > line
> >> > 158, in eig
> >> >     geev, = get_lapack_funcs(('geev',),(a1,))
> >> >   File
> "/usr/local/lib/python2.6/dist-packages/scipy/linalg/lapack.py",
> >> > line
> >> > 82, in get_lapack_funcs
> >> >     raise ValueError("Non-aligned array cannot be passed to LAPACK
> >> > without
> >> > copying")
> >> > ValueError: Non-aligned array cannot be passed to LAPACK without
> copying
> >> [...]
> >> > I suspect the last failure is an mpmath version problem, and maybe the
> >> > second also. Is anyone else seeing the other error?
> >>
> >> This error is related to ticket 794:
> >> http://projects.scipy.org/scipy/ticket/794
> >> Under certain poorly-defined circumstances, passing non-aligned
> >> matrices to ATLAS can cause a segfault. I've posted a support request
> >> on the ATLAS tracker, hoping to find out whether it's supposed to be
> >> able to deal with non-aligned matrices, and in the meantime I have
> >> code to raise exceptions when non-aligned matrices are fed to LAPACK.
> >>
> >> I don't know whether the bug occurs at all on 64-bit systems, and I
> >> don't know whether it's the result of us abusing ATLAS or a bug in
> >> ATLAS. If it's a bug in ATLAS, I don't know for sure what triggers it
> >> - in particular, whether alignment actually solves the problem on all
> >> platforms.
> >>
> >>
> >> One solution would be to annotate all relevant f2py LAPACK wrappers
> >> with the new align8 keyword and hope that cures the problem (by
> >> forcing a copy of all not-sufficiently-aligned arrays on all LAPACK
> >> installations).
> >>
> >> Another "solution" would be to simply remove the failing test and tell
> >> people not to feed non-aligned matrices full of outrageous values into
> >> ATLAS on pain of segfaults. (The bug was filed by someone who'd had a
> >> segfault while working with an unpickled array, so it does bite some
> >> people.)
> >>
> >> A third option would be to raise ValueErrors any time non-aligned
> >> matrices are supposed to be passed to LAPACK. (This is what happens
> >> now, but the tests fail when this happens; if this were the permanent
> >> decision I would of course fix the tests to expect exceptions.)
> >>
> >> It might be possible, though I'm not sure how and it would be
> >> complicated, to trigger all this working-around only when using ATLAS.
> >>
> >>
> >> I'm not sure how best to deal with this. What do you think?
> >>
> >
> > I haven't a clue as to what the best thing to do is. Using aligned
> matrices
> > might be the best workaround. Were the alignment problems on SPARC? I
> recall
> > a thread on the topic but don't remember what all was said.
>
> I don't know about SPARC, but I was able to trigger them on my
> Pentium-M machine using the SSE2 version of ATLAS. (Which means, among
> other things, that this problem is going to affect a reasonable number
> of users.)
>
> Part of the problem with using aligned matrices is that I'm not
> confident I know which routines need aligned matrices: I found
> segfaults using eig and svd, but many others were fine - on my
> machine. svd was a particular problem because as I understand the
> f2py, the matrix is already always copied on input (and adding the
> aligned flag didn't help, though aligning the array before I called
> svd made the problem go away).
>
>
ATLAS is a moving target and who knows what will cause trouble in the
future. On top of that, it is trying to get the best performance and that is
likely to mean code somewhere that likes aligned data. I've now read the
ticket and I think you are right to just use the new alignment option added
to f2py. I don't think you should wait too long on the ATLAS folks.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091104/340a0e24/attachment.html>

From pav+sp at iki.fi  Thu Nov  5 03:40:40 2009
From: pav+sp at iki.fi (Pauli Virtanen)
Date: Thu, 5 Nov 2009 08:40:40 +0000 (UTC)
Subject: [SciPy-dev] scipy errors
References: <e06186140911041918p2b303880s9a6596933ed79e82@mail.gmail.com>
Message-ID: <hcu328$roc$1@ger.gmane.org>

Wed, 04 Nov 2009 20:18:01 -0700, Charles R Harris wrote:
> I see the following test errors on ubuntu_x86_64 9.10
> 
> ERROR: Check linalg works with non-aligned memory
> ----------------------------------------------------------------------
[clip]
> ValueError: Non-aligned array cannot be passed to LAPACK without copying

The correct fix IMHO would be here to copy unaligned arrays.
This requires some messing around with all affected linalg functions.

> ======================================================================
> ERROR: test_mpmath.test_hyp2f1_real_some_points
[clip]
> ERROR: test_mpmath.test_hyp2f1_real_some
[clip]
> I suspect the last failure is an mpmath version problem, and maybe the
> second also. Is anyone else seeing the other error?

Both are mpmath version issues. Fixed.

-- 
Pauli Virtanen



From pav+sp at iki.fi  Thu Nov  5 03:48:07 2009
From: pav+sp at iki.fi (Pauli Virtanen)
Date: Thu, 5 Nov 2009 08:48:07 +0000 (UTC)
Subject: [SciPy-dev] scipy errors
References: <e06186140911041918p2b303880s9a6596933ed79e82@mail.gmail.com>
	<ce557a360911041939x4e5b3b59yaf84d0fcc449229c@mail.gmail.com>
	<e06186140911041957h35083ddfj39f398072560124e@mail.gmail.com>
	<ce557a360911042004p51a0ed44m92c9515d23ad5c5a@mail.gmail.com>
	<e06186140911042015td666ca4l8d02fc6034688528@mail.gmail.com>
Message-ID: <hcu3g7$roc$2@ger.gmane.org>

Wed, 04 Nov 2009 21:15:48 -0700, Charles R Harris wrote:
[clip]
> ATLAS is a moving target and who knows what will cause trouble in the
> future. On top of that, it is trying to get the best performance and
> that is likely to mean code somewhere that likes aligned data. I've now
> read the ticket and I think you are right to just use the new alignment
> option added to f2py. I don't think you should wait too long on the
> ATLAS folks.

Ah yes, using the f2py functionality is a correct fix, too, now that I 
remember it again :)

I agree that it's best to just go ahead with the workaround already, and 
if the Atlas/LAPACK people find a fix, we can take the workarounds out.

(Note that the eig-headaches.diff patch contains

    for a in arrays:
+       break
        a = numpy.asarray(a)

Maybe it's best to remove the whole loop?)

-- 
Pauli Virtanen



From millman at berkeley.edu  Thu Nov  5 05:52:37 2009
From: millman at berkeley.edu (Jarrod Millman)
Date: Thu, 5 Nov 2009 02:52:37 -0800
Subject: [SciPy-dev] ANN: SciPy India 2009 Call for Presentations
Message-ID: <c7009a550911050252h6e24b302gefdb6b90c55d9a5f@mail.gmail.com>

Call for Presentations
======================

The SciPy India 2009 Program Committee is currently developing the conference
program.  We are seeking presentations from industry as well as the
academic world.

We look forward to hearing your recent breakthroughs using Python! Please
read the full `call for papers <http://scipy.in/talks-cfp/>`_.

SciPy India 2009 Conference
---------------------------

The first `SciPy India Conference <http://scipy.in>`_ will be held
from December 12th to 17th, 2009 at the `Technopark in Trivandrum
<http://www.technopark.org/>`_, Kerala, India.

The theme of the conference will be "Scientific Python in Action" with
respect to application and teaching.  We are pleased to have Travis
Oliphant, the creator and lead developer of `numpy
<http://numpy.scipy.org>`_ as the keynote speaker.

Please register `here <http://scipy.in>`_.

Important Dates
---------------

* Friday, Nov. 20: Abstracts Due
* Friday, Nov. 27: Announce accepted talks, post schedule
* Saturday-Sunday, Dec. 12-13               Conference
* Monday-Tuesday, Dec. 14-15        Tutorials
* Wednesday-Thursday, Dec. 16-17     Sprints

Organizers
----------

* Jarrod Millman, Neuroscience Institute, UC Berkeley, USA (Conference Co-Chair)
* Prabhu Ramachandran, Department of Aerospace Engineering,
 IIT Bombay, India (Conference Co-Chair)
* FOSSEE Team

Sponsors
--------

* National Mission On Education through ICT - Ministry of Human
Resource Development, Government of India
* SPACE-Kerala (India)
* Kerala State IT Mission(KSITM)
* SIG-FOSS Of CSI


From nwagner at iam.uni-stuttgart.de  Thu Nov  5 12:53:53 2009
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Thu, 05 Nov 2009 18:53:53 +0100
Subject: [SciPy-dev] scipy_iv.o" failed with exit status 1
Message-ID: <web-126665290@uni-stuttgart.de>

Hi,

I cannot build scipy from svn.

gcc: scipy/special/cephes/scipy_iv.c
scipy/special/cephes/scipy_iv.c:76: error: expected ?)? 
before ?__extension__?
scipy/special/cephes/scipy_iv.c:76: error: expected ?;?, 
?,? or ?)? before ?double?
scipy/special/cephes/scipy_iv.c: In function ?cephes_iv?:
scipy/special/cephes/scipy_iv.c:127: warning: implicit 
declaration of function ?ikv_temme?
scipy/special/cephes/scipy_iv.c:81: warning: unused 
variable ?vp?
scipy/special/cephes/scipy_iv.c: In function 
?iv_asymptotic?:
scipy/special/cephes/scipy_iv.c:140: warning: unused 
variable ?mup?
scipy/special/cephes/scipy_iv.c: At top level:
scipy/special/cephes/scipy_iv.c:526: error: expected ?)? 
before ?__extension__?
scipy/special/cephes/scipy_iv.c:526: error: expected ?;?, 
?,? or ?)? before ?double?
scipy/special/cephes/scipy_iv.c:76: error: expected ?)? 
before ?__extension__?
scipy/special/cephes/scipy_iv.c:76: error: expected ?;?, 
?,? or ?)? before ?double?
scipy/special/cephes/scipy_iv.c: In function ?cephes_iv?:
scipy/special/cephes/scipy_iv.c:127: warning: implicit 
declaration of function ?ikv_temme?
scipy/special/cephes/scipy_iv.c:81: warning: unused 
variable ?vp?
scipy/special/cephes/scipy_iv.c: In function 
?iv_asymptotic?:
scipy/special/cephes/scipy_iv.c:140: warning: unused 
variable ?mup?
scipy/special/cephes/scipy_iv.c: At top level:
scipy/special/cephes/scipy_iv.c:526: error: expected ?)? 
before ?__extension__?
scipy/special/cephes/scipy_iv.c:526: error: expected ?;?, 
?,? or ?)? before ?double?
error: Command "/usr/bin/gcc -fno-strict-aliasing -DNDEBUG 
-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 
-fstack-protctor -funwind-tables 
-fasynchronous-unwind-tables -g -fwrapv -fPIC 
-I/usr/include/python2.6 
-I/home/nwagner/local/lib64/ython2.6/site-packages/numpy/core/include 
-I/home/nwagner/local/lib64/python2.6/site-packages/numpy/core/include 
-c scip/special/cephes/scipy_iv.c -o 
build/temp.linux-x86_64-2.6/scipy/special/cephes/scipy_iv.o" 
failed with exit status 1
  
Nils


From pav+sp at iki.fi  Thu Nov  5 13:18:29 2009
From: pav+sp at iki.fi (Pauli Virtanen)
Date: Thu, 5 Nov 2009 18:18:29 +0000 (UTC)
Subject: [SciPy-dev] scipy_iv.o" failed with exit status 1
References: <web-126665290@uni-stuttgart.de>
Message-ID: <hcv4tl$jde$1@ger.gmane.org>

Thu, 05 Nov 2009 18:53:53 +0100, Nils Wagner wrote:
> I cannot build scipy from svn.
[clip]
> scipy/special/cephes/scipy_iv.c:76: error: expected ")"
> before "__extension__"
[clip]

It's because the current npy_math.h includes <complex.h> which defines 
"I" as the imaginary unit. Fixing...

-- 
Pauli Virtanen



From nwagner at iam.uni-stuttgart.de  Thu Nov  5 15:11:03 2009
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Thu, 05 Nov 2009 21:11:03 +0100
Subject: [SciPy-dev] scipy_iv.o" failed with exit status 1
In-Reply-To: <hcv4tl$jde$1@ger.gmane.org>
References: <web-126665290@uni-stuttgart.de>
 <hcv4tl$jde$1@ger.gmane.org>
Message-ID: <web-126669297@uni-stuttgart.de>

On Thu, 5 Nov 2009 18:18:29 +0000 (UTC)
  Pauli Virtanen <pav+sp at iki.fi> wrote:
> Thu, 05 Nov 2009 18:53:53 +0100, Nils Wagner wrote:
>> I cannot build scipy from svn.
> [clip]
>> scipy/special/cephes/scipy_iv.c:76: error: expected ")"
>> before "__extension__"
> [clip]
> 
> It's because the current npy_math.h includes <complex.h> 
>which defines 
> "I" as the imaginary unit. Fixing...
> 
> -- 
> Pauli Virtanen
> 
The next problem is

Warning: Unused variable 'deltatolepstol' declared at (1)
/usr/bin/gfortran -Wall -Wall -shared 
build/temp.linux-x86_64-2.6/build/src.linux-x86_64-2.6/build/src.linux-x86_64-2.6/scipy/sparse/linalg/isolve/iterative/_iterativemodule.o 
build/temp.linux-x86_64-2.6/build/src.linux-x86_64-2.6/fortranobject.o 
build/temp.linux-x86_64-2.6/build/src.linux-x86_64-2.6/scipy/sparse/linalg/isolve/iterative/STOPTEST2.o 
build/temp.linux-x86_64-2.6/build/src.linux-x86_64-2.6/scipy/sparse/linalg/isolve/iterative/getbreak.o 
build/temp.linux-x86_64-2.6/build/src.linux-x86_64-2.6/scipy/sparse/linalg/isolve/iterative/BiCGREVCOM.o 
build/temp.linux-x86_64-2.6/build/src.linux-x86_64-2.6/scipy/sparse/linalg/isolve/iterative/BiCGSTABREVCOM.o 
build/temp.linux-x86_64-2.6/build/src.linux-x86_64-2.6/scipy/sparse/linalg/isolve/iterative/CGREVCOM.o 
build/temp.linux-x86_64-2.6/build/src.linux-x86_64-2.6/scipy/sparse/linalg/isolve/iterative/CGSREVCOM.o 
build/temp.linux-x86_64-2.6/build/src.linux-x86_64-2.6/scipy/sparse/linalg/isolve/iterative/GMRESREVCOM.o 
build/temp.linux-x86_64-2.6/build/src.linux-x86_64-2.6/scipy/sparse/linalg/isolve/iterative/QMRREVCOM.o 
-L/home/nwagner/src/ATLAS3.8.2/mybuild/lib -L/usr/lib64 
-Lbuild/temp.linux-x86_64-2.6 -llapack -lptf77blas 
-lptcblas -latlas -lpython2.6 -lgfortran -o 
build/lib.linux-x86_64-2.6/scipy/sparse/linalg/isolve/_iterative.so
building 'scipy.sparse.linalg.dsolve._zsuperlu' extension
compiling C sources
C compiler: /usr/bin/gcc -fno-strict-aliasing -DNDEBUG 
-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 
-fstack-protector -funwind-tables 
-fasynchronous-unwind-tables -g -fwrapv -fPIC

compile options: '-DATLAS_INFO="\"3.8.2\"" 
-DUSE_VENDOR_BLAS=1 -I/home/nwagner/src/ATLAS3.8.2/include 
-I/home/nwagner/local/lib64/python2.6/site-packages/numpy/core/include 
-I/usr/include/python2.6 -c'
gcc: scipy/sparse/linalg/dsolve/_zsuperlumodule.c
In file included from 
scipy/sparse/linalg/dsolve/_superluobject.h:8,
                  from 
scipy/sparse/linalg/dsolve/_zsuperlumodule.c:32:
scipy/sparse/linalg/dsolve/SuperLU/SRC/scomplex.h:19: 
error: two or more data types in declaration specifiers
scipy/sparse/linalg/dsolve/SuperLU/SRC/scomplex.h:19: 
warning: unnamed struct/union that defines no instances
In file included from 
scipy/sparse/linalg/dsolve/_superluobject.h:8,
                  from 
scipy/sparse/linalg/dsolve/_zsuperlumodule.c:32:
scipy/sparse/linalg/dsolve/SuperLU/SRC/scomplex.h:19: 
error: two or more data types in declaration specifiers
scipy/sparse/linalg/dsolve/SuperLU/SRC/scomplex.h:19: 
warning: unnamed struct/union that defines no instances
error: Command "/usr/bin/gcc -fno-strict-aliasing -DNDEBUG 
-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 
-fstack-protector -funwind-tables 
-fasynchronous-unwind-tables -g -fwrapv -fPIC 
-DATLAS_INFO="\"3.8.2\"" -DUSE_VENDOR_BLAS=1 
-I/home/nwagner/src/ATLAS3.8.2/include 
-I/home/nwagner/local/lib64/python2.6/site-packages/numpy/core/include 
-I/usr/include/python2.6 -c 
scipy/sparse/linalg/dsolve/_zsuperlumodule.c -o 
build/temp.linux-x86_64-2.6/scipy/sparse/linalg/dsolve/_zsuperlumodule.o" 
failed with exit status 1
  

Nils


From jakevdp at gmail.com  Fri Nov  6 13:22:31 2009
From: jakevdp at gmail.com (Jake VanderPlas)
Date: Fri, 6 Nov 2009 10:22:31 -0800
Subject: [SciPy-dev] How to include new code (Re: Ball Tree)
In-Reply-To: <e06186140911021008q7ea3eb78p61806a3459ea6b12@mail.gmail.com>
References: <58df6dc20911020741l57c2feex942cf7097a8f4fe3@mail.gmail.com>
	<e06186140911021008q7ea3eb78p61806a3459ea6b12@mail.gmail.com>
Message-ID: <58df6dc20911061022o54f3cfa3ka813cca6ccf25f5f@mail.gmail.com>

On Mon, Nov 2, 2009 at 10:08 AM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
> On Mon, Nov 2, 2009 at 8:41 AM, Jake VanderPlas <jakevdp at gmail.com> wrote:
>>
>> Hello,
>> I have been following the developer's list for a while, and I would
>> like to start contributing to scipy. ?I wrote the list about a Ball
>> Tree implementation that I would like to include in scipy.spatial.
>> I've written a python/C++ implementation, and for k-nearest-neighbor
>> searches in large dimensions (d~1000), it is about 10 times faster
>> than the current scipy.spatial.cKDTree. ?Can someone point me to
>> instructions on how to start the process of including this in scipy?
>> I have a local copy of the scipy svn, and my code consists of a few
>> C++ files and a working setup.py ?Thanks!
>> ? -Jake
>> __
>
> Sounds like the easiest way would be to open a ticket, attach a patch, and
> mark it for review. If it doesn't get any attention, complain on the list.
> In any case, if the new addition needs maintenance you will probably need
> commit privileges in the long run.
>
> Chuck
>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
Thanks for the info,
I've uploaded my BallTree code to ticket number 1048
  http://projects.scipy.org/scipy/ticket/1048
The Ball Tree class offers order-of-magnitude speed improvements over
scipy.spatial.cKDTree for high-dimensional neighbor searches.  Take a
look - I'd love to hear your thoughts!
   -Jake


From dwf at cs.toronto.edu  Fri Nov  6 16:23:46 2009
From: dwf at cs.toronto.edu (David Warde-Farley)
Date: Fri, 6 Nov 2009 16:23:46 -0500
Subject: [SciPy-dev] Build failure on OS X 10.5.8, Python 2.5, gcc-4.0.1
Message-ID: <807642B9-90E9-47B8-97A8-2665F682D544@cs.toronto.edu>

Not sure what's going on here, it looks like an issue with the new  
complex number stuff?

Also, I see lots of warnings about "missing required architecture  
x86_64 in file". This is puzzling since I'm compiling against 32-bit  
Python...

This is with r7694 of NumPy and r6083 of SciPy.

David


compile options: '-Ibuild/src.macosx-10.3-ppc-2.5 -I/Library/ 
Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/ 
numpy/core/include -I/Library/Frameworks/Python.framework/Versions/2.5/ 
include/python2.5 -c'
gcc: build/src.macosx-10.3-ppc-2.5/scipy/integrate/_dopmodule.c
/usr/local/bin/gfortran -Wall -arch ppc -arch i686 -arch x86_64 -Wall - 
undefined dynamic_lookup -bundle build/temp.macosx-10.3-ppc-2.5/build/ 
src.macosx-10.3-ppc-2.5/scipy/integrate/_dopmodule.o build/ 
temp.macosx-10.3-ppc-2.5/build/src.macosx-10.3-ppc-2.5/fortranobject.o  
-Lbuild/temp.macosx-10.3-ppc-2.5 -ldop -lgfortran -o build/ 
lib.macosx-10.3-ppc-2.5/scipy/integrate/_dop.so
ld warning: in build/temp.macosx-10.3-ppc-2.5/build/src.macosx-10.3- 
ppc-2.5/scipy/integrate/_dopmodule.o, missing required architecture  
x86_64 in file
ld warning: in build/temp.macosx-10.3-ppc-2.5/build/src.macosx-10.3- 
ppc-2.5/fortranobject.o, missing required architecture x86_64 in file
building 'scipy.interpolate._fitpack' extension
compiling C sources
C compiler: gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/ 
MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp - 
mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3

creating build/temp.macosx-10.3-ppc-2.5/scipy/interpolate/src
compile options: '-I/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/numpy/core/include -I/Library/Frameworks/ 
Python.framework/Versions/2.5/include/python2.5 -c'
gcc: scipy/interpolate/src/_fitpackmodule.c
In file included from scipy/interpolate/src/_fitpackmodule.c:7:
scipy/interpolate/src/__fitpack.h: In function ?fitpack_surfit?:
scipy/interpolate/src/__fitpack.h:217: warning: passing argument 18 of  
?surfit_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h:217: warning: passing argument 20 of  
?surfit_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h:225: warning: passing argument 18 of  
?surfit_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h:225: warning: passing argument 20 of  
?surfit_? from incompatible pointer type
In file included from scipy/interpolate/src/_fitpackmodule.c:7:
scipy/interpolate/src/__fitpack.h: In function ?fitpack_surfit?:
scipy/interpolate/src/__fitpack.h:217: warning: passing argument 18 of  
?surfit_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h:217: warning: passing argument 20 of  
?surfit_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h:225: warning: passing argument 18 of  
?surfit_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h:225: warning: passing argument 20 of  
?surfit_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h: In function ?fitpack_parcur?:
scipy/interpolate/src/__fitpack.h:329: warning: passing argument 12 of  
?clocur_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h:332: warning: passing argument 14 of  
?parcur_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h: In function ?fitpack_parcur?:
scipy/interpolate/src/__fitpack.h:329: warning: passing argument 12 of  
?clocur_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h:332: warning: passing argument 14 of  
?parcur_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h: In function ?fitpack_curfit?:
scipy/interpolate/src/__fitpack.h:408: warning: passing argument 9 of  
?percur_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h:410: warning: passing argument 11 of  
?curfit_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h: In function ?fitpack_curfit?:
scipy/interpolate/src/__fitpack.h:408: warning: passing argument 9 of  
?percur_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h:410: warning: passing argument 11 of  
?curfit_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h: In function ?fitpack_spl_?:
scipy/interpolate/src/__fitpack.h:474: warning: passing argument 8 of  
?splder_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h:476: warning: passing argument 7 of  
?splev_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h: In function ?fitpack_spl_?:
scipy/interpolate/src/__fitpack.h:474: warning: passing argument 8 of  
?splder_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h:476: warning: passing argument 7 of  
?splev_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h: In function ?fitpack_splint?:
scipy/interpolate/src/__fitpack.h:508: warning: passing argument 2 of  
?splint_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h: In function ?fitpack_splint?:
scipy/interpolate/src/__fitpack.h:508: warning: passing argument 2 of  
?splint_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h: In function ?fitpack_sproot?:
scipy/interpolate/src/__fitpack.h:537: warning: passing argument 6 of  
?sproot_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h: In function ?fitpack_sproot?:
scipy/interpolate/src/__fitpack.h:537: warning: passing argument 6 of  
?sproot_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h: In function ?fitpack_spalde?:
scipy/interpolate/src/__fitpack.h:571: warning: passing argument 4 of  
?spalde_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h: In function ?fitpack_spalde?:
scipy/interpolate/src/__fitpack.h:571: warning: passing argument 4 of  
?spalde_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h: In function ?fitpack_insert?:
scipy/interpolate/src/__fitpack.h:604: warning: passing argument 10 of  
?insert_? from incompatible pointer type
scipy/interpolate/src/__fitpack.h: In function ?fitpack_insert?:
scipy/interpolate/src/__fitpack.h:604: warning: passing argument 10 of  
?insert_? from incompatible pointer type
/usr/local/bin/gfortran -Wall -arch ppc -arch i686 -arch x86_64 -Wall - 
undefined dynamic_lookup -bundle build/temp.macosx-10.3-ppc-2.5/scipy/ 
interpolate/src/_fitpackmodule.o -Lbuild/temp.macosx-10.3-ppc-2.5 - 
lfitpack -lgfortran -o build/lib.macosx-10.3-ppc-2.5/scipy/interpolate/ 
_fitpack.so
ld warning: in build/temp.macosx-10.3-ppc-2.5/scipy/interpolate/src/ 
_fitpackmodule.o, missing required architecture x86_64 in file
building 'scipy.interpolate.dfitpack' extension
compiling C sources
C compiler: gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/ 
MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp - 
mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3

creating build/temp.macosx-10.3-ppc-2.5/build/src.macosx-10.3-ppc-2.5/ 
scipy/interpolate
creating build/temp.macosx-10.3-ppc-2.5/build/src.macosx-10.3-ppc-2.5/ 
scipy/interpolate/src
compile options: '-Ibuild/src.macosx-10.3-ppc-2.5 -I/Library/ 
Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/ 
numpy/core/include -I/Library/Frameworks/Python.framework/Versions/2.5/ 
include/python2.5 -c'
gcc: build/src.macosx-10.3-ppc-2.5/scipy/interpolate/src/ 
dfitpackmodule.c
compiling Fortran sources
Fortran f77 compiler: /usr/local/bin/gfortran -Wall -ffixed-form -fno- 
second-underscore -arch ppc -arch i686 -arch x86_64 -fPIC -O3 -funroll- 
loops
Fortran f90 compiler: /usr/local/bin/gfortran -Wall -fno-second- 
underscore -arch ppc -arch i686 -arch x86_64 -fPIC -O3 -funroll-loops
Fortran fix compiler: /usr/local/bin/gfortran -Wall -ffixed-form -fno- 
second-underscore -Wall -fno-second-underscore -arch ppc -arch i686 - 
arch x86_64 -fPIC -O3 -funroll-loops
compile options: '-Ibuild/src.macosx-10.3-ppc-2.5 -I/Library/ 
Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/ 
numpy/core/include -I/Library/Frameworks/Python.framework/Versions/2.5/ 
include/python2.5 -c'
gfortran:f77: build/src.macosx-10.3-ppc-2.5/scipy/interpolate/src/ 
dfitpack-f2pywrappers.f
/usr/local/bin/gfortran -Wall -arch ppc -arch i686 -arch x86_64 -Wall - 
undefined dynamic_lookup -bundle build/temp.macosx-10.3-ppc-2.5/build/ 
src.macosx-10.3-ppc-2.5/scipy/interpolate/src/dfitpackmodule.o build/ 
temp.macosx-10.3-ppc-2.5/build/src.macosx-10.3-ppc-2.5/fortranobject.o  
build/temp.macosx-10.3-ppc-2.5/build/src.macosx-10.3-ppc-2.5/scipy/ 
interpolate/src/dfitpack-f2pywrappers.o -Lbuild/temp.macosx-10.3- 
ppc-2.5 -lfitpack -lgfortran -o build/lib.macosx-10.3-ppc-2.5/scipy/ 
interpolate/dfitpack.so
ld warning: in build/temp.macosx-10.3-ppc-2.5/build/src.macosx-10.3- 
ppc-2.5/scipy/interpolate/src/dfitpackmodule.o, missing required  
architecture x86_64 in file
ld warning: in build/temp.macosx-10.3-ppc-2.5/build/src.macosx-10.3- 
ppc-2.5/fortranobject.o, missing required architecture x86_64 in file
building 'scipy.interpolate._interpolate' extension
compiling C++ sources
C compiler: g++ -arch ppc -arch i386 -isysroot /Developer/SDKs/ 
MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp - 
mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3

compile options: '-Iscipy/interpolate/src -I/Library/Frameworks/ 
Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy/core/ 
include -I/Library/Frameworks/Python.framework/Versions/2.5/include/ 
python2.5 -c'
g++: scipy/interpolate/src/_interpolate.cpp
In file included from /Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/ 
4.0.0/backward/complex.h:31,
                  from /Library/Frameworks/Python.framework/Versions/ 
2.5/lib/python2.5/site-packages/numpy/core/include/numpy/npy_common.h: 
101,
                  from /Library/Frameworks/Python.framework/Versions/ 
2.5/lib/python2.5/site-packages/numpy/core/include/numpy/ 
ndarrayobject.h:68,
                  from /Library/Frameworks/Python.framework/Versions/ 
2.5/lib/python2.5/site-packages/numpy/core/include/numpy/arrayobject.h: 
14,
                  from scipy/interpolate/src/_interpolate.cpp:5:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/backward/ 
backward_warning.h:32:2: warning: #warning This file includes at least  
one deprecated or antiquateIn file included from /Developer/SDKs/ 
MacOSX10.4u.sdk/usr/include/c++/4.0.0/backward/complex.h:31d,
                  from /Library/Frameworks/Python.framework/Versions/ 
2.5/lib/python2.5/site-packages/numpy/core/include/numpy/npy_common.h: 
101 h,
                  from /Library/Frameworks/Python.framework/Versions/ 
2.5/lib/python2.5/site-packages/numpy/core/include/numpy/ 
ndarrayobject.h:68ea,
                  from /Library/Frameworks/Python.framework/Versions/ 
2.5/lib/python2.5/site-packages/numpy/core/include/numpy/arrayobject.h: 
14de,
                  from scipy/interpolate/src/_interpolate.cpp:5r:
./Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/backward/ 
backward_warning.h:32:2:  Pleawarning: #warning Thiss fiele c  
oinnscilduedre using one of s at lethe 32 headersast  onef oundepd in  
section 17.4.1.2 orecf the C++ stateandd or antiquatedard. Examples   
hinecadleurd.e Pleas seu bcsotnitsuitdienrg u stihne g< Xo> header for  
ne tofh et <hXe 32 headers. found in section 17.4.1.2h o>f  thhee aCd+e 
+r  sftoarn dCa+rd+.  iEnxcalmpuldeess ,i nocrl u<dei suobstituting  
thstree <X> aheadmer>  fori nsttheea d<X .ohf>  htehea ddeer pfroerca  
tCe+d+  ihnecaldeurd es, <or io<iosstreatrema.mh>. To disabl>e   
tihnsitse awdarn ionfg t huese  d-epWrneo-decaprecatedt.
ed header <iostream.h>. To disable this warning use -Wno-deprecated.
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:85: error:  
template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?float std::abs(float)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:92: error:  
declaration of C function ?float std::abs(float)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:88: error:  
previous declaration ?double std::abs(double)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::abs(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:96: error:  
declaration of C function ?long double std::abs(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:92: error:  
previous declaration ?float std::abs(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::acos(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:106:  
error: declaration of C function ?long double std::acos(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:102:  
error: previous declaration ?float std::acos(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:111:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::asin(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:123:  
error: declaration of C function ?long double std::asin(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:119:  
error: previous declaration ?float std::asin(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:128:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::atan(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:138:  
error: declaration of C function ?long double std::atan(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:134:  
error: previous declaration ?float std::atan(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:143:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::atan2(long double, long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:153:  
error: declaration of C function ?long double std::atan2(long double,  
long double)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:149:  
error: previous declaration ?float std::atan2(float, float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:159:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::ceil(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:169:  
error: declaration of C function ?long double std::ceil(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:165:  
error: previous declaration ?float std::ceil(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:174:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::cos(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:184:  
error: declaration of C function ?long double std::cos(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:180:  
error: previous declaration ?float std::cos(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:189:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:85: error:  
template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?float std::abs(float)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:92: error:  
declaration of C function ?float std::abs(float)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:88: error:  
previous declaration ?double std::abs(double)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::abs(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:96: error:  
declaration of C function ?long double std::abs(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:92: error:  
previous declaration ?float std::abs(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::acos(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:106:  
error: declaration of C function ?long double std::acos(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::cosh(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:199:  
error: declaration of C function ?long double std::cosh(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:195:  
error: previous declaration ?float std::cosh(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:102:  
error: previous declaration ?float std::acos(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:204:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:111:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::asin(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:123:  
error: declaration of C function ?long double std::asin(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:119:  
error: previous declaration ?float std::asin(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::exp(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:214:  
error: declaration of C function ?long double std::exp(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:210:  
error: previous declaration ?float std::exp(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:128:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:219:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::atan(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:138:  
error: declaration of C function ?long double std::atan(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:134:  
error: previous declaration ?float std::atan(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:143:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::fabs(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:229:  
error: declaration of C function ?long double std::fabs(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:225:  
error: previous declaration ?float std::fabs(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::atan2(long double, long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:153:  
error: declaration of C function ?long double std::atan2(long double,  
long double)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:149:  
error: previous declaration ?float std::atan2(float, float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:159:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:234:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::ceil(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:169:  
error: declaration of C function ?long double std::ceil(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:165:  
error: previous declaration ?float std::ceil(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:174:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::floor(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:244:  
error: declaration of C function ?long double std::floor(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:240:  
error: previous declaration ?float std::floor(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::cos(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:184:  
error: declaration of C function ?long double std::cos(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:180:  
error: previous declaration ?float std::cos(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:249:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:189:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::fmod(long double, long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:259:  
error: declaration of C function ?long double std::fmod(long double,  
long double)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::cosh(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:199:  
error: declaration of C function ?long double std::cosh(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:255:  
error: previous declaration ?float std::fmod(float, float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:195:  
error: previous declaration ?float std::cosh(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:204:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::frexp(long double, int*)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:269:  
error: declaration of C function ?long double std::frexp(long double,  
int*)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:265:  
error: previous declaration ?float std::frexp(float, int*)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::exp(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:214:  
error: declaration of C function ?long double std::exp(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:210:  
error: previous declaration ?float std::exp(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:274:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:219:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::ldexp(long double, int)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:284:  
error: declaration of C function ?long double std::ldexp(long double,  
int)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:280:  
error: previous declaration ?float std::ldexp(float, int)? here/ 
Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::fabs(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:229:  
error: declaration of C function ?long double std::fabs(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:225:  
error: previous declaration ?float std::fabs(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:234:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::floor(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:244:  
error: declaration of C function ?long double std::floor(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:240:  
error: previous declaration ?float std::floor(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:249:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::fmod(long double, long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:259:  
error: declaration of C function ?long double std::fmod(long double,  
long double)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:255:  
error: previous declaration ?float std::fmod(float, float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::frexp(long double, int*)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:269:  
error: declaration of C function ?long double std::frexp(long double,  
int*)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:265:  
error: previous declaration ?float std::frexp(float, int*)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:274:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::ldexp(long double, int)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:284:  
error: declaration of C function ?long double std::ldexp(long double,  
int)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:280:  
error: previous declaration ?float std::ldexp(float, int)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:289:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::log(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:299:  
error: declaration of C function ?long double std::log(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:295:  
error: previous declaration ?float std::log(float)? here

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:304:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::log10(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:314:  
error: declaration of C function ?long double std::log10(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:310:  
error: previous declaration ?float std::log10(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:319:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:289:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::modf(long double, long double*)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:329:  
error: declaration of C function ?long double std::modf(long double,  
long double*)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:325:  
error: previous declaration ?float std::modf(float, float*)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:334:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::pow(long double, long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:348:  
error: declaration of C function ?long double std::pow(long double,  
long double)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:344:  
error: previous declaration ?float std::pow(float, float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:352:  
error: declaration of C function ?double std::pow(double, int)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:348:  
error: previous declaration ?long double std::pow(long double, long  
double)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::log(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:299:  
error: declaration of C function ?long double std::log(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:295:  
error: previous declaration ?float std::log(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?float std::pow(float, int)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:356:  
error: declaration of C function ?float std::pow(float, int)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:352:  
error: previous declaration ?double std::pow(double, int)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::pow(long double, int)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:360:  
error: declaration of C function ?long double std::pow(long double,  
int)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:356:  
error: previous declaration ?float std::pow(float, int)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:304:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::sin(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:370:  
error: declaration of C function ?long double std::sin(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:366:  
error: previous declaration ?float std::sin(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:375:  
error: template with C linkage/Developer/SDKs/MacOSX10.4u.sdk/usr/ 
include/c++/4.0.0/cmath: In function ?long double std::log10(long  
double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:314:  
error: declaration of C function ?long double std::log10(long double)?  
conflicts with

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:310:  
error: previous declaration ?float std::log10(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:319:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::sinh(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:385:  
error: declaration of C function ?long double std::sinh(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:381:  
error: previous declaration ?float std::sinh(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:390:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::modf(long double, long double*)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:329:  
error: declaration of C function ?long double std::modf(long double,  
long double*)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:325:  
error: previous declaration ?float std::modf(float, float*)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::sqrt(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:400:  
error: declaration of C function ?long double std::sqrt(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:396:  
error: previous declaration ?float std::sqrt(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:334:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:405:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::pow(long double, long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:348:  
error: declaration of C function ?long double std::pow(long double,  
long double)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:344:  
error: previous declaration ?float std::pow(float, float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::tan(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:415:  
error: declaration of C function ?long double std::tan(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:411:  
error: previous declaration ?float std::tan(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?double std::pow(double, int)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:352:  
error: declaration of C function ?double std::pow(double, int)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:348:  
error: previous declaration ?long double std::pow(long double, long  
double)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:420:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::pow(long double, long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:356:  
error: declaration of C function ?float std::pow(float, int)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:352:  
error: previous declaration ?double std::pow(double, int)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::tanh(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:430:  
error: declaration of C function ?long double std::tanh(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:426:  
error: previous declaration ?float std::tanh(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::pow(long double, int)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:360:  
error: declaration of C function ?long double std::pow(long double,  
int)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:356:  
error: previous declaration ?float std::pow(float, int)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:435:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:448:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:452:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:456:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:460:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:464:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:468:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:472:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:477:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:482:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::sin(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:370:  
error: declaration of C function ?long double std::sin(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:366:  
error: previous declaration ?float std::sin(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:486:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:491:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:496:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:518:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:375:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:522:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:526:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:530:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::sinh(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:385:  
error: declaration of C function ?long double std::sinh(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:381:  
error: previous declaration ?float std::sinh(float)? here/Developer/ 
SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:534: error: template  
with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:538:  
error: template with C linkage

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:542:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:547:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:390:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:552:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:557:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:562:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::sqrt(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:400:  
error: declaration of C function ?long double std::sqrt(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:567:  
error: template with C linkage/Developer/SDKs/MacOSX10.4u.sdk/usr/ 
include/c++/4.0.0/cmath:396: error: previous declaration ?float  
std::sqrt(float)? here

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/bits/cmath.tcc: 
39: error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:405:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::tan(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:415:  
error: declaration of C function ?long double std::tan(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:411:  
error: previous declaration ?float std::tan(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:420:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::tanh(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:430:  
error: declaration of C function ?long double std::tanh(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:426:  
error: previous declaration ?float std::tanh(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:435:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:448:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:452:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:456:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:460:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:464:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:468:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:472:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:477:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:482:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:486:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:491:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:496:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:518:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:522:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:526:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:530:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:534:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:538:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:542:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:547:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:552:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:557:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:562:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:567:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/bits/cmath.tcc: 
39: error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:55:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:61:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:63:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:65:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:68:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:70:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:74:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:76:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:78:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:80:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:82:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:84:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:86:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:89:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:91:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:93:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:95:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:97:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:99:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:101:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:128:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:155:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:158:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:161:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:164:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:167:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:55:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:61:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:63:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:65:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:318:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:68:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:70:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:74:  
error: template with C linkage/Developer/SDKs/MacOSX10.4u.sdk/usr/ 
include/c++/4.0.0/complex:327: error: template with C linkage

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:76:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:336:  
error: template with C linkage/Developer/SDKs/MacOSX10.4u.sdk/usr/ 
include/c++/4.0.0/complex:78: error: template with C linkage

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:80:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:348:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:357:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:82:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:366:  
error: template with C linkage/Developer/SDKs/MacOSX10.4u.sdk/usr/ 
include/c++/4.0.0/complex:84: error: template with C linkage

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:86:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:378:  
error: template with C linkage/Developer/SDKs/MacOSX10.4u.sdk/usr/ 
include/c++/4.0.0/complex:89: error: template with C linkage

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:91:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:93:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:387:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:95:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:396:  
error: template with C linkage/Developer/SDKs/MacOSX10.4u.sdk/usr/ 
include/c++/4.0.0/complex:97: error: template with C linkage

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:99:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:101:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:408:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:417:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:128:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:426:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:437:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:443:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:155:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:158:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:161:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:164:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:450:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:167:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:455:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:460:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:468:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:473:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:478:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:485:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:518:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:531:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:536:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:541:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:546:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:318:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:552:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:327:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:336:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:348:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double std::__complex_abs(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:569:  
error: declaration of C function ?double std::__complex_abs(double  
__complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:566:  
error: previous declaration ?float std::__complex_abs(float  
__complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:357:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double std::__complex_abs(const long double  
__complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:572:  
error: declaration of C function ?long double std::__complex_abs(const  
long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:366:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:569:  
error: previous declaration ?double std::__complex_abs(double  
__complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:378:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:577:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:387:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:588:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:396:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double std::__complex_arg(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:596:  
error: declaration of C function ?double std::__complex_arg(double  
__complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:593:  
error: previous declaration ?float std::__complex_arg(float  
__complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double std::__complex_arg(const long double  
__complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:599:  
error: declaration of C function ?long double std::__complex_arg(const  
long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:596:  
error: previous declaration ?double std::__complex_arg(double  
__complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:408:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:604:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:417:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:617:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:426:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:620:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:437:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:632:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:443:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:450:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:641:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:455:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:649:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:460:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:654:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:468:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:662:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:473:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:478:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:485:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_cos(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:674:  
error: declaration of C function ?double __complex__  
std::__complex_cos(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:671:  
error: previous declaration ?float __complex__  
std::__complex_cos(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_cos(const long double  
__complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:677:  
error: declaration of C function ?long double __complex__  
std::__complex_cos(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:674:  
error: previous declaration ?double __complex__  
std::__complex_cos(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:518:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:682:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:692:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:531:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:536:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:541:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_cosh(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:704:  
error: declaration of C function ?double __complex__  
std::__complex_cosh(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:701:  
error: previous declaration ?float __complex__  
std::__complex_cosh(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:546:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_cosh(const long  
double __complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:707:  
error: declaration of C function ?long double __complex__  
std::__complex_cosh(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:704:  
error: previous declaration ?double __complex__  
std::__complex_cosh(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:712:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:552:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:722:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double std::__complex_abs(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:569:  
error: declaration of C function ?double std::__complex_abs(double  
__complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:566:  
error: previous declaration ?float std::__complex_abs(float  
__complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_exp(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:730:  
error: declaration of C function ?double __complex__  
std::__complex_exp(double __complex__)? conflicts with/Developer/SDKs/ 
MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In function ?long  
double std::__complex_abs(const long double __complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:572:  
error: declaration of C function ?long double std::__complex_abs(const  
long double __complex__&)? conflicts with

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:727:  
error: previous declaration ?float __complex__  
std::__complex_exp(float __complex__)? here/Developer/SDKs/ 
MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:569: error: previous  
declaration ?double std::__complex_abs(double __complex__)? here

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_exp(const long double  
__complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:733:  
error: declaration of C function ?long double __complex__  
std::__complex_exp(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:577:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:730:  
error: previous declaration ?double __complex__  
std::__complex_exp(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:588:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:738:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:749:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double std::__complex_arg(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:596:  
error: declaration of C function ?double std::__complex_arg(double  
__complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:593:  
error: previous declaration ?float std::__complex_arg(float  
__complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:768:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double std::__complex_arg(const long double  
__complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:599:  
error: declaration of C function ?long double std::__complex_arg(const  
long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:772:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:596:  
error: previous declaration ?double std::__complex_arg(double  
__complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:604:  
error: template with C linkage/Developer/SDKs/MacOSX10.4u.sdk/usr/ 
include/c++/4.0.0/complex:778: error: template with C linkage

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:617:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:620:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:632:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:641:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_sin(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:790:  
error: declaration of C function ?double __complex__  
std::__complex_sin(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:649:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:787:  
error: previous declaration ?float __complex__  
std::__complex_sin(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:654:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_sin(const long double  
__complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:793:  
error: declaration of C function ?long double __complex__  
std::__complex_sin(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:790:  
error: previous declaration ?double __complex__  
std::__complex_sin(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:662:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:798:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:808:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_cos(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:674:  
error: declaration of C function ?double __complex__  
std::__complex_cos(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:671:  
error: previous declaration ?float __complex__  
std::__complex_cos(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_sinh(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:820:  
error: declaration of C function ?double __complex__  
std::__complex_sinh(double __complex__)? conflicts with/Developer/SDKs/ 
MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In function ?long  
double __complex__ std::__complex_cos(const long double __complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:677:  
error: declaration of C function ?long double __complex__  
std::__complex_cos(const long double __complex__&)? conflicts with

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:817:  
error: previous declaration ?float __complex__  
std::__complex_sinh(float __complex__)? here/Developer/SDKs/ 
MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:674: error: previous  
declaration ?double __complex__ std::__complex_cos(double  
__complex__)? here

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_sinh(const long  
double __complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:823:  
error: declaration of C function ?long double __complex__  
std::__complex_sinh(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:682:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:820:  
error: previous declaration ?double __complex__  
std::__complex_sinh(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:692:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:828:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:839:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_cosh(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:704:  
error: declaration of C function ?double __complex__  
std::__complex_cosh(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:701:  
error: previous declaration ?float __complex__  
std::__complex_cosh(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:707:  
error: declaration of C function ?long double __complex__  
std::__complex_cosh(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:704:  
error: previous declaration ?double __complex__  
std::__complex_cosh(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:712:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:722:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_sqrt(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:864:  
error: declaration of C function ?double __complex__  
std::__complex_sqrt(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:861:  
error: previous declaration ?float __complex__  
std::__complex_sqrt(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_exp(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:730:  
error: declaration of C function ?double __complex__  
std::__complex_exp(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:727:  
error: previous declaration ?float __complex__  
std::__complex_exp(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_sqrt(const long  
double __complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:867:  
error: declaration of C function ?long double __complex__  
std::__complex_sqrt(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:864:  
error: previous declaration ?double __complex__  
std::__complex_sqrt(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_exp(const long double  
__complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:733:  
error: declaration of C function ?long double __complex__  
std::__complex_exp(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:730:  
error: previous declaration ?double __complex__  
std::__complex_exp(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:872:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:738:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:883:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:749:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:768:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_tan(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:891:  
error: declaration of C function ?double __complex__  
std::__complex_tan(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:888:  
error: previous declaration ?float __complex__  
std::__complex_tan(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:772:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_tan(const long double  
__complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:894:  
error: declaration of C function ?long double __complex__  
std::__complex_tan(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:778:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:891:  
error: previous declaration ?double __complex__  
std::__complex_tan(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:899:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:911:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_sin(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:790:  
error: declaration of C function ?double __complex__  
std::__complex_sin(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:787:  
error: previous declaration ?float __complex__  
std::__complex_sin(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_sin(const long double  
__complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:793:  
error: declaration of C function ?long double __complex__  
std::__complex_sin(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_tanh(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:919:  
error: declaration of C function ?double __complex__  
std::__complex_tanh(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:790:  
error: previous declaration ?double __complex__  
std::__complex_sin(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:916:  
error: previous declaration ?float __complex__  
std::__complex_tanh(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:798:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_tanh(const long  
double __complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:922:  
error: declaration of C function ?long double __complex__  
std::__complex_tanh(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:919:  
error: previous declaration ?double __complex__  
std::__complex_tanh(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:808:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:927:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:940:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_sinh(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:820:  
error: declaration of C function ?double __complex__  
std::__complex_sinh(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:817:  
error: previous declaration ?float __complex__  
std::__complex_sinh(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:945:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_sinh(const long  
double __complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:823:  
error: declaration of C function ?long double __complex__  
std::__complex_sinh(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:820:  
error: previous declaration ?double __complex__  
std::__complex_sinh(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:960:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:828:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:839:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_pow(double __complex__,  
double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:969:  
error: declaration of C function ?double __complex__  
std::__complex_pow(double __complex__, double __complex__)? conflicts  
with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:965:  
error: previous declaration ?float __complex__  
std::__complex_pow(float __complex__, float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_pow(const long double  
__complex__&, const long double __complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:974:  
error: declaration of C function ?long double __complex__  
std::__complex_pow(const long double __complex__&, const long double  
__complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:969:  
error: previous declaration ?double __complex__  
std::__complex_pow(double __complex__, double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:979:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:990:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1027:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1029:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1031:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1033:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1035:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_sqrt(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:864:  
error: declaration of C function ?double __complex__  
std::__complex_sqrt(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:861:  
error: previous declaration ?float __complex__  
std::__complex_sqrt(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_sqrt(const long  
double __complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:867:  
error: declaration of C function ?long double __complex__  
std::__complex_sqrt(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:864:  
error: previous declaration ?double __complex__  
std::__complex_sqrt(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:872:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:883:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_tan(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:891:  
error: declaration of C function ?double __complex__  
std::__complex_tan(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:888:  
error: previous declaration ?float __complex__  
std::__complex_tan(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_tan(const long double  
__complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:894:  
error: declaration of C function ?long double __complex__  
std::__complex_tan(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:891:  
error: previous declaration ?double __complex__  
std::__complex_tan(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:899:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:911:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_tanh(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:919:  
error: declaration of C function ?double __complex__  
std::__complex_tanh(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:916:  
error: previous declaration ?float __complex__  
std::__complex_tanh(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_tanh(const long  
double __complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:922:  
error: declaration of C function ?long double __complex__  
std::__complex_tanh(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:919:  
error: previous declaration ?double __complex__  
std::__complex_tanh(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:927:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:940:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:945:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:960:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_pow(double __complex__,  
double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:969:  
error: declaration of C function ?double __complex__  
std::__complex_pow(double __complex__, double __complex__)? conflicts  
with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:965:  
error: previous declaration ?float __complex__  
std::__complex_pow(float __complex__, float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_pow(const long double  
__complex__&, const long double __complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:974:  
error: declaration of C function ?long double __complex__  
std::__complex_pow(const long double __complex__&, const long double  
__complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:969:  
error: previous declaration ?double __complex__  
std::__complex_pow(double __complex__, double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:979:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:990:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1180:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1182:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1184:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1027:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1186:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1029:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1188:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1031:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1033:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1035:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1333:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1335:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1337:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1339:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1341:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1180:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1182:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1184:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1186:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1188:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1333:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1335:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1337:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1339:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1341:  
error: template with C linkage
lipo: can't figure out the architecture type of: /var/folders/jz/ 
jzMQLnV-GOWCP55tPgPBl++++Tc/-Tmp-//cccQ8EWC.out
In file included from /Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/ 
4.0.0/backward/complex.h:31,
                  from /Library/Frameworks/Python.framework/Versions/ 
2.5/lib/python2.5/site-packages/numpy/core/include/numpy/npy_common.h: 
101,
                  from /Library/Frameworks/Python.framework/Versions/ 
2.5/lib/python2.5/site-packages/numpy/core/include/numpy/ 
ndarrayobject.h:68,
                  from /Library/Frameworks/Python.framework/Versions/ 
2.5/lib/python2.5/site-packages/numpy/core/include/numpy/arrayobject.h: 
14,
                  from scipy/interpolate/src/_interpolate.cpp:5:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/backward/ 
backward_warning.h:32:2: warning: #warning This file includes at least  
one deprecated or antiquateIn file included from /Developer/SDKs/ 
MacOSX10.4u.sdk/usr/include/c++/4.0.0/backward/complex.h:31d,
                  from /Library/Frameworks/Python.framework/Versions/ 
2.5/lib/python2.5/site-packages/numpy/core/include/numpy/npy_common.h: 
101 h,
                  from /Library/Frameworks/Python.framework/Versions/ 
2.5/lib/python2.5/site-packages/numpy/core/include/numpy/ 
ndarrayobject.h:68ea,
                  from /Library/Frameworks/Python.framework/Versions/ 
2.5/lib/python2.5/site-packages/numpy/core/include/numpy/arrayobject.h: 
14de,
                  from scipy/interpolate/src/_interpolate.cpp:5r:
./Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/backward/ 
backward_warning.h:32:2:  Pleawarning: #warning Thiss fiele c  
oinnscilduedre using one of s at lethe 32 headersast  onef oundepd in  
section 17.4.1.2 orecf the C++ stateandd or antiquatedard. Examples   
hinecadleurd.e Pleas seu bcsotnitsuitdienrg u stihne g< Xo> header for  
ne tofh et <hXe 32 headers. found in section 17.4.1.2h o>f  thhee aCd+e 
+r  sftoarn dCa+rd+.  iEnxcalmpuldeess ,i nocrl u<dei suobstituting  
thstree <X> aheadmer>  fori nsttheea d<X .ohf>  htehea ddeer pfroerca  
tCe+d+  ihnecaldeurd es, <or io<iosstreatrema.mh>. To disabl>e   
tihnsitse awdarn ionfg t huese  d-epWrneo-decaprecatedt.
ed header <iostream.h>. To disable this warning use -Wno-deprecated.
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:85: error:  
template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?float std::abs(float)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:92: error:  
declaration of C function ?float std::abs(float)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:88: error:  
previous declaration ?double std::abs(double)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::abs(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:96: error:  
declaration of C function ?long double std::abs(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:92: error:  
previous declaration ?float std::abs(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::acos(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:106:  
error: declaration of C function ?long double std::acos(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:102:  
error: previous declaration ?float std::acos(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:111:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::asin(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:123:  
error: declaration of C function ?long double std::asin(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:119:  
error: previous declaration ?float std::asin(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:128:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::atan(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:138:  
error: declaration of C function ?long double std::atan(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:134:  
error: previous declaration ?float std::atan(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:143:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::atan2(long double, long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:153:  
error: declaration of C function ?long double std::atan2(long double,  
long double)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:149:  
error: previous declaration ?float std::atan2(float, float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:159:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::ceil(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:169:  
error: declaration of C function ?long double std::ceil(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:165:  
error: previous declaration ?float std::ceil(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:174:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::cos(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:184:  
error: declaration of C function ?long double std::cos(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:180:  
error: previous declaration ?float std::cos(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:189:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:85: error:  
template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?float std::abs(float)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:92: error:  
declaration of C function ?float std::abs(float)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:88: error:  
previous declaration ?double std::abs(double)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::abs(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:96: error:  
declaration of C function ?long double std::abs(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:92: error:  
previous declaration ?float std::abs(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::acos(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:106:  
error: declaration of C function ?long double std::acos(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::cosh(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:199:  
error: declaration of C function ?long double std::cosh(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:195:  
error: previous declaration ?float std::cosh(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:102:  
error: previous declaration ?float std::acos(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:204:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:111:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::asin(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:123:  
error: declaration of C function ?long double std::asin(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:119:  
error: previous declaration ?float std::asin(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::exp(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:214:  
error: declaration of C function ?long double std::exp(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:210:  
error: previous declaration ?float std::exp(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:128:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:219:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::atan(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:138:  
error: declaration of C function ?long double std::atan(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:134:  
error: previous declaration ?float std::atan(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:143:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::fabs(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:229:  
error: declaration of C function ?long double std::fabs(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:225:  
error: previous declaration ?float std::fabs(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::atan2(long double, long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:153:  
error: declaration of C function ?long double std::atan2(long double,  
long double)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:149:  
error: previous declaration ?float std::atan2(float, float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:159:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:234:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::ceil(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:169:  
error: declaration of C function ?long double std::ceil(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:165:  
error: previous declaration ?float std::ceil(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:174:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::floor(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:244:  
error: declaration of C function ?long double std::floor(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:240:  
error: previous declaration ?float std::floor(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::cos(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:184:  
error: declaration of C function ?long double std::cos(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:180:  
error: previous declaration ?float std::cos(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:249:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:189:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::fmod(long double, long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:259:  
error: declaration of C function ?long double std::fmod(long double,  
long double)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::cosh(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:199:  
error: declaration of C function ?long double std::cosh(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:255:  
error: previous declaration ?float std::fmod(float, float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:195:  
error: previous declaration ?float std::cosh(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:204:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::frexp(long double, int*)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:269:  
error: declaration of C function ?long double std::frexp(long double,  
int*)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:265:  
error: previous declaration ?float std::frexp(float, int*)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::exp(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:214:  
error: declaration of C function ?long double std::exp(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:210:  
error: previous declaration ?float std::exp(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:274:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:219:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::ldexp(long double, int)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:284:  
error: declaration of C function ?long double std::ldexp(long double,  
int)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:280:  
error: previous declaration ?float std::ldexp(float, int)? here/ 
Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::fabs(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:229:  
error: declaration of C function ?long double std::fabs(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:225:  
error: previous declaration ?float std::fabs(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:234:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::floor(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:244:  
error: declaration of C function ?long double std::floor(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:240:  
error: previous declaration ?float std::floor(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:249:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::fmod(long double, long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:259:  
error: declaration of C function ?long double std::fmod(long double,  
long double)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:255:  
error: previous declaration ?float std::fmod(float, float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::frexp(long double, int*)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:269:  
error: declaration of C function ?long double std::frexp(long double,  
int*)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:265:  
error: previous declaration ?float std::frexp(float, int*)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:274:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::ldexp(long double, int)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:284:  
error: declaration of C function ?long double std::ldexp(long double,  
int)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:280:  
error: previous declaration ?float std::ldexp(float, int)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:289:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::log(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:299:  
error: declaration of C function ?long double std::log(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:295:  
error: previous declaration ?float std::log(float)? here

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:304:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::log10(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:314:  
error: declaration of C function ?long double std::log10(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:310:  
error: previous declaration ?float std::log10(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:319:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:289:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::modf(long double, long double*)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:329:  
error: declaration of C function ?long double std::modf(long double,  
long double*)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:325:  
error: previous declaration ?float std::modf(float, float*)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:334:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::pow(long double, long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:348:  
error: declaration of C function ?long double std::pow(long double,  
long double)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:344:  
error: previous declaration ?float std::pow(float, float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:352:  
error: declaration of C function ?double std::pow(double, int)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:348:  
error: previous declaration ?long double std::pow(long double, long  
double)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::log(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:299:  
error: declaration of C function ?long double std::log(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:295:  
error: previous declaration ?float std::log(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?float std::pow(float, int)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:356:  
error: declaration of C function ?float std::pow(float, int)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:352:  
error: previous declaration ?double std::pow(double, int)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::pow(long double, int)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:360:  
error: declaration of C function ?long double std::pow(long double,  
int)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:356:  
error: previous declaration ?float std::pow(float, int)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:304:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::sin(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:370:  
error: declaration of C function ?long double std::sin(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:366:  
error: previous declaration ?float std::sin(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:375:  
error: template with C linkage/Developer/SDKs/MacOSX10.4u.sdk/usr/ 
include/c++/4.0.0/cmath: In function ?long double std::log10(long  
double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:314:  
error: declaration of C function ?long double std::log10(long double)?  
conflicts with

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:310:  
error: previous declaration ?float std::log10(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:319:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::sinh(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:385:  
error: declaration of C function ?long double std::sinh(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:381:  
error: previous declaration ?float std::sinh(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:390:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::modf(long double, long double*)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:329:  
error: declaration of C function ?long double std::modf(long double,  
long double*)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:325:  
error: previous declaration ?float std::modf(float, float*)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::sqrt(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:400:  
error: declaration of C function ?long double std::sqrt(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:396:  
error: previous declaration ?float std::sqrt(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:334:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:405:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::pow(long double, long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:348:  
error: declaration of C function ?long double std::pow(long double,  
long double)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:344:  
error: previous declaration ?float std::pow(float, float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::tan(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:415:  
error: declaration of C function ?long double std::tan(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:411:  
error: previous declaration ?float std::tan(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?double std::pow(double, int)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:352:  
error: declaration of C function ?double std::pow(double, int)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:348:  
error: previous declaration ?long double std::pow(long double, long  
double)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:420:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::pow(long double, long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:356:  
error: declaration of C function ?float std::pow(float, int)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:352:  
error: previous declaration ?double std::pow(double, int)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::tanh(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:430:  
error: declaration of C function ?long double std::tanh(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:426:  
error: previous declaration ?float std::tanh(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::pow(long double, int)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:360:  
error: declaration of C function ?long double std::pow(long double,  
int)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:356:  
error: previous declaration ?float std::pow(float, int)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:435:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:448:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:452:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:456:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:460:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:464:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:468:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:472:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:477:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:482:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::sin(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:370:  
error: declaration of C function ?long double std::sin(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:366:  
error: previous declaration ?float std::sin(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:486:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:491:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:496:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:518:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:375:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:522:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:526:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:530:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::sinh(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:385:  
error: declaration of C function ?long double std::sinh(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:381:  
error: previous declaration ?float std::sinh(float)? here/Developer/ 
SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:534: error: template  
with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:538:  
error: template with C linkage

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:542:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:547:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:390:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:552:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:557:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:562:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::sqrt(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:400:  
error: declaration of C function ?long double std::sqrt(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:567:  
error: template with C linkage/Developer/SDKs/MacOSX10.4u.sdk/usr/ 
include/c++/4.0.0/cmath:396: error: previous declaration ?float  
std::sqrt(float)? here

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/bits/cmath.tcc: 
39: error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:405:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::tan(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:415:  
error: declaration of C function ?long double std::tan(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:411:  
error: previous declaration ?float std::tan(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:420:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: In  
function ?long double std::tanh(long double)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:430:  
error: declaration of C function ?long double std::tanh(long double)?  
conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:426:  
error: previous declaration ?float std::tanh(float)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath: At global  
scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:435:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:448:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:452:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:456:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:460:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:464:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:468:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:472:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:477:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:482:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:486:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:491:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:496:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:518:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:522:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:526:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:530:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:534:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:538:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:542:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:547:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:552:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:557:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:562:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/cmath:567:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/bits/cmath.tcc: 
39: error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:55:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:61:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:63:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:65:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:68:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:70:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:74:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:76:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:78:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:80:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:82:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:84:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:86:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:89:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:91:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:93:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:95:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:97:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:99:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:101:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:128:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:155:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:158:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:161:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:164:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:167:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:55:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:61:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:63:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:65:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:318:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:68:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:70:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:74:  
error: template with C linkage/Developer/SDKs/MacOSX10.4u.sdk/usr/ 
include/c++/4.0.0/complex:327: error: template with C linkage

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:76:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:336:  
error: template with C linkage/Developer/SDKs/MacOSX10.4u.sdk/usr/ 
include/c++/4.0.0/complex:78: error: template with C linkage

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:80:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:348:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:357:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:82:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:366:  
error: template with C linkage/Developer/SDKs/MacOSX10.4u.sdk/usr/ 
include/c++/4.0.0/complex:84: error: template with C linkage

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:86:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:378:  
error: template with C linkage/Developer/SDKs/MacOSX10.4u.sdk/usr/ 
include/c++/4.0.0/complex:89: error: template with C linkage

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:91:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:93:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:387:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:95:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:396:  
error: template with C linkage/Developer/SDKs/MacOSX10.4u.sdk/usr/ 
include/c++/4.0.0/complex:97: error: template with C linkage

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:99:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:101:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:408:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:417:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:128:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:426:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:437:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:443:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:155:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:158:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:161:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:164:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:450:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:167:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:455:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:460:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:468:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:473:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:478:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:485:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:518:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:531:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:536:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:541:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:546:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:318:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:552:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:327:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:336:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:348:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double std::__complex_abs(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:569:  
error: declaration of C function ?double std::__complex_abs(double  
__complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:566:  
error: previous declaration ?float std::__complex_abs(float  
__complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:357:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double std::__complex_abs(const long double  
__complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:572:  
error: declaration of C function ?long double std::__complex_abs(const  
long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:366:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:569:  
error: previous declaration ?double std::__complex_abs(double  
__complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:378:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:577:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:387:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:588:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:396:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double std::__complex_arg(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:596:  
error: declaration of C function ?double std::__complex_arg(double  
__complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:593:  
error: previous declaration ?float std::__complex_arg(float  
__complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double std::__complex_arg(const long double  
__complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:599:  
error: declaration of C function ?long double std::__complex_arg(const  
long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:596:  
error: previous declaration ?double std::__complex_arg(double  
__complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:408:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:604:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:417:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:617:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:426:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:620:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:437:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:632:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:443:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:450:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:641:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:455:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:649:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:460:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:654:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:468:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:662:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:473:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:478:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:485:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_cos(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:674:  
error: declaration of C function ?double __complex__  
std::__complex_cos(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:671:  
error: previous declaration ?float __complex__  
std::__complex_cos(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_cos(const long double  
__complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:677:  
error: declaration of C function ?long double __complex__  
std::__complex_cos(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:674:  
error: previous declaration ?double __complex__  
std::__complex_cos(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:518:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:682:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:692:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:531:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:536:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:541:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_cosh(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:704:  
error: declaration of C function ?double __complex__  
std::__complex_cosh(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:701:  
error: previous declaration ?float __complex__  
std::__complex_cosh(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:546:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_cosh(const long  
double __complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:707:  
error: declaration of C function ?long double __complex__  
std::__complex_cosh(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:704:  
error: previous declaration ?double __complex__  
std::__complex_cosh(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:712:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:552:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:722:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double std::__complex_abs(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:569:  
error: declaration of C function ?double std::__complex_abs(double  
__complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:566:  
error: previous declaration ?float std::__complex_abs(float  
__complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_exp(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:730:  
error: declaration of C function ?double __complex__  
std::__complex_exp(double __complex__)? conflicts with/Developer/SDKs/ 
MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In function ?long  
double std::__complex_abs(const long double __complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:572:  
error: declaration of C function ?long double std::__complex_abs(const  
long double __complex__&)? conflicts with

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:727:  
error: previous declaration ?float __complex__  
std::__complex_exp(float __complex__)? here/Developer/SDKs/ 
MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:569: error: previous  
declaration ?double std::__complex_abs(double __complex__)? here

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_exp(const long double  
__complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:733:  
error: declaration of C function ?long double __complex__  
std::__complex_exp(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:577:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:730:  
error: previous declaration ?double __complex__  
std::__complex_exp(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:588:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:738:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:749:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double std::__complex_arg(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:596:  
error: declaration of C function ?double std::__complex_arg(double  
__complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:593:  
error: previous declaration ?float std::__complex_arg(float  
__complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:768:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double std::__complex_arg(const long double  
__complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:599:  
error: declaration of C function ?long double std::__complex_arg(const  
long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:772:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:596:  
error: previous declaration ?double std::__complex_arg(double  
__complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:604:  
error: template with C linkage/Developer/SDKs/MacOSX10.4u.sdk/usr/ 
include/c++/4.0.0/complex:778: error: template with C linkage

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:617:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:620:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:632:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:641:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_sin(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:790:  
error: declaration of C function ?double __complex__  
std::__complex_sin(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:649:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:787:  
error: previous declaration ?float __complex__  
std::__complex_sin(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:654:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_sin(const long double  
__complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:793:  
error: declaration of C function ?long double __complex__  
std::__complex_sin(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:790:  
error: previous declaration ?double __complex__  
std::__complex_sin(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:662:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:798:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:808:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_cos(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:674:  
error: declaration of C function ?double __complex__  
std::__complex_cos(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:671:  
error: previous declaration ?float __complex__  
std::__complex_cos(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_sinh(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:820:  
error: declaration of C function ?double __complex__  
std::__complex_sinh(double __complex__)? conflicts with/Developer/SDKs/ 
MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In function ?long  
double __complex__ std::__complex_cos(const long double __complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:677:  
error: declaration of C function ?long double __complex__  
std::__complex_cos(const long double __complex__&)? conflicts with

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:817:  
error: previous declaration ?float __complex__  
std::__complex_sinh(float __complex__)? here/Developer/SDKs/ 
MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:674: error: previous  
declaration ?double __complex__ std::__complex_cos(double  
__complex__)? here

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_sinh(const long  
double __complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:823:  
error: declaration of C function ?long double __complex__  
std::__complex_sinh(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:682:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:820:  
error: previous declaration ?double __complex__  
std::__complex_sinh(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:692:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:828:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:839:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_cosh(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:704:  
error: declaration of C function ?double __complex__  
std::__complex_cosh(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:701:  
error: previous declaration ?float __complex__  
std::__complex_cosh(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:707:  
error: declaration of C function ?long double __complex__  
std::__complex_cosh(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:704:  
error: previous declaration ?double __complex__  
std::__complex_cosh(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:712:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:722:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_sqrt(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:864:  
error: declaration of C function ?double __complex__  
std::__complex_sqrt(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:861:  
error: previous declaration ?float __complex__  
std::__complex_sqrt(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_exp(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:730:  
error: declaration of C function ?double __complex__  
std::__complex_exp(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:727:  
error: previous declaration ?float __complex__  
std::__complex_exp(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_sqrt(const long  
double __complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:867:  
error: declaration of C function ?long double __complex__  
std::__complex_sqrt(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:864:  
error: previous declaration ?double __complex__  
std::__complex_sqrt(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_exp(const long double  
__complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:733:  
error: declaration of C function ?long double __complex__  
std::__complex_exp(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:730:  
error: previous declaration ?double __complex__  
std::__complex_exp(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:872:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:738:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:883:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:749:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:768:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_tan(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:891:  
error: declaration of C function ?double __complex__  
std::__complex_tan(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:888:  
error: previous declaration ?float __complex__  
std::__complex_tan(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:772:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_tan(const long double  
__complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:894:  
error: declaration of C function ?long double __complex__  
std::__complex_tan(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:778:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:891:  
error: previous declaration ?double __complex__  
std::__complex_tan(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:899:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:911:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_sin(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:790:  
error: declaration of C function ?double __complex__  
std::__complex_sin(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:787:  
error: previous declaration ?float __complex__  
std::__complex_sin(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_sin(const long double  
__complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:793:  
error: declaration of C function ?long double __complex__  
std::__complex_sin(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_tanh(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:919:  
error: declaration of C function ?double __complex__  
std::__complex_tanh(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:790:  
error: previous declaration ?double __complex__  
std::__complex_sin(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:916:  
error: previous declaration ?float __complex__  
std::__complex_tanh(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:798:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_tanh(const long  
double __complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:922:  
error: declaration of C function ?long double __complex__  
std::__complex_tanh(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:919:  
error: previous declaration ?double __complex__  
std::__complex_tanh(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:808:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:927:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:940:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_sinh(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:820:  
error: declaration of C function ?double __complex__  
std::__complex_sinh(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:817:  
error: previous declaration ?float __complex__  
std::__complex_sinh(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:945:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_sinh(const long  
double __complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:823:  
error: declaration of C function ?long double __complex__  
std::__complex_sinh(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:820:  
error: previous declaration ?double __complex__  
std::__complex_sinh(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:960:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:828:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:839:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_pow(double __complex__,  
double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:969:  
error: declaration of C function ?double __complex__  
std::__complex_pow(double __complex__, double __complex__)? conflicts  
with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:965:  
error: previous declaration ?float __complex__  
std::__complex_pow(float __complex__, float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_pow(const long double  
__complex__&, const long double __complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:974:  
error: declaration of C function ?long double __complex__  
std::__complex_pow(const long double __complex__&, const long double  
__complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:969:  
error: previous declaration ?double __complex__  
std::__complex_pow(double __complex__, double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:979:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:990:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1027:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1029:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1031:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1033:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1035:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_sqrt(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:864:  
error: declaration of C function ?double __complex__  
std::__complex_sqrt(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:861:  
error: previous declaration ?float __complex__  
std::__complex_sqrt(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_sqrt(const long  
double __complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:867:  
error: declaration of C function ?long double __complex__  
std::__complex_sqrt(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:864:  
error: previous declaration ?double __complex__  
std::__complex_sqrt(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:872:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:883:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_tan(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:891:  
error: declaration of C function ?double __complex__  
std::__complex_tan(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:888:  
error: previous declaration ?float __complex__  
std::__complex_tan(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_tan(const long double  
__complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:894:  
error: declaration of C function ?long double __complex__  
std::__complex_tan(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:891:  
error: previous declaration ?double __complex__  
std::__complex_tan(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:899:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:911:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_tanh(double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:919:  
error: declaration of C function ?double __complex__  
std::__complex_tanh(double __complex__)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:916:  
error: previous declaration ?float __complex__  
std::__complex_tanh(float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_tanh(const long  
double __complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:922:  
error: declaration of C function ?long double __complex__  
std::__complex_tanh(const long double __complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:919:  
error: previous declaration ?double __complex__  
std::__complex_tanh(double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:927:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:940:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:945:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:960:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?double __complex__ std::__complex_pow(double __complex__,  
double __complex__)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:969:  
error: declaration of C function ?double __complex__  
std::__complex_pow(double __complex__, double __complex__)? conflicts  
with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:965:  
error: previous declaration ?float __complex__  
std::__complex_pow(float __complex__, float __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: In  
function ?long double __complex__ std::__complex_pow(const long double  
__complex__&, const long double __complex__&)?:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:974:  
error: declaration of C function ?long double __complex__  
std::__complex_pow(const long double __complex__&, const long double  
__complex__&)? conflicts with
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:969:  
error: previous declaration ?double __complex__  
std::__complex_pow(double __complex__, double __complex__)? here
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex: At  
global scope:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:979:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:990:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1180:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1182:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1184:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1027:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1186:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1029:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1188:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1031:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1033:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1035:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1333:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1335:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1337:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1339:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1341:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1180:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1182:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1184:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1186:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1188:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1333:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1335:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1337:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1339:  
error: template with C linkage
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/c++/4.0.0/complex:1341:  
error: template with C linkage
lipo: can't figure out the architecture type of: /var/folders/jz/ 
jzMQLnV-GOWCP55tPgPBl++++Tc/-Tmp-//cccQ8EWC.out
error: Command "g++ -arch ppc -arch i386 -isysroot /Developer/SDKs/ 
MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp - 
mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Iscipy/ 
interpolate/src -I/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/numpy/core/include -I/Library/Frameworks/ 
Python.framework/Versions/2.5/include/python2.5 -c scipy/interpolate/ 
src/_interpolate.cpp -o build/temp.macosx-10.3-ppc-2.5/scipy/ 
interpolate/src/_interpolate.o" failed with exit status 1



From charlesr.harris at gmail.com  Fri Nov  6 16:53:20 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Fri, 6 Nov 2009 14:53:20 -0700
Subject: [SciPy-dev] Build failure on OS X 10.5.8, Python 2.5, gcc-4.0.1
In-Reply-To: <807642B9-90E9-47B8-97A8-2665F682D544@cs.toronto.edu>
References: <807642B9-90E9-47B8-97A8-2665F682D544@cs.toronto.edu>
Message-ID: <e06186140911061353w7c1999dwf3e3ef5d7d8e6501@mail.gmail.com>

On Fri, Nov 6, 2009 at 2:23 PM, David Warde-Farley <dwf at cs.toronto.edu>wrote:

> Not sure what's going on here, it looks like an issue with the new
> complex number stuff?
>
> Also, I see lots of warnings about "missing required architecture
> x86_64 in file". This is puzzling since I'm compiling against 32-bit
> Python...
>
> This is with r7694 of NumPy and r6083 of SciPy.
>
> David
>
>
>
This looks like a confusion between the c/c++ complex.h files. They aren't
the same. I'm beginning to think we need to back out the complex.h stuff
until we can figure out a way to hide it, or at least keep the c version
from getting confused with the c++ version.

<snip>

Chuck

PS, no need to include vast quantities of repeated errors.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091106/cd6ee30d/attachment.html>

From dwf at cs.toronto.edu  Fri Nov  6 18:41:29 2009
From: dwf at cs.toronto.edu (David Warde-Farley)
Date: Fri, 6 Nov 2009 18:41:29 -0500
Subject: [SciPy-dev] Build failure on OS X 10.5.8, Python 2.5, gcc-4.0.1
In-Reply-To: <e06186140911061353w7c1999dwf3e3ef5d7d8e6501@mail.gmail.com>
References: <807642B9-90E9-47B8-97A8-2665F682D544@cs.toronto.edu>
	<e06186140911061353w7c1999dwf3e3ef5d7d8e6501@mail.gmail.com>
Message-ID: <F453CAA1-E73E-4841-B96E-54956E9C62F5@cs.toronto.edu>

On 6-Nov-09, at 4:53 PM, Charles R Harris wrote:

> This looks like a confusion between the c/c++ complex.h files. They  
> aren't
> the same. I'm beginning to think we need to back out the complex.h  
> stuff
> until we can figure out a way to hide it, or at least keep the c  
> version
> from getting confused with the c++ version.

Sorry for the gratuitous errors, I should've deduplicated. Better too  
much than too little, though. :)

FWIW, when I switched to using gcc/g++/etc. 4.2, the problem goes  
away, however there's yet another problem related to recent NumPy  
mailing list traffic re: long double:

creating build/temp.macosx-10.3-ppc-2.5/scipy/optimize/Zeros
compile options: '-I/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/numpy/core/include -c'
gcc: scipy/optimize/Zeros/bisect.c
cc1: error: unrecognized command line option "-Wno-long-double"
cc1: error: unrecognized command line option "-Wno-long-double"
lipo: can't figure out the architecture type of: /var/folders/jz/ 
jzMQLnV-GOWCP55tPgPBl++++Tc/-Tmp-//ccWBbydS.out
...
error: Command "gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/ 
MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp - 
mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -I/Library/ 
Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/ 
numpy/core/include -c scipy/optimize/Zeros/bisect.c -o build/ 
temp.macosx-10.3-ppc-2.5/scipy/optimize/Zeros/bisect.o" failed with  
exit status 1

I will try removing -Wno-long-double from the appropriate places and  
muddle through the build (I should note that I'm on a PPC machine  
which may be one of the boundary cases where all of this long double  
confusion is coming from.)

David


From charlesr.harris at gmail.com  Fri Nov  6 19:10:12 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Fri, 6 Nov 2009 17:10:12 -0700
Subject: [SciPy-dev] Build failure on OS X 10.5.8, Python 2.5, gcc-4.0.1
In-Reply-To: <F453CAA1-E73E-4841-B96E-54956E9C62F5@cs.toronto.edu>
References: <807642B9-90E9-47B8-97A8-2665F682D544@cs.toronto.edu>
	<e06186140911061353w7c1999dwf3e3ef5d7d8e6501@mail.gmail.com>
	<F453CAA1-E73E-4841-B96E-54956E9C62F5@cs.toronto.edu>
Message-ID: <e06186140911061610t29da2a06n79891d4d78eb5ca2@mail.gmail.com>

On Fri, Nov 6, 2009 at 4:41 PM, David Warde-Farley <dwf at cs.toronto.edu>wrote:

> On 6-Nov-09, at 4:53 PM, Charles R Harris wrote:
>
> > This looks like a confusion between the c/c++ complex.h files. They
> > aren't
> > the same. I'm beginning to think we need to back out the complex.h
> > stuff
> > until we can figure out a way to hide it, or at least keep the c
> > version
> > from getting confused with the c++ version.
>
> Sorry for the gratuitous errors, I should've deduplicated. Better too
> much than too little, though. :)
>
> FWIW, when I switched to using gcc/g++/etc. 4.2, the problem goes
> away, however there's yet another problem related to recent NumPy
> mailing list traffic re: long double:
>
>
The include files may be differently set up between the two. I note the gnu
lists complex.h support as broken for all the 4.* versions currently out
there.


> creating build/temp.macosx-10.3-ppc-2.5/scipy/optimize/Zeros
> compile options: '-I/Library/Frameworks/Python.framework/Versions/2.5/
> lib/python2.5/site-packages/numpy/core/include -c'
> gcc: scipy/optimize/Zeros/bisect.c
> cc1: error: unrecognized command line option "-Wno-long-double"
> cc1: error: unrecognized command line option "-Wno-long-double"
> lipo: can't figure out the architecture type of: /var/folders/jz/
> jzMQLnV-GOWCP55tPgPBl++++Tc/-Tmp-//ccWBbydS.out
> ...
> error: Command "gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/
> MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -
> mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -I/Library/
> Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/
> numpy/core/include -c scipy/optimize/Zeros/bisect.c -o build/
> temp.macosx-10.3-ppc-2.5/scipy/optimize/Zeros/bisect.o" failed with
> exit status 1
>
> I will try removing -Wno-long-double from the appropriate places and
> muddle through the build (I should note that I'm on a PPC machine
> which may be one of the boundary cases where all of this long double
> confusion is coming from.)
>
>
I suspect David (C) can fix this one. PPC has it's own, non-ieee, version of
long doubles and so is a bit of an outlier. It's a good thing that you are
building on the PPC during this work just to uncover the problems ;)

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091106/cb64178c/attachment.html>

From jsseabold at gmail.com  Fri Nov  6 19:26:29 2009
From: jsseabold at gmail.com (Skipper Seabold)
Date: Fri, 6 Nov 2009 19:26:29 -0500
Subject: [SciPy-dev] Unexpected behavior getting fields from a structured
	array
Message-ID: <c048da1c0911061626g7a385e88jd79a73b044460934@mail.gmail.com>

All,

I just got bit by this and was curious if this is just a limitation of
structured arrays.

import numpy as np
dt = [('var1', 'f'),('var2','f'),('var3','f')]
a = np.array([(1,3.5,0),(1,2.5,1),(3,4,1)], dtype=dt)
a[['var2','var3','var1']].view('f').reshape(3,3)

Out[100]:
array([[ 1. ,  3.5,  0. ],
       [ 1. ,  2.5,  1. ],
       [ 3. ,  4. ,  1. ]], dtype=float32)


I expected this to give me the fields in the order I asked for them,
but I got the fields in the order they occur.  Based on recent
discussions I guess this makes sense, so this might just be something
to look out for?

Skipper


From david at ar.media.kyoto-u.ac.jp  Sat Nov  7 02:16:27 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Sat, 07 Nov 2009 16:16:27 +0900
Subject: [SciPy-dev] Build failure on OS X 10.5.8, Python 2.5, gcc-4.0.1
In-Reply-To: <e06186140911061610t29da2a06n79891d4d78eb5ca2@mail.gmail.com>
References: <807642B9-90E9-47B8-97A8-2665F682D544@cs.toronto.edu>	<e06186140911061353w7c1999dwf3e3ef5d7d8e6501@mail.gmail.com>	<F453CAA1-E73E-4841-B96E-54956E9C62F5@cs.toronto.edu>
	<e06186140911061610t29da2a06n79891d4d78eb5ca2@mail.gmail.com>
Message-ID: <4AF51ECB.3000009@ar.media.kyoto-u.ac.jp>

Charles R Harris wrote:
>
>
>     error: Command "gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/
>     MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double
>     -no-cpp-precomp -
>     mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -I/Library/
>     Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/
>     numpy/core/include -c scipy/optimize/Zeros/bisect.c -o build/
>     temp.macosx-10.3-ppc-2.5/scipy/optimize/Zeros/bisect.o" failed with
>     exit status 1
>
>     I will try removing -Wno-long-double from the appropriate places and
>     muddle through the build (I should note that I'm on a PPC machine
>     which may be one of the boundary cases where all of this long double
>     confusion is coming from.)
>
>
> I suspect David (C) can fix this one. PPC has it's own, non-ieee,
> version of long doubles and so is a bit of an outlier.

The work on long double has not touched build options. For all I can
remember, the -wno-long-double flag was there for quite some time. Maybe
a python distutils bug ? I have a ppc minimac at home, I may fire it up
to check this, but I don't think it is a regression by numpy,

David


From cournape at gmail.com  Sat Nov  7 03:52:57 2009
From: cournape at gmail.com (David Cournapeau)
Date: Sat, 7 Nov 2009 17:52:57 +0900
Subject: [SciPy-dev] Build failure on OS X 10.5.8, Python 2.5, gcc-4.0.1
In-Reply-To: <4AF51ECB.3000009@ar.media.kyoto-u.ac.jp>
References: <807642B9-90E9-47B8-97A8-2665F682D544@cs.toronto.edu>
	<e06186140911061353w7c1999dwf3e3ef5d7d8e6501@mail.gmail.com>
	<F453CAA1-E73E-4841-B96E-54956E9C62F5@cs.toronto.edu>
	<e06186140911061610t29da2a06n79891d4d78eb5ca2@mail.gmail.com>
	<4AF51ECB.3000009@ar.media.kyoto-u.ac.jp>
Message-ID: <5b8d13220911070052r21ddca41wfa5c0dfaeb6979a9@mail.gmail.com>

On Sat, Nov 7, 2009 at 4:16 PM, David Cournapeau
<david at ar.media.kyoto-u.ac.jp> wrote:

>
> The work on long double has not touched build options. For all I can
> remember, the -wno-long-double flag was there for quite some time. Maybe
> a python distutils bug ? I have a ppc minimac at home, I may fire it up
> to check this, but I don't think it is a regression by numpy,

After checking the python sources, -Wno-long-double has been removed
starting python 2.6. The comment in configure.in for 2.6 is that only
apple-built gcc support -Wno-long-double. But since you use -arch, you
use Apple gcc, so I don't think the comment is entirely accurate.

This is a bit strange, you've never seen the problem before ?

David


From mellerf at netvision.net.il  Sat Nov  7 08:52:05 2009
From: mellerf at netvision.net.il (Yosef Meller)
Date: Sat, 07 Nov 2009 15:52:05 +0200
Subject: [SciPy-dev] Lambert W implementation
In-Reply-To: <hcebjn$aps$1@ger.gmane.org>
References: <4AE9CB10.2090503@netvision.net.il>
	<c048da1c0910291154i1c300a9fndb5feb8086dab9db@mail.gmail.com>
	<hcd1h5$2na$1@ger.gmane.org> <4AEAA9D0.9050106@netvision.net.il>
	<hcebjn$aps$1@ger.gmane.org>
Message-ID: <4AF57B85.9090007@netvision.net.il>

????? Pauli Virtanen:
> It's faster to make it a Ufunc -- np.vectorize will likely sacrifice 
> much of the speed gained from using Cython since it's going to box and unbox
> numbers in Python floats. There's an example how to do Ufuncs in
> Cython here:
> 
> 	http://projects.scipy.org/scipy/browser/trunk/scipy/special/orthogonal_eval.pyx

Thanks for the example, it really helped.

> If you get it done, please post the result (preferably, create
> a ticket on http://projects.scipy.org/scipy/ and attach the file) and
> we'll integrate it in scipy.special. If you also write tests, that'd
> be great!

Here it is, with the tests:
http://projects.scipy.org/scipy/ticket/1049

The doc-string is not exactly in the doc format of SciPy, but I don't 
have time to work on it right now.

> Note that newer Cythons also have support for native complex numbers, so
> you can do
> 
> 	cdef double complex a = ...
> 
> The same algorithm probably works both for real and complex parameters.

Thanks. Took some hunting around to get all the complex machinery to 
work, but it's finally done.

Yours,
Yosef.


From matthew.brett at gmail.com  Sun Nov  8 04:05:41 2009
From: matthew.brett at gmail.com (Matthew Brett)
Date: Sun, 8 Nov 2009 01:05:41 -0800
Subject: [SciPy-dev] Cython and large generated .c files
Message-ID: <1e2af89e0911080105k1ca54c2epc2000e6d8e9a107e@mail.gmail.com>

I'm speeding up the Matlab file IO routines by using Cython.
Generally this has been a pleasant experience, but the size of the
generated .c files is beginning to worry me.

As y'all know, the accepted approach is to commit both the Cython .pyx
files, and the Cython-generated .c files.

My problem is that the .c files are getting big - a 22K .pyx file
generating 516K of .c file.

If I do a few changes in the .pyx file, and commit the .pyx and the .c
file, that's going to add up to lot of space in the SVN repository.

An obvious way round this is to let distutils run Cython for developer
builds, and only generate the .c for releases, or some such, but I can
see that could get messy.   But, the space the .c file takes up is
making me think twice about commits.

Have y'all got any thoughts how to deal with this problem?

Thanks a lot,

Matthew


From pav at iki.fi  Sun Nov  8 09:20:01 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Sun, 08 Nov 2009 16:20:01 +0200
Subject: [SciPy-dev] Cython and large generated .c files
In-Reply-To: <1e2af89e0911080105k1ca54c2epc2000e6d8e9a107e@mail.gmail.com>
References: <1e2af89e0911080105k1ca54c2epc2000e6d8e9a107e@mail.gmail.com>
Message-ID: <1257690000.8180.19.camel@idol>

su, 2009-11-08 kello 01:05 -0800, Matthew Brett kirjoitti: 
[clip: huge Cython-generated .c files]
> An obvious way round this is to let distutils run Cython for developer
> builds, and only generate the .c for releases, or some such, but I can
> see that could get messy.   But, the space the .c file takes up is
> making me think twice about commits.
>
> Have y'all got any thoughts how to deal with this problem?

I think Cython has some pre-made distutils hooks to make this less
painless. I don't know how nicely they work with numpy.distutils,
however...

A bigger issue than build setup may be that then we'd require users to
have the latest Cython installed to build Scipy. (Perhaps the
generated .c files could be shipped with the distributed tarballs,
though, so only people interested in SVN would need Cython.)
Actually, this might not be so much to ask, given that Cython is a
pure-Python package.

So, should we make Scipy depend on Cython at build-time?

I agree that things may get annoying if we decide to avoid this in the
long run, if the number of Cython-based extensions starts to grow.

-- 
Pauli Virtanen





From david at ar.media.kyoto-u.ac.jp  Sun Nov  8 09:01:47 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Sun, 08 Nov 2009 23:01:47 +0900
Subject: [SciPy-dev] Cython and large generated .c files
In-Reply-To: <1257690000.8180.19.camel@idol>
References: <1e2af89e0911080105k1ca54c2epc2000e6d8e9a107e@mail.gmail.com>
	<1257690000.8180.19.camel@idol>
Message-ID: <4AF6CF4B.2020408@ar.media.kyoto-u.ac.jp>

Pauli Virtanen wrote:
>
> I think Cython has some pre-made distutils hooks to make this less
> painless. I don't know how nicely they work with numpy.distutils,
> however...
>   

Should not be too hard to support it.

> I agree that things may get annoying if we decide to avoid this in the
> long run, if the number of Cython-based extensions starts to grow.
>   

Is size really a problem ? I am a bit worried about adding cython as a
build requirement. We have already enough problems as it is, adding a
requirement can only make things worse.

David



From david at ar.media.kyoto-u.ac.jp  Sun Nov  8 09:04:12 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Sun, 08 Nov 2009 23:04:12 +0900
Subject: [SciPy-dev] Cython and large generated .c files
In-Reply-To: <4AF6CF4B.2020408@ar.media.kyoto-u.ac.jp>
References: <1e2af89e0911080105k1ca54c2epc2000e6d8e9a107e@mail.gmail.com>	<1257690000.8180.19.camel@idol>
	<4AF6CF4B.2020408@ar.media.kyoto-u.ac.jp>
Message-ID: <4AF6CFDC.2080803@ar.media.kyoto-u.ac.jp>

David Cournapeau wrote:
> Is size really a problem ? I am a bit worried about adding cython as a
> build requirement. We have already enough problems as it is, adding a
> requirement can only make things worse.

I meant "enough *build* problems" in the above sentence.

David


From mattknox.ca at gmail.com  Sun Nov  8 11:43:34 2009
From: mattknox.ca at gmail.com (Matt Knox)
Date: Sun, 8 Nov 2009 16:43:34 +0000 (UTC)
Subject: [SciPy-dev] trac account
Message-ID: <loom.20091108T173638-778@post.gmane.org>

I tried to use the new trac server for the first time today but it looks like
my account never got moved over from the old one to the new one. My user name
on the old server (scipy.org/scipy/scikits/) is mattknox_ca . Could somebody
please set me up on the new server (/projects.scipy.org/scikits/) ? I am one of
the developers on the scikits.timeseries project so I need the ability to
open / modify tickets for the timeseries component.

Thanks!

- Matt




From tgrav at mac.com  Sun Nov  8 12:07:47 2009
From: tgrav at mac.com (Tommy Grav)
Date: Sun, 08 Nov 2009 12:07:47 -0500
Subject: [SciPy-dev] Build failure on OS X 10.5.8, Python 2.5, gcc-4.0.1
In-Reply-To: <5b8d13220911070052r21ddca41wfa5c0dfaeb6979a9@mail.gmail.com>
References: <807642B9-90E9-47B8-97A8-2665F682D544@cs.toronto.edu>
	<e06186140911061353w7c1999dwf3e3ef5d7d8e6501@mail.gmail.com>
	<F453CAA1-E73E-4841-B96E-54956E9C62F5@cs.toronto.edu>
	<e06186140911061610t29da2a06n79891d4d78eb5ca2@mail.gmail.com>
	<4AF51ECB.3000009@ar.media.kyoto-u.ac.jp>
	<5b8d13220911070052r21ddca41wfa5c0dfaeb6979a9@mail.gmail.com>
Message-ID: <34021DC6-3074-4D8D-8AD2-FC67D69D7369@mac.com>


On Nov 7, 2009, at 3:52 AM, David Cournapeau wrote:

> On Sat, Nov 7, 2009 at 4:16 PM, David Cournapeau
> <david at ar.media.kyoto-u.ac.jp> wrote:
>
>>
>> The work on long double has not touched build options. For all I can
>> remember, the -wno-long-double flag was there for quite some time.  
>> Maybe
>> a python distutils bug ? I have a ppc minimac at home, I may fire  
>> it up
>> to check this, but I don't think it is a regression by numpy,
>
> After checking the python sources, -Wno-long-double has been removed
> starting python 2.6. The comment in configure.in for 2.6 is that only
> apple-built gcc support -Wno-long-double. But since you use -arch, you
> use Apple gcc, so I don't think the comment is entirely accurate.
>
> This is a bit strange, you've never seen the problem before ?

I think -Wno-long-double was removed in apples gcc 4.2. It is not  
described
in the documentation
  http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/gcc-4.2.1.html

Cheers
   Tommy


From mattknox.ca at gmail.com  Sun Nov  8 12:29:37 2009
From: mattknox.ca at gmail.com (Matt Knox)
Date: Sun, 8 Nov 2009 17:29:37 +0000 (UTC)
Subject: [SciPy-dev] trac account
References: <loom.20091108T173638-778@post.gmane.org>
Message-ID: <loom.20091108T182724-943@post.gmane.org>

> I tried to use the new trac server for the first time today but it looks like
> my account never got moved over from the old one to the new one. My user name
> on the old server (scipy.org/scipy/scikits/) is mattknox_ca .

Sorry, was entering the wrong password. *Bows head in shame*. Apologies for the 
noise.

- Matt



From dagss at student.matnat.uio.no  Sun Nov  8 14:57:11 2009
From: dagss at student.matnat.uio.no (Dag Sverre Seljebotn)
Date: Sun, 8 Nov 2009 20:57:11 +0100
Subject: [SciPy-dev] Cython and large generated .c files
In-Reply-To: <4AF6CF4B.2020408@ar.media.kyoto-u.ac.jp>
References: <1e2af89e0911080105k1ca54c2epc2000e6d8e9a107e@mail.gmail.com>
	<1257690000.8180.19.camel@idol>
	<4AF6CF4B.2020408@ar.media.kyoto-u.ac.jp>
Message-ID: <29dd85aca7a0d1399a42b979be001523.squirrel@webmail.uio.no>

David Cournapeau wrote:
> Pauli Virtanen wrote:
>>
>> I think Cython has some pre-made distutils hooks to make this less
>> painless. I don't know how nicely they work with numpy.distutils,
>> however...
>>
>
> Should not be too hard to support it.
>
>> I agree that things may get annoying if we decide to avoid this in the
>> long run, if the number of Cython-based extensions starts to grow.
>>
>
> Is size really a problem ? I am a bit worried about adding cython as a
> build requirement. We have already enough problems as it is, adding a
> requirement can only make things worse.

What mpi4py does is have a simple script "cythonize" which runs Cython on
all pyx files in the tree. Then:

 - Generated C files are NOT checked into version control
 - Generated C files ARE shipped with tarball source downloads (i.e.
cythonize is run on Lisandro's computer after exporting from revision
control). So endusers building from source do not need Cython.

Obviously setup.py etc. can be tailored to run cythonize if the C files
are older than the pyx files etc. I think this sounds like the solutions
with least drawbacks.

Dag Sverre



From matthew.brett at gmail.com  Sun Nov  8 15:32:44 2009
From: matthew.brett at gmail.com (Matthew Brett)
Date: Sun, 8 Nov 2009 12:32:44 -0800
Subject: [SciPy-dev] Cython and large generated .c files
In-Reply-To: <29dd85aca7a0d1399a42b979be001523.squirrel@webmail.uio.no>
References: <1e2af89e0911080105k1ca54c2epc2000e6d8e9a107e@mail.gmail.com>
	<1257690000.8180.19.camel@idol>
	<4AF6CF4B.2020408@ar.media.kyoto-u.ac.jp>
	<29dd85aca7a0d1399a42b979be001523.squirrel@webmail.uio.no>
Message-ID: <1e2af89e0911081232l10890376k15787bdb6c2ed871@mail.gmail.com>

Hi,

> What mpi4py does is have a simple script "cythonize" which runs Cython on
> all pyx files in the tree. Then:
>
> ?- Generated C files are NOT checked into version control
> ?- Generated C files ARE shipped with tarball source downloads (i.e.
> cythonize is run on Lisandro's computer after exporting from revision
> control). So endusers building from source do not need Cython.
>
> Obviously setup.py etc. can be tailored to run cythonize if the C files
> are older than the pyx files etc. I think this sounds like the solutions
> with least drawbacks.

Something like that sounds as though it could work very well.  I guess
it does mean that, if you have an old version of cython on your
system, the pyx code might not compile properly to c?  If so, will
that overwrite the c source in the release, making the result
impossible to build?  Or do you somehow disable 'cythonize' for
building from source code releases?

I think that size does matter, as they say, because, if we add a
moderate number of .pyx files to scipy, we can easily end up adding
megabytes of diff _per_commit_.   In the meantime the repository will
start growing rapidly.  If we ever go to distributed version control,
we'll get all of that with a 'git clone' or similar.

Best,

Matthew


From stefan at sun.ac.za  Sun Nov  8 16:56:22 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 8 Nov 2009 23:56:22 +0200
Subject: [SciPy-dev] Cython and large generated .c files
In-Reply-To: <1e2af89e0911081232l10890376k15787bdb6c2ed871@mail.gmail.com>
References: <1e2af89e0911080105k1ca54c2epc2000e6d8e9a107e@mail.gmail.com> 
	<1257690000.8180.19.camel@idol>
	<4AF6CF4B.2020408@ar.media.kyoto-u.ac.jp> 
	<29dd85aca7a0d1399a42b979be001523.squirrel@webmail.uio.no> 
	<1e2af89e0911081232l10890376k15787bdb6c2ed871@mail.gmail.com>
Message-ID: <9457e7c80911081356o575bfe80yc489385f0ce33904@mail.gmail.com>

2009/11/8 Matthew Brett <matthew.brett at gmail.com>:
> Something like that sounds as though it could work very well. ?I guess
> it does mean that, if you have an old version of cython on your
> system, the pyx code might not compile properly to c? ?If so, will
> that overwrite the c source in the release, making the result
> impossible to build? ?Or do you somehow disable 'cythonize' for
> building from source code releases?

In scikits.image we take md5sums of the generated and the distributed
.c files (skipping the time-stamp headers).  If those don't match, the
generated version is used:

http://github.com/stefanv/scikits.image/blob/master/scikits/image/_build.py#L43

Cheers
St?fan


From jsseabold at gmail.com  Sun Nov  8 18:26:11 2009
From: jsseabold at gmail.com (Skipper Seabold)
Date: Sun, 8 Nov 2009 18:26:11 -0500
Subject: [SciPy-dev] np.savetxt: apply patch in enhancement ticket 1079 to
	add headers?
Message-ID: <c048da1c0911081526t906a3ebke1448544cce8366@mail.gmail.com>

Hi all,

I am assuming that this is ok to request via the list...  Could we
discuss or could someone apply the patch in enhancement ticket 1079?

http://projects.scipy.org/numpy/ticket/1079

I needed this functionality recently, and this is a quick and easy fix
that may have been overlooked.

There is also another enhancement request about this here:
http://projects.scipy.org/numpy/ticket/1236

The only thing that I can think of that might need to be added is a
test to see that the header length is the same as the number of
columns, but really that might just be up to the user to supply the
right headers.  It might also be nice to have a header = True, that
uses the field names for a structured array, but I can live without
that.

Cheers,

Skipper


From aarchiba at physics.mcgill.ca  Sun Nov  8 18:42:56 2009
From: aarchiba at physics.mcgill.ca (Anne Archibald)
Date: Sun, 8 Nov 2009 18:42:56 -0500
Subject: [SciPy-dev] f2py and ATLAS crashing bug
Message-ID: <ce557a360911081542k2d3b9464m680406135fa6f87@mail.gmail.com>

Hi,

I am still trying to fix the bug where non-aligned matrices can cause
ATLAS to segfault, and I think I need to improve my understanding of
f2py somewhat.

First of all, I'll note that the bug appears in several routines (eig,
svd, qr, rq, hessenberg, and schur that I have found so far) but only
when the overwrite_a flag is passed in. So I tried to determine how
overwrite_a is used in these routines, and I am puzzled. The python
routines appear to pass it unmodified to the FORTRAN routines. The
.pyf files mention it in the python call signatures, but nowhere else;
from the f2py files it looks like it should be ignored. But clearly it
has some effect, since it allows crashes.

Second, if I copy the input arrays in python, the copies are aligned
and the problem goes away. So I was hoping that enforcing a copy in
f2py if the arrays were misaligned would solve the problem. But (for
example) in svd, the relevant array already has intent(copy), so it's
not clear how the bug is being triggered. (And adding align8 does not
cure it.) The array also has intent(in) but not intent(out), so f2py
may not be expecting the underlying gesdd to modify the array (which
it is presumably doing if overwrite_a has an effect).

There is still the draconian solution of raising an exception when
operating on misaligned arrays, but I'd like to find a better solution
for this problem.

Anne


From charlesr.harris at gmail.com  Sun Nov  8 20:14:56 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Sun, 8 Nov 2009 18:14:56 -0700
Subject: [SciPy-dev] f2py and ATLAS crashing bug
In-Reply-To: <ce557a360911081542k2d3b9464m680406135fa6f87@mail.gmail.com>
References: <ce557a360911081542k2d3b9464m680406135fa6f87@mail.gmail.com>
Message-ID: <e06186140911081714v6e46d40bo4ed18f6d5b9b3428@mail.gmail.com>

On Sun, Nov 8, 2009 at 4:42 PM, Anne Archibald
<aarchiba at physics.mcgill.ca>wrote:

> Hi,
>
> I am still trying to fix the bug where non-aligned matrices can cause
> ATLAS to segfault, and I think I need to improve my understanding of
> f2py somewhat.
>
> First of all, I'll note that the bug appears in several routines (eig,
> svd, qr, rq, hessenberg, and schur that I have found so far) but only
> when the overwrite_a flag is passed in. So I tried to determine how
> overwrite_a is used in these routines, and I am puzzled. The python
> routines appear to pass it unmodified to the FORTRAN routines. The
> .pyf files mention it in the python call signatures, but nowhere else;
> from the f2py files it looks like it should be ignored. But clearly it
> has some effect, since it allows crashes.
>
>
I'm going to guess there is a conflict between the overwrite flag and the
copy flag. Might be considered a bug, but I'm not sure how those two should
interact anyway. The quick fix would seem to be to not use overwrite, which
might have the same effect you are shooting for with the copy flag. Pearu
probably needs to take a look at the flag interaction and maybe we can maybe
fix things differently at some point. Does everything work if you just don't
set the overwrite flag?

<snip>

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091108/382dbf16/attachment.html>

From charlesr.harris at gmail.com  Sun Nov  8 20:26:24 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Sun, 8 Nov 2009 18:26:24 -0700
Subject: [SciPy-dev] f2py and ATLAS crashing bug
In-Reply-To: <e06186140911081714v6e46d40bo4ed18f6d5b9b3428@mail.gmail.com>
References: <ce557a360911081542k2d3b9464m680406135fa6f87@mail.gmail.com>
	<e06186140911081714v6e46d40bo4ed18f6d5b9b3428@mail.gmail.com>
Message-ID: <e06186140911081726i64e7b16en9bf8cdb7520508bb@mail.gmail.com>

On Sun, Nov 8, 2009 at 6:14 PM, Charles R Harris
<charlesr.harris at gmail.com>wrote:

>
>
> On Sun, Nov 8, 2009 at 4:42 PM, Anne Archibald <aarchiba at physics.mcgill.ca
> > wrote:
>
>> Hi,
>>
>> I am still trying to fix the bug where non-aligned matrices can cause
>> ATLAS to segfault, and I think I need to improve my understanding of
>> f2py somewhat.
>>
>> First of all, I'll note that the bug appears in several routines (eig,
>> svd, qr, rq, hessenberg, and schur that I have found so far) but only
>> when the overwrite_a flag is passed in. So I tried to determine how
>> overwrite_a is used in these routines, and I am puzzled. The python
>> routines appear to pass it unmodified to the FORTRAN routines. The
>> .pyf files mention it in the python call signatures, but nowhere else;
>> from the f2py files it looks like it should be ignored. But clearly it
>> has some effect, since it allows crashes.
>>
>>
> I'm going to guess there is a conflict between the overwrite flag and the
> copy flag. Might be considered a bug, but I'm not sure how those two should
> interact anyway. The quick fix would seem to be to not use overwrite, which
> might have the same effect you are shooting for with the copy flag. Pearu
> probably needs to take a look at the flag interaction and maybe we can maybe
> fix things differently at some point. Does everything work if you just don't
> set the overwrite flag?
>
> <snip>
>
>
A question, are these problems specific to the pentium machine, and if so,
where did the ATLAS come from. I had some problem with segfaults on a
pentium back when and had to build my own ATLAS to get around them.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091108/a51bd361/attachment.html>

From peridot.faceted at gmail.com  Sun Nov  8 20:46:41 2009
From: peridot.faceted at gmail.com (Anne Archibald)
Date: Sun, 8 Nov 2009 20:46:41 -0500
Subject: [SciPy-dev] f2py and ATLAS crashing bug
In-Reply-To: <e06186140911081714v6e46d40bo4ed18f6d5b9b3428@mail.gmail.com>
References: <ce557a360911081542k2d3b9464m680406135fa6f87@mail.gmail.com>
	<e06186140911081714v6e46d40bo4ed18f6d5b9b3428@mail.gmail.com>
Message-ID: <ce557a360911081746j474386f4r90d15b67bf3171c4@mail.gmail.com>

2009/11/8 Charles R Harris <charlesr.harris at gmail.com>:
>
> On Sun, Nov 8, 2009 at 4:42 PM, Anne Archibald <aarchiba at physics.mcgill.ca>
> wrote:
>>
>> Hi,
>>
>> I am still trying to fix the bug where non-aligned matrices can cause
>> ATLAS to segfault, and I think I need to improve my understanding of
>> f2py somewhat.
>>
>> First of all, I'll note that the bug appears in several routines (eig,
>> svd, qr, rq, hessenberg, and schur that I have found so far) but only
>> when the overwrite_a flag is passed in. So I tried to determine how
>> overwrite_a is used in these routines, and I am puzzled. The python
>> routines appear to pass it unmodified to the FORTRAN routines. The
>> .pyf files mention it in the python call signatures, but nowhere else;
>> from the f2py files it looks like it should be ignored. But clearly it
>> has some effect, since it allows crashes.
>>
>
> I'm going to guess there is a conflict between the overwrite flag and the
> copy flag. Might be considered a bug, but I'm not sure how those two should
> interact anyway. The quick fix would seem to be to not use overwrite, which
> might have the same effect you are shooting for with the copy flag. Pearu
> probably needs to take a look at the flag interaction and maybe we can maybe
> fix things differently at some point. Does everything work if you just don't
> set the overwrite flag?

The two flags are at very different levels: the copy flag is set in
the f2py spec file, as a property of the underlying C/Fortran routine,
while overwrite_a is a python-level parameter that can (unfortunately)
be set by the user.

In principle, overwrite_a is specified by the user to say that they
don't mind if the routine uses the input matrix as scratch space. In
an ideal world, this would automatically get set when the python
wrappers need to copy the matrix, since the user doesn't even have
access to the matrix that actually gets passed in to the underlying
routine.

I have to say I don't understand the f2py flags well enough to know
whether the fact that the underlying routine modifies the input matrix
means that the f2py spec file should contain intent(out).

Anne


From charlesr.harris at gmail.com  Sun Nov  8 21:24:32 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Sun, 8 Nov 2009 19:24:32 -0700
Subject: [SciPy-dev] f2py and ATLAS crashing bug
In-Reply-To: <ce557a360911081746j474386f4r90d15b67bf3171c4@mail.gmail.com>
References: <ce557a360911081542k2d3b9464m680406135fa6f87@mail.gmail.com>
	<e06186140911081714v6e46d40bo4ed18f6d5b9b3428@mail.gmail.com>
	<ce557a360911081746j474386f4r90d15b67bf3171c4@mail.gmail.com>
Message-ID: <e06186140911081824v4046b59elf5b9a4a0d85fb1c3@mail.gmail.com>

On Sun, Nov 8, 2009 at 6:46 PM, Anne Archibald <peridot.faceted at gmail.com>wrote:

> 2009/11/8 Charles R Harris <charlesr.harris at gmail.com>:
> >
> > On Sun, Nov 8, 2009 at 4:42 PM, Anne Archibald <
> aarchiba at physics.mcgill.ca>
> > wrote:
> >>
> >> Hi,
> >>
> >> I am still trying to fix the bug where non-aligned matrices can cause
> >> ATLAS to segfault, and I think I need to improve my understanding of
> >> f2py somewhat.
> >>
> >> First of all, I'll note that the bug appears in several routines (eig,
> >> svd, qr, rq, hessenberg, and schur that I have found so far) but only
> >> when the overwrite_a flag is passed in. So I tried to determine how
> >> overwrite_a is used in these routines, and I am puzzled. The python
> >> routines appear to pass it unmodified to the FORTRAN routines. The
> >> .pyf files mention it in the python call signatures, but nowhere else;
> >> from the f2py files it looks like it should be ignored. But clearly it
> >> has some effect, since it allows crashes.
> >>
> >
> > I'm going to guess there is a conflict between the overwrite flag and the
> > copy flag. Might be considered a bug, but I'm not sure how those two
> should
> > interact anyway. The quick fix would seem to be to not use overwrite,
> which
> > might have the same effect you are shooting for with the copy flag. Pearu
> > probably needs to take a look at the flag interaction and maybe we can
> maybe
> > fix things differently at some point. Does everything work if you just
> don't
> > set the overwrite flag?
>
> The two flags are at very different levels: the copy flag is set in
> the f2py spec file, as a property of the underlying C/Fortran routine,
> while overwrite_a is a python-level parameter that can (unfortunately)
> be set by the user.
>
> In principle, overwrite_a is specified by the user to say that they
> don't mind if the routine uses the input matrix as scratch space. In
> an ideal world, this would automatically get set when the python
> wrappers need to copy the matrix, since the user doesn't even have
> access to the matrix that actually gets passed in to the underlying
> routine.
>
> I have to say I don't understand the f2py flags well enough to know
> whether the fact that the underlying routine modifies the input matrix
> means that the f2py spec file should contain intent(out).
>

I think the intent(out) only means that the array will be returned to the
user. I would also expect that the overwrite isn't so much providing scratch
space as saying that the routine can do it's work inplace, so in that
situation the array should probably be marked for both input and output. But
I think Pearu need to be consulted here because things don't seem to be
working right.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091108/0177b406/attachment.html>

From david at ar.media.kyoto-u.ac.jp  Mon Nov  9 00:38:44 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Mon, 09 Nov 2009 14:38:44 +0900
Subject: [SciPy-dev] Cython and large generated .c files
In-Reply-To: <29dd85aca7a0d1399a42b979be001523.squirrel@webmail.uio.no>
References: <1e2af89e0911080105k1ca54c2epc2000e6d8e9a107e@mail.gmail.com>	<1257690000.8180.19.camel@idol>	<4AF6CF4B.2020408@ar.media.kyoto-u.ac.jp>
	<29dd85aca7a0d1399a42b979be001523.squirrel@webmail.uio.no>
Message-ID: <4AF7AAE4.7060203@ar.media.kyoto-u.ac.jp>

Dag Sverre Seljebotn wrote:
> What mpi4py does is have a simple script "cythonize" which runs Cython on
> all pyx files in the tree. Then:
>
>  - Generated C files are NOT checked into version control
>  - Generated C files ARE shipped with tarball source downloads (i.e.
> cythonize is run on Lisandro's computer after exporting from revision
> control). So endusers building from source do not need Cython.

I expect quite a few users to build sources from svn, and I am worried
that many distributions do not package a recent enough version of cython.

David


From david at ar.media.kyoto-u.ac.jp  Mon Nov  9 00:51:13 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Mon, 09 Nov 2009 14:51:13 +0900
Subject: [SciPy-dev] Cython and large generated .c files
In-Reply-To: <1e2af89e0911081232l10890376k15787bdb6c2ed871@mail.gmail.com>
References: <1e2af89e0911080105k1ca54c2epc2000e6d8e9a107e@mail.gmail.com>	<1257690000.8180.19.camel@idol>	<4AF6CF4B.2020408@ar.media.kyoto-u.ac.jp>	<29dd85aca7a0d1399a42b979be001523.squirrel@webmail.uio.no>
	<1e2af89e0911081232l10890376k15787bdb6c2ed871@mail.gmail.com>
Message-ID: <4AF7ADD1.3090600@ar.media.kyoto-u.ac.jp>

Matthew Brett wrote:
> I think that size does matter, as they say, because, if we add a
> moderate number of .pyx files to scipy, we can easily end up adding
> megabytes of diff _per_commit_. 

The diff problem can be somewhat alleviated by marking the generated
files as binary.

>   In the meantime the repository will
> start growing rapidly.  If we ever go to distributed version control,
> we'll get all of that with a 'git clone' or similar.
>   

Git file-format compression is good. In numpy's case, a git clone takes
the same space as a svn checkout.

Now, if everybody else does not mind having a build dependency on a
recent cython version, I won't be against it either.

David


From njs at pobox.com  Mon Nov  9 03:07:36 2009
From: njs at pobox.com (Nathaniel Smith)
Date: Mon, 9 Nov 2009 00:07:36 -0800
Subject: [SciPy-dev] Cython and large generated .c files
In-Reply-To: <4AF7AAE4.7060203@ar.media.kyoto-u.ac.jp>
References: <1e2af89e0911080105k1ca54c2epc2000e6d8e9a107e@mail.gmail.com>
	<1257690000.8180.19.camel@idol>
	<4AF6CF4B.2020408@ar.media.kyoto-u.ac.jp>
	<29dd85aca7a0d1399a42b979be001523.squirrel@webmail.uio.no>
	<4AF7AAE4.7060203@ar.media.kyoto-u.ac.jp>
Message-ID: <961fa2b40911090007h50b35dc6i7877cfb87bba1b4e@mail.gmail.com>

On Sun, Nov 8, 2009 at 9:38 PM, David Cournapeau
<david at ar.media.kyoto-u.ac.jp> wrote:
> I expect quite a few users to build sources from svn, and I am worried
> that many distributions do not package a recent enough version of cython.

Surely anyone taking the trouble to build from sources (checking out,
making sure they have a writeable install location, etc.) can just as
easily type 'easy_install cython' along the way? (That's what I do...)

-- Nathaniel


From pav+sp at iki.fi  Mon Nov  9 04:19:43 2009
From: pav+sp at iki.fi (Pauli Virtanen)
Date: Mon, 9 Nov 2009 09:19:43 +0000 (UTC)
Subject: [SciPy-dev] f2py and ATLAS crashing bug
References: <ce557a360911081542k2d3b9464m680406135fa6f87@mail.gmail.com>
Message-ID: <hd8mrf$7gr$1@ger.gmane.org>

Hi,

Sun, 08 Nov 2009 18:42:56 -0500, Anne Archibald wrote:
> I am still trying to fix the bug where non-aligned matrices can cause
> ATLAS to segfault, and I think I need to improve my understanding of
> f2py somewhat.
> 
> First of all, I'll note that the bug appears in several routines (eig,
> svd, qr, rq, hessenberg, and schur that I have found so far) but only
> when the overwrite_a flag is passed in. So I tried to determine how
> overwrite_a is used in these routines, and I am puzzled. The python
> routines appear to pass it unmodified to the FORTRAN routines. The .pyf
> files mention it in the python call signatures, but nowhere else; from
> the f2py files it looks like it should be ignored. But clearly it has
> some effect, since it allows crashes.
[clip]

You can probably get more insight by looking at what f2py generates from 
the .pyf files:

	build/src.linux-i686-2.6/build/src.linux-i686-2.6/scipy/linalg
	/flapackmodule.c:

	capi_a_intent |= (capi_overwrite_a?0:F2PY_INTENT_COPY);

So, overwrite_a seems to turn copying the array off. Now the question is 
then why intent(align8) doesn't help: looking at

	build/src.linux-i686-2.6/fortranobject.c:array_from_pyobj

it seems that it always forces a copy of misaligned arrays -- but taking 
a look with gdb could be useful to verify this... Maybe there's a bug?

(BTW, did you rm -rf build/ after adding the align8 directives -- there's 
so much autogeneration going on there that it might be possible that 
something is not updating correctly.)

-- 
Pauli Virtanen



From pearu.peterson at gmail.com  Mon Nov  9 05:04:04 2009
From: pearu.peterson at gmail.com (Pearu Peterson)
Date: Mon, 09 Nov 2009 12:04:04 +0200
Subject: [SciPy-dev] f2py and ATLAS crashing bug
In-Reply-To: <hd8mrf$7gr$1@ger.gmane.org>
References: <ce557a360911081542k2d3b9464m680406135fa6f87@mail.gmail.com>
	<hd8mrf$7gr$1@ger.gmane.org>
Message-ID: <4AF7E914.8070007@cens.ioc.ee>



Pauli Virtanen wrote:

> So, overwrite_a seems to turn copying the array off. Now the question is 
> then why intent(align8) doesn't help: looking at

Note that intent(align8) should read intent(aligned8).

HTH,
Pearu


From sturla at molden.no  Mon Nov  9 05:12:09 2009
From: sturla at molden.no (Sturla Molden)
Date: Mon, 9 Nov 2009 11:12:09 +0100
Subject: [SciPy-dev] Cython and large generated .c files
In-Reply-To: <4AF7ADD1.3090600@ar.media.kyoto-u.ac.jp>
References: <1e2af89e0911080105k1ca54c2epc2000e6d8e9a107e@mail.gmail.com>	<1257690000.8180.19.camel@idol>	<4AF6CF4B.2020408@ar.media.kyoto-u.ac.jp>	<29dd85aca7a0d1399a42b979be001523.squirrel@webmail.uio.no>
	<1e2af89e0911081232l10890376k15787bdb6c2ed871@mail.gmail.com>
	<4AF7ADD1.3090600@ar.media.kyoto-u.ac.jp>
Message-ID: <CA745F2E-29CC-4B6B-9E53-CA4582FDC1D6@molden.no>



Den 9. nov. 2009 kl. 06.51 skrev David Cournapeau <david at ar.media.kyoto-u.ac.jp 
 >:

> Matthew Brett wrote:
>> I think that size does matter, as they say, because, if we add a
>> moderate number of .pyx files to scipy, we can easily end up adding
>> megabytes of diff _per_commit_.
>
> The diff problem can be somewhat alleviated by marking the generated
> files as binary.

There is a security issue here: the genererated C code is difficult to  
review. Not that I think scipy developers cannot be trusted, but it is  
easy to hide malicious code in there. At least we need to verify  
that .pyx and generated .c match.

As for the diff issue: generated C must be considered binary. The  
purpose of a diff is for reviewing code. Those C files are hardly  
human readable.

Should we depend on Cython or include Cython? Or have a verified  
buildbot that converts SciPy's Cython source to C?


Sturla


From sturla at molden.no  Mon Nov  9 05:19:11 2009
From: sturla at molden.no (Sturla Molden)
Date: Mon, 9 Nov 2009 11:19:11 +0100
Subject: [SciPy-dev] Cython and large generated .c files
In-Reply-To: <CA745F2E-29CC-4B6B-9E53-CA4582FDC1D6@molden.no>
References: <1e2af89e0911080105k1ca54c2epc2000e6d8e9a107e@mail.gmail.com>	<1257690000.8180.19.camel@idol>	<4AF6CF4B.2020408@ar.media.kyoto-u.ac.jp>	<29dd85aca7a0d1399a42b979be001523.squirrel@webmail.uio.no>
	<1e2af89e0911081232l10890376k15787bdb6c2ed871@mail.gmail.com>
	<4AF7ADD1.3090600@ar.media.kyoto-u.ac.jp>
	<CA745F2E-29CC-4B6B-9E53-CA4582FDC1D6@molden.no>
Message-ID: <E2CEF94F-E644-4549-9C66-4408276E577C@molden.no>



Den 9. nov. 2009 kl. 11.12 skrev Sturla Molden <sturla at molden.no>:

>
>
> Den 9. nov. 2009 kl. 06.51 skrev David Cournapeau <david at ar.media.kyoto-u.ac.jp
>> :
>
>> Matthew Brett wrote:
>>> I think that size does matter, as they say, because, if we add a
>>> moderate number of .pyx files to scipy, we can easily end up adding
>>> megabytes of diff _per_commit_.
>>
>> The diff problem can be somewhat alleviated by marking the generated
>> files as binary.
>
> There is a security issue here: the genererated C code is difficult to
> review. Not that I think scipy developers cannot be trusted, but it is
> easy to hide malicious code in there. At least we need to verify
> that .pyx and generated .c match.
>

And there is the issue of sloppy mistakes: The source of a segfault  
could be in the C, but we would look for it in the Cython source. All  
it takes is for the developer to forget to generate new C before  
commiting.


Sturla


From sturla at molden.no  Mon Nov  9 05:23:54 2009
From: sturla at molden.no (Sturla Molden)
Date: Mon, 9 Nov 2009 11:23:54 +0100
Subject: [SciPy-dev] Cython and large generated .c files
In-Reply-To: <4AF7AAE4.7060203@ar.media.kyoto-u.ac.jp>
References: <1e2af89e0911080105k1ca54c2epc2000e6d8e9a107e@mail.gmail.com>	<1257690000.8180.19.camel@idol>	<4AF6CF4B.2020408@ar.media.kyoto-u.ac.jp>
	<29dd85aca7a0d1399a42b979be001523.squirrel@webmail.uio.no>
	<4AF7AAE4.7060203@ar.media.kyoto-u.ac.jp>
Message-ID: <8DBB68AD-83C7-4728-8D7D-27CBDDC66FE8@molden.no>



Sendt fra min iPhone

Den 9. nov. 2009 kl. 06.38 skrev David Cournapeau <david at ar.media.kyoto-u.ac.jp 
 >:

>>
> I expect quite a few users to build sources from svn, and I am worried
> that many distributions do not package a recent enough version of  
> Cython

Then include one in SciPy. It's just a small Python package.

Sturla



From nwagner at iam.uni-stuttgart.de  Mon Nov  9 13:15:52 2009
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Mon, 09 Nov 2009 19:15:52 +0100
Subject: [SciPy-dev] New build issue
Message-ID: <web-126810330@uni-stuttgart.de>

In file included from scipy/integrate/_odepackmodule.c:6:
scipy/integrate/__odepack.h: In function ?odepack_odeint?:
scipy/integrate/__odepack.h:328: warning: call to function 
?lsoda_? without a real prototype
scipy/integrate/__odepack.h:31: note: ?lsoda_? was 
declared here
scipy/integrate/_odepackmodule.c: At top level:
scipy/integrate/multipack.h:114: warning: 
?my_make_numpy_array? defined but not used
scipy/integrate/__odepack.h: In function ?odepack_odeint?:
scipy/integrate/__odepack.h:226: warning: ?tcrit? may be 
used uninitialized in this function
scipy/integrate/__odepack.h:227: warning: ?wa? may be used 
uninitialized in this function
/usr/bin/gfortran -Wall -Wall -shared 
build/temp.linux-x86_64-2.6/scipy/integrate/_odepackmodule.o 
-L/home/nwagner/src/ATLAS3.8.2/mybuild/lib -L/usr/lib64 
-Lbuild/temp.linux-x86_64-2.6 -lodepack -llinpack_lite 
-lmach -lptf77blas -lptcblas -latlas -lpython2.6 
-lgfortran -o 
build/lib.linux-x86_64-2.6/scipy/integrate/_odepack.so
building 'scipy.integrate.vode' extension
compiling C sources
C compiler: /usr/bin/gcc -fno-strict-aliasing -DNDEBUG 
-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 
-fstack-protector -funwind-tables 
-fasynchronous-unwind-tables -g -fwrapv -fPIC

creating 
build/temp.linux-x86_64-2.6/build/src.linux-x86_64-2.6/scipy/integrate
compile options: '-DATLAS_INFO="\"3.8.2\"" 
-I/home/nwagner/src/ATLAS3.8.2/include 
-Ibuild/src.linux-x86_64-2.6 
-I/home/nwagner/local/lib64/python2.6/site-packages/numpy/core/include 
-I/usr/include/python2.6 -c'
gcc: 
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c: 
In function ?cb_f_in_dvode__user__routines?:
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:376: 
error: ?y_Dims? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:376: 
error: (Each undeclared identifier is reported only once
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:376: 
error: for each function it appears in.)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:376: 
error: ?n? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:377: 
error: ?ydot_Dims? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:335: 
warning: unused variable ?ipar_5?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:334: 
warning: unused variable ?rpar_4?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:332: 
warning: unused variable ?n_0?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c: 
In function ?cb_jac_in_dvode__user__routines?:
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:508: 
error: ?y_Dims? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:508: 
error: ?n? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:509: 
error: ?jac_Dims? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:509: 
error: ?nrowpd? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:509: 
warning: left-hand operand of comma expression has no 
effect
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:467: 
warning: unused variable ?ipar_8?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:466: 
warning: unused variable ?rpar_7?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:465: 
warning: unused variable ?nrowpd_6?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:464: 
warning: unused variable ?mu_4?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:463: 
warning: unused variable ?ml_3?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:461: 
warning: unused variable ?n_0?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c: 
In function ?cb_f_in_zvode__user__routines?:
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:636: 
error: ?y_Dims? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:636: 
error: ?n? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:637: 
error: ?ydot_Dims? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:595: 
warning: unused variable ?ipar_5?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:594: 
warning: unused variable ?rpar_4?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:592: 
warning: unused variable ?n_0?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c: 
In function ?cb_jac_in_zvode__user__routines?:
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:768: 
error: ?y_Dims? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:768: 
error: ?n? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:769: 
error: ?jac_Dims? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:769: 
error: ?nrowpd? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:769: 
warning: left-hand operand of comma expression has no 
effect
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:727: 
warning: unused variable ?ipar_8?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:726: 
warning: unused variable ?rpar_7?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:725: 
warning: unused variable ?nrowpd_6?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:724: 
warning: unused variable ?mu_4?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:723: 
warning: unused variable ?ml_3?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:721: 
warning: unused variable ?n_0?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c: 
In function ?cb_f_in_dvode__user__routines?:
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:376: 
error: ?y_Dims? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:376: 
error: (Each undeclared identifier is reported only once
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:376: 
error: for each function it appears in.)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:376: 
error: ?n? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:377: 
error: ?ydot_Dims? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:335: 
warning: unused variable ?ipar_5?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:334: 
warning: unused variable ?rpar_4?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:332: 
warning: unused variable ?n_0?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c: 
In function ?cb_jac_in_dvode__user__routines?:
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:508: 
error: ?y_Dims? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:508: 
error: ?n? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:509: 
error: ?jac_Dims? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:509: 
error: ?nrowpd? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:509: 
warning: left-hand operand of comma expression has no 
effect
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:467: 
warning: unused variable ?ipar_8?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:466: 
warning: unused variable ?rpar_7?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:465: 
warning: unused variable ?nrowpd_6?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:464: 
warning: unused variable ?mu_4?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:463: 
warning: unused variable ?ml_3?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:461: 
warning: unused variable ?n_0?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c: 
In function ?cb_f_in_zvode__user__routines?:
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:636: 
error: ?y_Dims? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:636: 
error: ?n? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:637: 
error: ?ydot_Dims? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:595: 
warning: unused variable ?ipar_5?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:594: 
warning: unused variable ?rpar_4?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:592: 
warning: unused variable ?n_0?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c: 
In function ?cb_jac_in_zvode__user__routines?:
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:768: 
error: ?y_Dims? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:768: 
error: ?n? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:769: 
error: ?jac_Dims? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:769: 
error: ?nrowpd? undeclared (first use in this function)
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:769: 
warning: left-hand operand of comma expression has no 
effect
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:727: 
warning: unused variable ?ipar_8?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:726: 
warning: unused variable ?rpar_7?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:725: 
warning: unused variable ?nrowpd_6?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:724: 
warning: unused variable ?mu_4?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:723: 
warning: unused variable ?ml_3?
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:721: 
warning: unused variable ?n_0?
error: Command "/usr/bin/gcc -fno-strict-aliasing -DNDEBUG 
-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 
-fstack-protector -funwind-tables 
-fasynchronous-unwind-tables -g -fwrapv -fPIC 
-DATLAS_INFO="\"3.8.2\"" 
-I/home/nwagner/src/ATLAS3.8.2/include 
-Ibuild/src.linux-x86_64-2.6 
-I/home/nwagner/local/lib64/python2.6/site-packages/numpy/core/include 
-I/usr/include/python2.6 -c 
build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c -o 
build/temp.linux-x86_64-2.6/build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.o" 
failed with exit status 1
  
Nils


From charlesr.harris at gmail.com  Mon Nov  9 14:01:33 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Mon, 9 Nov 2009 12:01:33 -0700
Subject: [SciPy-dev] New build issue
In-Reply-To: <web-126810330@uni-stuttgart.de>
References: <web-126810330@uni-stuttgart.de>
Message-ID: <e06186140911091101o45da82admc4392a6fdde4314@mail.gmail.com>

On Mon, Nov 9, 2009 at 11:15 AM, Nils Wagner
<nwagner at iam.uni-stuttgart.de>wrote:

> In file included from scipy/integrate/_odepackmodule.c:6:
> scipy/integrate/__odepack.h: In function ?odepack_odeint?:
> scipy/integrate/__odepack.h:328: warning: call to function
> ?lsoda_? without a real prototype
> scipy/integrate/__odepack.h:31: note: ?lsoda_? was
> declared here
> scipy/integrate/_odepackmodule.c: At top level:
> scipy/integrate/multipack.h:114: warning:
> ?my_make_numpy_array? defined but not used
> scipy/integrate/__odepack.h: In function ?odepack_odeint?:
> scipy/integrate/__odepack.h:226: warning: ?tcrit? may be
> used uninitialized in this function
> scipy/integrate/__odepack.h:227: warning: ?wa? may be used
> uninitialized in this function
> /usr/bin/gfortran -Wall -Wall -shared
> build/temp.linux-x86_64-2.6/scipy/integrate/_odepackmodule.o
> -L/home/nwagner/src/ATLAS3.8.2/mybuild/lib -L/usr/lib64
> -Lbuild/temp.linux-x86_64-2.6 -lodepack -llinpack_lite
> -lmach -lptf77blas -lptcblas -latlas -lpython2.6
> -lgfortran -o
> build/lib.linux-x86_64-2.6/scipy/integrate/_odepack.so
> building 'scipy.integrate.vode' extension
> compiling C sources
> C compiler: /usr/bin/gcc -fno-strict-aliasing -DNDEBUG
> -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2
> -fstack-protector -funwind-tables
> -fasynchronous-unwind-tables -g -fwrapv -fPIC
>
> creating
> build/temp.linux-x86_64-2.6/build/src.linux-x86_64-2.6/scipy/integrate
> compile options: '-DATLAS_INFO="\"3.8.2\""
> -I/home/nwagner/src/ATLAS3.8.2/include
> -Ibuild/src.linux-x86_64-2.6
> -I/home/nwagner/local/lib64/python2.6/site-packages/numpy/core/include
> -I/usr/include/python2.6 -c'
> gcc:
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:
> In function ?cb_f_in_dvode__user__routines?:
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:376:
> error: ?y_Dims? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:376:
> error: (Each undeclared identifier is reported only once
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:376:
> error: for each function it appears in.)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:376:
> error: ?n? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:377:
> error: ?ydot_Dims? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:335:
> warning: unused variable ?ipar_5?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:334:
> warning: unused variable ?rpar_4?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:332:
> warning: unused variable ?n_0?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:
> In function ?cb_jac_in_dvode__user__routines?:
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:508:
> error: ?y_Dims? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:508:
> error: ?n? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:509:
> error: ?jac_Dims? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:509:
> error: ?nrowpd? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:509:
> warning: left-hand operand of comma expression has no
> effect
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:467:
> warning: unused variable ?ipar_8?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:466:
> warning: unused variable ?rpar_7?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:465:
> warning: unused variable ?nrowpd_6?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:464:
> warning: unused variable ?mu_4?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:463:
> warning: unused variable ?ml_3?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:461:
> warning: unused variable ?n_0?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:
> In function ?cb_f_in_zvode__user__routines?:
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:636:
> error: ?y_Dims? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:636:
> error: ?n? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:637:
> error: ?ydot_Dims? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:595:
> warning: unused variable ?ipar_5?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:594:
> warning: unused variable ?rpar_4?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:592:
> warning: unused variable ?n_0?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:
> In function ?cb_jac_in_zvode__user__routines?:
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:768:
> error: ?y_Dims? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:768:
> error: ?n? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:769:
> error: ?jac_Dims? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:769:
> error: ?nrowpd? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:769:
> warning: left-hand operand of comma expression has no
> effect
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:727:
> warning: unused variable ?ipar_8?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:726:
> warning: unused variable ?rpar_7?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:725:
> warning: unused variable ?nrowpd_6?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:724:
> warning: unused variable ?mu_4?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:723:
> warning: unused variable ?ml_3?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:721:
> warning: unused variable ?n_0?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:
> In function ?cb_f_in_dvode__user__routines?:
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:376:
> error: ?y_Dims? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:376:
> error: (Each undeclared identifier is reported only once
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:376:
> error: for each function it appears in.)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:376:
> error: ?n? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:377:
> error: ?ydot_Dims? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:335:
> warning: unused variable ?ipar_5?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:334:
> warning: unused variable ?rpar_4?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:332:
> warning: unused variable ?n_0?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:
> In function ?cb_jac_in_dvode__user__routines?:
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:508:
> error: ?y_Dims? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:508:
> error: ?n? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:509:
> error: ?jac_Dims? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:509:
> error: ?nrowpd? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:509:
> warning: left-hand operand of comma expression has no
> effect
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:467:
> warning: unused variable ?ipar_8?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:466:
> warning: unused variable ?rpar_7?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:465:
> warning: unused variable ?nrowpd_6?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:464:
> warning: unused variable ?mu_4?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:463:
> warning: unused variable ?ml_3?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:461:
> warning: unused variable ?n_0?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:
> In function ?cb_f_in_zvode__user__routines?:
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:636:
> error: ?y_Dims? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:636:
> error: ?n? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:637:
> error: ?ydot_Dims? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:595:
> warning: unused variable ?ipar_5?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:594:
> warning: unused variable ?rpar_4?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:592:
> warning: unused variable ?n_0?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:
> In function ?cb_jac_in_zvode__user__routines?:
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:768:
> error: ?y_Dims? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:768:
> error: ?n? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:769:
> error: ?jac_Dims? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:769:
> error: ?nrowpd? undeclared (first use in this function)
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:769:
> warning: left-hand operand of comma expression has no
> effect
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:727:
> warning: unused variable ?ipar_8?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:726:
> warning: unused variable ?rpar_7?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:725:
> warning: unused variable ?nrowpd_6?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:724:
> warning: unused variable ?mu_4?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:723:
> warning: unused variable ?ml_3?
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:721:
> warning: unused variable ?n_0?
> error: Command "/usr/bin/gcc -fno-strict-aliasing -DNDEBUG
> -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2
> -fstack-protector -funwind-tables
> -fasynchronous-unwind-tables -g -fwrapv -fPIC
> -DATLAS_INFO="\"3.8.2\""
> -I/home/nwagner/src/ATLAS3.8.2/include
> -Ibuild/src.linux-x86_64-2.6
> -I/home/nwagner/local/lib64/python2.6/site-packages/numpy/core/include
> -I/usr/include/python2.6 -c
> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c -o
>
> build/temp.linux-x86_64-2.6/build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.o"
> failed with exit status 1
>
>
The problem file is generated by f2py. I'm going to guess that the recent
changes to the numpy include files may have broken f2py. Although if that is
the case I don't know why more files didn't fail.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091109/6dc9b000/attachment.html>

From charlesr.harris at gmail.com  Mon Nov  9 14:13:54 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Mon, 9 Nov 2009 12:13:54 -0700
Subject: [SciPy-dev] New build issue
In-Reply-To: <e06186140911091101o45da82admc4392a6fdde4314@mail.gmail.com>
References: <web-126810330@uni-stuttgart.de>
	<e06186140911091101o45da82admc4392a6fdde4314@mail.gmail.com>
Message-ID: <e06186140911091113w1eaa8ba5va0311de61b744b3@mail.gmail.com>

On Mon, Nov 9, 2009 at 12:01 PM, Charles R Harris <charlesr.harris at gmail.com
> wrote:

>
>
> On Mon, Nov 9, 2009 at 11:15 AM, Nils Wagner <nwagner at iam.uni-stuttgart.de
> > wrote:
>
>> In file included from scipy/integrate/_odepackmodule.c:6:
>> scipy/integrate/__odepack.h: In function ?odepack_odeint?:
>> scipy/integrate/__odepack.h:328: warning: call to function
>> ?lsoda_? without a real prototype
>> scipy/integrate/__odepack.h:31: note: ?lsoda_? was
>> declared here
>> scipy/integrate/_odepackmodule.c: At top level:
>> scipy/integrate/multipack.h:114: warning:
>> ?my_make_numpy_array? defined but not used
>> scipy/integrate/__odepack.h: In function ?odepack_odeint?:
>> scipy/integrate/__odepack.h:226: warning: ?tcrit? may be
>> used uninitialized in this function
>> scipy/integrate/__odepack.h:227: warning: ?wa? may be used
>> uninitialized in this function
>> /usr/bin/gfortran -Wall -Wall -shared
>> build/temp.linux-x86_64-2.6/scipy/integrate/_odepackmodule.o
>> -L/home/nwagner/src/ATLAS3.8.2/mybuild/lib -L/usr/lib64
>> -Lbuild/temp.linux-x86_64-2.6 -lodepack -llinpack_lite
>> -lmach -lptf77blas -lptcblas -latlas -lpython2.6
>> -lgfortran -o
>> build/lib.linux-x86_64-2.6/scipy/integrate/_odepack.so
>> building 'scipy.integrate.vode' extension
>> compiling C sources
>> C compiler: /usr/bin/gcc -fno-strict-aliasing -DNDEBUG
>> -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2
>> -fstack-protector -funwind-tables
>> -fasynchronous-unwind-tables -g -fwrapv -fPIC
>>
>> creating
>> build/temp.linux-x86_64-2.6/build/src.linux-x86_64-2.6/scipy/integrate
>> compile options: '-DATLAS_INFO="\"3.8.2\""
>> -I/home/nwagner/src/ATLAS3.8.2/include
>> -Ibuild/src.linux-x86_64-2.6
>> -I/home/nwagner/local/lib64/python2.6/site-packages/numpy/core/include
>> -I/usr/include/python2.6 -c'
>> gcc:
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:
>> In function ?cb_f_in_dvode__user__routines?:
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:376:
>> error: ?y_Dims? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:376:
>> error: (Each undeclared identifier is reported only once
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:376:
>> error: for each function it appears in.)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:376:
>> error: ?n? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:377:
>> error: ?ydot_Dims? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:335:
>> warning: unused variable ?ipar_5?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:334:
>> warning: unused variable ?rpar_4?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:332:
>> warning: unused variable ?n_0?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:
>> In function ?cb_jac_in_dvode__user__routines?:
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:508:
>> error: ?y_Dims? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:508:
>> error: ?n? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:509:
>> error: ?jac_Dims? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:509:
>> error: ?nrowpd? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:509:
>> warning: left-hand operand of comma expression has no
>> effect
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:467:
>> warning: unused variable ?ipar_8?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:466:
>> warning: unused variable ?rpar_7?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:465:
>> warning: unused variable ?nrowpd_6?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:464:
>> warning: unused variable ?mu_4?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:463:
>> warning: unused variable ?ml_3?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:461:
>> warning: unused variable ?n_0?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:
>> In function ?cb_f_in_zvode__user__routines?:
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:636:
>> error: ?y_Dims? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:636:
>> error: ?n? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:637:
>> error: ?ydot_Dims? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:595:
>> warning: unused variable ?ipar_5?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:594:
>> warning: unused variable ?rpar_4?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:592:
>> warning: unused variable ?n_0?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:
>> In function ?cb_jac_in_zvode__user__routines?:
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:768:
>> error: ?y_Dims? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:768:
>> error: ?n? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:769:
>> error: ?jac_Dims? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:769:
>> error: ?nrowpd? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:769:
>> warning: left-hand operand of comma expression has no
>> effect
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:727:
>> warning: unused variable ?ipar_8?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:726:
>> warning: unused variable ?rpar_7?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:725:
>> warning: unused variable ?nrowpd_6?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:724:
>> warning: unused variable ?mu_4?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:723:
>> warning: unused variable ?ml_3?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:721:
>> warning: unused variable ?n_0?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:
>> In function ?cb_f_in_dvode__user__routines?:
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:376:
>> error: ?y_Dims? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:376:
>> error: (Each undeclared identifier is reported only once
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:376:
>> error: for each function it appears in.)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:376:
>> error: ?n? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:377:
>> error: ?ydot_Dims? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:335:
>> warning: unused variable ?ipar_5?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:334:
>> warning: unused variable ?rpar_4?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:332:
>> warning: unused variable ?n_0?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:
>> In function ?cb_jac_in_dvode__user__routines?:
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:508:
>> error: ?y_Dims? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:508:
>> error: ?n? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:509:
>> error: ?jac_Dims? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:509:
>> error: ?nrowpd? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:509:
>> warning: left-hand operand of comma expression has no
>> effect
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:467:
>> warning: unused variable ?ipar_8?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:466:
>> warning: unused variable ?rpar_7?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:465:
>> warning: unused variable ?nrowpd_6?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:464:
>> warning: unused variable ?mu_4?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:463:
>> warning: unused variable ?ml_3?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:461:
>> warning: unused variable ?n_0?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:
>> In function ?cb_f_in_zvode__user__routines?:
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:636:
>> error: ?y_Dims? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:636:
>> error: ?n? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:637:
>> error: ?ydot_Dims? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:595:
>> warning: unused variable ?ipar_5?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:594:
>> warning: unused variable ?rpar_4?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:592:
>> warning: unused variable ?n_0?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:
>> In function ?cb_jac_in_zvode__user__routines?:
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:768:
>> error: ?y_Dims? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:768:
>> error: ?n? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:769:
>> error: ?jac_Dims? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:769:
>> error: ?nrowpd? undeclared (first use in this function)
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:769:
>> warning: left-hand operand of comma expression has no
>> effect
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:727:
>> warning: unused variable ?ipar_8?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:726:
>> warning: unused variable ?rpar_7?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:725:
>> warning: unused variable ?nrowpd_6?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:724:
>> warning: unused variable ?mu_4?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:723:
>> warning: unused variable ?ml_3?
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c:721:
>> warning: unused variable ?n_0?
>> error: Command "/usr/bin/gcc -fno-strict-aliasing -DNDEBUG
>> -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2
>> -fstack-protector -funwind-tables
>> -fasynchronous-unwind-tables -g -fwrapv -fPIC
>> -DATLAS_INFO="\"3.8.2\""
>> -I/home/nwagner/src/ATLAS3.8.2/include
>> -Ibuild/src.linux-x86_64-2.6
>> -I/home/nwagner/local/lib64/python2.6/site-packages/numpy/core/include
>> -I/usr/include/python2.6 -c
>> build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.c -o
>>
>> build/temp.linux-x86_64-2.6/build/src.linux-x86_64-2.6/scipy/integrate/vodemodule.o"
>> failed with exit status 1
>>
>>
> The problem file is generated by f2py. I'm going to guess that the recent
> changes to the numpy include files may have broken f2py. Although if that is
> the case I don't know why more files didn't fail.
>
>
There is also this recent change to f2py
http://projects.scipy.org/numpy/changeset/7712. Could you try backing that
out?

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091109/94d0f368/attachment.html>

From nwagner at iam.uni-stuttgart.de  Mon Nov  9 14:21:39 2009
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Mon, 09 Nov 2009 20:21:39 +0100
Subject: [SciPy-dev] New build issue
In-Reply-To: <e06186140911091113w1eaa8ba5va0311de61b744b3@mail.gmail.com>
References: <web-126810330@uni-stuttgart.de>
	<e06186140911091101o45da82admc4392a6fdde4314@mail.gmail.com>
	<e06186140911091113w1eaa8ba5va0311de61b744b3@mail.gmail.com>
Message-ID: <web-126812253@uni-stuttgart.de>

>> The problem file is generated by f2py. I'm going to 
>>guess that the recent
>> changes to the numpy include files may have broken f2py. 
>>Although if that is
>> the case I don't know why more files didn't fail.
>>
>>
> There is also this recent change to f2py
> http://projects.scipy.org/numpy/changeset/7712. Could 
>you try backing that
> out?
> 

Do you mean

svn co -r7711 http://svn.scipy.org/svn/numpy/trunk numpy
  
Nils


From charlesr.harris at gmail.com  Mon Nov  9 14:44:47 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Mon, 9 Nov 2009 12:44:47 -0700
Subject: [SciPy-dev] New build issue
In-Reply-To: <web-126812253@uni-stuttgart.de>
References: <web-126810330@uni-stuttgart.de>
	<e06186140911091101o45da82admc4392a6fdde4314@mail.gmail.com>
	<e06186140911091113w1eaa8ba5va0311de61b744b3@mail.gmail.com>
	<web-126812253@uni-stuttgart.de>
Message-ID: <e06186140911091144o6baf4a02id85e28dc1386c53e@mail.gmail.com>

On Mon, Nov 9, 2009 at 12:21 PM, Nils Wagner
<nwagner at iam.uni-stuttgart.de>wrote:

> >> The problem file is generated by f2py. I'm going to
> >>guess that the recent
> >> changes to the numpy include files may have broken f2py.
> >>Although if that is
> >> the case I don't know why more files didn't fail.
> >>
> >>
> > There is also this recent change to f2py
> > http://projects.scipy.org/numpy/changeset/7712. Could
> >you try backing that
> > out?
> >
>
> Do you mean
>
> svn co -r7711 http://svn.scipy.org/svn/numpy/trunk numpy
>
>
Yes...Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091109/af7f05ee/attachment.html>

From nwagner at iam.uni-stuttgart.de  Mon Nov  9 15:40:57 2009
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Mon, 09 Nov 2009 21:40:57 +0100
Subject: [SciPy-dev] New build issue
In-Reply-To: <e06186140911091144o6baf4a02id85e28dc1386c53e@mail.gmail.com>
References: <web-126810330@uni-stuttgart.de>
	<e06186140911091101o45da82admc4392a6fdde4314@mail.gmail.com>
	<e06186140911091113w1eaa8ba5va0311de61b744b3@mail.gmail.com>
	<web-126812253@uni-stuttgart.de>
	<e06186140911091144o6baf4a02id85e28dc1386c53e@mail.gmail.com>
Message-ID: <web-126814106@uni-stuttgart.de>

On Mon, 9 Nov 2009 12:44:47 -0700
  Charles R Harris <charlesr.harris at gmail.com> wrote:
> On Mon, Nov 9, 2009 at 12:21 PM, Nils Wagner
> <nwagner at iam.uni-stuttgart.de>wrote:
> 
>> >> The problem file is generated by f2py. I'm going to
>> >>guess that the recent
>> >> changes to the numpy include files may have broken 
>>f2py.
>> >>Although if that is
>> >> the case I don't know why more files didn't fail.
>> >>
>> >>
>> > There is also this recent change to f2py
>> > http://projects.scipy.org/numpy/changeset/7712. Could
>> >you try backing that
>> > out?
>> >
>>
>> Do you mean
>>
>> svn co -r7711 http://svn.scipy.org/svn/numpy/trunk numpy


Done. It works with r7711.

Cheers,

                 Nils
  


From charlesr.harris at gmail.com  Mon Nov  9 15:46:28 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Mon, 9 Nov 2009 13:46:28 -0700
Subject: [SciPy-dev] New build issue
In-Reply-To: <web-126814106@uni-stuttgart.de>
References: <web-126810330@uni-stuttgart.de>
	<e06186140911091101o45da82admc4392a6fdde4314@mail.gmail.com>
	<e06186140911091113w1eaa8ba5va0311de61b744b3@mail.gmail.com>
	<web-126812253@uni-stuttgart.de>
	<e06186140911091144o6baf4a02id85e28dc1386c53e@mail.gmail.com>
	<web-126814106@uni-stuttgart.de>
Message-ID: <e06186140911091246s7c3e6c3elca9a66a9dd9a3854@mail.gmail.com>

On Mon, Nov 9, 2009 at 1:40 PM, Nils Wagner <nwagner at iam.uni-stuttgart.de>wrote:

> On Mon, 9 Nov 2009 12:44:47 -0700
>   Charles R Harris <charlesr.harris at gmail.com> wrote:
> > On Mon, Nov 9, 2009 at 12:21 PM, Nils Wagner
> > <nwagner at iam.uni-stuttgart.de>wrote:
> >
> >> >> The problem file is generated by f2py. I'm going to
> >> >>guess that the recent
> >> >> changes to the numpy include files may have broken
> >>f2py.
> >> >>Although if that is
> >> >> the case I don't know why more files didn't fail.
> >> >>
> >> >>
> >> > There is also this recent change to f2py
> >> > http://projects.scipy.org/numpy/changeset/7712. Could
> >> >you try backing that
> >> > out?
> >> >
> >>
> >> Do you mean
> >>
> >> svn co -r7711 http://svn.scipy.org/svn/numpy/trunk numpy
>
>
> Done. It works with r7711.
>
>
Great. Could you open a numpy ticket for this?

TIA,
Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091109/ef160331/attachment.html>

From oliphant at enthought.com  Mon Nov  9 17:49:26 2009
From: oliphant at enthought.com (Travis Oliphant)
Date: Mon, 9 Nov 2009 16:49:26 -0600
Subject: [SciPy-dev] Cython and large generated .c files
In-Reply-To: <1257690000.8180.19.camel@idol>
References: <1e2af89e0911080105k1ca54c2epc2000e6d8e9a107e@mail.gmail.com>
	<1257690000.8180.19.camel@idol>
Message-ID: <009E7AD4-D82E-406A-B357-8C0BC6338699@enthought.com>


On Nov 8, 2009, at 8:20 AM, Pauli Virtanen wrote:

> su, 2009-11-08 kello 01:05 -0800, Matthew Brett kirjoitti:
> [clip: huge Cython-generated .c files]
>> An obvious way round this is to let distutils run Cython for  
>> developer
>> builds, and only generate the .c for releases, or some such, but I  
>> can
>> see that could get messy.   But, the space the .c file takes up is
>> making me think twice about commits.
>>
>> Have y'all got any thoughts how to deal with this problem?
>
> I think Cython has some pre-made distutils hooks to make this less
> painless. I don't know how nicely they work with numpy.distutils,
> however...
>
> A bigger issue than build setup may be that then we'd require users to
> have the latest Cython installed to build Scipy. (Perhaps the
> generated .c files could be shipped with the distributed tarballs,
> though, so only people interested in SVN would need Cython.)
> Actually, this might not be so much to ask, given that Cython is a
> pure-Python package.
>
> So, should we make Scipy depend on Cython at build-time?

I think this would be fine.   In fact, I think it would be a good  
idea.  It would encourage Cython extensions.

-Travis



From matthew.brett at gmail.com  Mon Nov  9 18:03:52 2009
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 9 Nov 2009 15:03:52 -0800
Subject: [SciPy-dev] Cython and large generated .c files
In-Reply-To: <009E7AD4-D82E-406A-B357-8C0BC6338699@enthought.com>
References: <1e2af89e0911080105k1ca54c2epc2000e6d8e9a107e@mail.gmail.com>
	<1257690000.8180.19.camel@idol>
	<009E7AD4-D82E-406A-B357-8C0BC6338699@enthought.com>
Message-ID: <1e2af89e0911091503n2c6421aft674c7418597ed535@mail.gmail.com>

>> So, should we make Scipy depend on Cython at build-time?
>
> I think this would be fine. ? In fact, I think it would be a good
> idea. ?It would encourage Cython extensions.

That seems good to me too.

Matthew


From peridot.faceted at gmail.com  Mon Nov  9 19:08:22 2009
From: peridot.faceted at gmail.com (Anne Archibald)
Date: Mon, 9 Nov 2009 19:08:22 -0500
Subject: [SciPy-dev] f2py and ATLAS crashing bug
In-Reply-To: <4AF7E914.8070007@cens.ioc.ee>
References: <ce557a360911081542k2d3b9464m680406135fa6f87@mail.gmail.com>
	<hd8mrf$7gr$1@ger.gmane.org> <4AF7E914.8070007@cens.ioc.ee>
Message-ID: <ce557a360911091608r3d4d8b78u746e62129ae19114@mail.gmail.com>

2009/11/9 Pearu Peterson <pearu.peterson at gmail.com>:
>
>
> Pauli Virtanen wrote:
>
>> So, overwrite_a seems to turn copying the array off. Now the question is
>> then why intent(align8) doesn't help: looking at
>
> Note that intent(align8) should read intent(aligned8).

Oops. I feel dumb now.

I've just checked in code (r6096) that fixes all cases where I was
able to trigger the bug. Some more difficult cases like eigh, banded
eigensolvers, and cholesky I wasn't able to trigger the bug and so I
haven't modified.

Anne

> HTH,
> Pearu
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From dwf at cs.toronto.edu  Mon Nov  9 19:38:03 2009
From: dwf at cs.toronto.edu (David Warde-Farley)
Date: Mon, 9 Nov 2009 19:38:03 -0500
Subject: [SciPy-dev] Build failure on OS X 10.5.8, Python 2.5, gcc-4.0.1
In-Reply-To: <5b8d13220911070052r21ddca41wfa5c0dfaeb6979a9@mail.gmail.com>
References: <807642B9-90E9-47B8-97A8-2665F682D544@cs.toronto.edu>
	<e06186140911061353w7c1999dwf3e3ef5d7d8e6501@mail.gmail.com>
	<F453CAA1-E73E-4841-B96E-54956E9C62F5@cs.toronto.edu>
	<e06186140911061610t29da2a06n79891d4d78eb5ca2@mail.gmail.com>
	<4AF51ECB.3000009@ar.media.kyoto-u.ac.jp>
	<5b8d13220911070052r21ddca41wfa5c0dfaeb6979a9@mail.gmail.com>
Message-ID: <32AA00EE-2EB4-4ED8-986D-CE500D118097@cs.toronto.edu>

On 7-Nov-09, at 3:52 AM, David Cournapeau wrote:

> This is a bit strange, you've never seen the problem before ?

Nope, but as someone else pointed out, it may be a gcc-4.2 artifact. I  
just switched from 4.0.1 because of the complex business.

David


From cournape at gmail.com  Mon Nov  9 19:58:40 2009
From: cournape at gmail.com (David Cournapeau)
Date: Tue, 10 Nov 2009 09:58:40 +0900
Subject: [SciPy-dev] Build failure on OS X 10.5.8, Python 2.5, gcc-4.0.1
In-Reply-To: <32AA00EE-2EB4-4ED8-986D-CE500D118097@cs.toronto.edu>
References: <807642B9-90E9-47B8-97A8-2665F682D544@cs.toronto.edu>
	<e06186140911061353w7c1999dwf3e3ef5d7d8e6501@mail.gmail.com>
	<F453CAA1-E73E-4841-B96E-54956E9C62F5@cs.toronto.edu>
	<e06186140911061610t29da2a06n79891d4d78eb5ca2@mail.gmail.com>
	<4AF51ECB.3000009@ar.media.kyoto-u.ac.jp>
	<5b8d13220911070052r21ddca41wfa5c0dfaeb6979a9@mail.gmail.com>
	<32AA00EE-2EB4-4ED8-986D-CE500D118097@cs.toronto.edu>
Message-ID: <5b8d13220911091658h542b60b8se1c21efeff8a24dd@mail.gmail.com>

On Tue, Nov 10, 2009 at 9:38 AM, David Warde-Farley <dwf at cs.toronto.edu> wrote:
> On 7-Nov-09, at 3:52 AM, David Cournapeau wrote:
>
>> This is a bit strange, you've never seen the problem before ?
>
> Nope, but as someone else pointed out, it may be a gcc-4.2 artifact. I
> just switched from 4.0.1 because of the complex business.

Oh, ok, that explains it. gcc 4.2, including apple one, does not
support -Wno-long-double. You should not change gcc compared to what
python distutils expects, it will not work as is (unless you use
numscons).

The complex thing should be fixed in trunk - would you mind testing
the last numpy/scipy for python 2.5 and ppc ?

cheers,

David


From cournape at gmail.com  Mon Nov  9 21:06:44 2009
From: cournape at gmail.com (David Cournapeau)
Date: Tue, 10 Nov 2009 11:06:44 +0900
Subject: [SciPy-dev] Cython and large generated .c files
In-Reply-To: <1e2af89e0911091503n2c6421aft674c7418597ed535@mail.gmail.com>
References: <1e2af89e0911080105k1ca54c2epc2000e6d8e9a107e@mail.gmail.com>
	<1257690000.8180.19.camel@idol>
	<009E7AD4-D82E-406A-B357-8C0BC6338699@enthought.com>
	<1e2af89e0911091503n2c6421aft674c7418597ed535@mail.gmail.com>
Message-ID: <5b8d13220911091806y6c2967d9hf11812000ca14552@mail.gmail.com>

On Tue, Nov 10, 2009 at 8:03 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
>>> So, should we make Scipy depend on Cython at build-time?
>>
>> I think this would be fine. ? In fact, I think it would be a good
>> idea. ?It would encourage Cython extensions.
>
> That seems good to me too.

That's decided then. I will add cython support to numpy.distutils (and
will also expand the cython support in numscons). For numpy.distutils,
I would prefer add it after 1.4.0 (meaning manual cython for scipy
0.8.0): is this acceptable for you Matthew ?

cheers,

David


From dalcinl at gmail.com  Mon Nov  9 21:06:55 2009
From: dalcinl at gmail.com (Lisandro Dalcin)
Date: Mon, 9 Nov 2009 23:06:55 -0300
Subject: [SciPy-dev] Cython and large generated .c files
In-Reply-To: <1e2af89e0911091503n2c6421aft674c7418597ed535@mail.gmail.com>
References: <1e2af89e0911080105k1ca54c2epc2000e6d8e9a107e@mail.gmail.com>
	<1257690000.8180.19.camel@idol>
	<009E7AD4-D82E-406A-B357-8C0BC6338699@enthought.com>
	<1e2af89e0911091503n2c6421aft674c7418597ed535@mail.gmail.com>
Message-ID: <e7ba66e40911091806u7ce06c7ejcad988e34169af8d@mail.gmail.com>

On Mon, Nov 9, 2009 at 8:03 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
>>> So, should we make Scipy depend on Cython at build-time?
>>
>> I think this would be fine. ? In fact, I think it would be a good
>> idea. ?It would encourage Cython extensions.
>
> That seems good to me too.
>

I have some naive code implementing automatic download of a zip file
checkout from the Cython repos. After a few fixes some time ago,
Cython can happily run with zipimport (there is a nasty warning that
could be worked for removal), so the build-time dependency could be
somewhat alleviated, the scipy buildsystem could just try to
automatically download a zip file in case of a missing/outdated Cython
installation.


-- 
Lisandro Dalc?n
---------------
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594


From david at ar.media.kyoto-u.ac.jp  Mon Nov  9 20:52:10 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Tue, 10 Nov 2009 10:52:10 +0900
Subject: [SciPy-dev] Cython and large generated .c files
In-Reply-To: <e7ba66e40911091806u7ce06c7ejcad988e34169af8d@mail.gmail.com>
References: <1e2af89e0911080105k1ca54c2epc2000e6d8e9a107e@mail.gmail.com>	<1257690000.8180.19.camel@idol>	<009E7AD4-D82E-406A-B357-8C0BC6338699@enthought.com>	<1e2af89e0911091503n2c6421aft674c7418597ed535@mail.gmail.com>
	<e7ba66e40911091806u7ce06c7ejcad988e34169af8d@mail.gmail.com>
Message-ID: <4AF8C74A.30900@ar.media.kyoto-u.ac.jp>

Lisandro Dalcin wrote:
> I have some naive code implementing automatic download of a zip file
> checkout from the Cython repos. After a few fixes some time ago,
> Cython can happily run with zipimport (there is a nasty warning that
> could be worked for removal), so the build-time dependency could be
> somewhat alleviated, the scipy buildsystem could just try to
> automatically download a zip file in case of a missing/outdated Cython
> installation.
>   

Please, no. Building should not involve any internet connection. This
can fail in so many ways, we will get many reports of people with weird
network policies and so on. And OS packagers will hate us even more.

Cython becomes a build dependency, it should be checked and handled as
such. I will add numpy.distutils support  to make this transparent
(unless someone beats me to it).

cheers,

David



From matthew.brett at gmail.com  Mon Nov  9 21:15:55 2009
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 9 Nov 2009 18:15:55 -0800
Subject: [SciPy-dev] Cython and large generated .c files
In-Reply-To: <5b8d13220911091806y6c2967d9hf11812000ca14552@mail.gmail.com>
References: <1e2af89e0911080105k1ca54c2epc2000e6d8e9a107e@mail.gmail.com>
	<1257690000.8180.19.camel@idol>
	<009E7AD4-D82E-406A-B357-8C0BC6338699@enthought.com>
	<1e2af89e0911091503n2c6421aft674c7418597ed535@mail.gmail.com>
	<5b8d13220911091806y6c2967d9hf11812000ca14552@mail.gmail.com>
Message-ID: <1e2af89e0911091815g43929467sbac3b034e8ecdb8f@mail.gmail.com>

Hi,

>>> I think this would be fine. ? In fact, I think it would be a good
>>> idea. ?It would encourage Cython extensions.
>>
>> That seems good to me too.
>
> That's decided then. I will add cython support to numpy.distutils (and
> will also expand the cython support in numscons). For numpy.distutils,
> I would prefer add it after 1.4.0 (meaning manual cython for scipy
> 0.8.0): is this acceptable for you Matthew ?

Fine by me - thank you.

Matthew


From rcsqtc at iqac.csic.es  Tue Nov 10 11:59:45 2009
From: rcsqtc at iqac.csic.es (Ramon Crehuet)
Date: Tue, 10 Nov 2009 17:59:45 +0100
Subject: [SciPy-dev] Performance Python
Message-ID: <4AF99C01.8020603@iqac.csic.es>

Hi all,
A few days ago I posted a contribution to the Performace Python page at
the Scipy-users list. This list is probably a better place to send it.
I would like to add that to the wiki. Can I be authorized for that?
Best regards,
Ramon



Subject: Contribution to Performance Python
From: Ramon Crehuet <rcsqtc at iqac.csic.es>
Date: Fri, 06 Nov 2009 11:53:25 +0100
To: scipy-user at scipy.net

Hi all,
After reading the "Performance Python" page at:
http://www.scipy.org/PerformancePython?action=show
I thought some code with Fortran 90/95 was missing, in partuclar
considering its useful array features. So I have written a couple of
examples with Fortran 90 arrays and with the Fortran 95 forall
construct. Both are nicer (to me  :-)  ) than the FORTRAN77 loops and also
faster! In my PC a 1000x1000 array gives:

Doing 100 iterations on a 1000x1000 grid
numeric took 5.86 seconds
fortran77 took 3.53 seconds
fortran90-arrays took 1.58 seconds
fortran95-forall took 1.58 seconds
slow (1 iteration) took 9.13 seconds
100 iterations should take about 913.000000 seconds

If this is interesting to the community, who should I contact to have
this included in the scipy web page?
Cheers,
Ramon


This are the two new subroutines. I can send the modified laplace.py to
whoever wants it.
******************************************************
! File flaplace90_arrays.f90

subroutine timestep(u,n,m,dx,dy,error)

implicit none

real (kind=8), dimension(0:n-1,0:m-1), intent(inout):: u


real (kind=8), intent(in) :: dx,dy
real (kind=8), intent(out) :: error
integer, intent(in) :: n,m
real (kind=8), dimension(0:n-1,0:m-1) :: diff
real (kind=8) :: dx2,dy2,dnr_inv

!f2py intent(in) :: dx,dy
!f2py intent(in,out) :: u
!f2py intent(out) :: error
!f2py intent(hide) :: n,m

dx2 = dx*dx
dy2 = dy*dy
dnr_inv = 0.5d0 / (dx2+dy2)

diff=u

u(1:n-2, 1:m-2) = ((u(0:n-3, 1:m-2) + u(2:n-1, 1:m-2))*dy2 + &
                         (u(1:n-2,0:m-3) + u(1:n-2, 2:m-1))*dx2)*dnr_inv

error=sqrt(sum((u-diff)**2))

end subroutine
******************************************************
! File flaplace95_forall.f90

subroutine timestep(u,n,m,dx,dy,error)

implicit none

real (kind=8), dimension(0:n-1,0:m-1), intent(inout):: u


real (kind=8), intent(in) :: dx,dy
real (kind=8), intent(out) :: error
integer, intent(in) :: n,m
real (kind=8), dimension(0:n-1,0:m-1) :: diff
real (kind=8) :: dx2,dy2,dnr_inv
integer :: i,j

!f2py intent(in) :: dx,dy
!f2py intent(in,out) :: u
!f2py intent(out) :: error
!f2py intent(hide) :: n,m

dx2 = dx*dx
dy2 = dy*dy
dnr_inv = 0.5d0 / (dx2+dy2)

diff=u

forall (i=1:n-2,j=1:m-2)
    u(i,j) = ((u(i-1,j) + u(i+1,j))*dy2+(u(i,j-1) + u(i,j+1))*dx2)*dnr_inv
end forall

error=sqrt(sum((u-diff)**2))

end subroutine

******************************************************



From dwf at cs.toronto.edu  Tue Nov 10 12:03:38 2009
From: dwf at cs.toronto.edu (David Warde-Farley)
Date: Tue, 10 Nov 2009 12:03:38 -0500
Subject: [SciPy-dev] Performance Python
In-Reply-To: <4AF99C01.8020603@iqac.csic.es>
References: <4AF99C01.8020603@iqac.csic.es>
Message-ID: <6A506A2D-C999-4164-82B4-F06D6218F31A@cs.toronto.edu>


On 10-Nov-09, at 11:59 AM, Ramon Crehuet wrote:

> If this is interesting to the community, who should I contact to have
> this included in the scipy web page?

I've added it to the list of things that should go in the Cookbook.  
We're in the process of renewing the scipy.org website and while we  
made big progress at the end of October we're still not done. A  
preliminary (several revisions behind SVN) version of the new site is  
at new.scipy.org.

David


From dalcinl at gmail.com  Tue Nov 10 18:20:40 2009
From: dalcinl at gmail.com (Lisandro Dalcin)
Date: Tue, 10 Nov 2009 20:20:40 -0300
Subject: [SciPy-dev] Cython and large generated .c files
In-Reply-To: <4AF8C74A.30900@ar.media.kyoto-u.ac.jp>
References: <1e2af89e0911080105k1ca54c2epc2000e6d8e9a107e@mail.gmail.com>
	<1257690000.8180.19.camel@idol>
	<009E7AD4-D82E-406A-B357-8C0BC6338699@enthought.com>
	<1e2af89e0911091503n2c6421aft674c7418597ed535@mail.gmail.com>
	<e7ba66e40911091806u7ce06c7ejcad988e34169af8d@mail.gmail.com>
	<4AF8C74A.30900@ar.media.kyoto-u.ac.jp>
Message-ID: <e7ba66e40911101520v25bbf17cuebd745866e2e499b@mail.gmail.com>

On Mon, Nov 9, 2009 at 10:52 PM, David Cournapeau
<david at ar.media.kyoto-u.ac.jp> wrote:
> Lisandro Dalcin wrote:
>> I have some naive code implementing automatic download of a zip file
>> checkout from the Cython repos. After a few fixes some time ago,
>> Cython can happily run with zipimport (there is a nasty warning that
>> could be worked for removal), so the build-time dependency could be
>> somewhat alleviated, the scipy buildsystem could just try to
>> automatically download a zip file in case of a missing/outdated Cython
>> installation.
>>
>
> Please, no. Building should not involve any internet connection. This
> can fail in so many ways, we will get many reports of people with weird
> network policies and so on. And OS packagers will hate us even more.
>

David, Iwas just talking about building -dev SVN checkouts. Release
tarballs should ship the generated C sources.

> Cython becomes a build dependency, it should be checked and handled as
> such. I will add numpy.distutils support ?to make this transparent
> (unless someone beats me to it).
>

What this means?

-- 
Lisandro Dalc?n
---------------
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594


From dwf at cs.toronto.edu  Tue Nov 10 18:48:07 2009
From: dwf at cs.toronto.edu (David Warde-Farley)
Date: Tue, 10 Nov 2009 18:48:07 -0500
Subject: [SciPy-dev] Build failure on OS X 10.5.8, Python 2.5, gcc-4.0.1
In-Reply-To: <5b8d13220911091658h542b60b8se1c21efeff8a24dd@mail.gmail.com>
References: <807642B9-90E9-47B8-97A8-2665F682D544@cs.toronto.edu>
	<e06186140911061353w7c1999dwf3e3ef5d7d8e6501@mail.gmail.com>
	<F453CAA1-E73E-4841-B96E-54956E9C62F5@cs.toronto.edu>
	<e06186140911061610t29da2a06n79891d4d78eb5ca2@mail.gmail.com>
	<4AF51ECB.3000009@ar.media.kyoto-u.ac.jp>
	<5b8d13220911070052r21ddca41wfa5c0dfaeb6979a9@mail.gmail.com>
	<32AA00EE-2EB4-4ED8-986D-CE500D118097@cs.toronto.edu>
	<5b8d13220911091658h542b60b8se1c21efeff8a24dd@mail.gmail.com>
Message-ID: <DBAB3B2A-A1C7-4808-A64E-1CE16F4FFB35@cs.toronto.edu>

On 9-Nov-09, at 7:58 PM, David Cournapeau wrote:

> The complex thing should be fixed in trunk - would you mind testing
> the last numpy/scipy for python 2.5 and ppc ?

Confirmed -- all is well on py2.5/ppc as of r6096. Thanks!

David


From david at ar.media.kyoto-u.ac.jp  Tue Nov 10 20:08:52 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Wed, 11 Nov 2009 10:08:52 +0900
Subject: [SciPy-dev] Cython and large generated .c files
In-Reply-To: <e7ba66e40911101520v25bbf17cuebd745866e2e499b@mail.gmail.com>
References: <1e2af89e0911080105k1ca54c2epc2000e6d8e9a107e@mail.gmail.com>	<1257690000.8180.19.camel@idol>	<009E7AD4-D82E-406A-B357-8C0BC6338699@enthought.com>	<1e2af89e0911091503n2c6421aft674c7418597ed535@mail.gmail.com>	<e7ba66e40911091806u7ce06c7ejcad988e34169af8d@mail.gmail.com>	<4AF8C74A.30900@ar.media.kyoto-u.ac.jp>
	<e7ba66e40911101520v25bbf17cuebd745866e2e499b@mail.gmail.com>
Message-ID: <4AFA0EA4.5050608@ar.media.kyoto-u.ac.jp>

Hi Lisandro,

Lisandro Dalcin wrote:
>
> David, Iwas just talking about building -dev SVN checkouts. Release
> tarballs should ship the generated C sources.
>   

It does not change my argument: dependencies should be explicit, and
build should never trigger network access.

Network is inherently fragile, and makes sandboxing builds more
difficult. Making a difference between release and dev makes the release
process is not great either: the more different they are, the more
likely you are to produce a broken release out there in my experience. I
think it is a good policy that dev builds are as similar as possible to
building releases from sources.

> What this means?
>   

It means that if a package depends on cython at a certain version, it
should check for this, and fails if it does not, like it does if you
don't have a fortran compiler or blas/lapack for scipy. It was argued
that installing the right version of cython is not difficult, after all :)

cheers,

David



From rcsqtc at iqac.csic.es  Wed Nov 11 06:13:13 2009
From: rcsqtc at iqac.csic.es (Ramon Crehuet)
Date: Wed, 11 Nov 2009 12:13:13 +0100
Subject: [SciPy-dev] Adding an attachment to the wiki
Message-ID: <4AFA9C49.4010906@iqac.csic.es>

Dear all,
I have modified the Performance Python page:
http://www.scipy.org/PerformancePython
and I would like to upload a new version of the attached perfpy.tgz. I
do not know how to do that and I couldn't find it in HelpOnEditing. Any
hints where to find the info?
Cheers,
Ramon


From scott.sinclair.za at gmail.com  Wed Nov 11 06:19:10 2009
From: scott.sinclair.za at gmail.com (Scott Sinclair)
Date: Wed, 11 Nov 2009 13:19:10 +0200
Subject: [SciPy-dev] Adding an attachment to the wiki
In-Reply-To: <4AFA9C49.4010906@iqac.csic.es>
References: <4AFA9C49.4010906@iqac.csic.es>
Message-ID: <6a17e9ee0911110319y4167b118s30bca67e40991afe@mail.gmail.com>

>2009/11/11 Ramon Crehuet <rcsqtc at iqac.csic.es>:
> I have modified the Performance Python page:
> http://www.scipy.org/PerformancePython
> and I would like to upload a new version of the attached perfpy.tgz. I
> do not know how to do that and I couldn't find it in HelpOnEditing. Any
> hints where to find the info?

Thanks!

When you're logged in you can click the Attachments link on the
lefthand side panel. It looks like you'll need to rename your new
attachment and update the links in the wiki page.

Cheers,
Scott


From rcsqtc at iqac.csic.es  Wed Nov 11 07:24:58 2009
From: rcsqtc at iqac.csic.es (Ramon Crehuet)
Date: Wed, 11 Nov 2009 13:24:58 +0100
Subject: [SciPy-dev] Performance Python
Message-ID: <4AFAAD1A.8000005@iqac.csic.es>

Dear all,
I have upadated some issues in the performace python page. I would also
like to update the timings but I do not have octave or matlab. Is
somebody with this software willing to do the benchmarks so that we can
give a complete report? If so, contact me and I can send all the codes.
Thanks in advance!
Ramon


From pav+sp at iki.fi  Wed Nov 11 08:38:40 2009
From: pav+sp at iki.fi (Pauli Virtanen)
Date: Wed, 11 Nov 2009 13:38:40 +0000 (UTC)
Subject: [SciPy-dev] Performance Python
References: <4AFAAD1A.8000005@iqac.csic.es>
Message-ID: <hdeep0$7dv$1@ger.gmane.org>

Wed, 11 Nov 2009 13:24:58 +0100, Ramon Crehuet wrote:
> I have upadated some issues in the performace python page. I would also
> like to update the timings but I do not have octave or matlab. Is
> somebody with this software willing to do the benchmarks so that we can
> give a complete report? If so, contact me and I can send all the codes.

You can get Octave for free from www.octave.org



From opossumnano at gmail.com  Wed Nov 11 17:04:22 2009
From: opossumnano at gmail.com (Tiziano Zito)
Date: Wed, 11 Nov 2009 23:04:22 +0100
Subject: [SciPy-dev] f2py and ATLAS crashing bug
In-Reply-To: <ce557a360911091608r3d4d8b78u746e62129ae19114@mail.gmail.com>
References: <ce557a360911081542k2d3b9464m680406135fa6f87@mail.gmail.com>
	<hd8mrf$7gr$1@ger.gmane.org> <4AF7E914.8070007@cens.ioc.ee>
	<ce557a360911091608r3d4d8b78u746e62129ae19114@mail.gmail.com>
Message-ID: <e195e9cb0911111404o2c4f37e4s13e62e9e84ca9a9@mail.gmail.com>

Hi Anne,
I just checked in the fix for the eigh-related LAPACK wrappers in r6097.
You can trigger a segfault in r6096 with:

import scipy
import scipy.linalg
import pickle
N = 100
x = scipy.random.random((N, N))
s = pickle.dumps(x)
y = pickle.loads(s)
out = scipy.linalg.eigh(y.T, overwrite_a=True)

this is fixed in r6097.

Cheers,
Tiziano

On Tue, Nov 10, 2009 at 1:08 AM, Anne Archibald
<peridot.faceted at gmail.com> wrote:
> I've just checked in code (r6096) that fixes all cases where I was
> able to trigger the bug. Some more difficult cases like eigh, banded
> eigensolvers, and cholesky I wasn't able to trigger the bug and so I
> haven't modified.
>
> Anne


From d.l.goldsmith at gmail.com  Thu Nov 12 05:07:39 2009
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Thu, 12 Nov 2009 02:07:39 -0800
Subject: [SciPy-dev] I need "Needs Review (revised)" permission, please.
Message-ID: <45d1ab480911120207s2f8854b1k80f07c4d6cb7fc99@mail.gmail.com>

Thanks!

DG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091112/433b65c0/attachment.html>

From gael.varoquaux at normalesup.org  Thu Nov 12 05:12:06 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Thu, 12 Nov 2009 11:12:06 +0100
Subject: [SciPy-dev] DocServer error
Message-ID: <20091112101206.GA9829@phare.normalesup.org>

I am getting a 500 error on:
http://docs.scipy.org/numpy/docs/numpy.core.fromnumeric.choose/

Ga?l


From d.l.goldsmith at gmail.com  Thu Nov 12 05:18:48 2009
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Thu, 12 Nov 2009 02:18:48 -0800
Subject: [SciPy-dev] DocServer error
In-Reply-To: <20091112101206.GA9829@phare.normalesup.org>
References: <20091112101206.GA9829@phare.normalesup.org>
Message-ID: <45d1ab480911120218r2c85f824pb3ca81091187b71a@mail.gmail.com>

How long ago?  (I was editing it, but am done now, and can refresh the page,
no error; try again).

DG

On Thu, Nov 12, 2009 at 2:12 AM, Gael Varoquaux <
gael.varoquaux at normalesup.org> wrote:

> I am getting a 500 error on:
> http://docs.scipy.org/numpy/docs/numpy.core.fromnumeric.choose/
>
> Ga?l
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091112/daced15c/attachment.html>

From gael.varoquaux at normalesup.org  Thu Nov 12 05:20:05 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Thu, 12 Nov 2009 11:20:05 +0100
Subject: [SciPy-dev] DocServer error
In-Reply-To: <45d1ab480911120218r2c85f824pb3ca81091187b71a@mail.gmail.com>
References: <20091112101206.GA9829@phare.normalesup.org>
	<45d1ab480911120218r2c85f824pb3ca81091187b71a@mail.gmail.com>
Message-ID: <20091112102005.GC9829@phare.normalesup.org>

On Thu, Nov 12, 2009 at 02:18:48AM -0800, David Goldsmith wrote:
>    How long ago?? (I was editing it, but am done now, and can refresh the
>    page, no error; try again).

Indeed, it now works :)

Ga?l


From lesserwhirls at gmail.com  Thu Nov 12 11:24:12 2009
From: lesserwhirls at gmail.com (Sean Arms)
Date: Thu, 12 Nov 2009 10:24:12 -0600
Subject: [SciPy-dev] Continuous Wavelet Transform for SciPy
In-Reply-To: <b45a83780903021925t1c5ad75aw9d9178775134c0f8@mail.gmail.com>
References: <b45a83780903021925t1c5ad75aw9d9178775134c0f8@mail.gmail.com>
Message-ID: <b45a83780911120824o527a8e26t8e5e0bc898beefcb@mail.gmail.com>

Greetings!

     I just wanted to let everyone know that I've updated the CWT
package and updated the TRAC ticket: (current version tagged as 0.2.1
on github).

  project git repo:

     http://github.com/lesserwhirls/scipy-cwt/tree/0.2.1

  code review:

     http://codereview.appspot.com/154092/show

     (the old code review located at
http://codereview.appspot.com/40099 is no longer valid).

Cheers!

Sean Arms
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Mon, Mar 2, 2009 at 9:25 PM, Sean Arms <lesserwhirls at gmail.com> wrote:
> Greetings!
>
> ?????? My name is Sean Arms and I'm a graduate student at the University of
> Oklahoma in the School of Meteorology.? As part of my PhD research, I'm
> studying coherent structures in atmospheric boundary layer turbulence,
> primarily using in-situ observations and, secondarily, Direct Numerical
> Simulation (DNS) output.? One common approach for detecting coherent
> structures in observational datasets relies on the use of the global wavelet
> power spectrum as estimated from a continuous wavelet transform (CWT).? I
> know SciPy has a DWT impementation, and I've already been in contact with
> Filip.? He recommeded that I post my code in hopes that it would add some
> momentum to the python-cwt development and create some feedback (I'm
> currently looking for a good place to post my code).? I've implemented the
> CWT using pure python (that is, I did not write any C extension code myself
> - nothing to build), along with one mother wavelet (second derivitive of a
> Gaussian, or the Mexican Hat) - I'll be adding more Mother wavelets as I go
> along.? I've made it a point to (try to) design my MotherWavelet class to be
> easily extendable.? I'm working on documentation and a few tests at the
> moment, but so far my code compares well with other wavelet routines.
>
> ???? The point of this email is to introduce myself and let the SciPy dev
> community know that I am willing to help develop CWT support for SciPy -
> I'll already be doing the work for my research, so I might as well put in
> the extra effort to make is usable by the larger community!
>
> Cheers!
>
> Sean Arms
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
>


From d.l.goldsmith at gmail.com  Thu Nov 12 16:42:43 2009
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Thu, 12 Nov 2009 13:42:43 -0800
Subject: [SciPy-dev] Module docstrings, round 2
Message-ID: <45d1ab480911121342o419c9922m415bd7be750042c4@mail.gmail.com>

Hi, folks.  Is there an efficient way in the wiki to get a listing of all of
numpy's modules?  I tried searching for the empty string (i.e., entered
nothing in the search field) and limited the search to modules and got 58
results - does that sound right?

DG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091112/3850420d/attachment.html>

From d.l.goldsmith at gmail.com  Thu Nov 12 16:59:12 2009
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Thu, 12 Nov 2009 13:59:12 -0800
Subject: [SciPy-dev] Module docstrings, round 2
In-Reply-To: <45d1ab480911121342o419c9922m415bd7be750042c4@mail.gmail.com>
References: <45d1ab480911121342o419c9922m415bd7be750042c4@mail.gmail.com>
Message-ID: <45d1ab480911121359v66f5d427of31ff2bc040b88c7@mail.gmail.com>

Revision: Is there a way to get a listing of all of numpy's modules whose
docstrings have *not* been classified as *Unimportant* (the first three that
I tried of the 58 below were so classified)?

DG

On Thu, Nov 12, 2009 at 1:42 PM, David Goldsmith <d.l.goldsmith at gmail.com>wrote:

> Hi, folks.  Is there an efficient way in the wiki to get a listing of all
> of numpy's modules?  I tried searching for the empty string (i.e., entered
> nothing in the search field) and limited the search to modules and got 58
> results - does that sound right?
>
> DG
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091112/f47c2c3d/attachment.html>

From robertlayton at gmail.com  Thu Nov 12 18:47:25 2009
From: robertlayton at gmail.com (Robert Layton)
Date: Fri, 13 Nov 2009 10:47:25 +1100
Subject: [SciPy-dev] Decision on ticket #467
Message-ID: <585dc5e20911121547t402af4aemb003517a9db541b7@mail.gmail.com>

On ticket #467, I have uploaded two different patches, one which removes
unneeded tests of numpy's mean function within scipy (since scipy's mean is
now not used) and the other is an update of the tests based on cdavid's
earlier patch.

I'd like to go through and see if any other tests can be removed/cleaned
using the same principle (i.e. only test functions that are part of scipy in
scipy's tests, remove tests of functions that are now part of numpy), but I
wanted to wait for a decision to be made on this ticket first. Does anybody
have any input into this?

Thanks,

Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091113/0cda2f85/attachment.html>

From d.l.goldsmith at gmail.com  Thu Nov 12 20:55:44 2009
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Thu, 12 Nov 2009 17:55:44 -0800
Subject: [SciPy-dev] doc.<item> == module?
Message-ID: <45d1ab480911121755g2447acf9yb07e843240ab944e@mail.gmail.com>

Hi!  Are the various doc.<name> (e.g., doc.basics, doc.creation, etc.)
modules?  Does it vary (i.e., some are, some aren't)?  (I'm compiling a list
of the "Being written" and "Needs editing" module docstrings.)  Thanks!

DG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091112/5c814a7c/attachment.html>

From josef.pktd at gmail.com  Thu Nov 12 21:26:48 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 12 Nov 2009 21:26:48 -0500
Subject: [SciPy-dev] doc.<item> == module?
In-Reply-To: <45d1ab480911121755g2447acf9yb07e843240ab944e@mail.gmail.com>
References: <45d1ab480911121755g2447acf9yb07e843240ab944e@mail.gmail.com>
Message-ID: <1cd32cbb0911121826g4c022a81x70784c1d582fd9d1@mail.gmail.com>

On Thu, Nov 12, 2009 at 8:55 PM, David Goldsmith
<d.l.goldsmith at gmail.com> wrote:
> Hi!? Are the various doc.<name> (e.g., doc.basics, doc.creation, etc.)
> modules?? Does it vary (i.e., some are, some aren't)?? (I'm compiling a list
> of the "Being written" and "Needs editing" module docstrings.)? Thanks!

I've never seen these files before. It looks like, each module (that I
checked) is just a docstring that is included into the numpy
documentation. Bu, After a quick look it doesn't seem that they can be
edited where they are displayed in the rst source, e.g.

http://docs.scipy.org/numpy/docs/numpy-docs/user/basics.broadcasting.rst/#basics-broadcasting

However, they can be edited as a module, e.g.

http://docs.scipy.org/numpy/docs/numpy.doc.broadcasting/

So it looks like that these are part of the User Guide in the docs.

Josef



>
> DG
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From d.l.goldsmith at gmail.com  Thu Nov 12 21:35:59 2009
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Thu, 12 Nov 2009 18:35:59 -0800
Subject: [SciPy-dev] doc.<item> == module?
In-Reply-To: <45d1ab480911121755g2447acf9yb07e843240ab944e@mail.gmail.com>
References: <45d1ab480911121755g2447acf9yb07e843240ab944e@mail.gmail.com>
Message-ID: <45d1ab480911121835o78aa09aoab0d8db233d507ea@mail.gmail.com>

On Thu, Nov 12, 2009 at 5:55 PM, David Goldsmith <d.l.goldsmith at gmail.com>wrote:

> Hi!  Are the various doc.<name> (e.g., doc.basics, doc.creation, etc.)
> modules?  Does it vary (i.e., some are, some aren't)?  (I'm compiling a list
> of the "Being written" and "Needs editing" module docstrings.)  Thanks!
>
> DG
>

Compiled by manually cross-referencing the results of a module-limited
search for the empty string and the color-coded "All docstrings" list, here
it is:

Module docstrings
    "Being written":
core.records
ctypeslib
doc.basics
doc.broadcasting
doc.creation
doc.glossary
doc.indexing
doc.internals
doc.structured_arrays
doc.ufuncs

    "Needs Editing":
core.umath
distutils.npy_pkg_config
core.function_base
core.shape_base
matrixlib

(Note: the module-limited empty string search returned a few strange
results, namely the now deprecated core.defmatrix - which no longer comes up
in the list of All docstrings - and matrx and matrx.defmatrx.)

DG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091112/265bf288/attachment.html>

From d.l.goldsmith at gmail.com  Thu Nov 12 21:38:58 2009
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Thu, 12 Nov 2009 18:38:58 -0800
Subject: [SciPy-dev] doc.<item> == module?
In-Reply-To: <1cd32cbb0911121826g4c022a81x70784c1d582fd9d1@mail.gmail.com>
References: <45d1ab480911121755g2447acf9yb07e843240ab944e@mail.gmail.com>
	<1cd32cbb0911121826g4c022a81x70784c1d582fd9d1@mail.gmail.com>
Message-ID: <45d1ab480911121838n3a24c992n84398238945c39ea@mail.gmail.com>

On Thu, Nov 12, 2009 at 6:26 PM, <josef.pktd at gmail.com> wrote:

> On Thu, Nov 12, 2009 at 8:55 PM, David Goldsmith
> <d.l.goldsmith at gmail.com> wrote:
> > Hi!  Are the various doc.<name> (e.g., doc.basics, doc.creation, etc.)
> > modules?  Does it vary (i.e., some are, some aren't)?  (I'm compiling a
> list
> > of the "Being written" and "Needs editing" module docstrings.)  Thanks!
>
> I've never seen these files before. It looks like, each module (that I
> checked) is just a docstring that is included into the numpy
> documentation. Bu, After a quick look it doesn't seem that they can be
> edited where they are displayed in the rst source, e.g.
>
>
> http://docs.scipy.org/numpy/docs/numpy-docs/user/basics.broadcasting.rst/#basics-broadcasting
>
> However, they can be edited as a module, e.g.
>
> http://docs.scipy.org/numpy/docs/numpy.doc.broadcasting/
>
> So it looks like that these are part of the User Guide in the docs.
>

And so not modules, which the wiki is treating as if they were modules?

DG

>
> Josef
>
>
>
> >
> > DG
> >
> > _______________________________________________
> > Scipy-dev mailing list
> > Scipy-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> >
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091112/60ed2d8a/attachment.html>

From josef.pktd at gmail.com  Thu Nov 12 22:27:16 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 12 Nov 2009 22:27:16 -0500
Subject: [SciPy-dev] doc.<item> == module?
In-Reply-To: <45d1ab480911121838n3a24c992n84398238945c39ea@mail.gmail.com>
References: <45d1ab480911121755g2447acf9yb07e843240ab944e@mail.gmail.com>
	<1cd32cbb0911121826g4c022a81x70784c1d582fd9d1@mail.gmail.com>
	<45d1ab480911121838n3a24c992n84398238945c39ea@mail.gmail.com>
Message-ID: <1cd32cbb0911121927o16d77454qae062c5fcb3c99fb@mail.gmail.com>

On Thu, Nov 12, 2009 at 9:38 PM, David Goldsmith
<d.l.goldsmith at gmail.com> wrote:
> On Thu, Nov 12, 2009 at 6:26 PM, <josef.pktd at gmail.com> wrote:
>>
>> On Thu, Nov 12, 2009 at 8:55 PM, David Goldsmith
>> <d.l.goldsmith at gmail.com> wrote:
>> > Hi!? Are the various doc.<name> (e.g., doc.basics, doc.creation, etc.)
>> > modules?? Does it vary (i.e., some are, some aren't)?? (I'm compiling a
>> > list
>> > of the "Being written" and "Needs editing" module docstrings.)? Thanks!
>>
>> I've never seen these files before. It looks like, each module (that I
>> checked) is just a docstring that is included into the numpy
>> documentation. Bu, After a quick look it doesn't seem that they can be
>> edited where they are displayed in the rst source, e.g.
>>
>>
>> http://docs.scipy.org/numpy/docs/numpy-docs/user/basics.broadcasting.rst/#basics-broadcasting
>>
>> However, they can be edited as a module, e.g.
>>
>> http://docs.scipy.org/numpy/docs/numpy.doc.broadcasting/
>>
>> So it looks like that these are part of the User Guide in the docs.
>
> And so not modules, which the wiki is treating as if they were modules?

They are python modules (although not doing any calculations) and
imported in numpy.doc.__init__ . As far as I can see, the doceditor
needs to treat them as modules to make them editable.
Editable as modules and included through automodule in the rst file.

So they are part of the docs and should be edited as such, but they
don't contain any functions that need to be documented.

(This is just after looking at them for a brief time and might miss something.)

Josef


>
> DG
>>
>> Josef
>>
>>
>>
>> >
>> > DG
>> >
>> > _______________________________________________
>> > Scipy-dev mailing list
>> > Scipy-dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >
>> >
>> _______________________________________________
>> Scipy-dev mailing list
>> Scipy-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From matthew.brett at gmail.com  Fri Nov 13 03:03:42 2009
From: matthew.brett at gmail.com (Matthew Brett)
Date: Fri, 13 Nov 2009 00:03:42 -0800
Subject: [SciPy-dev] Matlab reader refactored, please stress test
Message-ID: <1e2af89e0911130003o5fed55c1u20193dfd39912d3e@mail.gmail.com>

Hi,

I've just committed a comprehensive refactoring of the matlab file
readers.   Much of the heavy code is now in Cython.  It's much faster
now,  around the same order as Matlab itself, I think.

Because the code is almost completely rewritten, I'd be very grateful
if you matlab io users and developers out there could check out and
run the code on the files you use.

Thanks to Robin Ince and Alireza Alemi-Neissi for pointing out the
problem and for helpful test files.

Cheers,

Matthew


From dwf at cs.toronto.edu  Fri Nov 13 12:40:54 2009
From: dwf at cs.toronto.edu (David Warde-Farley)
Date: Fri, 13 Nov 2009 12:40:54 -0500
Subject: [SciPy-dev] Matlab reader refactored, please stress test
In-Reply-To: <1e2af89e0911130003o5fed55c1u20193dfd39912d3e@mail.gmail.com>
References: <1e2af89e0911130003o5fed55c1u20193dfd39912d3e@mail.gmail.com>
Message-ID: <B66F7FD3-E412-44E1-A445-44C603BECE46@cs.toronto.edu>

On 13-Nov-09, at 3:03 AM, Matthew Brett wrote:

> I've just committed a comprehensive refactoring of the matlab file
> readers.   Much of the heavy code is now in Cython.  It's much faster
> now,  around the same order as Matlab itself, I think.

I saw the benchmarks you posted, I'm very impressed!

> Because the code is almost completely rewritten, I'd be very grateful
> if you matlab io users and developers out there could check out and
> run the code on the files you use.

I'm not a typical user of the mio stuff but I do have some mat files  
hanging around from the bad old days, I will try them out ASAP.

David


From d.l.goldsmith at gmail.com  Fri Nov 13 13:44:37 2009
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Fri, 13 Nov 2009 10:44:37 -0800
Subject: [SciPy-dev] Matlab reader refactored, please stress test
In-Reply-To: <B66F7FD3-E412-44E1-A445-44C603BECE46@cs.toronto.edu>
References: <1e2af89e0911130003o5fed55c1u20193dfd39912d3e@mail.gmail.com>
	<B66F7FD3-E412-44E1-A445-44C603BECE46@cs.toronto.edu>
Message-ID: <45d1ab480911131044s1c7a4358ue3ca50fbfa3dd44c@mail.gmail.com>

On Fri, Nov 13, 2009 at 9:40 AM, David Warde-Farley <dwf at cs.toronto.edu>wrote:

> On 13-Nov-09, at 3:03 AM, Matthew Brett wrote:
>
> > I've just committed a comprehensive refactoring of the matlab file
> > readers.   Much of the heavy code is now in Cython.  It's much faster
> > now,  around the same order as Matlab itself, I think.
>
> I saw the benchmarks you posted, I'm very impressed!
>
> > Because the code is almost completely rewritten, I'd be very grateful
> > if you matlab io users and developers out there could check out and
> > run the code on the files you use.
>
> I'm not a typical user of the mio stuff but I do have some mat files
> hanging around from the bad old days, I will try them out ASAP.
>

Same here, but I use the pre-built Windows binary of scipy, so presumably
(for now) I'll have to build SVN HEAD to use/test, yes?  I've gone ahead and
checked it out, and downloaded both MinGW, incl. g++ and other offered
enhancements, and MSVC8 Express (in order to build BLAS, which I'm lacking
according to my initial attempt to build scipy brom source).  Anyone reading
this have any recommendations/advice vis-a-vis how to proceed so as to
minimize my headaches (which I've had in the past trying to build blas and
scipy from source in Windows).  Thanks!

DG


>
> David
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091113/291b8dec/attachment.html>

From ralf.gommers at googlemail.com  Sun Nov 15 11:08:41 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Sun, 15 Nov 2009 17:08:41 +0100
Subject: [SciPy-dev] ndimage - docfiller and output_type
In-Reply-To: <dde7764a0910300745n5f6e67dfvd534bc6cccf9ba25@mail.gmail.com>
References: <dde7764a0910121251n5ac3a109n488416bb7d09ea82@mail.gmail.com>
	<1cd32cbb0910280813t6c3655b7n68bdb8cbac57c9f0@mail.gmail.com>
	<hca19u$spu$1@ger.gmane.org>
	<1cd32cbb0910281234j540934d8kf53d253c6599e392@mail.gmail.com>
	<dde7764a0910281316jf78ad8dr69ce853f3ed4b245@mail.gmail.com>
	<1cd32cbb0910281400p894d32cidac20aa450cf9391@mail.gmail.com>
	<1cd32cbb0910281515l2035fb0fjfb4ad8742095178e@mail.gmail.com>
	<dde7764a0910290228n601f42c0tb73ec096d7631119@mail.gmail.com>
	<1cd32cbb0910290733q1d034c03g3db530bb10bec564@mail.gmail.com>
	<dde7764a0910300745n5f6e67dfvd534bc6cccf9ba25@mail.gmail.com>
Message-ID: <dde7764a0911150808g75574ebega794676309dbd55b@mail.gmail.com>

On Fri, Oct 30, 2009 at 3:45 PM, Ralf Gommers
<ralf.gommers at googlemail.com>wrote:

>
>
> On Thu, Oct 29, 2009 at 3:33 PM, <josef.pktd at gmail.com> wrote:
>
>> I have to look at this again next week when I have a bit more time.
>>
>> Did you have time to look at it again Josef? I created ticket 1055 and
attached a patch. Please review either there or on github if you can.

Thanks,
Ralf



> I don't mind the boiler plate code in the individual distributions anymore,
>> if we can improve the docs for the distributions this way. You could try
>> it out on a few distributions to avoid having to edit 90 templates if
>> there
>> are any changes.
>>
>>
> Josef, the changes are here:
> http://github.com/rgommers/scipy/tree/statsdocs For examples of new
> docstrings, see maxwell, wald and nbinom.
>
>
> Do you use git, or would you prefer it if I opened a ticket and attached a
> diff?
>
> The things I was not sure about:
> 1. do you want the old-style classes with better help()? I actually
> consider this a bug:
> >>> help(wald)
> Help on wald_gen .....         # I asked for help on wald, not wald_gen
>
> 2. Where should doccer.py live? Now I do "from scipy.ndimage import
> doccer", but doccer is useful in multiple SciPy modules, and probably in
> NumPy as well. Could we move it to NumPy?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091115/224b0366/attachment.html>

From josef.pktd at gmail.com  Sun Nov 15 21:52:57 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Sun, 15 Nov 2009 21:52:57 -0500
Subject: [SciPy-dev] ndimage - docfiller and output_type
In-Reply-To: <dde7764a0911150808g75574ebega794676309dbd55b@mail.gmail.com>
References: <dde7764a0910121251n5ac3a109n488416bb7d09ea82@mail.gmail.com>
	<hca19u$spu$1@ger.gmane.org>
	<1cd32cbb0910281234j540934d8kf53d253c6599e392@mail.gmail.com>
	<dde7764a0910281316jf78ad8dr69ce853f3ed4b245@mail.gmail.com>
	<1cd32cbb0910281400p894d32cidac20aa450cf9391@mail.gmail.com>
	<1cd32cbb0910281515l2035fb0fjfb4ad8742095178e@mail.gmail.com>
	<dde7764a0910290228n601f42c0tb73ec096d7631119@mail.gmail.com>
	<1cd32cbb0910290733q1d034c03g3db530bb10bec564@mail.gmail.com>
	<dde7764a0910300745n5f6e67dfvd534bc6cccf9ba25@mail.gmail.com>
	<dde7764a0911150808g75574ebega794676309dbd55b@mail.gmail.com>
Message-ID: <1cd32cbb0911151852h62b302f0g4449e9f1c7d7474a@mail.gmail.com>

On Sun, Nov 15, 2009 at 11:08 AM, Ralf Gommers
<ralf.gommers at googlemail.com> wrote:
>
>
> On Fri, Oct 30, 2009 at 3:45 PM, Ralf Gommers <ralf.gommers at googlemail.com>
> wrote:
>>
>>
>> On Thu, Oct 29, 2009 at 3:33 PM, <josef.pktd at gmail.com> wrote:
>>>
>>> I have to look at this again next week when I have a bit more time.
>>>
> Did you have time to look at it again Josef? I created ticket 1055 and
> attached a patch. Please review either there or on github if you can.

Thanks, I took your version from github. Since there are many changes,
including cosmetic, I didn't go over all of them. I compared several
docstrings of the old and the new version, and overall it seems to work
very well.

The main mistake currently is that the generic docstring for discrete is
the same as the one for the continuous distributions, e.g.

print stats.poisson.__doc__

discrete distributions don't have a scale argument, and don't have a pdf
method, instead of pdf, discrete distributions have a pmf probability mass
function.

Second, the generic class docstrings are pretty empty, e.g. they don't have
the list of methods.

print stats.distributions.rv_discrete.__doc__
print stats.distributions.rv_continuous.__doc__

taste questions:
I don't think I like the formulas in the methods, e.g. print stats.wald.__doc__
I think, formulas from the extradocs should go into a notes section.

I would also prefer to keep extradoc for now, even if it is not used
anymore for the docstrings, just because I'm very used to using it. We
can drop them later once the new system is fully working.

Given that there is more flexibility with the new system, I would
prefer to put the extradoc information into a notes section instead of
tucking them on at the end in the default template, if possible.

Why did you special case before and after pdf?

Also, I think it would be better making the framework changes separate
from any changes to the content, e.g rv_continuous, rv_discrete. If
everything works, we can edit and review changes to the content in the
doc editor.

Sorry for the delay in the review, I've been busy and I have problems
keeping up with the C changes in numpy and scipy.
(I only commented on the parts I didn't like so much, because the rest
is a good improvement.)

Thanks,

Josef


> Thanks,
> Ralf
>
>
>>>
>>> I don't mind the boiler plate code in the individual distributions
>>> anymore,
>>> if we can improve the docs for the distributions this way. You could try
>>> it out on a few distributions to avoid having to edit 90 templates if
>>> there
>>> are any changes.
>>>
>>
>> Josef, the changes are here:
>> http://github.com/rgommers/scipy/tree/statsdocs For examples of new
>> docstrings, see maxwell, wald and nbinom.
>>
>>
>> Do you use git, or would you prefer it if I opened a ticket and attached a
>> diff?
>>
>> The things I was not sure about:
>> 1. do you want the old-style classes with better help()? I actually
>> consider this a bug:
>> >>> help(wald)
>> Help on wald_gen .....???????? # I asked for help on wald, not wald_gen
>>
>> 2. Where should doccer.py live? Now I do "from scipy.ndimage import
>> doccer", but doccer is useful in multiple SciPy modules, and probably in
>> NumPy as well. Could we move it to NumPy?
>>
>>
>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From ralf.gommers at googlemail.com  Mon Nov 16 11:50:49 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Mon, 16 Nov 2009 17:50:49 +0100
Subject: [SciPy-dev] ndimage - docfiller and output_type
In-Reply-To: <1cd32cbb0911151852h62b302f0g4449e9f1c7d7474a@mail.gmail.com>
References: <dde7764a0910121251n5ac3a109n488416bb7d09ea82@mail.gmail.com>
	<1cd32cbb0910281234j540934d8kf53d253c6599e392@mail.gmail.com>
	<dde7764a0910281316jf78ad8dr69ce853f3ed4b245@mail.gmail.com>
	<1cd32cbb0910281400p894d32cidac20aa450cf9391@mail.gmail.com>
	<1cd32cbb0910281515l2035fb0fjfb4ad8742095178e@mail.gmail.com>
	<dde7764a0910290228n601f42c0tb73ec096d7631119@mail.gmail.com>
	<1cd32cbb0910290733q1d034c03g3db530bb10bec564@mail.gmail.com>
	<dde7764a0910300745n5f6e67dfvd534bc6cccf9ba25@mail.gmail.com>
	<dde7764a0911150808g75574ebega794676309dbd55b@mail.gmail.com>
	<1cd32cbb0911151852h62b302f0g4449e9f1c7d7474a@mail.gmail.com>
Message-ID: <dde7764a0911160850i5eaf7445nd6526ba5f095a2f@mail.gmail.com>

Thanks for the review Josef.

On Mon, Nov 16, 2009 at 3:52 AM, <josef.pktd at gmail.com> wrote:

> Thanks, I took your version from github. Since there are many changes,
> including cosmetic, I didn't go over all of them. I compared several
> docstrings of the old and the new version, and overall it seems to work
> very well.
>
> The main mistake currently is that the generic docstring for discrete is
> the same as the one for the continuous distributions, e.g.
>
> print stats.poisson.__doc__
>
> discrete distributions don't have a scale argument, and don't have a pdf
> method, instead of pdf, discrete distributions have a pmf probability mass
> function.
>

fixed.

>
> Second, the generic class docstrings are pretty empty, e.g. they don't have
> the list of methods.
>
> print stats.distributions.rv_discrete.__doc__
> print stats.distributions.rv_continuous.__doc__
>
> What is missing is mainly info on how to subclass those two classes. I was
hoping you would fill in the blanks there since you know much more about how
this works than I do.

I do not think simply listing all methods is helpful, and that is also
explicitly discouraged in the doc standard.


> taste questions:
> I don't think I like the formulas in the methods, e.g. print
> stats.wald.__doc__
> I think, formulas from the extradocs should go into a notes section.
>

That does look a little better, done.

>
> I would also prefer to keep extradoc for now, even if it is not used
> anymore for the docstrings, just because I'm very used to using it. We
> can drop them later once the new system is fully working.
>

Sure, done.

>
> Given that there is more flexibility with the new system, I would
> prefer to put the extradoc information into a notes section instead of
> tucking them on at the end in the default template, if possible.
>
> Possible and done, looks much better now.


> Why did you special case before and after pdf?
>

Because the typical extradoc contains only info on the pdf. That info now
goes into Notes, so I removed before_pdf and after_pdf, and added
before_notes instead.

>
> Also, I think it would be better making the framework changes separate
> from any changes to the content, e.g rv_continuous, rv_discrete.


I'm not 100% sure what you mean here.

If everything works, we can edit and review changes to the content in the
> doc editor.
>

Yes, that would be ideal. It won't work just yet, but the next step is
indeed to get the doc editor to handle this intelligently.

>
> Sorry for the delay in the review, I've been busy and I have problems
> keeping up with the C changes in numpy and scipy.
>

No problem. I've had a few problems compiling things as well.


> (I only commented on the parts I didn't like so much, because the rest
> is a good improvement.)
>
>
I updated both the patch in ticket 1055 and the code on github. If you're
happy with the changes, can you please commit them?

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091116/748b8390/attachment.html>

From josef.pktd at gmail.com  Mon Nov 16 12:07:41 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Mon, 16 Nov 2009 12:07:41 -0500
Subject: [SciPy-dev] ndimage - docfiller and output_type
In-Reply-To: <dde7764a0911160850i5eaf7445nd6526ba5f095a2f@mail.gmail.com>
References: <dde7764a0910121251n5ac3a109n488416bb7d09ea82@mail.gmail.com>
	<dde7764a0910281316jf78ad8dr69ce853f3ed4b245@mail.gmail.com>
	<1cd32cbb0910281400p894d32cidac20aa450cf9391@mail.gmail.com>
	<1cd32cbb0910281515l2035fb0fjfb4ad8742095178e@mail.gmail.com>
	<dde7764a0910290228n601f42c0tb73ec096d7631119@mail.gmail.com>
	<1cd32cbb0910290733q1d034c03g3db530bb10bec564@mail.gmail.com>
	<dde7764a0910300745n5f6e67dfvd534bc6cccf9ba25@mail.gmail.com>
	<dde7764a0911150808g75574ebega794676309dbd55b@mail.gmail.com>
	<1cd32cbb0911151852h62b302f0g4449e9f1c7d7474a@mail.gmail.com>
	<dde7764a0911160850i5eaf7445nd6526ba5f095a2f@mail.gmail.com>
Message-ID: <1cd32cbb0911160907s70fc016dm1ae791a61e4fa65c@mail.gmail.com>

On Mon, Nov 16, 2009 at 11:50 AM, Ralf Gommers
<ralf.gommers at googlemail.com> wrote:
> Thanks for the review Josef.
>
> On Mon, Nov 16, 2009 at 3:52 AM, <josef.pktd at gmail.com> wrote:
>>
>> Thanks, I took your version from github. Since there are many changes,
>> including cosmetic, I didn't go over all of them. I compared several
>> docstrings of the old and the new version, and overall it seems to work
>> very well.
>>
>> The main mistake currently is that the generic docstring for discrete is
>> the same as the one for the continuous distributions, e.g.
>>
>> print stats.poisson.__doc__
>>
>> discrete distributions don't have a scale argument, and don't have a pdf
>> method, instead of pdf, discrete distributions have a pmf probability mass
>> function.
>
> fixed.
>>
>> Second, the generic class docstrings are pretty empty, e.g. they don't
>> have
>> the list of methods.
>>
>> print stats.distributions.rv_discrete.__doc__
>> print stats.distributions.rv_continuous.__doc__
>>
> What is missing is mainly info on how to subclass those two classes. I was
> hoping you would fill in the blanks there since you know much more about how
> this works than I do.
>
> I do not think simply listing all methods is helpful, and that is also
> explicitly discouraged in the doc standard.

see below

>
>>
>> taste questions:
>> I don't think I like the formulas in the methods, e.g. print
>> stats.wald.__doc__
>> I think, formulas from the extradocs should go into a notes section.
>
> That does look a little better, done.
>>
>> I would also prefer to keep extradoc for now, even if it is not used
>> anymore for the docstrings, just because I'm very used to using it. We
>> can drop them later once the new system is fully working.
>
> Sure, done.
>>
>> Given that there is more flexibility with the new system, I would
>> prefer to put the extradoc information into a notes section instead of
>> tucking them on at the end in the default template, if possible.
>>
> Possible and done, looks much better now.
>
>>
>> Why did you special case before and after pdf?
>
> Because the typical extradoc contains only info on the pdf. That info now
> goes into Notes, so I removed before_pdf and after_pdf, and added
> before_notes instead.
>>
>> Also, I think it would be better making the framework changes separate
>> from any changes to the content, e.g rv_continuous, rv_discrete.
>
> I'm not 100% sure what you mean here.

I meant keep the old docstring content of rv_continuous, rv_discrete and
edit the changes when I or someone has time to rewrite them.

In general it's better to have single purpose changesets, to keep track of
changes more easily, than making only partially related changes at the
same time.

>
>> If everything works, we can edit and review changes to the content in the
>> doc editor.
>
> Yes, that would be ideal. It won't work just yet, but the next step is
> indeed to get the doc editor to handle this intelligently.
>>
>> Sorry for the delay in the review, I've been busy and I have problems
>> keeping up with the C changes in numpy and scipy.
>
> No problem. I've had a few problems compiling things as well.
>
>>
>> (I only commented on the parts I didn't like so much, because the rest
>> is a good improvement.)
>>
>
> I updated both the patch in ticket 1055 and the code on github. If you're
> happy with the changes, can you please commit them?

I will try to do this tonight.
Did you try to rebuild the sphinx html docs to see whether they are
affected by the changes?

Thanks,

Josef

>
> Cheers,
> Ralf
>
>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From ralf.gommers at googlemail.com  Mon Nov 16 14:09:50 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Mon, 16 Nov 2009 20:09:50 +0100
Subject: [SciPy-dev] ndimage - docfiller and output_type
In-Reply-To: <1cd32cbb0911160907s70fc016dm1ae791a61e4fa65c@mail.gmail.com>
References: <dde7764a0910121251n5ac3a109n488416bb7d09ea82@mail.gmail.com>
	<1cd32cbb0910281400p894d32cidac20aa450cf9391@mail.gmail.com>
	<1cd32cbb0910281515l2035fb0fjfb4ad8742095178e@mail.gmail.com>
	<dde7764a0910290228n601f42c0tb73ec096d7631119@mail.gmail.com>
	<1cd32cbb0910290733q1d034c03g3db530bb10bec564@mail.gmail.com>
	<dde7764a0910300745n5f6e67dfvd534bc6cccf9ba25@mail.gmail.com>
	<dde7764a0911150808g75574ebega794676309dbd55b@mail.gmail.com>
	<1cd32cbb0911151852h62b302f0g4449e9f1c7d7474a@mail.gmail.com>
	<dde7764a0911160850i5eaf7445nd6526ba5f095a2f@mail.gmail.com>
	<1cd32cbb0911160907s70fc016dm1ae791a61e4fa65c@mail.gmail.com>
Message-ID: <dde7764a0911161109x354613ecx188c60fd4deec3d2@mail.gmail.com>

On Mon, Nov 16, 2009 at 6:07 PM, <josef.pktd at gmail.com> wrote:

> >> Also, I think it would be better making the framework changes separate
> >> from any changes to the content, e.g rv_continuous, rv_discrete.
> >
> > I'm not 100% sure what you mean here.
>
> I meant keep the old docstring content of rv_continuous, rv_discrete and
> edit the changes when I or someone has time to rewrite them.
>
> Well, I wrote it as far as I could. Still better than having an unused
template sticking around.


> In general it's better to have single purpose changesets, to keep track of
> changes more easily, than making only partially related changes at the
> same time.
>

I understand that, and in git I have about 10 more or less single-purpose
commits. But squashed into a single 1000-line diff it is a bit hard to keep
it single-purpose:)

>
> >
> >> If everything works, we can edit and review changes to the content in
> the
> >> doc editor.
> >
> > Yes, that would be ideal. It won't work just yet, but the next step is
> > indeed to get the doc editor to handle this intelligently.
> >>
> >> Sorry for the delay in the review, I've been busy and I have problems
> >> keeping up with the C changes in numpy and scipy.
> >
> > No problem. I've had a few problems compiling things as well.
> >
> >>
> >> (I only commented on the parts I didn't like so much, because the rest
> >> is a good improvement.)
> >>
> >
> > I updated both the patch in ticket 1055 and the code on github. If you're
> > happy with the changes, can you please commit them?
>
> I will try to do this tonight.
> Did you try to rebuild the sphinx html docs to see whether they are
> affected by the changes?
>
> I checked several docstrings with the preview function of the doc wiki,
looks good.

Can you build the scipy docs? The scipy/doc folder seems to be an incomplete
copy of numpy/doc, and the Makefile refers to non-existing files. I can
build the numpy docs so I do have all required tools for building.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091116/1a4441c3/attachment.html>

From jakevdp at gmail.com  Mon Nov 16 14:13:17 2009
From: jakevdp at gmail.com (Jake VanderPlas)
Date: Mon, 16 Nov 2009 11:13:17 -0800
Subject: [SciPy-dev] Ball Tree code (ticket 1048)
Message-ID: <58df6dc20911161113g426f0e22l84be822628c88372@mail.gmail.com>

I wrote to the list about this a couple weeks ago, but there hasn't
been any activity.  At the link below, there is a tarball with a
distutils setup script, and a simple script that compares the
performance of BallTree with scipy.spatial.cKDTree.  This is my first
submission to scipy - I'd love some feedback if you get a chance!
http://projects.scipy.org/scipy/ticket/1048
  -Jake


From dwf at cs.toronto.edu  Mon Nov 16 20:24:45 2009
From: dwf at cs.toronto.edu (David Warde-Farley)
Date: Mon, 16 Nov 2009 20:24:45 -0500
Subject: [SciPy-dev] Ball Tree code (ticket 1048)
In-Reply-To: <58df6dc20911161113g426f0e22l84be822628c88372@mail.gmail.com>
References: <58df6dc20911161113g426f0e22l84be822628c88372@mail.gmail.com>
Message-ID: <88AAD4E9-FAD2-49B6-9EFA-17B09A005E17@cs.toronto.edu>

Hi Jake,

It's been on my todo list for a while, since I'm frequently faced with  
problems that might benefit from such data structures. I'll try and  
get to it in the next few days.

David


On 16-Nov-09, at 2:13 PM, Jake VanderPlas wrote:

> I wrote to the list about this a couple weeks ago, but there hasn't
> been any activity.  At the link below, there is a tarball with a
> distutils setup script, and a simple script that compares the
> performance of BallTree with scipy.spatial.cKDTree.  This is my first
> submission to scipy - I'd love some feedback if you get a chance!
> http://projects.scipy.org/scipy/ticket/1048
>  -Jake
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev



From peridot.faceted at gmail.com  Mon Nov 16 20:49:21 2009
From: peridot.faceted at gmail.com (Anne Archibald)
Date: Mon, 16 Nov 2009 20:49:21 -0500
Subject: [SciPy-dev] Ball Tree code (ticket 1048)
In-Reply-To: <58df6dc20911161113g426f0e22l84be822628c88372@mail.gmail.com>
References: <58df6dc20911161113g426f0e22l84be822628c88372@mail.gmail.com>
Message-ID: <ce557a360911161749u514f8a47o90c99452d4738b02@mail.gmail.com>

2009/11/16 Jake VanderPlas <jakevdp at gmail.com>:
> I wrote to the list about this a couple weeks ago, but there hasn't
> been any activity. ?At the link below, there is a tarball with a
> distutils setup script, and a simple script that compares the
> performance of BallTree with scipy.spatial.cKDTree. ?This is my first
> submission to scipy - I'd love some feedback if you get a chance!
> http://projects.scipy.org/scipy/ticket/1048

I took a quick look at the code. I have a few comments:

* The code is specific to Euclidean distances.

* The code is specific to R**n.

* There's no approximate searching.

* The way the tree is constructed is very nearly a kd-tree: you
subdivide the dimension with the largest span. The only difference
between this and a kd-tree is that rather than store a cut plane at
each node, you store a ball containing the children of that node.

In principle, ball trees (and similar structures) can work on
arbitrary metric spaces. I don't know how important that feature is to
anyone; maybe anyone who needs such a thing needs a smarter algorithm
than ball trees (e.g. cover trees).

Given the last point above, I don't really understand why your code is
faster than cKDTree. Is the difference in how the tree is constructed
(I think cKDTree uses a different heuristic to find the cut plane) or
in the fact that you keep track of a ball containing each node? If the
former, then it might make more sense to add an option of  a different
heuristic to cKDTree. If the latter, it might make more sense to use a
different heuristic in the ball tree code - the traditional one is
partitioning the data into inside/outside a ball at each level of the
tree, which might allow faster construction, and faster search
(because the balls might shrink faster as you walk down the tree).

Overall, it's hard to argue with something that works and is faster in
concrete cases. But I'm not sure how general the code is.

Anne

> ?-Jake
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From sturla at molden.no  Tue Nov 17 06:45:41 2009
From: sturla at molden.no (Sturla Molden)
Date: Tue, 17 Nov 2009 12:45:41 +0100
Subject: [SciPy-dev] Ball Tree code (ticket 1048)
In-Reply-To: <ce557a360911161749u514f8a47o90c99452d4738b02@mail.gmail.com>
References: <58df6dc20911161113g426f0e22l84be822628c88372@mail.gmail.com>
	<ce557a360911161749u514f8a47o90c99452d4738b02@mail.gmail.com>
Message-ID: <4B028CE5.2090309@molden.no>


Anne Archibald skrev:
 >
 > * The code is specific to Euclidean distances.

I was wondering if we should try to loop-unroll minkowski distances in 
cKDTree? Right now it does a lot of wasteful for work for common cases 
like Euclidian distances.

I think this version should be rather friendly to autovectorizing 
compilers. It's easy to change the hard-coded values of k and p by 
editing minkowski.py.

Also, absolute values are computed by zeroing the sign bit, which is 
much faster.

Sturla Molden
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: minkowski.py
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091117/11df4b32/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: minkowski.pyx
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091117/11df4b32/attachment-0001.ksh>

From josef.pktd at gmail.com  Tue Nov 17 11:25:19 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Tue, 17 Nov 2009 11:25:19 -0500
Subject: [SciPy-dev] print in tests
Message-ID: <1cd32cbb0911170825ie96104ey9e1fee625e80f8e3@mail.gmail.com>

scipy.stats   vonmises.pyx has a print left in it, that creates a lot
of output when running the tests.

also
scipy\io\tests\test_wavfile.py  has a print

Josef


From josef.pktd at gmail.com  Tue Nov 17 11:36:40 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Tue, 17 Nov 2009 11:36:40 -0500
Subject: [SciPy-dev] testresults current trunk
Message-ID: <1cd32cbb0911170836w69e2f06ao65c227413d7ed658@mail.gmail.com>

2 errors 1 failure: anything new or just a consequence of my numpy
test failures ?

Josef

>python -c "import scipy; scipy.test()"
Running unit tests for scipy
NumPy version 1.4.0.dev7746
NumPy is installed in c:\programs\python25\lib\site-packages\numpy
SciPy version 0.8.0.dev6118
SciPy is installed in C:\Josef\_progs\Subversion\scipy-trunk_after\trunk\dist\sc
ipy-0.8.0.dev6118.win32\Programs\Python25\Lib\site-packages\scipy
Python version 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Int
el)]
nose version 0.11.1
nose.config: INFO: Excluding tests matching ['f2py_ext', 'f2py_f90_ext', 'gen_ex
t', 'pyrex_ext', 'swig_ext', 'array_from_pyobj']

ERROR: test_decomp.test_lapack_misaligned(<function solve at 0x01C55AF0>, (array
([[  1.734e-255,   8.189e-217,   4.025e-178,   1.903e-139,   9.344e-101,
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\case.p
y", line 183, in runTest
    self.test(*self.arg)
  File "C:\Josef\_progs\Subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6
118.win32\Programs\Python25\Lib\site-packages\scipy\linalg\tests\test_decomp.py"
, line 1106, in check_lapack_misaligned
    func(*a,**kwargs)
  File "\Programs\Python25\Lib\site-packages\scipy\linalg\basic.py", line 127, i
n solve
  File "\programs\python25\Lib\site-packages\numpy\lib\function_base.py", line 5
86, in asarray_chkfinite
    raise ValueError, "array must not contain infs or NaNs"
ValueError: array must not contain infs or NaNs

======================================================================
ERROR: test_mpmath.test_expi_complex
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\case.p
y", line 183, in runTest
    self.test(*self.arg)
  File "C:\Josef\_progs\Subversion\numpy-trunk\dist\numpy-1.4.0.dev7746.win32\pr
ograms\python25\Lib\site-packages\numpy\testing\decorators.py", line 143, in ski
pper_func
  File "C:\Josef\_progs\Subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6
118.win32\Programs\Python25\Lib\site-packages\scipy\special\tests\test_mpmath.py
", line 45, in test_expi_complex
    dataset = np.array(dataset, dtype=np.complex_)
TypeError: a float is required

======================================================================
FAIL: test_lambertw.test_values
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\case.p
y", line 183, in runTest
    self.test(*self.arg)
  File "C:\Josef\_progs\Subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6
118.win32\Programs\Python25\Lib\site-packages\scipy\special\tests\test_lambertw.
py", line 80, in test_values
    FuncData(w, data, (0,1), 2, rtol=1e-10, atol=1e-13).check()
  File "C:\Josef\_progs\Subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6
118.win32\Programs\Python25\Lib\site-packages\scipy\special\tests\testutils.py",
 line 187, in check
    assert False, "\n".join(msg)
AssertionError:
Max |adiff|: 2.5797
Max |rdiff|: 3.81511
Bad results for the following points (in output 0):
(-0.44800000000000001+0.40000000000000002j)                              0j => (
-1.2370928928166736-1.6588828572971361j) != (-0.11855133765652383+0.665705343135
83418j)  (rdiff             3.8151122286225245)

----------------------------------------------------------------------
Ran 4245 tests in 71.687s

FAILED (KNOWNFAIL=6, SKIP=33, errors=2, failures=1)


From jakevdp at gmail.com  Tue Nov 17 14:24:23 2009
From: jakevdp at gmail.com (Jake VanderPlas)
Date: Tue, 17 Nov 2009 11:24:23 -0800
Subject: [SciPy-dev] Ball Tree code (ticket 1048)
Message-ID: <58df6dc20911171124r18db97bet4cef6905a26f1690@mail.gmail.com>

> > I wrote to the list about this a couple weeks ago, but there hasn't
> > been any activity. ?At the link below, there is a tarball with a
> > distutils setup script, and a simple script that compares the
> > performance of BallTree with scipy.spatial.cKDTree. ?This is my first
> > submission to scipy - I'd love some feedback if you get a chance!
> > http://projects.scipy.org/scipy/ticket/1048

>I took a quick look at the code. I have a few comments:

>* The code is specific to Euclidean distances.

>* The code is specific to R**n.

>* There's no approximate searching.

>* The way the tree is constructed is very nearly a kd-tree: you
>subdivide the dimension with the largest span. The only difference
>between this and a kd-tree is that rather than store a cut plane at
>each node, you store a ball containing the children of that node.

>In principle, ball trees (and similar structures) can work on
>arbitrary metric spaces. I don't know how important that feature is to
>anyone; maybe anyone who needs such a thing needs a smarter algorithm
>than ball trees (e.g. cover trees).

>Given the last point above, I don't really understand why your code is
>faster than cKDTree. Is the difference in how the tree is constructed
>(I think cKDTree uses a different heuristic to find the cut plane) or
>in the fact that you keep track of a ball containing each node? If the
>former, then it might make more sense to add an option of  a different
>heuristic to cKDTree. If the latter, it might make more sense to use a
>different heuristic in the ball tree code - the traditional one is
>partitioning the data into inside/outside a ball at each level of the
>tree, which might allow faster construction, and faster search
>(because the balls might shrink faster as you walk down the tree).

>Overall, it's hard to argue with something that works and is faster in
>concrete cases. But I'm not sure how general the code is.

>Anne

True, the code is not very general.  I wrote it for a specific use
case, using the most general constuction algorithm in the paper linked
below.  Though it is constructed in a way similar to a KD tree, you
gain speed in traversing the tree because your nodes define a much
smaller region than the nodes in a KD-tree, especially as the
dimension gets very large.
You're correct in saying that a Ball Tree can be built upon a general
distance metric, as long as it satisfies the triangle inequality.  It
would be nice to be able to pass any distance metric, for instance one
of the scipy.spatial.distance functions, to use in the ball tree.  I
stopped short of this, because I didn't want to introduce the overhead
of a python function call within the search.  For my own application,
speed was much more important than generality.

We could make the Ball Tree more general without sacrificing speed -
what we would need is to have a library of C distance metrics, wrapped
by python, such that passing one of these functions to the search tree
wrapper would allow the optimized C code direct access to the C
function itself.  Perhaps something similar to the _cpointer attribute
of f2py functions?

paper link: ftp://ftp.icsi.berkeley.edu/pub/techreports/1989/tr-89-063.pdf

-Jake


From peridot.faceted at gmail.com  Tue Nov 17 16:01:08 2009
From: peridot.faceted at gmail.com (Anne Archibald)
Date: Tue, 17 Nov 2009 16:01:08 -0500
Subject: [SciPy-dev] testresults current trunk
In-Reply-To: <1cd32cbb0911170836w69e2f06ao65c227413d7ed658@mail.gmail.com>
References: <1cd32cbb0911170836w69e2f06ao65c227413d7ed658@mail.gmail.com>
Message-ID: <ce557a360911171301gf7673ccw927dd4a953567a23@mail.gmail.com>

2009/11/17  <josef.pktd at gmail.com>:
> 2 errors 1 failure: anything new or just a consequence of my numpy
> test failures ?

> ERROR: test_decomp.test_lapack_misaligned(<function solve at 0x01C55AF0>, (array
> ([[ ?1.734e-255, ? 8.189e-217, ? 4.025e-178, ? 1.903e-139, ? 9.344e-101,
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> ?File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\case.p
> y", line 183, in runTest
> ? ?self.test(*self.arg)
> ?File "C:\Josef\_progs\Subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6
> 118.win32\Programs\Python25\Lib\site-packages\scipy\linalg\tests\test_decomp.py"
> , line 1106, in check_lapack_misaligned
> ? ?func(*a,**kwargs)
> ?File "\Programs\Python25\Lib\site-packages\scipy\linalg\basic.py", line 127, i
> n solve
> ?File "\programs\python25\Lib\site-packages\numpy\lib\function_base.py", line 5
> 86, in asarray_chkfinite
> ? ?raise ValueError, "array must not contain infs or NaNs"
> ValueError: array must not contain infs or NaNs

That's weird - what architecture are you running the tests on? On my
machine I don't get any NaNs or  infs, but the array is made by
reinterpreting a byte array.

I'm not quite sure what the best way around this is, since the bug is
not always triggered if I supply sensible values.

Anne


From josef.pktd at gmail.com  Tue Nov 17 16:15:02 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Tue, 17 Nov 2009 16:15:02 -0500
Subject: [SciPy-dev] testresults current trunk
In-Reply-To: <ce557a360911171301gf7673ccw927dd4a953567a23@mail.gmail.com>
References: <1cd32cbb0911170836w69e2f06ao65c227413d7ed658@mail.gmail.com>
	<ce557a360911171301gf7673ccw927dd4a953567a23@mail.gmail.com>
Message-ID: <1cd32cbb0911171315i74938393l418742d34ba01415@mail.gmail.com>

On Tue, Nov 17, 2009 at 4:01 PM, Anne Archibald
<peridot.faceted at gmail.com> wrote:
> 2009/11/17 ?<josef.pktd at gmail.com>:
>> 2 errors 1 failure: anything new or just a consequence of my numpy
>> test failures ?
>
>> ERROR: test_decomp.test_lapack_misaligned(<function solve at 0x01C55AF0>, (array
>> ([[ ?1.734e-255, ? 8.189e-217, ? 4.025e-178, ? 1.903e-139, ? 9.344e-101,
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>> ?File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\case.p
>> y", line 183, in runTest
>> ? ?self.test(*self.arg)
>> ?File "C:\Josef\_progs\Subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6
>> 118.win32\Programs\Python25\Lib\site-packages\scipy\linalg\tests\test_decomp.py"
>> , line 1106, in check_lapack_misaligned
>> ? ?func(*a,**kwargs)
>> ?File "\Programs\Python25\Lib\site-packages\scipy\linalg\basic.py", line 127, i
>> n solve
>> ?File "\programs\python25\Lib\site-packages\numpy\lib\function_base.py", line 5
>> 86, in asarray_chkfinite
>> ? ?raise ValueError, "array must not contain infs or NaNs"
>> ValueError: array must not contain infs or NaNs
>
> That's weird - what architecture are you running the tests on? On my
> machine I don't get any NaNs or ?infs, but the array is made by
> reinterpreting a byte array.
>
> I'm not quite sure what the best way around this is, since the bug is
> not always triggered if I supply sensible values.

Windows XP notebook, Intel
I have several nan errors with the numpy test suite. So this might not
be a scipy problem if it doesn't happen on other machines. I never had
any problems with linalg and lapack, so it might be something that the
test uses.

Josef


>
> Anne
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From peridot.faceted at gmail.com  Tue Nov 17 16:16:59 2009
From: peridot.faceted at gmail.com (Anne Archibald)
Date: Tue, 17 Nov 2009 16:16:59 -0500
Subject: [SciPy-dev] print in tests
In-Reply-To: <1cd32cbb0911170825ie96104ey9e1fee625e80f8e3@mail.gmail.com>
References: <1cd32cbb0911170825ie96104ey9e1fee625e80f8e3@mail.gmail.com>
Message-ID: <ce557a360911171316w1badc83bh12602bb6707ac6bb@mail.gmail.com>

2009/11/17  <josef.pktd at gmail.com>:
> scipy.stats ? vonmises.pyx has a print left in it, that creates a lot
> of output when running the tests.

Oops. Fixed.

> also
> scipy\io\tests\test_wavfile.py ?has a print
>

More generally, though, should we assume people are going to be using
nosetests? If so, then stray prints are not a problem as long as they
are in the tests - they don't appear unless the test fails, in which
case they can be rather handy.

Anne

> Josef
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From peridot.faceted at gmail.com  Tue Nov 17 16:18:16 2009
From: peridot.faceted at gmail.com (Anne Archibald)
Date: Tue, 17 Nov 2009 16:18:16 -0500
Subject: [SciPy-dev] testresults current trunk
In-Reply-To: <1cd32cbb0911171315i74938393l418742d34ba01415@mail.gmail.com>
References: <1cd32cbb0911170836w69e2f06ao65c227413d7ed658@mail.gmail.com>
	<ce557a360911171301gf7673ccw927dd4a953567a23@mail.gmail.com>
	<1cd32cbb0911171315i74938393l418742d34ba01415@mail.gmail.com>
Message-ID: <ce557a360911171318n184c2e4eqd784359b025c5d56@mail.gmail.com>

2009/11/17  <josef.pktd at gmail.com>:
> On Tue, Nov 17, 2009 at 4:01 PM, Anne Archibald
> <peridot.faceted at gmail.com> wrote:
>> 2009/11/17 ?<josef.pktd at gmail.com>:
>>> 2 errors 1 failure: anything new or just a consequence of my numpy
>>> test failures ?
>>
>>> ERROR: test_decomp.test_lapack_misaligned(<function solve at 0x01C55AF0>, (array
>>> ([[ ?1.734e-255, ? 8.189e-217, ? 4.025e-178, ? 1.903e-139, ? 9.344e-101,
>>> ----------------------------------------------------------------------
>>> Traceback (most recent call last):
>>> ?File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\case.p
>>> y", line 183, in runTest
>>> ? ?self.test(*self.arg)
>>> ?File "C:\Josef\_progs\Subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6
>>> 118.win32\Programs\Python25\Lib\site-packages\scipy\linalg\tests\test_decomp.py"
>>> , line 1106, in check_lapack_misaligned
>>> ? ?func(*a,**kwargs)
>>> ?File "\Programs\Python25\Lib\site-packages\scipy\linalg\basic.py", line 127, i
>>> n solve
>>> ?File "\programs\python25\Lib\site-packages\numpy\lib\function_base.py", line 5
>>> 86, in asarray_chkfinite
>>> ? ?raise ValueError, "array must not contain infs or NaNs"
>>> ValueError: array must not contain infs or NaNs
>>
>> That's weird - what architecture are you running the tests on? On my
>> machine I don't get any NaNs or ?infs, but the array is made by
>> reinterpreting a byte array.
>>
>> I'm not quite sure what the best way around this is, since the bug is
>> not always triggered if I supply sensible values.
>
> Windows XP notebook, Intel

64-bit or 32?

> I have several nan errors with the numpy test suite. So this might not
> be a scipy problem if it doesn't happen on other machines. I never had
> any problems with linalg and lapack, so it might be something that the
> test uses.

The test does feed in outrageous values. What LAPACK are you using?

Anne

> Josef
>
>
>>
>> Anne
>> _______________________________________________
>> Scipy-dev mailing list
>> Scipy-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From dwf at cs.toronto.edu  Tue Nov 17 16:27:04 2009
From: dwf at cs.toronto.edu (David Warde-Farley)
Date: Tue, 17 Nov 2009 16:27:04 -0500
Subject: [SciPy-dev] Ball Tree code (ticket 1048)
In-Reply-To: <58df6dc20911171124r18db97bet4cef6905a26f1690@mail.gmail.com>
References: <58df6dc20911171124r18db97bet4cef6905a26f1690@mail.gmail.com>
Message-ID: <5E7D7219-F770-41E5-9E9A-6CBB6870708B@cs.toronto.edu>


On 17-Nov-09, at 2:24 PM, Jake VanderPlas wrote:

> We could make the Ball Tree more general without sacrificing speed -
> what we would need is to have a library of C distance metrics, wrapped
> by python, such that passing one of these functions to the search tree
> wrapper would allow the optimized C code direct access to the C
> function itself.  Perhaps something similar to the _cpointer attribute
> of f2py functions?

There is C code already written for this, at least the distance  
functions themselves, in spatial/src/distance.c. Not sure about the  
wrapping situation.

David


From josef.pktd at gmail.com  Tue Nov 17 16:28:55 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Tue, 17 Nov 2009 16:28:55 -0500
Subject: [SciPy-dev] print in tests
In-Reply-To: <ce557a360911171316w1badc83bh12602bb6707ac6bb@mail.gmail.com>
References: <1cd32cbb0911170825ie96104ey9e1fee625e80f8e3@mail.gmail.com>
	<ce557a360911171316w1badc83bh12602bb6707ac6bb@mail.gmail.com>
Message-ID: <1cd32cbb0911171328k6136b284u8e87eff57e9442e8@mail.gmail.com>

On Tue, Nov 17, 2009 at 4:16 PM, Anne Archibald
<peridot.faceted at gmail.com> wrote:
> 2009/11/17 ?<josef.pktd at gmail.com>:
>> scipy.stats ? vonmises.pyx has a print left in it, that creates a lot
>> of output when running the tests.
>
> Oops. Fixed.
>
>> also
>> scipy\io\tests\test_wavfile.py ?has a print
>>
>
> More generally, though, should we assume people are going to be using
> nosetests? If so, then stray prints are not a problem as long as they
> are in the tests - they don't appear unless the test fails, in which
> case they can be rather handy.

The advertised is scipy.test() , scipy.stats.test(). I almost never use
nosetests directly, unless I target very specific tests.
scipy.test() prints so much on the command line that I loose the beginning.

Josef
>
> Anne
>
>> Josef
>> _______________________________________________
>> Scipy-dev mailing list
>> Scipy-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From robert.kern at gmail.com  Tue Nov 17 16:27:05 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 17 Nov 2009 15:27:05 -0600
Subject: [SciPy-dev] print in tests
In-Reply-To: <ce557a360911171316w1badc83bh12602bb6707ac6bb@mail.gmail.com>
References: <1cd32cbb0911170825ie96104ey9e1fee625e80f8e3@mail.gmail.com> 
	<ce557a360911171316w1badc83bh12602bb6707ac6bb@mail.gmail.com>
Message-ID: <3d375d730911171327j363e51e6ra5389abcd346731b@mail.gmail.com>

On Tue, Nov 17, 2009 at 15:16, Anne Archibald <peridot.faceted at gmail.com> wrote:
> 2009/11/17 ?<josef.pktd at gmail.com>:

>> also
>> scipy\io\tests\test_wavfile.py ?has a print
>
> More generally, though, should we assume people are going to be using
> nosetests? If so, then stray prints are not a problem as long as they
> are in the tests - they don't appear unless the test fails, in which
> case they can be rather handy.

We should assume people are going to be using nosetest.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From josef.pktd at gmail.com  Tue Nov 17 16:39:00 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Tue, 17 Nov 2009 16:39:00 -0500
Subject: [SciPy-dev] testresults current trunk
In-Reply-To: <ce557a360911171318n184c2e4eqd784359b025c5d56@mail.gmail.com>
References: <1cd32cbb0911170836w69e2f06ao65c227413d7ed658@mail.gmail.com>
	<ce557a360911171301gf7673ccw927dd4a953567a23@mail.gmail.com>
	<1cd32cbb0911171315i74938393l418742d34ba01415@mail.gmail.com>
	<ce557a360911171318n184c2e4eqd784359b025c5d56@mail.gmail.com>
Message-ID: <1cd32cbb0911171339w785f301bk55f83f4b2580e1f@mail.gmail.com>

On Tue, Nov 17, 2009 at 4:18 PM, Anne Archibald
<peridot.faceted at gmail.com> wrote:
> 2009/11/17 ?<josef.pktd at gmail.com>:
>> On Tue, Nov 17, 2009 at 4:01 PM, Anne Archibald
>> <peridot.faceted at gmail.com> wrote:
>>> 2009/11/17 ?<josef.pktd at gmail.com>:
>>>> 2 errors 1 failure: anything new or just a consequence of my numpy
>>>> test failures ?
>>>
>>>> ERROR: test_decomp.test_lapack_misaligned(<function solve at 0x01C55AF0>, (array
>>>> ([[ ?1.734e-255, ? 8.189e-217, ? 4.025e-178, ? 1.903e-139, ? 9.344e-101,
>>>> ----------------------------------------------------------------------
>>>> Traceback (most recent call last):
>>>> ?File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\case.p
>>>> y", line 183, in runTest
>>>> ? ?self.test(*self.arg)
>>>> ?File "C:\Josef\_progs\Subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6
>>>> 118.win32\Programs\Python25\Lib\site-packages\scipy\linalg\tests\test_decomp.py"
>>>> , line 1106, in check_lapack_misaligned
>>>> ? ?func(*a,**kwargs)
>>>> ?File "\Programs\Python25\Lib\site-packages\scipy\linalg\basic.py", line 127, i
>>>> n solve
>>>> ?File "\programs\python25\Lib\site-packages\numpy\lib\function_base.py", line 5
>>>> 86, in asarray_chkfinite
>>>> ? ?raise ValueError, "array must not contain infs or NaNs"
>>>> ValueError: array must not contain infs or NaNs
>>>
>>> That's weird - what architecture are you running the tests on? On my
>>> machine I don't get any NaNs or ?infs, but the array is made by
>>> reinterpreting a byte array.
>>>
>>> I'm not quite sure what the best way around this is, since the bug is
>>> not always triggered if I supply sensible values.
>>
>> Windows XP notebook, Intel
>
> 64-bit or 32?

32 single core pretty old

>
>> I have several nan errors with the numpy test suite. So this might not
>> be a scipy problem if it doesn't happen on other machines. I never had
>> any problems with linalg and lapack, so it might be something that the
>> test uses.
>
> The test does feed in outrageous values. What LAPACK are you using?

A (very) old ATLAS from the scipy website. It doesn't show the version info,
at least not without a lot of searching.

Josef

>
> Anne
>
>> Josef
>>
>>
>>>
>>> Anne
>>> _______________________________________________
>>> Scipy-dev mailing list
>>> Scipy-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>>
>> _______________________________________________
>> Scipy-dev mailing list
>> Scipy-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From robert.kern at gmail.com  Tue Nov 17 16:32:42 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 17 Nov 2009 15:32:42 -0600
Subject: [SciPy-dev] print in tests
In-Reply-To: <1cd32cbb0911171328k6136b284u8e87eff57e9442e8@mail.gmail.com>
References: <1cd32cbb0911170825ie96104ey9e1fee625e80f8e3@mail.gmail.com> 
	<ce557a360911171316w1badc83bh12602bb6707ac6bb@mail.gmail.com> 
	<1cd32cbb0911171328k6136b284u8e87eff57e9442e8@mail.gmail.com>
Message-ID: <3d375d730911171332t5778b180gd7de7c7bdcf7c87a@mail.gmail.com>

On Tue, Nov 17, 2009 at 15:28,  <josef.pktd at gmail.com> wrote:
> On Tue, Nov 17, 2009 at 4:16 PM, Anne Archibald
> <peridot.faceted at gmail.com> wrote:
>> 2009/11/17 ?<josef.pktd at gmail.com>:
>>> scipy.stats ? vonmises.pyx has a print left in it, that creates a lot
>>> of output when running the tests.
>>
>> Oops. Fixed.
>>
>>> also
>>> scipy\io\tests\test_wavfile.py ?has a print
>>>
>>
>> More generally, though, should we assume people are going to be using
>> nosetests? If so, then stray prints are not a problem as long as they
>> are in the tests - they don't appear unless the test fails, in which
>> case they can be rather handy.
>
> The advertised is scipy.test() , scipy.stats.test(). I almost never use
> nosetests directly, unless I target very specific tests.

It doesn't matter. Those functions use nosetests.

> scipy.test() prints so much on the command line that I loose the beginning.

Why would you lose the beginning? Just bump up the number of lines
that are retained by the command window.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From rcsqtc at iqac.csic.es  Wed Nov 18 04:23:38 2009
From: rcsqtc at iqac.csic.es (Ramon Crehuet)
Date: Wed, 18 Nov 2009 10:23:38 +0100
Subject: [SciPy-dev] Uploading attachments in scipy.org
Message-ID: <4B03BD1A.1080409@iqac.csic.es>

Hi all,
I few days ago I posted a question and I have not received any answer. I
have modified the Performance Python page, introducing new examples with
fortran 90.

I do not know how to upload attached files (the .tgz with all programs).
This is important because the page is now inconsistent (the .tgz does
not contain the new additions).

If this is not the right place to ask this question, can you suggest a
better one?

Thanks again!

Ramon


From scott.sinclair.za at gmail.com  Wed Nov 18 06:28:52 2009
From: scott.sinclair.za at gmail.com (Scott Sinclair)
Date: Wed, 18 Nov 2009 13:28:52 +0200
Subject: [SciPy-dev] Uploading attachments in scipy.org
In-Reply-To: <4B03BD1A.1080409@iqac.csic.es>
References: <4B03BD1A.1080409@iqac.csic.es>
Message-ID: <6a17e9ee0911180328w2a7b3245n671620829f75d6f8@mail.gmail.com>

>2009/11/18 Ramon Crehuet <rcsqtc at iqac.csic.es>:
> I few days ago I posted a question and I have not received any answer.

Um...

http://mail.scipy.org/pipermail/scipy-dev/2009-November/013318.html

Cheers,
Scott


From sturla at molden.no  Wed Nov 18 07:21:15 2009
From: sturla at molden.no (Sturla Molden)
Date: Wed, 18 Nov 2009 13:21:15 +0100
Subject: [SciPy-dev] Uploading attachments in scipy.org
In-Reply-To: <4B03BD1A.1080409@iqac.csic.es>
References: <4B03BD1A.1080409@iqac.csic.es>
Message-ID: <4B03E6BB.4040805@molden.no>

Ramon Crehuet skrev:
> Hi all,
> I few days ago I posted a question and I have not received any answer. I
> have modified the Performance Python page, introducing new examples with
> fortran 90.

I think the Performance Python page needs a Cython version as well.

Sturla Molden





import numpy as np
cimport numpy as np
cimport cython
import laplace

cdef extern from "math.h":
    double sqrt(double)

class LaplaceSolver(laplace.LaplaceSolver):

    @cython.wraparound(False)
    @cython.boundscheck(False)
    def cythonTimeStep(self, dt=0.0):

        cdef np.ndarray[double, ndim=2, mode="c"] u
        cdef double dx2, dy2, dnr_inv, diff, tmp, err
        cdef int nx, ny, i, j

        g = self.grid
        u = g.u
        nx = u.shape[0]
        ny = u.shape[1]
        dx2 = g.dx**2
        dy2 = g.dy**2
        dnr_inv = 0.5/(dx2 + dy2)

        err = 0.0
        for i in range(1, nx-1):
            for j in range(1, ny-1):
                tmp = u[i,j]
                u[i,j] = ((u[i-1, j] + u[i+1, j])*dy2 +
                    (u[i, j-1] + u[i, j+1])*dx2)*dnr_inv
                diff = u[i,j] - tmp
                err += diff*diff

        return float(sqrt(err))





From sturla at molden.no  Wed Nov 18 07:35:27 2009
From: sturla at molden.no (Sturla Molden)
Date: Wed, 18 Nov 2009 13:35:27 +0100
Subject: [SciPy-dev] Uploading attachments in scipy.org
In-Reply-To: <4B03BD1A.1080409@iqac.csic.es>
References: <4B03BD1A.1080409@iqac.csic.es>
Message-ID: <4B03EA0F.2030409@molden.no>

Ramon Crehuet skrev:
> Hi all,
> I few days ago I posted a question and I have not received any answer. I
> have modified the Performance Python page, introducing new examples with
> fortran 90.
>   
By the way: It is important that the measurements are taken on the same 
computer. For example, if you claim you Fortran 90 code is twice as fast 
a Pearu's Fortran 77, then that should not reflect differences in 
hardware, compiler, compiler flags, etc. I see no reason why Fortran 90 
should be faster than Fortran 77.

The same goes for the MATLAB and Octave measurements.


Sturla










From millman at berkeley.edu  Wed Nov 18 15:44:15 2009
From: millman at berkeley.edu (Jarrod Millman)
Date: Wed, 18 Nov 2009 12:44:15 -0800
Subject: [SciPy-dev] scipy bzr mirror
Message-ID: <c7009a550911181244i1a713f50t321924f86789fb22@mail.gmail.com>

Launchpad is now mirroring the scipy svn trunk:
https://code.launchpad.net/~vcs-imports/scipy/trunk

Cheers,

-- 
Jarrod Millman
Helen Wills Neuroscience Institute
10 Giannini Hall, UC Berkeley
http://cirl.berkeley.edu/


From oliphant at enthought.com  Wed Nov 18 23:45:16 2009
From: oliphant at enthought.com (Travis Oliphant)
Date: Wed, 18 Nov 2009 22:45:16 -0600
Subject: [SciPy-dev] Inclusion of Kuiper test in Scipy
In-Reply-To: <ce557a360911020650h2f6c883crf67f5b808aa4eab8@mail.gmail.com>
References: <ce557a360911020650h2f6c883crf67f5b808aa4eab8@mail.gmail.com>
Message-ID: <F1909C5B-A834-4DE2-867D-79219AF744BD@enthought.com>


On Nov 2, 2009, at 8:50 AM, Anne Archibald wrote:

> Hi,
>
> I have implemented a statistical test from the literature, the Kuiper
> test, for my own work, but I think it might be worth including it in
> Scipy itself. I'd like to hear other people's opinions, though, both
> on what (if anything) should go into scipy, and on whether it needs
> modification. The code is at:
>
> http://github.com/aarchiba/kuiper
>
> This code includes a number of things beyond the basic test, some or
> all of which may not be worth including in Scipy. What's there:
>
> The Kuiper test - analogous to the Kolmogorov-Smirnov test, this takes
> either a sample and a callable CDF or two samples and returns an
> abstract score and the probability that a score that large would have
> arisen if the two arguments are from the same distribution. This test
> is sensitive to somewhat different features of the distribution than
> the K-S test, and, importantly, it is invariant under cyclic
> permutation: that is, if all the samples and distribution are modulo
> (say) 1, then any shift in both arguments leaves the value unaffected.
> Thus it is well suited to periodic distributions.
>
> The Z_m^2 test - a test for uniformity on [0,1) based on the first m
> Fourier coefficients. Returns a score and the probability of a score
> that large.
>
> The H test - a test that uses a data-dependent number of harmonics to
> test for uniformity. Returns the score and the probability, and also
> the number of harmonics that gave the most significant detection.
>
> fold_intervals - a function to take a series of weighted intervals and
> return the total exposure of each phase modulo 1. For testing for
> uniformity when you have more data from some phases than others.
> cdf_from_intervals - a function to construct a piecewise-linear CDF
> from a set of exposures (as returned by the above function).
> histogram_intervals - A function to evaluate how much exposure each
> histogram bin received, to allow testing for uniformity using a
> histogram in the presence of non-uniform exposure.
>
> There are also a couple of handy decorators in the test suite:
>
> seed - set the random seed before running a test
> double_check - for randomized tests: run once, and if it fails, run  
> it again.
>
> All have tests and somewhat informative docstrings, but I suspect some
> of them may be too specialized to be of much use. The Kuiper test
> should have wide applicability; the Z_m^2 test and H test, not so
> much, although they are handy when testinf gor periodicity. The last
> batch of utility functions I'm not sure are general enough to be very
> useful, but I needed them.
>
> What do you think? How much of this would be useful in Scipy?


I'm sure the Kuiper test is of interest and perhaps some of the others  
as well.   I was hoping Josef or Robert would chime in.  I would be  
interested in these additions, though I don't have time to review  
them.    If you could post them as a patch on the tracker that would  
be great.

-Travis



From nwagner at iam.uni-stuttgart.de  Thu Nov 19 12:56:55 2009
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Thu, 19 Nov 2009 18:56:55 +0100
Subject: [SciPy-dev] scipy.test() segfaults
Message-ID: <web-127252972@uni-stuttgart.de>

Hi all,

  >>> import scipy
>>> scipy.test()
Running unit tests for scipy
NumPy version 1.4.0.dev7749
NumPy is installed in 
/data/home/nwagner/local/lib/python2.5/site-packages/numpy
SciPy version 0.8.0.dev6119
SciPy is installed in 
/data/home/nwagner/local/lib/python2.5/site-packages/scipy
Python version 2.5.1 (r251:54863, Dec 21 2007, 09:21:07) 
[GCC 3.4.6 20060404 (Red Hat 3.4.6-3)]
nose version 0.11.1
Detaching after fork from child process 18306.
Detaching after fork from child process 18307.
Detaching after fork from child process 18308.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 182894199840 (LWP 18217)]
0x0000002a987a8843 in PyArray_SetDatetimeParseFunction 
(op=0x2) at numpy/core/src/multiarray/arrayobject.c:357
357         Py_XINCREF(op);

Any idea ? I have installed numpy and scipy from scratch.

Nils


From pav at iki.fi  Thu Nov 19 14:32:02 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Thu, 19 Nov 2009 21:32:02 +0200
Subject: [SciPy-dev] scipy.test() segfaults
In-Reply-To: <web-127252972@uni-stuttgart.de>
References: <web-127252972@uni-stuttgart.de>
Message-ID: <1258659121.6439.1.camel@idol>

to, 2009-11-19 kello 18:56 +0100, Nils Wagner kirjoitti:
> Hi all,
> 
>   >>> import scipy
> >>> scipy.test()

Run it with

	scipy.test(verbose=2)

We need to see which test segfaults.

-- 
Pauli Virtanen




From charlesr.harris at gmail.com  Thu Nov 19 14:47:13 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Thu, 19 Nov 2009 12:47:13 -0700
Subject: [SciPy-dev] scipy.test() segfaults
In-Reply-To: <web-127252972@uni-stuttgart.de>
References: <web-127252972@uni-stuttgart.de>
Message-ID: <e06186140911191147t763133b7wbf1a33a65ca8bad3@mail.gmail.com>

On Thu, Nov 19, 2009 at 10:56 AM, Nils Wagner
<nwagner at iam.uni-stuttgart.de>wrote:

> Hi all,
>
>  >>> import scipy
> >>> scipy.test()
> Running unit tests for scipy
> NumPy version 1.4.0.dev7749
> NumPy is installed in
> /data/home/nwagner/local/lib/python2.5/site-packages/numpy
> SciPy version 0.8.0.dev6119
> SciPy is installed in
> /data/home/nwagner/local/lib/python2.5/site-packages/scipy
> Python version 2.5.1 (r251:54863, Dec 21 2007, 09:21:07)
> [GCC 3.4.6 20060404 (Red Hat 3.4.6-3)]
> nose version 0.11.1
> Detaching after fork from child process 18306.
> Detaching after fork from child process 18307.
> Detaching after fork from child process 18308.
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 182894199840 (LWP 18217)]
> 0x0000002a987a8843 in PyArray_SetDatetimeParseFunction
> (op=0x2) at numpy/core/src/multiarray/arrayobject.c:357
> 357         Py_XINCREF(op);
>
> Any idea ? I have installed numpy and scipy from scratch.
>
>
Travis just made some commits to numpy involving datetime. What version are
you using?

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091119/ed94e561/attachment.html>

From charlesr.harris at gmail.com  Thu Nov 19 14:49:27 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Thu, 19 Nov 2009 12:49:27 -0700
Subject: [SciPy-dev] scipy.test() segfaults
In-Reply-To: <e06186140911191147t763133b7wbf1a33a65ca8bad3@mail.gmail.com>
References: <web-127252972@uni-stuttgart.de>
	<e06186140911191147t763133b7wbf1a33a65ca8bad3@mail.gmail.com>
Message-ID: <e06186140911191149l2ba81888y45ca7e0ed9b986dc@mail.gmail.com>

On Thu, Nov 19, 2009 at 12:47 PM, Charles R Harris <
charlesr.harris at gmail.com> wrote:

>
>
> On Thu, Nov 19, 2009 at 10:56 AM, Nils Wagner <
> nwagner at iam.uni-stuttgart.de> wrote:
>
>> Hi all,
>>
>>  >>> import scipy
>> >>> scipy.test()
>> Running unit tests for scipy
>> NumPy version 1.4.0.dev7749
>> NumPy is installed in
>> /data/home/nwagner/local/lib/python2.5/site-packages/numpy
>> SciPy version 0.8.0.dev6119
>> SciPy is installed in
>> /data/home/nwagner/local/lib/python2.5/site-packages/scipy
>> Python version 2.5.1 (r251:54863, Dec 21 2007, 09:21:07)
>> [GCC 3.4.6 20060404 (Red Hat 3.4.6-3)]
>> nose version 0.11.1
>> Detaching after fork from child process 18306.
>> Detaching after fork from child process 18307.
>> Detaching after fork from child process 18308.
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 182894199840 (LWP 18217)]
>> 0x0000002a987a8843 in PyArray_SetDatetimeParseFunction
>> (op=0x2) at numpy/core/src/multiarray/arrayobject.c:357
>> 357         Py_XINCREF(op);
>>
>> Any idea ? I have installed numpy and scipy from scratch.
>>
>>
> Travis just made some commits to numpy involving datetime. What version are
> you using?
>
>
Checkout numpy r7047 and see if the problems persist. The following three
revisions are from Travis.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091119/81e0b431/attachment.html>

From jdh2358 at gmail.com  Fri Nov 20 13:20:02 2009
From: jdh2358 at gmail.com (John Hunter)
Date: Fri, 20 Nov 2009 10:20:02 -0800
Subject: [SciPy-dev] scipy.org servers *slow*
Message-ID: <88e473830911201020j3e0799dbo883d1eca32fd7892@mail.gmail.com>

I am trying to do some svn checkouts of numpy and scipy, as well as
get the latest tarball release of ipython. and things are coming down
from scipy.org at a snail's pace.  I've tried this from three client
sides across the US on fast ethernet etc, so I think it is a server
side problem.

My ipython download has been going for several minutes and still has a
4 min ETA, for example, and my numpy and scipy checkouts are slowly
chugging along but are not finished after an unreasonably long time.

> time wget http://ipython.scipy.org/dist/ipython-0.10.tar.gz


JDH


From fperez.net at gmail.com  Fri Nov 20 15:14:10 2009
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 20 Nov 2009 12:14:10 -0800
Subject: [SciPy-dev] scipy.org servers *slow*
In-Reply-To: <88e473830911201020j3e0799dbo883d1eca32fd7892@mail.gmail.com>
References: <88e473830911201020j3e0799dbo883d1eca32fd7892@mail.gmail.com>
Message-ID: <db6b5ecc0911201214x211c37eav3faee80c62466c1e@mail.gmail.com>

On Fri, Nov 20, 2009 at 10:20 AM, John Hunter <jdh2358 at gmail.com> wrote:
> I am trying to do some svn checkouts of numpy and scipy, as well as
> get the latest tarball release of ipython. and things are coming down
> from scipy.org at a snail's pace. ?I've tried this from three client
> sides across the US on fast ethernet etc, so I think it is a server
> side problem.

FWIW, it seems now that scipy.org is down over http.  I was able to do
an svn update of numpy, but it was very slow (it seemed to hang for a
while, and eventually completed).

Cheers,

f


From robert.kern at gmail.com  Fri Nov 20 15:29:15 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 20 Nov 2009 14:29:15 -0600
Subject: [SciPy-dev] scipy.org servers *slow*
In-Reply-To: <db6b5ecc0911201214x211c37eav3faee80c62466c1e@mail.gmail.com>
References: <88e473830911201020j3e0799dbo883d1eca32fd7892@mail.gmail.com> 
	<db6b5ecc0911201214x211c37eav3faee80c62466c1e@mail.gmail.com>
Message-ID: <3d375d730911201229uff0be19xc33c0fdb5d530d8@mail.gmail.com>

On Fri, Nov 20, 2009 at 14:14, Fernando Perez <fperez.net at gmail.com> wrote:
> On Fri, Nov 20, 2009 at 10:20 AM, John Hunter <jdh2358 at gmail.com> wrote:
>> I am trying to do some svn checkouts of numpy and scipy, as well as
>> get the latest tarball release of ipython. and things are coming down
>> from scipy.org at a snail's pace. ?I've tried this from three client
>> sides across the US on fast ethernet etc, so I think it is a server
>> side problem.
>
> FWIW, it seems now that scipy.org is down over http. ?I was able to do
> an svn update of numpy, but it was very slow (it seemed to hang for a
> while, and eventually completed).

It seems to be up for me, both inside and outside of our network. It
is possible that our IT guy bounced the server while working on the
slowness just as you checked it.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From fperez.net at gmail.com  Fri Nov 20 15:54:23 2009
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 20 Nov 2009 12:54:23 -0800
Subject: [SciPy-dev] scipy.org servers *slow*
In-Reply-To: <3d375d730911201229uff0be19xc33c0fdb5d530d8@mail.gmail.com>
References: <88e473830911201020j3e0799dbo883d1eca32fd7892@mail.gmail.com> 
	<db6b5ecc0911201214x211c37eav3faee80c62466c1e@mail.gmail.com> 
	<3d375d730911201229uff0be19xc33c0fdb5d530d8@mail.gmail.com>
Message-ID: <db6b5ecc0911201254wfd35426s55caa664c7f4d079@mail.gmail.com>

On Fri, Nov 20, 2009 at 12:29 PM, Robert Kern <robert.kern at gmail.com> wrote:
> It seems to be up for me, both inside and outside of our network. It
> is possible that our IT guy bounced the server while working on the
> slowness just as you checked it.

Ah, I just tried again and now noticed:

www.scipy.org -> OK
scipy.org -> Times out for me, though it works for John (next to me,
same ISP, same ubuntu version).

No idea why the non-www site is timing out, but if it's just me, no worries.

Cheers,

f


From robert.kern at gmail.com  Fri Nov 20 16:09:23 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 20 Nov 2009 15:09:23 -0600
Subject: [SciPy-dev] scipy.org servers *slow*
In-Reply-To: <db6b5ecc0911201254wfd35426s55caa664c7f4d079@mail.gmail.com>
References: <88e473830911201020j3e0799dbo883d1eca32fd7892@mail.gmail.com> 
	<db6b5ecc0911201214x211c37eav3faee80c62466c1e@mail.gmail.com> 
	<3d375d730911201229uff0be19xc33c0fdb5d530d8@mail.gmail.com> 
	<db6b5ecc0911201254wfd35426s55caa664c7f4d079@mail.gmail.com>
Message-ID: <3d375d730911201309k7bf84d3dg7807c8566105f176@mail.gmail.com>

On Fri, Nov 20, 2009 at 14:54, Fernando Perez <fperez.net at gmail.com> wrote:
> On Fri, Nov 20, 2009 at 12:29 PM, Robert Kern <robert.kern at gmail.com> wrote:
>> It seems to be up for me, both inside and outside of our network. It
>> is possible that our IT guy bounced the server while working on the
>> slowness just as you checked it.
>
> Ah, I just tried again and now noticed:
>
> www.scipy.org -> OK
> scipy.org -> Times out for me, though it works for John (next to me,
> same ISP, same ubuntu version).
>
> No idea why the non-www site is timing out, but if it's just me, no worries.

It's working for me (outside of the Enthought network). Try flushing
your DNS cache.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From it at enthought.com  Sun Nov 22 13:39:31 2009
From: it at enthought.com (Aaron River via Support)
Date: Sun, 22 Nov 2009 12:39:31 -0600
Subject: [SciPy-dev] [IT #734] SciPy.org Server is SLOW (via SciPy-Dev)
In-Reply-To: <rt-3.8.1-20619-1258742135-417.734-6-0@enthought.com>
References: <RT-Ticket-734@enthought.com>
	<88e473830911201020j3e0799dbo883d1eca32fd7892@mail.gmail.com>
	<3d375d730911201026j2f77c7c0ub08d582088eddf63@mail.gmail.com>
	<rt-3.8.1-20591-1258741590-899.734-4-0@enthought.com>
	<0672A177-0D59-4606-B2F0-5B9301D0DB48@enthought.com>
	<rt-3.8.1-20619-1258742135-417.734-6-0@enthought.com>
Message-ID: <rt-3.8.1-604-1258915171-636.734-6-0@enthought.com>

I tracked this down to a mirror we host on scipy.org.
I've set bandwidth restrictions for this mirror.

Thanks,

--
Aaron

> From: John Hunter <jdh2358 at gmail.com>
> Date: Fri, Nov 20, 2009 at 12:20
> Subject: [SciPy-dev] scipy.org servers *slow*
> To: SciPy Developers List <scipy-dev at scipy.org>
> 
> I am trying to do some svn checkouts of numpy and scipy, as well as
> get the latest tarball release of ipython. and things are coming down
> from scipy.org at a snail's pace.  I've tried this from three client
> sides across the US on fast ethernet etc, so I think it is a server
> side problem.
> 
> My ipython download has been going for several minutes and still has a
> 4 min ETA, for example, and my numpy and scipy checkouts are slowly
> chugging along but are not finished after an unreasonably long time.
> 
>> time wget http://ipython.scipy.org/dist/ipython-0.10.tar.gz
> 
> JDH
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev



From timvictor at gmail.com  Tue Nov 24 03:14:10 2009
From: timvictor at gmail.com (Tim Victor)
Date: Tue, 24 Nov 2009 03:14:10 -0500
Subject: [SciPy-dev] Possible fix for scipy.sparse.lil_matrix column-slicing
	problem
Message-ID: <c6d151100911240014j3910f744g89bb13b684843267@mail.gmail.com>

Hi folks. My first attempt at contributing code to a Python project...

Report of the problem prior to my finding it:
http://mail.scipy.org/pipermail/scipy-user/2009-April/020688.html

Ticket for the problem:
http://projects.scipy.org/scipy/ticket/917

Related code change between SciPy 0.7.0 and 0.7.1:
http://projects.scipy.org/scipy/changeset/5630

Diff of the changes is at the end of this message.

I'm running:
Ubuntu 9.04, Athlon64 X2
Python version 2.6.2
NumPy version 1.2.1
SciPy version 0.7.0

# under SciPy 0.7.0, I got:
>>> m = sp.sparse.lil_matrix((20,20))
>>> m[:,0] = sp.ones((20,1),'d')
>>> m[0,0]
<1x1 sparse matrix of type '<type 'numpy.float64'>'
	with 1 stored elements in LInked List format>
>>> m[0,0].todense()
matrix([[ 1.]])
>>> m[0,0][0,0]
1.0

# using scipy.sparse.lil.py from SciPy 0.7.1, I get:
>>> m = sp.sparse.lil_matrix((20,20))
>>> m[:,0] = sp.ones((20,1),'d')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/dist-packages/scipy/sparse/lil.py", line
329, in __setitem__
    self._insertat3(row, data, j, xx)
  File "/usr/lib/python2.6/dist-packages/scipy/sparse/lil.py", line
285, in _insertat3
    self._insertat2(row, data, j, x)
  File "/usr/lib/python2.6/dist-packages/scipy/sparse/lil.py", line
246, in _insertat2
    raise ValueError('setting an array element with a sequence')
ValueError: setting an array element with a sequence

# My version does this:
>>> m = sp.sparse.lil_matrix((20,20))
>>> m[:,0] = sp.ones((20,1),'d')
>>> m[0,0]
1.0
>>> type(m[0,0])
<type 'numpy.float64'>

# This matches the semantics for NumPy dense matrices:
>>> m = sp.matrix(sp.zeros((20,20), 'd'))
>>> m[:,0] = sp.ones((20,1),'d')
>>> m[0,0]
1.0
>>> type(m[0,0])
<type 'numpy.float64'>

Comments:
* The modified lil.py file is about the same size, actually four lines
longer I think.

* I've timed a selection of operations and all were as fast or faster
using my modified lil.py. Some are significantly faster now, such as
when assigning to a tall, narrow range of cells.

* It passes all unit tests in scipy.sparse.test(), but a special case
in the code is needed to pass the "test_lil_sequence_assignement" test
in scipy/sparse/tests/test_base.py. What I did might be excessively
permissive. I couldn't figure out what the semantics should be to
allow the assignment of a column vector to a row vector.

# Trying the same "test_lil_sequence_assignement" operations on a dense matrix:
>>> AA = sp.matrix(sp.zeros((4,3)))
>>> BB = sp.matrix(sp.eye(3,4))
>>> i0 = [0,1,2]
>>> i1 = (0,1,2)
>>> i2 = sp.array( i0 )
>>> AA[0,i0] = BB[i0,0]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: array is not broadcastable to correct shape
>>> AA[1,i1] = BB[i1,1]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: array is not broadcastable to correct shape
>>> AA[2,i2] = BB[i2,2]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: array is not broadcastable to correct shape

Best regards,

Tim Victor

-------------------------------

# apply with "patch lil.py <lil.py.diff"
226,233d225
<
<     def _insertat(self, i, j, x):
<         """ helper for __setitem__: insert a value at (i,j) where i, j and x
<         are all scalars """
<         row = self.rows[i]
<         data = self.data[i]
<         self._insertat2(row, data, j, x)
<
244d235
<
268,270c259
<
<     def _insertat3(self, row, data, j, x):
<         """ helper for __setitem__ """
---
>     def _setitem_setrow(self, row, data, j, xrow, xdata, xcols):
274,277c263,274
<             if isinstance(x, spmatrix):
<                 x = x.todense()
<             x = np.asarray(x).squeeze()
<             if np.isscalar(x) or x.size == 1:
---
>             if xcols == len(j):
>                 for jj, xi in zip(j, xrange(xcols)):
>                    pos = bisect_left(xrow, xi)
>                    if pos != len(xdata) and xrow[pos] == xi:
>                        self._insertat2(row, data, jj, xdata[pos])
>                    else:
>                        self._insertat2(row, data, jj, 0)
>             elif xcols == 1:           # OK, broadcast across row
>                 if len(xdata) > 0 and xrow[0] == 0:
>                     val = xdata[0]
>                 else:
>                     val = 0
279c276
<                     self._insertat2(row, data, jj, x)
---
>                     self._insertat2(row, data, jj,val)
281,283c278
<                 # x must be one D. maybe check these things out
<                 for jj, xx in zip(j, x):
<                     self._insertat2(row, data, jj, xx)
---
>                 raise IndexError('invalid index')
285c280,285
<             self._insertat2(row, data, j, x)
---
>             if not xcols == 1:
>                 raise ValueError('array dimensions are not compatible for copy')
>             if len(xdata) > 0 and xrow[0] == 0:
>                 self._insertat2(row, data, j, xdata[0])
>             else:
>                 self._insertat2(row, data, j, 0)
289d288
<
291,295d289
<         if np.isscalar(x):
<             x = self.dtype.type(x)
<         elif not isinstance(x, spmatrix):
<             x = lil_matrix(x)
<
300a295,300
>         # shortcut for common case of single entry assign:
>         if np.isscalar(x) and np.isscalar(i) and np.isscalar(j):
>             self._insertat2(self.rows[i], self.data[i], j, x)
>             return
>
>         # shortcut for common case of full matrix assign:
302,308c302,310
<             if (isinstance(i, slice) and (i == slice(None))) and \
<                (isinstance(j, slice) and (j == slice(None))):
<                 # self[:,:] = other_sparse
<                 x = lil_matrix(x)
<                 self.rows = x.rows
<                 self.data = x.data
<                 return
---
>           if isinstance(i, slice) and i == slice(None) and \
>              isinstance(j, slice) and j == slice(None):
>                x = lil_matrix(x)
>                self.rows = x.rows
>                self.data = x.data
>                return
>
>         if isinstance(i, tuple):       # can't index lists with tuple
>             i = list(i)
311,321c313,315
<             row = self.rows[i]
<             data = self.data[i]
<             self._insertat3(row, data, j, x)
<         elif issequence(i) and issequence(j):
<             if np.isscalar(x):
<                 for ii, jj in zip(i, j):
<                     self._insertat(ii, jj, x)
<             else:
<                 for ii, jj, xx in zip(i, j, x):
<                     self._insertat(ii, jj, xx)
<         elif isinstance(i, slice) or issequence(i):
---
>             rows = [self.rows[i]]
>             datas = [self.data[i]]
>         else:
324,329c318,333
<             if np.isscalar(x):
<                 for row, data in zip(rows, datas):
<                     self._insertat3(row, data, j, x)
<             else:
<                 for row, data, xx in zip(rows, datas, x):
<                     self._insertat3(row, data, j, xx)
---
>
>         x = lil_matrix(x, copy=False)
>         xrows, xcols = x.shape
>         if xrows == len(rows):    # normal rectangular copy
>             for row, data, xrow, xdata in zip(rows, datas, x.rows, x.data):
>                 self._setitem_setrow(row, data, j, xrow, xdata, xcols)
>         elif xrows == 1:          # OK, broadcast down column
>             for row, data in zip(rows, datas):
>                 self._setitem_setrow(row, data, j, x.rows[0], x.data[0], xcols)
>
>         # needed to pass 'test_lil_sequence_assignement' unit test:
>         # -- set row from column of entries --
>         elif xcols == len(rows):
>             x = x.T
>             for row, data, xrow, xdata in zip(rows, datas, x.rows, x.data):
>                 self._setitem_setrow(row, data, j, xrow, xdata, xrows)
331c335
<             raise ValueError('invalid index value: %s' % str((i, j)))
---
>             raise IndexError('invalid index')


From cimrman3 at ntc.zcu.cz  Tue Nov 24 07:10:58 2009
From: cimrman3 at ntc.zcu.cz (Robert Cimrman)
Date: Tue, 24 Nov 2009 13:10:58 +0100
Subject: [SciPy-dev] ANN: SfePy 2009.4
Message-ID: <4B0BCD52.4080706@ntc.zcu.cz>

I am pleased to announce release 2009.4 of SfePy.

Description
-----------

SfePy (simple finite elements in Python) is a software, distributed
under the BSD license, for solving systems of coupled partial
differential equations by the finite element method. The code is based
on NumPy and SciPy packages.

Mailing lists, issue tracking, git repository: http://sfepy.org
Home page: http://sfepy.kme.zcu.cz

New documentation site: http://docs.sfepy.org/doc

Many thanks to Logan Sorenson for the new documentation contents, and Vladimir
Lukes for setting up the server.

Highlights of this release
--------------------------
- unified handling of user-defined functions (for defining subdomains,
   heterogeneous material properties, boundary conditions etc.)
- greatly improved postprocessing and visualization capabilities, namely:
   - support for file sequences (evolutionary simulations)
   - animations (using ffmpeg)
   - automatic scalar bars
   - sfepy_gui.py: Mayavi2-based GUI to launch simulations

Major improvements
------------------
Apart from many bug-fixes, let us mention:
- quasistatic time stepping
- graphical logging:
   - dynamic adding of data groups (new axes) to Log and ProcessPlotter
- linear algebra:
   - reversed Cuthill-McKee permutation algorithm, graph in-place permutation
- setting of parameter variables by a user-defined function
- new tests and terms

For more information on this release, see
http://sfepy.googlecode.com/svn/web/releases/2009.4_RELEASE_NOTES.txt
(full release notes, rather long).

Best regards,
Robert Cimrman



From gael.varoquaux at normalesup.org  Tue Nov 24 16:24:35 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 24 Nov 2009 22:24:35 +0100
Subject: [SciPy-dev] [OT] Skipping whole modules in nose test discovery
Message-ID: <20091124212435.GC7130@phare.normalesup.org>

Hi there, 

this is off topic, but as they are some extensive users of nose, I am
piggy backing on my list subscription.

I have a package using autosummary, with a copy of autosummary in the
package itself. I am also testing that package with nose. My problem is
that, on systems where docutils is not installed, I get import errors
when nose tries to import the autosummary file to inspect it at test
discovery time. Any way I can tell nose not to inspect that file?

Cheers,

Ga?l


From nmb at wartburg.edu  Tue Nov 24 17:12:41 2009
From: nmb at wartburg.edu (Neil Martinsen-Burrell)
Date: Tue, 24 Nov 2009 16:12:41 -0600
Subject: [SciPy-dev] [OT] Skipping whole modules in nose test discovery
In-Reply-To: <20091124212435.GC7130@phare.normalesup.org>
References: <20091124212435.GC7130@phare.normalesup.org>
Message-ID: <4B0C5A59.9030401@wartburg.edu>

On 2009-11-24 15:24 , Gael Varoquaux wrote:
> Hi there,
>
> this is off topic, but as they are some extensive users of nose, I am
> piggy backing on my list subscription.
>
> I have a package using autosummary, with a copy of autosummary in the
> package itself. I am also testing that package with nose. My problem is
> that, on systems where docutils is not installed, I get import errors
> when nose tries to import the autosummary file to inspect it at test
> discovery time. Any way I can tell nose not to inspect that file?

 From nosetests --help:

[...]

   -e REGEX, --exclude=REGEX
                         Don't run tests that match regular expression
                         [NOSE_EXCLUDE]

[...]

or programmatically, it appears that 
nose.run(env={'NOSE_EXCLUDE':'autosummary'}) should do the same thing.

-Neil


From gael.varoquaux at normalesup.org  Tue Nov 24 17:16:31 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 24 Nov 2009 23:16:31 +0100
Subject: [SciPy-dev] [OT] Skipping whole modules in nose test discovery
In-Reply-To: <4B0C5A59.9030401@wartburg.edu>
References: <20091124212435.GC7130@phare.normalesup.org>
	<4B0C5A59.9030401@wartburg.edu>
Message-ID: <20091124221631.GD7130@phare.normalesup.org>

On Tue, Nov 24, 2009 at 04:12:41PM -0600, Neil Martinsen-Burrell wrote:
> On 2009-11-24 15:24 , Gael Varoquaux wrote:
>> Hi there,

>> this is off topic, but as they are some extensive users of nose, I am
>> piggy backing on my list subscription.

>> I have a package using autosummary, with a copy of autosummary in the
>> package itself. I am also testing that package with nose. My problem is
>> that, on systems where docutils is not installed, I get import errors
>> when nose tries to import the autosummary file to inspect it at test
>> discovery time. Any way I can tell nose not to inspect that file?
>
> From nosetests --help:
>
> [...]
>
>   -e REGEX, --exclude=REGEX
>                         Don't run tests that match regular expression
>                         [NOSE_EXCLUDE]
>
> [...]
>
> or programmatically, it appears that  
> nose.run(env={'NOSE_EXCLUDE':'autosummary'}) should do the same thing.

Thanks, I thought too that this would do this do the trick too, but
apparently the module is still imported at discovery time.

Ga?l


From matthew.brett at gmail.com  Wed Nov 25 16:07:36 2009
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 25 Nov 2009 13:07:36 -0800
Subject: [SciPy-dev] Question for git-svn masters
Message-ID: <1e2af89e0911251307s28a2049gb788b4f58d8a721@mail.gmail.com>

Hi David, Pauli, git-svn masters,

I have used the instructions here to good effect... :

http://projects.scipy.org/numpy/wiki/GitMirror

I cloned the git-svn mirror to good effect, and posted my repository
back to github:

http://github.com/matthew-brett/scipy-work

If I'm working from the original local clone of the scipy mirror, all
works well, I can do git svn rebase and so on.

If I clone from the github mirror:

git clone git at github.com:matthew-brett/scipy-work.git

then the resulting clone has lost the relationship with SVN:

b312 at tom:~/tmp/scipy-work$ git svn log
Migrating from a git-svn v1 layout...
Data from a previous version of git-svn exists, but
	.git/svn
	(required for this version (1.6.5) of git-svn) does not exist.
Done migrating from a git-svn v1 layout
fatal: bad default revision 'refs/remotes/git-svn'
------------------------------------------------------------------------

not surprisingly, because I have nothing about the svn in my .git/config

If I do this incantation (from the GitMirror page):

git-svn init -s --prefix=svn/ http://svn.scipy.org/svn/scipy
git-svn rebase -l

after a long time, I get:

Unable to determine upstream SVN information from working tree history

I tried Googling for this error, but reached a state of childish
confusion rather rapidly.  This page stood out as referring to my
problem, but I simply don't understand the issues well enough to see
an obvious fix from there:
http://stackoverflow.com/questions/1269566/unable-to-determine-upstream-svn-information-from-head-history

I'm using git-1.6.5 (latest stable compile from source).

Is there a way to reassociate my clone with SVN?

Is there a way to push this reassociation to my github mirror so that
'git clone ...' brings the SVN association with it?

Thanks a lot,

Matthew


From josef.pktd at gmail.com  Wed Nov 25 16:29:21 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Wed, 25 Nov 2009 16:29:21 -0500
Subject: [SciPy-dev] Possible fix for scipy.sparse.lil_matrix
	column-slicing problem
In-Reply-To: <c6d151100911240014j3910f744g89bb13b684843267@mail.gmail.com>
References: <c6d151100911240014j3910f744g89bb13b684843267@mail.gmail.com>
Message-ID: <1cd32cbb0911251329se97c355x8ec78903c4260ce@mail.gmail.com>

On Tue, Nov 24, 2009 at 3:14 AM, Tim Victor <timvictor at gmail.com> wrote:
> Hi folks. My first attempt at contributing code to a Python project...
>
> Report of the problem prior to my finding it:
> http://mail.scipy.org/pipermail/scipy-user/2009-April/020688.html
>
> Ticket for the problem:
> http://projects.scipy.org/scipy/ticket/917
>
> Related code change between SciPy 0.7.0 and 0.7.1:
> http://projects.scipy.org/scipy/changeset/5630
>
> Diff of the changes is at the end of this message.
>
> I'm running:
> Ubuntu 9.04, Athlon64 X2
> Python version 2.6.2
> NumPy version 1.2.1
> SciPy version 0.7.0
>
> # under SciPy 0.7.0, I got:
>>>> m = sp.sparse.lil_matrix((20,20))
>>>> m[:,0] = sp.ones((20,1),'d')
>>>> m[0,0]
> <1x1 sparse matrix of type '<type 'numpy.float64'>'
> ? ? ? ?with 1 stored elements in LInked List format>
>>>> m[0,0].todense()
> matrix([[ 1.]])
>>>> m[0,0][0,0]
> 1.0
>
> # using scipy.sparse.lil.py from SciPy 0.7.1, I get:
>>>> m = sp.sparse.lil_matrix((20,20))
>>>> m[:,0] = sp.ones((20,1),'d')
> Traceback (most recent call last):
> ?File "<stdin>", line 1, in <module>
> ?File "/usr/lib/python2.6/dist-packages/scipy/sparse/lil.py", line
> 329, in __setitem__
> ? ?self._insertat3(row, data, j, xx)
> ?File "/usr/lib/python2.6/dist-packages/scipy/sparse/lil.py", line
> 285, in _insertat3
> ? ?self._insertat2(row, data, j, x)
> ?File "/usr/lib/python2.6/dist-packages/scipy/sparse/lil.py", line
> 246, in _insertat2
> ? ?raise ValueError('setting an array element with a sequence')
> ValueError: setting an array element with a sequence
>
> # My version does this:
>>>> m = sp.sparse.lil_matrix((20,20))
>>>> m[:,0] = sp.ones((20,1),'d')
>>>> m[0,0]
> 1.0
>>>> type(m[0,0])
> <type 'numpy.float64'>
>
> # This matches the semantics for NumPy dense matrices:
>>>> m = sp.matrix(sp.zeros((20,20), 'd'))
>>>> m[:,0] = sp.ones((20,1),'d')
>>>> m[0,0]
> 1.0
>>>> type(m[0,0])
> <type 'numpy.float64'>
>
> Comments:
> * The modified lil.py file is about the same size, actually four lines
> longer I think.
>
> * I've timed a selection of operations and all were as fast or faster
> using my modified lil.py. Some are significantly faster now, such as
> when assigning to a tall, narrow range of cells.
>
> * It passes all unit tests in scipy.sparse.test(), but a special case
> in the code is needed to pass the "test_lil_sequence_assignement" test
> in scipy/sparse/tests/test_base.py. What I did might be excessively
> permissive. I couldn't figure out what the semantics should be to
> allow the assignment of a column vector to a row vector.
>
> # Trying the same "test_lil_sequence_assignement" operations on a dense matrix:
>>>> AA = sp.matrix(sp.zeros((4,3)))
>>>> BB = sp.matrix(sp.eye(3,4))
>>>> i0 = [0,1,2]
>>>> i1 = (0,1,2)
>>>> i2 = sp.array( i0 )
>>>> AA[0,i0] = BB[i0,0]
> Traceback (most recent call last):
> ?File "<stdin>", line 1, in <module>
> ValueError: array is not broadcastable to correct shape
>>>> AA[1,i1] = BB[i1,1]
> Traceback (most recent call last):
> ?File "<stdin>", line 1, in <module>
> ValueError: array is not broadcastable to correct shape
>>>> AA[2,i2] = BB[i2,2]
> Traceback (most recent call last):
> ?File "<stdin>", line 1, in <module>
> ValueError: array is not broadcastable to correct shape
>
> Best regards,
>
> Tim Victor
>
> -------------------------------
>
> # apply with "patch lil.py <lil.py.diff"
> 226,233d225
> <
> < ? ? def _insertat(self, i, j, x):
> < ? ? ? ? """ helper for __setitem__: insert a value at (i,j) where i, j and x
> < ? ? ? ? are all scalars """
> < ? ? ? ? row = self.rows[i]
> < ? ? ? ? data = self.data[i]
> < ? ? ? ? self._insertat2(row, data, j, x)
> <
> 244d235
> <
> 268,270c259
> <
> < ? ? def _insertat3(self, row, data, j, x):
> < ? ? ? ? """ helper for __setitem__ """
> ---
>> ? ? def _setitem_setrow(self, row, data, j, xrow, xdata, xcols):
> 274,277c263,274
> < ? ? ? ? ? ? if isinstance(x, spmatrix):
> < ? ? ? ? ? ? ? ? x = x.todense()
> < ? ? ? ? ? ? x = np.asarray(x).squeeze()
> < ? ? ? ? ? ? if np.isscalar(x) or x.size == 1:
> ---
>> ? ? ? ? ? ? if xcols == len(j):
>> ? ? ? ? ? ? ? ? for jj, xi in zip(j, xrange(xcols)):
>> ? ? ? ? ? ? ? ? ? ?pos = bisect_left(xrow, xi)
>> ? ? ? ? ? ? ? ? ? ?if pos != len(xdata) and xrow[pos] == xi:
>> ? ? ? ? ? ? ? ? ? ? ? ?self._insertat2(row, data, jj, xdata[pos])
>> ? ? ? ? ? ? ? ? ? ?else:
>> ? ? ? ? ? ? ? ? ? ? ? ?self._insertat2(row, data, jj, 0)
>> ? ? ? ? ? ? elif xcols == 1: ? ? ? ? ? # OK, broadcast across row
>> ? ? ? ? ? ? ? ? if len(xdata) > 0 and xrow[0] == 0:
>> ? ? ? ? ? ? ? ? ? ? val = xdata[0]
>> ? ? ? ? ? ? ? ? else:
>> ? ? ? ? ? ? ? ? ? ? val = 0
> 279c276
> < ? ? ? ? ? ? ? ? ? ? self._insertat2(row, data, jj, x)
> ---
>> ? ? ? ? ? ? ? ? ? ? self._insertat2(row, data, jj,val)
> 281,283c278
> < ? ? ? ? ? ? ? ? # x must be one D. maybe check these things out
> < ? ? ? ? ? ? ? ? for jj, xx in zip(j, x):
> < ? ? ? ? ? ? ? ? ? ? self._insertat2(row, data, jj, xx)
> ---
>> ? ? ? ? ? ? ? ? raise IndexError('invalid index')
> 285c280,285
> < ? ? ? ? ? ? self._insertat2(row, data, j, x)
> ---
>> ? ? ? ? ? ? if not xcols == 1:
>> ? ? ? ? ? ? ? ? raise ValueError('array dimensions are not compatible for copy')
>> ? ? ? ? ? ? if len(xdata) > 0 and xrow[0] == 0:
>> ? ? ? ? ? ? ? ? self._insertat2(row, data, j, xdata[0])
>> ? ? ? ? ? ? else:
>> ? ? ? ? ? ? ? ? self._insertat2(row, data, j, 0)
> 289d288
> <
> 291,295d289
> < ? ? ? ? if np.isscalar(x):
> < ? ? ? ? ? ? x = self.dtype.type(x)
> < ? ? ? ? elif not isinstance(x, spmatrix):
> < ? ? ? ? ? ? x = lil_matrix(x)
> <
> 300a295,300
>> ? ? ? ? # shortcut for common case of single entry assign:
>> ? ? ? ? if np.isscalar(x) and np.isscalar(i) and np.isscalar(j):
>> ? ? ? ? ? ? self._insertat2(self.rows[i], self.data[i], j, x)
>> ? ? ? ? ? ? return
>>
>> ? ? ? ? # shortcut for common case of full matrix assign:
> 302,308c302,310
> < ? ? ? ? ? ? if (isinstance(i, slice) and (i == slice(None))) and \
> < ? ? ? ? ? ? ? ?(isinstance(j, slice) and (j == slice(None))):
> < ? ? ? ? ? ? ? ? # self[:,:] = other_sparse
> < ? ? ? ? ? ? ? ? x = lil_matrix(x)
> < ? ? ? ? ? ? ? ? self.rows = x.rows
> < ? ? ? ? ? ? ? ? self.data = x.data
> < ? ? ? ? ? ? ? ? return
> ---
>> ? ? ? ? ? if isinstance(i, slice) and i == slice(None) and \
>> ? ? ? ? ? ? ?isinstance(j, slice) and j == slice(None):
>> ? ? ? ? ? ? ? ?x = lil_matrix(x)
>> ? ? ? ? ? ? ? ?self.rows = x.rows
>> ? ? ? ? ? ? ? ?self.data = x.data
>> ? ? ? ? ? ? ? ?return
>>
>> ? ? ? ? if isinstance(i, tuple): ? ? ? # can't index lists with tuple
>> ? ? ? ? ? ? i = list(i)
> 311,321c313,315
> < ? ? ? ? ? ? row = self.rows[i]
> < ? ? ? ? ? ? data = self.data[i]
> < ? ? ? ? ? ? self._insertat3(row, data, j, x)
> < ? ? ? ? elif issequence(i) and issequence(j):
> < ? ? ? ? ? ? if np.isscalar(x):
> < ? ? ? ? ? ? ? ? for ii, jj in zip(i, j):
> < ? ? ? ? ? ? ? ? ? ? self._insertat(ii, jj, x)
> < ? ? ? ? ? ? else:
> < ? ? ? ? ? ? ? ? for ii, jj, xx in zip(i, j, x):
> < ? ? ? ? ? ? ? ? ? ? self._insertat(ii, jj, xx)
> < ? ? ? ? elif isinstance(i, slice) or issequence(i):
> ---
>> ? ? ? ? ? ? rows = [self.rows[i]]
>> ? ? ? ? ? ? datas = [self.data[i]]
>> ? ? ? ? else:
> 324,329c318,333
> < ? ? ? ? ? ? if np.isscalar(x):
> < ? ? ? ? ? ? ? ? for row, data in zip(rows, datas):
> < ? ? ? ? ? ? ? ? ? ? self._insertat3(row, data, j, x)
> < ? ? ? ? ? ? else:
> < ? ? ? ? ? ? ? ? for row, data, xx in zip(rows, datas, x):
> < ? ? ? ? ? ? ? ? ? ? self._insertat3(row, data, j, xx)
> ---
>>
>> ? ? ? ? x = lil_matrix(x, copy=False)
>> ? ? ? ? xrows, xcols = x.shape
>> ? ? ? ? if xrows == len(rows): ? ?# normal rectangular copy
>> ? ? ? ? ? ? for row, data, xrow, xdata in zip(rows, datas, x.rows, x.data):
>> ? ? ? ? ? ? ? ? self._setitem_setrow(row, data, j, xrow, xdata, xcols)
>> ? ? ? ? elif xrows == 1: ? ? ? ? ?# OK, broadcast down column
>> ? ? ? ? ? ? for row, data in zip(rows, datas):
>> ? ? ? ? ? ? ? ? self._setitem_setrow(row, data, j, x.rows[0], x.data[0], xcols)
>>
>> ? ? ? ? # needed to pass 'test_lil_sequence_assignement' unit test:
>> ? ? ? ? # -- set row from column of entries --
>> ? ? ? ? elif xcols == len(rows):
>> ? ? ? ? ? ? x = x.T
>> ? ? ? ? ? ? for row, data, xrow, xdata in zip(rows, datas, x.rows, x.data):
>> ? ? ? ? ? ? ? ? self._setitem_setrow(row, data, j, xrow, xdata, xrows)
> 331c335
> < ? ? ? ? ? ? raise ValueError('invalid index value: %s' % str((i, j)))
> ---
>> ? ? ? ? ? ? raise IndexError('invalid index')
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>

Could you add this to the trac ticket, so that it doesn't get lost
until someone who knows this code has time to look at it?
maybe with a link to the mailing list.

Thanks,

Josef


From pav at iki.fi  Wed Nov 25 18:39:11 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Thu, 26 Nov 2009 01:39:11 +0200
Subject: [SciPy-dev] Question for git-svn masters
In-Reply-To: <1e2af89e0911251307s28a2049gb788b4f58d8a721@mail.gmail.com>
References: <1e2af89e0911251307s28a2049gb788b4f58d8a721@mail.gmail.com>
Message-ID: <1259192350.4291.13.camel@idol>

ke, 2009-11-25 kello 13:07 -0800, Matthew Brett kirjoitti:
[clip]
> If I clone from the github mirror:
> 
> git clone git at github.com:matthew-brett/scipy-work.git
> 
> then the resulting clone has lost the relationship with SVN:
[clip]
> If I do this incantation (from the GitMirror page):
> 
> git-svn init -s --prefix=svn/ http://svn.scipy.org/svn/scipy
> git-svn rebase -l
> 
> after a long time, I get:
> 
> Unable to determine upstream SVN information from working tree history
[clip]

You need to add the Scipy SVN mirror remote before doing git svn init:

        git remote add svn http://projects.scipy.org/git/scipy.git
        git fetch svn

so that git-svn knows about the svn tags and branches metadata.
I also added these instructions here:

http://projects.scipy.org/numpy/wiki/GitMirror#a...forrepositoryclonedfromelsewhere

Cheers,
Pauli






From pav at iki.fi  Wed Nov 25 19:01:28 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Thu, 26 Nov 2009 02:01:28 +0200
Subject: [SciPy-dev] Question for git-svn masters
In-Reply-To: <1e2af89e0911251307s28a2049gb788b4f58d8a721@mail.gmail.com>
References: <1e2af89e0911251307s28a2049gb788b4f58d8a721@mail.gmail.com>
Message-ID: <1259193688.4291.23.camel@idol>

ke, 2009-11-25 kello 13:07 -0800, Matthew Brett kirjoitti:
[clip]
> Is there a way to push this reassociation to my github mirror so that
> 'git clone ...' brings the SVN association with it?

The issue here is that "git push" by does not push the remote tags, so
the repo on github is missing the "svn/" heads.

There may be a way to make git-push push also the remote branches as
"remotes of a remote", but I think gnashing of teeth may be in store for
those who try it...

Cheers,
Pauli





From matthew.brett at gmail.com  Wed Nov 25 20:01:12 2009
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 25 Nov 2009 17:01:12 -0800
Subject: [SciPy-dev] Question for git-svn masters
In-Reply-To: <1259193688.4291.23.camel@idol>
References: <1e2af89e0911251307s28a2049gb788b4f58d8a721@mail.gmail.com>
	<1259193688.4291.23.camel@idol>
Message-ID: <1e2af89e0911251701q5f8e7790u26ff50af2424bf9f@mail.gmail.com>

Hi,

On Wed, Nov 25, 2009 at 4:01 PM, Pauli Virtanen <pav at iki.fi> wrote:
> ke, 2009-11-25 kello 13:07 -0800, Matthew Brett kirjoitti:
> [clip]
>> Is there a way to push this reassociation to my github mirror so that
>> 'git clone ...' brings the SVN association with it?
>
> The issue here is that "git push" by does not push the remote tags, so
> the repo on github is missing the "svn/" heads.

Thanks - but - when run:

       git remote add svn http://projects.scipy.org/git/scipy.git
       git fetch svn

In my github repository local clone, and then try and rebase:

mb312 at angela:~/dev_trees/scipy$ git svn rebase
Migrating from a git-svn v1 layout...
Data from a previous version of git-svn exists, but
	.git/svn
	(required for this version (1.6.5) of git-svn) does not exist.
Done migrating from a git-svn v1 layout
Unable to determine upstream SVN information from working tree history

I suppose the other option is to clone the scipy mirror and add my
github repository as another remote...

See you,

Matthew


From pav at iki.fi  Wed Nov 25 20:09:09 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Thu, 26 Nov 2009 03:09:09 +0200
Subject: [SciPy-dev] Question for git-svn masters
In-Reply-To: <1e2af89e0911251701q5f8e7790u26ff50af2424bf9f@mail.gmail.com>
References: <1e2af89e0911251307s28a2049gb788b4f58d8a721@mail.gmail.com>
	<1259193688.4291.23.camel@idol>
	<1e2af89e0911251701q5f8e7790u26ff50af2424bf9f@mail.gmail.com>
Message-ID: <1259197748.4291.29.camel@idol>

ke, 2009-11-25 kello 17:01 -0800, Matthew Brett kirjoitti:
[clip]
> Thanks - but - when run:
> 
>        git remote add svn http://projects.scipy.org/git/scipy.git
>        git fetch svn
> 
> In my github repository local clone, and then try and rebase:
> 
> mb312 at angela:~/dev_trees/scipy$ git svn rebase
> Migrating from a git-svn v1 layout...
> Data from a previous version of git-svn exists, but
> 	.git/svn
> 	(required for this version (1.6.5) of git-svn) does not exist.
> Done migrating from a git-svn v1 layout
> Unable to determine upstream SVN information from working tree history

Works for me (git 1.6.3.3):

	git clone git://github.com/matthew-brett/scipy-work.git
	git svn init -s --prefix=svn/ http://svn.scipy.org/svn/scipy
	git remote add svn http://projects.scipy.org/git/scipy.git
	git svn rebase -l -n

Are you sure you typed the correct commands? Perhaps you have to 
"rm -rf .git/svn" if it contains old cruft from your previous tries?
Perhaps there's some cruft in .git/config?

Also, I'd rather use "git rebase svn/trunk" than "git svn rebase", as
the latter is quite a bit more magical.

-- 
Pauli Virtanen





From pav at iki.fi  Wed Nov 25 20:14:30 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Thu, 26 Nov 2009 03:14:30 +0200
Subject: [SciPy-dev] Question for git-svn masters
In-Reply-To: <1259197748.4291.29.camel@idol>
References: <1e2af89e0911251307s28a2049gb788b4f58d8a721@mail.gmail.com>
	<1259193688.4291.23.camel@idol>
	<1e2af89e0911251701q5f8e7790u26ff50af2424bf9f@mail.gmail.com>
	<1259197748.4291.29.camel@idol>
Message-ID: <1259198069.4291.32.camel@idol>

to, 2009-11-26 kello 03:09 +0200, Pauli Virtanen kirjoitti:
[clip]
> Works for me (git 1.6.3.3):
> 
> 	git clone git://github.com/matthew-brett/scipy-work.git
> 	git svn init -s --prefix=svn/ http://svn.scipy.org/svn/scipy
> 	git remote add svn http://projects.scipy.org/git/scipy.git
          git fetch svn
> 	git svn rebase -l -n

I forgot "git fetch svn" before rebase in the previous mail.

	Pauli





From matthew.brett at gmail.com  Wed Nov 25 20:19:47 2009
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 25 Nov 2009 17:19:47 -0800
Subject: [SciPy-dev] Question for git-svn masters
In-Reply-To: <1259198069.4291.32.camel@idol>
References: <1e2af89e0911251307s28a2049gb788b4f58d8a721@mail.gmail.com>
	<1259193688.4291.23.camel@idol>
	<1e2af89e0911251701q5f8e7790u26ff50af2424bf9f@mail.gmail.com>
	<1259197748.4291.29.camel@idol> <1259198069.4291.32.camel@idol>
Message-ID: <1e2af89e0911251719l7e220c1dyaf5ff5dba7096ed3@mail.gmail.com>

Hi,

On Wed, Nov 25, 2009 at 5:14 PM, Pauli Virtanen <pav at iki.fi> wrote:
> to, 2009-11-26 kello 03:09 +0200, Pauli Virtanen kirjoitti:
> [clip]
>> Works for me (git 1.6.3.3):
>>
>> ? ? ? git clone git://github.com/matthew-brett/scipy-work.git
>> ? ? ? git svn init -s --prefix=svn/ http://svn.scipy.org/svn/scipy
>> ? ? ? git remote add svn http://projects.scipy.org/git/scipy.git
> ? ? ? ? ?git fetch svn
>> ? ? ? git svn rebase -l -n

Yes, that works - I missed the (perhaps obvious) git svn init .. step...

Thanks a lot,

Matthew


From thouis at broad.mit.edu  Thu Nov 26 14:39:42 2009
From: thouis at broad.mit.edu (Thouis (Ray) Jones)
Date: Thu, 26 Nov 2009 14:39:42 -0500
Subject: [SciPy-dev] ticket #945?
Message-ID: <6c17e6f50911261139k1a431756sd0865e559f9fee87@mail.gmail.com>

I'm soliciting thoughts on http://projects.scipy.org/scipy/ticket/945

We're using these changes in CellProfiler, and would be interested in
having them move to the trunk if they're useful.  Otherwise, we'll
need to make our own version so we can track the released version of
scipy (at some point).

Ray Jones


From zachary.pincus at yale.edu  Thu Nov 26 14:57:15 2009
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Thu, 26 Nov 2009 14:57:15 -0500
Subject: [SciPy-dev] ticket #945?
In-Reply-To: <6c17e6f50911261139k1a431756sd0865e559f9fee87@mail.gmail.com>
References: <6c17e6f50911261139k1a431756sd0865e559f9fee87@mail.gmail.com>
Message-ID: <0139500F-E013-460D-AE3C-DF9869EF115A@yale.edu>

If it's as fast, and backward-compatible, this certainly sounds like a  
great idea. Especially if it opens up the way for more easily adding  
new measurements.

Zach



On Nov 26, 2009, at 2:39 PM, Thouis (Ray) Jones wrote:

> I'm soliciting thoughts on http://projects.scipy.org/scipy/ticket/945
>
> We're using these changes in CellProfiler, and would be interested in
> having them move to the trunk if they're useful.  Otherwise, we'll
> need to make our own version so we can track the released version of
> scipy (at some point).
>
> Ray Jones
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev



From arkapravobhaumik at gmail.com  Thu Nov 26 15:38:22 2009
From: arkapravobhaumik at gmail.com (Arkapravo Bhaumik)
Date: Thu, 26 Nov 2009 20:38:22 +0000
Subject: [SciPy-dev] Issues in sici
Message-ID: <ba4564350911261238i5f7c5d2atfc73a31d00df5ab7@mail.gmail.com>

Hi everyone

I have come across a minor issue with the sici module which evaluates the
sine integral. Evaluation is excellent and gives precise values, however for
inputs of infinity the results are nan which is very annoying.

I have compared MATLAB and Scipy in these regards, please have a look
http://3chevrons.blogspot.com/2009/11/sine-integral-in-scipy.html . I would
guess that there should be special provisions for infinity in sici module
and an exception must be coded in.

I have also been playing around with such integrals,
http://3chevrons.blogspot.com/2009/10/exotic-integrals-in-scipy.html .

Please feel free to reply.

Regards

Arkapravo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091126/f0d3b65c/attachment.html>

From thouis at broad.mit.edu  Thu Nov 26 15:55:01 2009
From: thouis at broad.mit.edu (Thouis (Ray) Jones)
Date: Thu, 26 Nov 2009 15:55:01 -0500
Subject: [SciPy-dev] ticket #945?
In-Reply-To: <0139500F-E013-460D-AE3C-DF9869EF115A@yale.edu>
References: <6c17e6f50911261139k1a431756sd0865e559f9fee87@mail.gmail.com> 
	<0139500F-E013-460D-AE3C-DF9869EF115A@yale.edu>
Message-ID: <6c17e6f50911261255n688b0a46idd2bc7efeb2d0faf@mail.gmail.com>

The speed comparisons are here:
 http://mail.scipy.org/pipermail/scipy-dev/2009-May/012001.html

Most are about the same in speed.  histogram() is much slower, because
it tracks numpy.histogram instead of implementing its own.  Some could
be sped up, mostly those using _select in the modified
measurements.py.

histogram() is not backwards compatible (at least, it doesn't produce
exactly the same values).  Also, any code relying on non-lists being
returned when the functions are called with a list of labels (the
original motivation for this work) would break, but I expect that is a
limited number.

Ray


On Thu, Nov 26, 2009 at 14:57, Zachary Pincus <zachary.pincus at yale.edu> wrote:
> If it's as fast, and backward-compatible, this certainly sounds like a
> great idea. Especially if it opens up the way for more easily adding
> new measurements.
>
> Zach
>
>
>
> On Nov 26, 2009, at 2:39 PM, Thouis (Ray) Jones wrote:
>
>> I'm soliciting thoughts on http://projects.scipy.org/scipy/ticket/945
>>
>> We're using these changes in CellProfiler, and would be interested in
>> having them move to the trunk if they're useful. ?Otherwise, we'll
>> need to make our own version so we can track the released version of
>> scipy (at some point).
>>
>> Ray Jones
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From dwf at cs.toronto.edu  Thu Nov 26 16:03:26 2009
From: dwf at cs.toronto.edu (David Warde-Farley)
Date: Thu, 26 Nov 2009 16:03:26 -0500
Subject: [SciPy-dev] ticket #945?
In-Reply-To: <0139500F-E013-460D-AE3C-DF9869EF115A@yale.edu>
References: <6c17e6f50911261139k1a431756sd0865e559f9fee87@mail.gmail.com>
	<0139500F-E013-460D-AE3C-DF9869EF115A@yale.edu>
Message-ID: <7FBF0485-60FC-4D00-9584-1DA5040BFB57@cs.toronto.edu>

On 26-Nov-09, at 2:57 PM, Zachary Pincus wrote:

> If it's as fast, and backward-compatible, this certainly sounds like a
> great idea. Especially if it opens up the way for more easily adding
> new measurements.

+1 -- even a slight performance hit is worth the benefits this brings  
IMHO.

David


From timvictor at gmail.com  Thu Nov 26 19:21:15 2009
From: timvictor at gmail.com (Tim Victor)
Date: Thu, 26 Nov 2009 19:21:15 -0500
Subject: [SciPy-dev] Possible fix for scipy.sparse.lil_matrix
	column-slicing problem
In-Reply-To: <1cd32cbb0911251329se97c355x8ec78903c4260ce@mail.gmail.com>
References: <c6d151100911240014j3910f744g89bb13b684843267@mail.gmail.com>
	<1cd32cbb0911251329se97c355x8ec78903c4260ce@mail.gmail.com>
Message-ID: <c6d151100911261621g2973ceafo1d7c1e092a6c486e@mail.gmail.com>

On Wed, Nov 25, 2009 at 4:29 PM,  josef.pktd (at) gmail.com> wrote:
> [snip]
> Could you add this to the trac ticket, so that it doesn't get lost
> until someone who knows this code has time to look at it?
> maybe with a link to the mailing list.
>
> Thanks,
>
> Josef

I didn't know that I could do that! I've just created an account and
added a comment there with a link to this email thread. Thanks for the
reply.

Best regards,

Tim Victor


From thouis at broad.mit.edu  Thu Nov 26 19:40:08 2009
From: thouis at broad.mit.edu (Thouis (Ray) Jones)
Date: Thu, 26 Nov 2009 19:40:08 -0500
Subject: [SciPy-dev] is this a bug (take with indices in a matrix)
Message-ID: <6c17e6f50911261640p7b8175cck3b3799de16e2f5bd@mail.gmail.com>

>>> from numpy import *
>>> q = matrix(arange(9).reshape((3,3)))
>>> take(q, matrix([[0]]), axis=0)
matrix([[0, 1, 2]])
>>> take(q, matrix([[0]]), axis=1)
matrix([[0, 3, 6]])

Expected behavior for the last expression:
>>> take(q, [0], axis=1)
matrix([[0],
        [3],
        [6]])


From charlesr.harris at gmail.com  Thu Nov 26 19:54:11 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Thu, 26 Nov 2009 17:54:11 -0700
Subject: [SciPy-dev] is this a bug (take with indices in a matrix)
In-Reply-To: <6c17e6f50911261640p7b8175cck3b3799de16e2f5bd@mail.gmail.com>
References: <6c17e6f50911261640p7b8175cck3b3799de16e2f5bd@mail.gmail.com>
Message-ID: <e06186140911261654t3159726dpac2fffa1b941930f@mail.gmail.com>

On Thu, Nov 26, 2009 at 5:40 PM, Thouis (Ray) Jones <thouis at broad.mit.edu>wrote:

> >>> from numpy import *
> >>> q = matrix(arange(9).reshape((3,3)))
> >>> take(q, matrix([[0]]), axis=0)
> matrix([[0, 1, 2]])
> >>> take(q, matrix([[0]]), axis=1)
> matrix([[0, 3, 6]])
>
> Expected behavior for the last expression:
> >>> take(q, [0], axis=1)
> matrix([[0],
>        [3],
>        [6]])
> ____


Bug or feature could be the subject of much discussion, but it is definitely
a wart. What looks to be happening is a two step thing. First the column is
taken ndarray wise, resulting in a 1d array, which is then converted using
the default 1d -> row for matrix conversions.

I think it could be fixed, but the whole problem with the current matrix
class is that fixing all these warts starts to intrude on the base ndarray
class.

You should raise the issue on the numpy mailing list, it's time for another
discussion of the matrix class.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091126/41afc029/attachment.html>

From wnbell at gmail.com  Thu Nov 26 22:58:26 2009
From: wnbell at gmail.com (Nathan Bell)
Date: Thu, 26 Nov 2009 22:58:26 -0500
Subject: [SciPy-dev] Possible fix for scipy.sparse.lil_matrix
	column-slicing problem
In-Reply-To: <c6d151100911261621g2973ceafo1d7c1e092a6c486e@mail.gmail.com>
References: <c6d151100911240014j3910f744g89bb13b684843267@mail.gmail.com>
	<1cd32cbb0911251329se97c355x8ec78903c4260ce@mail.gmail.com>
	<c6d151100911261621g2973ceafo1d7c1e092a6c486e@mail.gmail.com>
Message-ID: <d05265cb0911261958o5cedf4efo917c2adee040a463@mail.gmail.com>

On Thu, Nov 26, 2009 at 7:21 PM, Tim Victor <timvictor at gmail.com> wrote:
>
> I didn't know that I could do that! I've just created an account and
> added a comment there with a link to this email thread. Thanks for the
> reply.
>

Nice work!

Your patch has been merged into r6121 [1].  The previous
implementation was a bit of a nightmare so I'm glad someone finally
took the time to simplify it :)

Thanks for your contribution.  I hope it is the first of many!

[1] http://projects.scipy.org/scipy/changeset/6121

-- 
Nathan Bell wnbell at gmail.com
http://www.wnbell.com/


From josef.pktd at gmail.com  Thu Nov 26 23:19:48 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 26 Nov 2009 23:19:48 -0500
Subject: [SciPy-dev] Possible fix for scipy.sparse.lil_matrix
	column-slicing problem
In-Reply-To: <d05265cb0911261958o5cedf4efo917c2adee040a463@mail.gmail.com>
References: <c6d151100911240014j3910f744g89bb13b684843267@mail.gmail.com>
	<1cd32cbb0911251329se97c355x8ec78903c4260ce@mail.gmail.com>
	<c6d151100911261621g2973ceafo1d7c1e092a6c486e@mail.gmail.com>
	<d05265cb0911261958o5cedf4efo917c2adee040a463@mail.gmail.com>
Message-ID: <1cd32cbb0911262019k5550ad33x69a2c5e5cf49f57f@mail.gmail.com>

On Thu, Nov 26, 2009 at 10:58 PM, Nathan Bell <wnbell at gmail.com> wrote:
> On Thu, Nov 26, 2009 at 7:21 PM, Tim Victor <timvictor at gmail.com> wrote:
>>
>> I didn't know that I could do that! I've just created an account and
>> added a comment there with a link to this email thread. Thanks for the
>> reply.
>>
>
> Nice work!
>
> Your patch has been merged into r6121 [1]. ?The previous
> implementation was a bit of a nightmare so I'm glad someone finally
> took the time to simplify it :)
>
> Thanks for your contribution. ?I hope it is the first of many!
>
> [1] http://projects.scipy.org/scipy/changeset/6121
>

That's a fast turnaround. I'm glad the patch didn't get lost on the
mailing list.

Thanks,

Josef

> --
> Nathan Bell wnbell at gmail.com
> http://www.wnbell.com/
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From cournape at gmail.com  Fri Nov 27 04:02:42 2009
From: cournape at gmail.com (David Cournapeau)
Date: Fri, 27 Nov 2009 18:02:42 +0900
Subject: [SciPy-dev] Issues in sici
In-Reply-To: <ba4564350911261238i5f7c5d2atfc73a31d00df5ab7@mail.gmail.com>
References: <ba4564350911261238i5f7c5d2atfc73a31d00df5ab7@mail.gmail.com>
Message-ID: <5b8d13220911270102n4aae151aw978b3be90ee11d76@mail.gmail.com>

On Fri, Nov 27, 2009 at 5:38 AM, Arkapravo Bhaumik
<arkapravobhaumik at gmail.com> wrote:
> Hi everyone
>
> I have come across a minor issue with the sici module which evaluates the
> sine integral. Evaluation is excellent and gives precise values, however for
> inputs of infinity the results are nan which is very annoying.

Yes, that's a bug in cephes: the case for big x uses cos and sin,
which is not a good in the case of infinite input. I added a special
case to return the theoretical values in the case of real input,

See #1060 for details, fixed in r6122. Note that the function is still
wrong for negative values, the real fix is more likely to rewrite the
function, as cephes quality for special case is generally quite poor
(and the code horrible).

cheers,

David


From timvictor at gmail.com  Fri Nov 27 14:30:53 2009
From: timvictor at gmail.com (Tim Victor)
Date: Fri, 27 Nov 2009 14:30:53 -0500
Subject: [SciPy-dev] Possible fix for scipy.sparse.lil_matrix
	column-slicing problem
In-Reply-To: <d05265cb0911261958o5cedf4efo917c2adee040a463@mail.gmail.com>
References: <c6d151100911240014j3910f744g89bb13b684843267@mail.gmail.com>
	<1cd32cbb0911251329se97c355x8ec78903c4260ce@mail.gmail.com>
	<c6d151100911261621g2973ceafo1d7c1e092a6c486e@mail.gmail.com>
	<d05265cb0911261958o5cedf4efo917c2adee040a463@mail.gmail.com>
Message-ID: <c6d151100911271130t3d2935d6pe00a8d12957ab22c@mail.gmail.com>

On Thu, Nov 26, 2009 at 10:58 PM, Nathan Bell wrote:
> On Thu, Nov 26, 2009 at 7:21 PM, Tim Victor wrote:
>>
>> I didn't know that I could do that! I've just created an account and
>> added a comment there with a link to this email thread. Thanks for the
>> reply.
>>
>
> Nice work!
>
> Your patch has been merged into r6121 [1]. ?The previous
> implementation was a bit of a nightmare so I'm glad someone finally
> took the time to simplify it :)
>
> Thanks for your contribution. ?I hope it is the first of many!
>
> [1] http://projects.scipy.org/scipy/changeset/6121
>
> --
> Nathan Bell wnbell at gmail.com
> http://www.wnbell.com/

Thanks for the really quick turnaround and the kind words, Nathan. I
enjoyed working on it. It was kinda like helping someone else on their
class project when I was a student. That was always more fun than
doing my own work.

I might see what other open tickets there are. It seems like a good
way to learn something about the different parts of the system.

Best regards,

Tim Victor


From timvictor at gmail.com  Fri Nov 27 14:36:58 2009
From: timvictor at gmail.com (Tim Victor)
Date: Fri, 27 Nov 2009 14:36:58 -0500
Subject: [SciPy-dev] Possible fix for scipy.sparse.lil_matrix
	column-slicing problem
In-Reply-To: <1cd32cbb0911262019k5550ad33x69a2c5e5cf49f57f@mail.gmail.com>
References: <c6d151100911240014j3910f744g89bb13b684843267@mail.gmail.com>
	<1cd32cbb0911251329se97c355x8ec78903c4260ce@mail.gmail.com>
	<c6d151100911261621g2973ceafo1d7c1e092a6c486e@mail.gmail.com>
	<d05265cb0911261958o5cedf4efo917c2adee040a463@mail.gmail.com>
	<1cd32cbb0911262019k5550ad33x69a2c5e5cf49f57f@mail.gmail.com>
Message-ID: <c6d151100911271136p69fd9ecah71daa2f5de67972f@mail.gmail.com>

On Thu, Nov 26, 2009 at 11:19 PM,  Josef wrote:
> On Thu, Nov 26, 2009 at 10:58 PM, Nathan Bell wrote:
>> On Thu, Nov 26, 2009 at 7:21 PM, Tim Victor wrote:
>>>
>>> I didn't know that I could do that! I've just created an account and
>>> added a comment there with a link to this email thread. Thanks for the
>>> reply.
>>>
>>
>> Nice work!
>>
>> Your patch has been merged into r6121 [1]. ?The previous
>> implementation was a bit of a nightmare so I'm glad someone finally
>> took the time to simplify it :)
>>
>> Thanks for your contribution. ?I hope it is the first of many!
>>
>> [1] http://projects.scipy.org/scipy/changeset/6121
>>
>
> That's a fast turnaround. I'm glad the patch didn't get lost on the
> mailing list.
>
> Thanks,
>
> Josef

Good call on adding a note to the tracking ticket, Josef. After I did
that, I got a direct email from the tracker when Nathan changed the
status of the ticket, so I'm guessing that my note might have done the
same to Nathan. But that was still some very quick action on his part.

Best regards,

Tim Victor


From arkapravobhaumik at gmail.com  Sat Nov 28 05:50:37 2009
From: arkapravobhaumik at gmail.com (Arkapravo Bhaumik)
Date: Sat, 28 Nov 2009 10:50:37 +0000
Subject: [SciPy-dev] Constants in Scipy
Message-ID: <ba4564350911280250y6227f6d3w1505e98a8baffaec@mail.gmail.com>

Hi everyone

I had a question, how many built-in constants are there in Scipy ?, I am
familiar with pi and e , how many more are there ?

I had been trying to evaluate euler-gamma in Scipy, which is easy
http://3chevrons.blogspot.com/2009/10/eulers-gamma.html . However, MATLAB in
comparison has euler-gamma built-into it and intelligently recognises the
expression as it is typed in, Scipy is not yet able to do so. If the desire
is indeed to make Scipy into a dynamic and robust software then various
constants must be built-into the software and Scipy made to identify such
expressions.

Many thanks David ( David Cournapeau) for replying to my previous posting
and confirming my observations about sici.

Regards

Arkapravo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091128/8db6bfbf/attachment.html>

From pav at iki.fi  Sat Nov 28 07:53:13 2009
From: pav at iki.fi (Pauli Virtanen)
Date: Sat, 28 Nov 2009 14:53:13 +0200
Subject: [SciPy-dev] Constants in Scipy
In-Reply-To: <ba4564350911280250y6227f6d3w1505e98a8baffaec@mail.gmail.com>
References: <ba4564350911280250y6227f6d3w1505e98a8baffaec@mail.gmail.com>
Message-ID: <1259412793.4236.13.camel@idol>

la, 2009-11-28 kello 10:50 +0000, Arkapravo Bhaumik kirjoitti:
> I had a question, how many built-in constants are there in Scipy ?, I
> am familiar with pi and e , how many more are there ? 

See the documentation:
http://docs.scipy.org/doc/scipy/reference/





From josef.pktd at gmail.com  Sat Nov 28 08:19:22 2009
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Sat, 28 Nov 2009 08:19:22 -0500
Subject: [SciPy-dev] Constants in Scipy
In-Reply-To: <ba4564350911280250y6227f6d3w1505e98a8baffaec@mail.gmail.com>
References: <ba4564350911280250y6227f6d3w1505e98a8baffaec@mail.gmail.com>
Message-ID: <1cd32cbb0911280519l518dcf45tb0a6437165b26eb9@mail.gmail.com>

On Sat, Nov 28, 2009 at 5:50 AM, Arkapravo Bhaumik
<arkapravobhaumik at gmail.com> wrote:
> Hi everyone
>
> I had a question, how many built-in constants are there in Scipy ?, I am
> familiar with pi and e , how many more are there ?
>
> I had been trying to evaluate euler-gamma in Scipy, which is easy
> http://3chevrons.blogspot.com/2009/10/eulers-gamma.html . However, MATLAB in
> comparison has euler-gamma built-into it and intelligently recognises the
> expression as it is typed in, Scipy is not yet able to do so.

I think your comparison is not really with MATLAB, it looks to me that
you are using the symbolic toolbox, which a while ago was MAPLE and is
now a different 3rd party package (don't remember name).

Your comparisons are a good check whether the scipy results are
correct. But if you want to compare packages, the better analog to
matlab symbolic would be sympy and mpmath.

Josef


 If the desire
> is indeed to make Scipy into a dynamic and robust software then various
> constants must be built-into the software and Scipy made to identify such
> expressions.
>
> Many thanks David ( David Cournapeau) for replying to my previous posting
> and confirming my observations about sici.
>
> Regards
>
> Arkapravo
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From dwf at cs.toronto.edu  Sat Nov 28 16:13:20 2009
From: dwf at cs.toronto.edu (David Warde-Farley)
Date: Sat, 28 Nov 2009 16:13:20 -0500
Subject: [SciPy-dev] Constants in Scipy
In-Reply-To: <ba4564350911280250y6227f6d3w1505e98a8baffaec@mail.gmail.com>
References: <ba4564350911280250y6227f6d3w1505e98a8baffaec@mail.gmail.com>
Message-ID: <CE71E059-FA7A-4779-92AA-06CC4D7CEC8F@cs.toronto.edu>

On 28-Nov-09, at 5:50 AM, Arkapravo Bhaumik wrote:

> However, MATLAB in comparison has euler-gamma built-into it and  
> intelligently recognises the expression as it is typed in, Scipy is  
> not yet able to do so.

SciPy is a library, Matlab is an IDE. Intelligent completion is way  
outside SciPy's territory. IPython should be able to tabcomplete any  
constants that are built in, though, if you've done from scipy import  
* or something similar.

As for identifying certain "expressions" as "special integrals",  
Python's architecture makes this basically impossible using the code  
you used. Note that your Matlab example passes a string to int(),  
whereas you are passing quad a Python callable. You would have to  
rewrite quad() to take string expressions rather than arbitrary  
callable functions, which is extremely undesirable because it both  
adds unnecessary bloat to SciPy and (if the usual method were  
unavailable) restricts functionality.

> If the desire is indeed to make Scipy into a dynamic and robust  
> software then various constants must be built-into the software and  
> Scipy made to identify such expressions.


"Identifying expressions" is outside the project's scope. You could  
certainly do it with SymPy, where exp() and the like yield placeholder  
objects rather than functions, but SciPy isn't a symbolic math package.

David


From gael.varoquaux at normalesup.org  Sat Nov 28 17:31:58 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sat, 28 Nov 2009 23:31:58 +0100
Subject: [SciPy-dev] Constants in Scipy
In-Reply-To: <ba4564350911280250y6227f6d3w1505e98a8baffaec@mail.gmail.com>
References: <ba4564350911280250y6227f6d3w1505e98a8baffaec@mail.gmail.com>
Message-ID: <20091128223158.GA13243@phare.normalesup.org>

On Sat, Nov 28, 2009 at 10:50:37AM +0000, Arkapravo Bhaumik wrote:
>    I had been trying to evaluate euler-gamma in Scipy, which is easy
>    [1]http://3chevrons.blogspot.com/2009/10/eulers-gamma.html . However,
>    MATLAB in comparison has euler-gamma built-into it and intelligently
>    recognises the expression as it is typed in, Scipy is not yet able to do
>    so. If the desire is indeed to make Scipy into a dynamic and robust
>    software then various constants must be built-into the software and Scipy
>    made to identify such expressions.

Interative work is more the resort of IPython, as other people have
replied before. If you have a recent version of IPython installed, as
well as scientific Python, you can do:

In [1]: import ipy_constants as C

In [2]: T = 1 s

In [3]: C.h_bar /T
Out[3]: 1.055E-34 J

In other words, you have a lot of dimensioned constants installed
already.

Ga?l


From dsdale24 at gmail.com  Sat Nov 28 18:06:03 2009
From: dsdale24 at gmail.com (Darren Dale)
Date: Sat, 28 Nov 2009 18:06:03 -0500
Subject: [SciPy-dev] Constants in Scipy
In-Reply-To: <20091128223158.GA13243@phare.normalesup.org>
References: <ba4564350911280250y6227f6d3w1505e98a8baffaec@mail.gmail.com>
	<20091128223158.GA13243@phare.normalesup.org>
Message-ID: <a08e5f80911281506n1dbcf70bt9e8d544943c1fbbe@mail.gmail.com>

On Sat, Nov 28, 2009 at 5:31 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Sat, Nov 28, 2009 at 10:50:37AM +0000, Arkapravo Bhaumik wrote:
>> ? ?I had been trying to evaluate euler-gamma in Scipy, which is easy
>> ? ?[1]http://3chevrons.blogspot.com/2009/10/eulers-gamma.html . However,
>> ? ?MATLAB in comparison has euler-gamma built-into it and intelligently
>> ? ?recognises the expression as it is typed in, Scipy is not yet able to do
>> ? ?so. If the desire is indeed to make Scipy into a dynamic and robust
>> ? ?software then various constants must be built-into the software and Scipy
>> ? ?made to identify such expressions.
>
> Interative work is more the resort of IPython, as other people have
> replied before. If you have a recent version of IPython installed, as
> well as scientific Python, you can do:
>
> In [1]: import ipy_constants as C
>
> In [2]: T = 1 s
>
> In [3]: C.h_bar /T
> Out[3]: 1.055E-34 J
>
> In other words, you have a lot of dimensioned constants installed
> already.

You may also want to check out quantities:
http://pypi.python.org/pypi/quantities

Darren


From arkapravobhaumik at gmail.com  Sun Nov 29 13:37:00 2009
From: arkapravobhaumik at gmail.com (Arkapravo Bhaumik)
Date: Sun, 29 Nov 2009 18:37:00 +0000
Subject: [SciPy-dev] Scipy on facebook ?
Message-ID: <ba4564350911291037q5859e7ecw87454f7f1b546b30@mail.gmail.com>

Hello everyone

Thank you for replies to my previous postings.

I recently came across this facebook group ,
http://www.facebook.com/group.php?gid=40809502527&ref=search&sid=1043259783.270759214..1&v=info

Is this the official group ? or there is some other ?

Regards

Arkapravo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091129/7948c3b4/attachment.html>

From charlesr.harris at gmail.com  Sun Nov 29 13:54:17 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Sun, 29 Nov 2009 11:54:17 -0700
Subject: [SciPy-dev] Scipy on facebook ?
In-Reply-To: <ba4564350911291037q5859e7ecw87454f7f1b546b30@mail.gmail.com>
References: <ba4564350911291037q5859e7ecw87454f7f1b546b30@mail.gmail.com>
Message-ID: <e06186140911291054y8427215x63d61c7c5d3d56a2@mail.gmail.com>

On Sun, Nov 29, 2009 at 11:37 AM, Arkapravo Bhaumik <
arkapravobhaumik at gmail.com> wrote:

> Hello everyone
>
> Thank you for replies to my previous postings.
>
> I recently came across this facebook group ,
> http://www.facebook.com/group.php?gid=40809502527&ref=search&sid=1043259783.270759214..1&v=info
>
> Is this the official group ? or there is some other ?
>
>
Heh. I've never heard of it. Not that that means much, but I'm not even sure
what an "official" group would be.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091129/d705947c/attachment.html>

From cimrman3 at ntc.zcu.cz  Mon Nov 30 05:32:08 2009
From: cimrman3 at ntc.zcu.cz (Robert Cimrman)
Date: Mon, 30 Nov 2009 11:32:08 +0100
Subject: [SciPy-dev] Possible fix for
 scipy.sparse.lil_matrix	column-slicing problem
In-Reply-To: <c6d151100911271130t3d2935d6pe00a8d12957ab22c@mail.gmail.com>
References: <c6d151100911240014j3910f744g89bb13b684843267@mail.gmail.com>	<1cd32cbb0911251329se97c355x8ec78903c4260ce@mail.gmail.com>	<c6d151100911261621g2973ceafo1d7c1e092a6c486e@mail.gmail.com>	<d05265cb0911261958o5cedf4efo917c2adee040a463@mail.gmail.com>
	<c6d151100911271130t3d2935d6pe00a8d12957ab22c@mail.gmail.com>
Message-ID: <4B139F28.8060807@ntc.zcu.cz>

Hi Tim,

Tim Victor wrote:
> On Thu, Nov 26, 2009 at 10:58 PM, Nathan Bell wrote:
>> On Thu, Nov 26, 2009 at 7:21 PM, Tim Victor wrote:
>>> I didn't know that I could do that! I've just created an account and
>>> added a comment there with a link to this email thread. Thanks for the
>>> reply.
>>>
>> Nice work!
>>
>> Your patch has been merged into r6121 [1].  The previous
>> implementation was a bit of a nightmare so I'm glad someone finally
>> took the time to simplify it :)
>>
>> Thanks for your contribution.  I hope it is the first of many!
>>
>> [1] http://projects.scipy.org/scipy/changeset/6121
>>
>> --
>> Nathan Bell wnbell at gmail.com
>> http://www.wnbell.com/
> 
> Thanks for the really quick turnaround and the kind words, Nathan. I
> enjoyed working on it. It was kinda like helping someone else on their
> class project when I was a student. That was always more fun than
> doing my own work.
> 
> I might see what other open tickets there are. It seems like a good
> way to learn something about the different parts of the system.
> 
> Best regards,
> 
> Tim Victor

Is there are reason why you removed the special case of x being a scalar, namely:

-        elif issequence(i) and issequence(j):
-            if np.isscalar(x):
-                for ii, jj in zip(i, j):
-                    self._insertat(ii, jj, x)
-            else:
-                for ii, jj, xx in zip(i, j, x):
-                    self._insertat(ii, jj, xx)

This removal broke a code of mine, which now takes forever, and behaves in a 
different way. Try this:

In [1]: import scipy.sparse as spp
In [2]: a = spp.lil_matrix((1000, 1000))
In [3]: a
Out[3]:
<1000x1000 sparse matrix of type '<type 'numpy.float64'>'
         with 0 stored elements in LInked List format>
In [4]: import numpy as np
In [5]: ir = ic = np.arange(1000)
In [6]: a[ir, ic] = 1

The result is a matrix with all the entries set to 1 (= full!), not just the 
diagonal, which was the previous (IMHO good) behaviour. In the real code I do 
not set the diagonal, but some other elements given by two lists ir, ic, but 
the code above shows the symptoms.

I can fix easily my code by not using the LIL matrix:

In [15]: a = spp.coo_matrix((np.ones((ir.shape[0],)), (ir, ic)))
In [16]: a
Out[16]:
<1000x1000 sparse matrix of type '<type 'numpy.float64'>'
         with 1000 stored elements in COOrdinate format>

but I wonder, if the above change in behaviour was intended...

cheers,
r.


From sturla at molden.no  Mon Nov 30 08:54:48 2009
From: sturla at molden.no (Sturla Molden)
Date: Mon, 30 Nov 2009 14:54:48 +0100
Subject: [SciPy-dev] Scipy on facebook ?
In-Reply-To: <e06186140911291054y8427215x63d61c7c5d3d56a2@mail.gmail.com>
References: <ba4564350911291037q5859e7ecw87454f7f1b546b30@mail.gmail.com>
	<e06186140911291054y8427215x63d61c7c5d3d56a2@mail.gmail.com>
Message-ID: <4B13CEA8.9040408@molden.no>

Charles R Harris skrev:
>
> Heh. I've never heard of it. Not that that means much, but I'm not 
> even sure what an "official" group would be.
An official group would be an entry under "pages" instead of "groups". 
Not that I care.

S.M.


From benny.malengier at gmail.com  Mon Nov 30 09:02:20 2009
From: benny.malengier at gmail.com (Benny Malengier)
Date: Mon, 30 Nov 2009 15:02:20 +0100
Subject: [SciPy-dev] slow setitem
Message-ID: <bcafe8290911300602n23b1c61bhac84ef8acdd14956@mail.gmail.com>

A question about the sparse matrix and suggestion for speed improvement.

I have a code of 1000*1000 sparse matrix of 11 full diagonals. Using csr.
Assigning the matrix via setdiags takes 14 seconds, of which 13
seconds is in the check_format function of sparse/base.py.

This is due to setdiag doing:

     self[i, i + k] = v

while setitem in compressed.py always does a

     self.check_format(full_check=True)

Removing the check_format reduces assignment of the matrix to 1 second.
Is it really needed that the assignmentof setdiag is again checked via
check_format?
Allowing for a setitem that does not call check_format would be usefull.

One could set a dirty flag on a setitem call, and do a check_format
only when a computation is performed and the flag is dirty. On the
other hand, I'm not making errors, and to have a flag like
NOCHECKS=TRUE would be handy as it would speed up the code a lot.
I could create a solution that is acceptable for scipy, but then I'd
need to know how such a solution should look like.

Note that there are quite some zeroes in my diagonals now too, that
are now set to 0., if setitem would be fast, I could drop setdiag
call, and do a fast setitem call. Or are sparse matrixes supposed to
be used differently?

Benny


From dsdale24 at gmail.com  Mon Nov 30 16:53:14 2009
From: dsdale24 at gmail.com (Darren Dale)
Date: Mon, 30 Nov 2009 16:53:14 -0500
Subject: [SciPy-dev] trouble building from svn
Message-ID: <a08e5f80911301353u23203421m59812c7ba8c84496@mail.gmail.com>

I am attempting to build scipy from svn sources on OS X 10.6. I get
the following error, could anyone please advise?

C compiler: gcc-4.2 -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes
-arch x86_64 -pipe

compile options: '-Iscipy/fftpack/src
-Ibuild/src.macosx-10.6-universal-2.6
-I/Users/darren/.local/lib/python2.6/site-packages/numpy/core/include
-I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6
-c'
/usr/local/bin/gfortran -Wall -arch x86_64
build/temp.macosx-10.6-universal-2.6/build/src.macosx-10.6-universal-2.6/scipy/fftpack/_fftpackmodule.o
build/temp.macosx-10.6-universal-2.6/scipy/fftpack/src/zfft.o
build/temp.macosx-10.6-universal-2.6/scipy/fftpack/src/drfft.o
build/temp.macosx-10.6-universal-2.6/scipy/fftpack/src/zrfft.o
build/temp.macosx-10.6-universal-2.6/scipy/fftpack/src/zfftnd.o
build/temp.macosx-10.6-universal-2.6/build/src.macosx-10.6-universal-2.6/scipy/fftpack/src/dct.o
build/temp.macosx-10.6-universal-2.6/build/src.macosx-10.6-universal-2.6/fortranobject.o
-L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3/x86_64
-Lbuild/temp.macosx-10.6-universal-2.6 -ldfftpack -lfftpack -lgfortran
-o build/lib.macosx-10.6-universal-2.6/scipy/fftpack/_fftpack.so
Undefined symbols:
  "_Py_BuildValue", referenced from:
      _f2py_rout__fftpack_destroy_dct1_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_dct2_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_ddct1_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_ddct2_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_rfft_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_cfftnd_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_cfft_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_drfft_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_zfftnd_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_zfft_cache in _fftpackmodule.o
      _f2py_rout__fftpack_dct3 in _fftpackmodule.o
      _f2py_rout__fftpack_dct2 in _fftpackmodule.o
      _f2py_rout__fftpack_dct1 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct3 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct2 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct1 in _fftpackmodule.o
      _f2py_rout__fftpack_crfft in _fftpackmodule.o
      _f2py_rout__fftpack_rfft in _fftpackmodule.o
      _f2py_rout__fftpack_cfft in _fftpackmodule.o
      _f2py_rout__fftpack_zrfft in _fftpackmodule.o
      _f2py_rout__fftpack_drfft in _fftpackmodule.o
      _f2py_rout__fftpack_zfft in _fftpackmodule.o
      _f2py_rout__fftpack_cfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_zfftnd in _fftpackmodule.o
  "_PyExc_RuntimeError", referenced from:
      _init_fftpack in _fftpackmodule.o
      _init_fftpack in _fftpackmodule.o
      _fortran_call in fortranobject.o
  "_PyExc_ImportError", referenced from:
      _init_fftpack in _fftpackmodule.o
  "_PyCObject_Type", referenced from:
      _init_fftpack in _fftpackmodule.o
  "_PyString_ConcatAndDel", referenced from:
      _fortran_getattr in fortranobject.o
  "_MAIN__", referenced from:
      _main in libgfortranbegin.a(fmain.o)
  "_PyImport_ImportModule", referenced from:
      _init_fftpack in _fftpackmodule.o
  "_PyArg_ParseTupleAndKeywords", referenced from:
      _f2py_rout__fftpack_destroy_dct1_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_dct2_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_ddct1_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_ddct2_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_rfft_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_cfftnd_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_cfft_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_drfft_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_zfftnd_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_zfft_cache in _fftpackmodule.o
      _f2py_rout__fftpack_dct3 in _fftpackmodule.o
      _f2py_rout__fftpack_dct2 in _fftpackmodule.o
      _f2py_rout__fftpack_dct1 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct3 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct2 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct1 in _fftpackmodule.o
      _f2py_rout__fftpack_crfft in _fftpackmodule.o
      _f2py_rout__fftpack_rfft in _fftpackmodule.o
      _f2py_rout__fftpack_cfft in _fftpackmodule.o
      _f2py_rout__fftpack_zrfft in _fftpackmodule.o
      _f2py_rout__fftpack_drfft in _fftpackmodule.o
      _f2py_rout__fftpack_zfft in _fftpackmodule.o
      _f2py_rout__fftpack_cfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_zfftnd in _fftpackmodule.o
  "_PyType_Type", referenced from:
      _init_fftpack in _fftpackmodule.o
  "_PySequence_GetItem", referenced from:
      _int_from_pyobj in _fftpackmodule.o
  "_PyMem_Free", referenced from:
      _fortran_dealloc in fortranobject.o
  "_PyErr_NewException", referenced from:
      _init_fftpack in _fftpackmodule.o
  "_PyObject_Type", referenced from:
      _array_from_pyobj in fortranobject.o
  "_PyErr_Clear", referenced from:
      _int_from_pyobj in _fftpackmodule.o
      _F2PyDict_SetItemString in fortranobject.o
  "_PyExc_AttributeError", referenced from:
      _fortran_setattr in fortranobject.o
  "_PyDict_SetItemString", referenced from:
      _init_fftpack in _fftpackmodule.o
      _init_fftpack in _fftpackmodule.o
      _init_fftpack in _fftpackmodule.o
      _fortran_getattr in fortranobject.o
      _fortran_getattr in fortranobject.o
      _PyFortranObject_New in fortranobject.o
      _F2PyDict_SetItemString in fortranobject.o
      _fortran_setattr in fortranobject.o
  "_PyCObject_AsVoidPtr", referenced from:
      _init_fftpack in _fftpackmodule.o
  "_PyErr_Format", referenced from:
      _init_fftpack in _fftpackmodule.o
      _init_fftpack in _fftpackmodule.o
      _fortran_call in fortranobject.o
  "_PyString_FromString", referenced from:
      _init_fftpack in _fftpackmodule.o
      _init_fftpack in _fftpackmodule.o
      _fortran_getattr in fortranobject.o
      _fortran_getattr in fortranobject.o
  "_PyObject_Str", referenced from:
      _array_from_pyobj in fortranobject.o
  "_PySequence_Check", referenced from:
      _int_from_pyobj in _fftpackmodule.o
  "_PyObject_GetAttrString", referenced from:
      _int_from_pyobj in _fftpackmodule.o
      _init_fftpack in _fftpackmodule.o
  "_PyExc_TypeError", referenced from:
      _fortran_call in fortranobject.o
      _array_from_pyobj in fortranobject.o
  "_PyDict_DelItemString", referenced from:
      _fortran_setattr in fortranobject.o
  "_PyString_AsString", referenced from:
      _array_from_pyobj in fortranobject.o
  "_PyDict_New", referenced from:
      _PyFortranObject_NewAsAttr in fortranobject.o
      _PyFortranObject_New in fortranobject.o
      _fortran_setattr in fortranobject.o
  "_PyErr_Occurred", referenced from:
      _f2py_rout__fftpack_destroy_dct1_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_dct2_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_ddct1_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_ddct2_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_rfft_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_cfftnd_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_cfft_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_drfft_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_zfftnd_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_zfft_cache in _fftpackmodule.o
      _int_from_pyobj in _fftpackmodule.o
      _f2py_rout__fftpack_dct3 in _fftpackmodule.o
      _f2py_rout__fftpack_dct3 in _fftpackmodule.o
      _f2py_rout__fftpack_dct2 in _fftpackmodule.o
      _f2py_rout__fftpack_dct2 in _fftpackmodule.o
      _f2py_rout__fftpack_dct1 in _fftpackmodule.o
      _f2py_rout__fftpack_dct1 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct3 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct3 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct2 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct2 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct1 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct1 in _fftpackmodule.o
      _f2py_rout__fftpack_crfft in _fftpackmodule.o
      _f2py_rout__fftpack_crfft in _fftpackmodule.o
      _f2py_rout__fftpack_rfft in _fftpackmodule.o
      _f2py_rout__fftpack_rfft in _fftpackmodule.o
      _f2py_rout__fftpack_cfft in _fftpackmodule.o
      _f2py_rout__fftpack_cfft in _fftpackmodule.o
      _f2py_rout__fftpack_zrfft in _fftpackmodule.o
      _f2py_rout__fftpack_zrfft in _fftpackmodule.o
      _f2py_rout__fftpack_drfft in _fftpackmodule.o
      _f2py_rout__fftpack_drfft in _fftpackmodule.o
      _f2py_rout__fftpack_zfft in _fftpackmodule.o
      _f2py_rout__fftpack_zfft in _fftpackmodule.o
      _f2py_rout__fftpack_cfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_cfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_cfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_cfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_zfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_zfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_zfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_zfftnd in _fftpackmodule.o
      _init_fftpack in _fftpackmodule.o
      _F2PyDict_SetItemString in fortranobject.o
  "_PyType_IsSubtype", referenced from:
      _int_from_pyobj in _fftpackmodule.o
      _array_from_pyobj in fortranobject.o
  "_PyDict_GetItemString", referenced from:
      _fortran_getattr in fortranobject.o
  "__PyObject_New", referenced from:
      _PyFortranObject_NewAsAttr in fortranobject.o
      _PyFortranObject_New in fortranobject.o
  "_Py_InitModule4_64", referenced from:
      _init_fftpack in _fftpackmodule.o
  "_PyCObject_FromVoidPtr", referenced from:
      _fortran_getattr in fortranobject.o
  "_PyErr_SetString", referenced from:
      _int_from_pyobj in _fftpackmodule.o
      _f2py_rout__fftpack_dct3 in _fftpackmodule.o
      _f2py_rout__fftpack_dct2 in _fftpackmodule.o
      _f2py_rout__fftpack_dct1 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct3 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct2 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct1 in _fftpackmodule.o
      _f2py_rout__fftpack_crfft in _fftpackmodule.o
      _f2py_rout__fftpack_rfft in _fftpackmodule.o
      _f2py_rout__fftpack_cfft in _fftpackmodule.o
      _f2py_rout__fftpack_zrfft in _fftpackmodule.o
      _f2py_rout__fftpack_drfft in _fftpackmodule.o
      _f2py_rout__fftpack_zfft in _fftpackmodule.o
      _f2py_rout__fftpack_cfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_cfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_cfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_cfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_zfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_zfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_zfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_zfftnd in _fftpackmodule.o
      _init_fftpack in _fftpackmodule.o
      _array_from_pyobj in fortranobject.o
      _fortran_setattr in fortranobject.o
  "_Py_FindMethod", referenced from:
      _fortran_getattr in fortranobject.o
  "_PyNumber_Int", referenced from:
      _int_from_pyobj in _fftpackmodule.o
  "_PyComplex_Type", referenced from:
      _int_from_pyobj in _fftpackmodule.o
  "__Py_NoneStruct", referenced from:
      _f2py_rout__fftpack_dct3 in _fftpackmodule.o
      _f2py_rout__fftpack_dct2 in _fftpackmodule.o
      _f2py_rout__fftpack_dct1 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct3 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct2 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct1 in _fftpackmodule.o
      _f2py_rout__fftpack_crfft in _fftpackmodule.o
      _f2py_rout__fftpack_rfft in _fftpackmodule.o
      _f2py_rout__fftpack_cfft in _fftpackmodule.o
      _f2py_rout__fftpack_zrfft in _fftpackmodule.o
      _f2py_rout__fftpack_drfft in _fftpackmodule.o
      _f2py_rout__fftpack_zfft in _fftpackmodule.o
      _f2py_rout__fftpack_cfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_zfftnd in _fftpackmodule.o
      _fortran_getattr in fortranobject.o
      _array_from_pyobj in fortranobject.o
      _array_from_pyobj in fortranobject.o
      _fortran_setattr in fortranobject.o
  "_PyExc_ValueError", referenced from:
      _array_from_pyobj in fortranobject.o
  "_PyModule_GetDict", referenced from:
      _init_fftpack in _fftpackmodule.o
  "_PyErr_Print", referenced from:
      _init_fftpack in _fftpackmodule.o
      _F2PyDict_SetItemString in fortranobject.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
Undefined symbols:
  "_Py_BuildValue", referenced from:
      _f2py_rout__fftpack_destroy_dct1_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_dct2_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_ddct1_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_ddct2_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_rfft_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_cfftnd_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_cfft_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_drfft_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_zfftnd_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_zfft_cache in _fftpackmodule.o
      _f2py_rout__fftpack_dct3 in _fftpackmodule.o
      _f2py_rout__fftpack_dct2 in _fftpackmodule.o
      _f2py_rout__fftpack_dct1 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct3 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct2 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct1 in _fftpackmodule.o
      _f2py_rout__fftpack_crfft in _fftpackmodule.o
      _f2py_rout__fftpack_rfft in _fftpackmodule.o
      _f2py_rout__fftpack_cfft in _fftpackmodule.o
      _f2py_rout__fftpack_zrfft in _fftpackmodule.o
      _f2py_rout__fftpack_drfft in _fftpackmodule.o
      _f2py_rout__fftpack_zfft in _fftpackmodule.o
      _f2py_rout__fftpack_cfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_zfftnd in _fftpackmodule.o
  "_PyExc_RuntimeError", referenced from:
      _init_fftpack in _fftpackmodule.o
      _init_fftpack in _fftpackmodule.o
      _fortran_call in fortranobject.o
  "_PyExc_ImportError", referenced from:
      _init_fftpack in _fftpackmodule.o
  "_PyCObject_Type", referenced from:
      _init_fftpack in _fftpackmodule.o
  "_PyString_ConcatAndDel", referenced from:
      _fortran_getattr in fortranobject.o
  "_MAIN__", referenced from:
      _main in libgfortranbegin.a(fmain.o)
  "_PyImport_ImportModule", referenced from:
      _init_fftpack in _fftpackmodule.o
  "_PyArg_ParseTupleAndKeywords", referenced from:
      _f2py_rout__fftpack_destroy_dct1_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_dct2_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_ddct1_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_ddct2_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_rfft_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_cfftnd_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_cfft_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_drfft_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_zfftnd_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_zfft_cache in _fftpackmodule.o
      _f2py_rout__fftpack_dct3 in _fftpackmodule.o
      _f2py_rout__fftpack_dct2 in _fftpackmodule.o
      _f2py_rout__fftpack_dct1 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct3 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct2 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct1 in _fftpackmodule.o
      _f2py_rout__fftpack_crfft in _fftpackmodule.o
      _f2py_rout__fftpack_rfft in _fftpackmodule.o
      _f2py_rout__fftpack_cfft in _fftpackmodule.o
      _f2py_rout__fftpack_zrfft in _fftpackmodule.o
      _f2py_rout__fftpack_drfft in _fftpackmodule.o
      _f2py_rout__fftpack_zfft in _fftpackmodule.o
      _f2py_rout__fftpack_cfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_zfftnd in _fftpackmodule.o
  "_PyType_Type", referenced from:
      _init_fftpack in _fftpackmodule.o
  "_PySequence_GetItem", referenced from:
      _int_from_pyobj in _fftpackmodule.o
  "_PyMem_Free", referenced from:
      _fortran_dealloc in fortranobject.o
  "_PyErr_NewException", referenced from:
      _init_fftpack in _fftpackmodule.o
  "_PyObject_Type", referenced from:
      _array_from_pyobj in fortranobject.o
  "_PyErr_Clear", referenced from:
      _int_from_pyobj in _fftpackmodule.o
      _F2PyDict_SetItemString in fortranobject.o
  "_PyExc_AttributeError", referenced from:
      _fortran_setattr in fortranobject.o
  "_PyDict_SetItemString", referenced from:
      _init_fftpack in _fftpackmodule.o
      _init_fftpack in _fftpackmodule.o
      _init_fftpack in _fftpackmodule.o
      _fortran_getattr in fortranobject.o
      _fortran_getattr in fortranobject.o
      _PyFortranObject_New in fortranobject.o
      _F2PyDict_SetItemString in fortranobject.o
      _fortran_setattr in fortranobject.o
  "_PyCObject_AsVoidPtr", referenced from:
      _init_fftpack in _fftpackmodule.o
  "_PyErr_Format", referenced from:
      _init_fftpack in _fftpackmodule.o
      _init_fftpack in _fftpackmodule.o
      _fortran_call in fortranobject.o
  "_PyString_FromString", referenced from:
      _init_fftpack in _fftpackmodule.o
      _init_fftpack in _fftpackmodule.o
      _fortran_getattr in fortranobject.o
      _fortran_getattr in fortranobject.o
  "_PyObject_Str", referenced from:
      _array_from_pyobj in fortranobject.o
  "_PySequence_Check", referenced from:
      _int_from_pyobj in _fftpackmodule.o
  "_PyObject_GetAttrString", referenced from:
      _int_from_pyobj in _fftpackmodule.o
      _init_fftpack in _fftpackmodule.o
  "_PyExc_TypeError", referenced from:
      _fortran_call in fortranobject.o
      _array_from_pyobj in fortranobject.o
  "_PyDict_DelItemString", referenced from:
      _fortran_setattr in fortranobject.o
  "_PyString_AsString", referenced from:
      _array_from_pyobj in fortranobject.o
  "_PyDict_New", referenced from:
      _PyFortranObject_NewAsAttr in fortranobject.o
      _PyFortranObject_New in fortranobject.o
      _fortran_setattr in fortranobject.o
  "_PyErr_Occurred", referenced from:
      _f2py_rout__fftpack_destroy_dct1_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_dct2_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_ddct1_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_ddct2_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_rfft_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_cfftnd_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_cfft_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_drfft_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_zfftnd_cache in _fftpackmodule.o
      _f2py_rout__fftpack_destroy_zfft_cache in _fftpackmodule.o
      _int_from_pyobj in _fftpackmodule.o
      _f2py_rout__fftpack_dct3 in _fftpackmodule.o
      _f2py_rout__fftpack_dct3 in _fftpackmodule.o
      _f2py_rout__fftpack_dct2 in _fftpackmodule.o
      _f2py_rout__fftpack_dct2 in _fftpackmodule.o
      _f2py_rout__fftpack_dct1 in _fftpackmodule.o
      _f2py_rout__fftpack_dct1 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct3 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct3 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct2 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct2 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct1 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct1 in _fftpackmodule.o
      _f2py_rout__fftpack_crfft in _fftpackmodule.o
      _f2py_rout__fftpack_crfft in _fftpackmodule.o
      _f2py_rout__fftpack_rfft in _fftpackmodule.o
      _f2py_rout__fftpack_rfft in _fftpackmodule.o
      _f2py_rout__fftpack_cfft in _fftpackmodule.o
      _f2py_rout__fftpack_cfft in _fftpackmodule.o
      _f2py_rout__fftpack_zrfft in _fftpackmodule.o
      _f2py_rout__fftpack_zrfft in _fftpackmodule.o
      _f2py_rout__fftpack_drfft in _fftpackmodule.o
      _f2py_rout__fftpack_drfft in _fftpackmodule.o
      _f2py_rout__fftpack_zfft in _fftpackmodule.o
      _f2py_rout__fftpack_zfft in _fftpackmodule.o
      _f2py_rout__fftpack_cfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_cfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_cfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_cfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_zfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_zfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_zfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_zfftnd in _fftpackmodule.o
      _init_fftpack in _fftpackmodule.o
      _F2PyDict_SetItemString in fortranobject.o
  "_PyType_IsSubtype", referenced from:
      _int_from_pyobj in _fftpackmodule.o
      _array_from_pyobj in fortranobject.o
  "_PyDict_GetItemString", referenced from:
      _fortran_getattr in fortranobject.o
  "__PyObject_New", referenced from:
      _PyFortranObject_NewAsAttr in fortranobject.o
      _PyFortranObject_New in fortranobject.o
  "_Py_InitModule4_64", referenced from:
      _init_fftpack in _fftpackmodule.o
  "_PyCObject_FromVoidPtr", referenced from:
      _fortran_getattr in fortranobject.o
  "_PyErr_SetString", referenced from:
      _int_from_pyobj in _fftpackmodule.o
      _f2py_rout__fftpack_dct3 in _fftpackmodule.o
      _f2py_rout__fftpack_dct2 in _fftpackmodule.o
      _f2py_rout__fftpack_dct1 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct3 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct2 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct1 in _fftpackmodule.o
      _f2py_rout__fftpack_crfft in _fftpackmodule.o
      _f2py_rout__fftpack_rfft in _fftpackmodule.o
      _f2py_rout__fftpack_cfft in _fftpackmodule.o
      _f2py_rout__fftpack_zrfft in _fftpackmodule.o
      _f2py_rout__fftpack_drfft in _fftpackmodule.o
      _f2py_rout__fftpack_zfft in _fftpackmodule.o
      _f2py_rout__fftpack_cfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_cfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_cfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_cfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_zfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_zfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_zfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_zfftnd in _fftpackmodule.o
      _init_fftpack in _fftpackmodule.o
      _array_from_pyobj in fortranobject.o
      _fortran_setattr in fortranobject.o
  "_Py_FindMethod", referenced from:
      _fortran_getattr in fortranobject.o
  "_PyNumber_Int", referenced from:
      _int_from_pyobj in _fftpackmodule.o
  "_PyComplex_Type", referenced from:
      _int_from_pyobj in _fftpackmodule.o
  "__Py_NoneStruct", referenced from:
      _f2py_rout__fftpack_dct3 in _fftpackmodule.o
      _f2py_rout__fftpack_dct2 in _fftpackmodule.o
      _f2py_rout__fftpack_dct1 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct3 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct2 in _fftpackmodule.o
      _f2py_rout__fftpack_ddct1 in _fftpackmodule.o
      _f2py_rout__fftpack_crfft in _fftpackmodule.o
      _f2py_rout__fftpack_rfft in _fftpackmodule.o
      _f2py_rout__fftpack_cfft in _fftpackmodule.o
      _f2py_rout__fftpack_zrfft in _fftpackmodule.o
      _f2py_rout__fftpack_drfft in _fftpackmodule.o
      _f2py_rout__fftpack_zfft in _fftpackmodule.o
      _f2py_rout__fftpack_cfftnd in _fftpackmodule.o
      _f2py_rout__fftpack_zfftnd in _fftpackmodule.o
      _fortran_getattr in fortranobject.o
      _array_from_pyobj in fortranobject.o
      _array_from_pyobj in fortranobject.o
      _fortran_setattr in fortranobject.o
  "_PyExc_ValueError", referenced from:
      _array_from_pyobj in fortranobject.o
  "_PyModule_GetDict", referenced from:
      _init_fftpack in _fftpackmodule.o
  "_PyErr_Print", referenced from:
      _init_fftpack in _fftpackmodule.o
      _F2PyDict_SetItemString in fortranobject.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
error: Command "/usr/local/bin/gfortran -Wall -arch x86_64
build/temp.macosx-10.6-universal-2.6/build/src.macosx-10.6-universal-2.6/scipy/fftpack/_fftpackmodule.o
build/temp.macosx-10.6-universal-2.6/scipy/fftpack/src/zfft.o
build/temp.macosx-10.6-universal-2.6/scipy/fftpack/src/drfft.o
build/temp.macosx-10.6-universal-2.6/scipy/fftpack/src/zrfft.o
build/temp.macosx-10.6-universal-2.6/scipy/fftpack/src/zfftnd.o
build/temp.macosx-10.6-universal-2.6/build/src.macosx-10.6-universal-2.6/scipy/fftpack/src/dct.o
build/temp.macosx-10.6-universal-2.6/build/src.macosx-10.6-universal-2.6/fortranobject.o
-L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3/x86_64
-Lbuild/temp.macosx-10.6-universal-2.6 -ldfftpack -lfftpack -lgfortran
-o build/lib.macosx-10.6-universal-2.6/scipy/fftpack/_fftpack.so"
failed with exit status 1


From charlesr.harris at gmail.com  Mon Nov 30 19:15:26 2009
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Mon, 30 Nov 2009 17:15:26 -0700
Subject: [SciPy-dev] trouble building from svn
In-Reply-To: <a08e5f80911301353u23203421m59812c7ba8c84496@mail.gmail.com>
References: <a08e5f80911301353u23203421m59812c7ba8c84496@mail.gmail.com>
Message-ID: <e06186140911301615t60633eddt51aff6343f0d47b2@mail.gmail.com>

On Mon, Nov 30, 2009 at 2:53 PM, Darren Dale <dsdale24 at gmail.com> wrote:

> I am attempting to build scipy from svn sources on OS X 10.6. I get
> the following error, could anyone please advise?
>
> C compiler: gcc-4.2 -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes
> -arch x86_64 -pipe
>
>
What numpy version?

<snip>

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091130/f730a63e/attachment.html>

From david at ar.media.kyoto-u.ac.jp  Mon Nov 30 23:37:06 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Tue, 01 Dec 2009 13:37:06 +0900
Subject: [SciPy-dev] trouble building from svn
In-Reply-To: <a08e5f80911301353u23203421m59812c7ba8c84496@mail.gmail.com>
References: <a08e5f80911301353u23203421m59812c7ba8c84496@mail.gmail.com>
Message-ID: <4B149D72.8010007@ar.media.kyoto-u.ac.jp>

Darren Dale wrote:
> I am attempting to build scipy from svn sources on OS X 10.6. I get
> the following error, could anyone please advise?
>
> C compiler: gcc-4.2 -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes
> -arch x86_64 -pipe
>   

Most likely you have LDFLAGS defined in your environment, which screws
up the build. LDFLAGS (and other similar variables) do not work as
expected with distutils, they *override* the options instead of
completing them.

The actual error is that the link step is missing the -shared option,
hence the missing errors, as the linker tries to build an executable.

cheers,

David