numpy-discussion — Discussion list for all users of Numerical Python

Re: [Numpy-discussion] Number of digits

[Robert K. <rob...@gm...>]

Robert Kern wrote:
> Tim Hochberg wrote:
>> Nils Wagner wrote:
>>> Hi all,
>>>
>>> how can I increase the number of digits in the output of str(.) ?
>>>   
>> You can't as far as I know. For floats, you can use "%.nf". For example:
>>
>> "%.13f" % 493.4802200544680
> 
> The problem is is that he doesn't have a float. He has one of our float64scalar 
> objects. The str() of a real Python float will give as many digits as are 
> necessary to recreate number and no more (or maybe one or two more). A str() of 
> a float64scalar will round according to some rule that I haven't figured out, 
> yet. It doesn't seem to be configurable with numpy.set_printoptions().

No, that's entirely wrong. Please ignore the ravings of a madman.

-- 
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

Re: [Numpy-discussion] Number of digits

[David D. <dav...@lo...>]

On Mon, Jul 10, 2006 at 08:46:33AM -0500, Robert Kern wrote:
> Tim Hochberg wrote:
> > Nils Wagner wrote:
> >> Hi all,
> >>
> >> how can I increase the number of digits in the output of str(.) ?
> >>  =20
> > You can't as far as I know. For floats, you can use "%.nf". For example:
> >=20
> > "%.13f" % 493.4802200544680
>=20
> The problem is is that he doesn't have a float. He has one of our float64=
scalar=20
> objects. The str() of a real Python float will give as many digits as are=
=20
> necessary to recreate number and no more (or maybe one or two more). A st=
r() of=20
> a float64scalar will round according to some rule that I haven't figured =
out,=20
> yet. It doesn't seem to be configurable with numpy.set_printoptions().

This is a different ptoblem from the one exposed by Nils. I mean, tha
fact that str() on numpy.float64 objects is somewhat obscure is a
problem that should obviously be addressed some day. However, as far as
I understand Nils' message, the "%.13f" trick is enough for what he
need. But I may be wrong... He just want to "increase the number of
digits", not have the "optimal" number of digits (as long as this is
meaningfull).

But I may have missed something.

David

--=20
David Douard                             LOGILAB, Paris (France)
Formations Python, Zope, Plone, Debian : http://www.logilab.fr/formations
D=E9veloppement logiciel sur mesure :      http://www.logilab.fr/services
Informatique scientifique :              http://www.logilab.fr/science

Re: [Numpy-discussion] Number of digits

[Robert K. <rob...@gm...>]

Tim Hochberg wrote:
> Nils Wagner wrote:
>> Hi all,
>>
>> how can I increase the number of digits in the output of str(.) ?
>>   
> You can't as far as I know. For floats, you can use "%.nf". For example:
> 
> "%.13f" % 493.4802200544680

The problem is is that he doesn't have a float. He has one of our float64scalar 
objects. The str() of a real Python float will give as many digits as are 
necessary to recreate number and no more (or maybe one or two more). A str() of 
a float64scalar will round according to some rule that I haven't figured out, 
yet. It doesn't seem to be configurable with numpy.set_printoptions().

-- 
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

Re: [Numpy-discussion] Number of digits

[Tim H. <tim...@co...>]

Nils Wagner wrote:
> Hi all,
>
> how can I increase the number of digits in the output of str(.) ?
>   
You can't as far as I know. For floats, you can use "%.nf". For example:

"%.13f" % 493.4802200544680

-tim


>   
>>>> lam**2
>>>>         
> 493.48022005446808
>   
>>>> str(lam**2)
>>>>         
> '493.480220054'
>
> '493.4802200544680' would be fine.
>
> Nils
>
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>
>   

Re: [Numpy-discussion] Number of digits

[David D. <dav...@lo...>]

On Mon, Jul 10, 2006 at 02:33:52PM +0200, Nils Wagner wrote:
> Hi all,
>=20
> how can I increase the number of digits in the output of str(.) ?
>=20
> >>> lam**2
> 493.48022005446808
> >>> str(lam**2)
> '493.480220054'
>=20
> '493.4802200544680' would be fine.

Maybe something like=20
>>> '%.13f'%(lam**2)

David

--=20
David Douard                             LOGILAB, Paris (France)
Formations Python, Zope, Plone, Debian : http://www.logilab.fr/formations
D=E9veloppement logiciel sur mesure :      http://www.logilab.fr/services
Informatique scientifique :              http://www.logilab.fr/science

[Numpy-discussion] Number of digits

[Nils W. <nw...@ia...>]

Hi all,

how can I increase the number of digits in the output of str(.) ?

>>> lam**2
493.48022005446808
>>> str(lam**2)
'493.480220054'

'493.4802200544680' would be fine.

Nils

Re: [Numpy-discussion] Converting a list

[Robert K. <rob...@gm...>]

Nils Wagner wrote:
> Hi all,
> 
> I have a list consisting of arrays of different size
> 
> data =  [array([-1.        +0.j, -1.33333333+0.j, -1.66666667+0.j]),
> array([-2.+0.j        , -2.-0.66666667j, -2.-1.33333333j]),
> array([-2.        -2.j, -1.33333333-2.j, -0.66666667-2.j]), array([
> 0.-2.j        ,  0.-1.66666667j,  0.-1.33333333j]), array([ 
> 6.12323400e-17-1.j        ,  -2.58819045e-01-0.96592583j,
>         -5.00000000e-01-0.8660254j ,  -7.07106781e-01-0.70710678j,
>         -8.66025404e-01-0.5j       ,  -9.65925826e-01-0.25881905j])]
> 
> type(data) =  <type 'list'>
> 
> shape(data) results in
> 
> shape(data) =
> Traceback (most recent call last):
>   File "sinai.py", line 107, in ?
>     p = polygon(P)
>   File "sinai.py", line 67, in polygon
>     print 'shape(data) = ',shape(data)
>   File "/usr/lib64/python2.4/site-packages/numpy/core/fromnumeric.py",
> line 258, in shape
>     result = asarray(a).shape
>   File "/usr/lib64/python2.4/site-packages/numpy/core/numeric.py", line
> 119, in asarray
>     return array(a, dtype, copy=False, order=order)
> TypeError: a float is required
> 
> Is this a bug ?

The error message is unhelpful, certainly, but the *fact* that an exception is 
raised is not a bug.

-- 
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

[Numpy-discussion] Converting a list

[Nils W. <nw...@ia...>]

Hi all,

I have a list consisting of arrays of different size

data =  [array([-1.        +0.j, -1.33333333+0.j, -1.66666667+0.j]),
array([-2.+0.j        , -2.-0.66666667j, -2.-1.33333333j]),
array([-2.        -2.j, -1.33333333-2.j, -0.66666667-2.j]), array([
0.-2.j        ,  0.-1.66666667j,  0.-1.33333333j]), array([ 
6.12323400e-17-1.j        ,  -2.58819045e-01-0.96592583j,
        -5.00000000e-01-0.8660254j ,  -7.07106781e-01-0.70710678j,
        -8.66025404e-01-0.5j       ,  -9.65925826e-01-0.25881905j])]

type(data) =  <type 'list'>

shape(data) results in

shape(data) =
Traceback (most recent call last):
  File "sinai.py", line 107, in ?
    p = polygon(P)
  File "sinai.py", line 67, in polygon
    print 'shape(data) = ',shape(data)
  File "/usr/lib64/python2.4/site-packages/numpy/core/fromnumeric.py",
line 258, in shape
    result = asarray(a).shape
  File "/usr/lib64/python2.4/site-packages/numpy/core/numeric.py", line
119, in asarray
    return array(a, dtype, copy=False, order=order)
TypeError: a float is required

Is this a bug ?

Nils

Re: [Numpy-discussion] NumPy beta release plan

[Christian K. <ck...@ho...>]

Charles R Harris <charlesr.harris <at> gmail.com> writes:

> 
> 
> Hi,
> 
> On 7/9/06, Robert Kern <robert.kern <at> gmail.com> wrote:
> Christian Kristukat wrote:> Robert Kern <robert.kern <at> gmail.com>
writes:>>> I believe that Debian recently changed its configuration to default to
> >> /usr/local (for good reason!). Perhaps that is causing what you see.>> I
just found out that this is feature/bug of opensuse 10.1. I'm beginning to> like
it but can you tell what you have to do to force it install to /usr/lib?
> 
> 
> Suse does that, but so does python by default if you compile it from scratch;

I think every autoconf managed source package out there will install itself to
/usr/local if you don't specify the --prefix. So this is not a python thing. 

> Suse is just following the path of least resistence. I don't like it much, I 
> think distributions should leave /usr/local empty, but when you compile your
> own stuff it should arguably end up in /usr/local by default.

The python modules shipped with suse are installed where python resides and that
is in /usr. But beginning with suse 10.1 user installed packages go to
/usr/local. What I don't like about that method so much is, that when you build
a rpm with distutils it gets installed in /usr/local/, too, even though the
system does handle third party rpms in the systems rpm database.

Christian

Re: [Numpy-discussion] logspace behaviour/documentation

[Arnd B. <arn...@we...>]

Hi Alan,

sorry, for answering so late - your message slipped through ...

On Fri, 30 Jun 2006, Alan Isaac wrote:

> On Fri, 30 Jun 2006, T) Arnd Baecker wrote:
> > I am wondering a bit about the the behaviour of logspace:
>
> http://www.mathworks.com/access/helpdesk/help/techdoc/ref/logspace.html
>
> fwiw,

Alright, if one wants to keep compatibility with matlab, the behaviour
of logspace should be unchanged.

I'd suggest that something along

def logspace(start,stop,num=50,endpoint=True,base=10.0):
    """Evenly spaced numbers on a logarithmic scale.

    Return 'int(num)' evenly spaced samples on a logarithmic scale from
    'base'**'start' to 'base'**'stop'.  If 'endpoint' is True, the
    last sample is 'base'**'stop'."""

is clearer than the present one

Docstring:
    Evenly spaced numbers on a logarithmic scale.

    Computes int(num) evenly spaced exponents from start to stop.
    If endpoint=True, then last exponent is stop.
    Returns base**exponents.


(Note that I am not a native speaker - surprise - ;
so maybe the present one is already clear enough?)

Best, Arnd

Re: [Numpy-discussion] Testing a self-compiled numpy

[Keith G. <kwg...@gm...>]

On 7/9/06, Bill Baxter <wb...@gm...> wrote:
> Thanks for the reply Keith.
>
>
> On 7/10/06, Keith Goodman <kwg...@gm...> wrote:
> > One quick hack is to install the new numpy somewhere else and then
> > rename the directory containing 0.9.8 to numpySTOP. Then you don't
> > have to worry about the ordering of the path.
>
>
> The  only thing is that the numpy installer built by the windows
> instructions on the Wiki doesn't give you an option of where to install
> numpy.  It installs straight to
> {PYTHON_DIR}\lib\site-packages\numpy.  (The command
> suggested by the wiki is:
> c:\path\to\python.exe setup.py config --compiler=mingw32 build
> --compiler=mingw32 bdist_wininst
> )

Doesn't  --prefix=/install/numpy/here/ work on windows?

Re: [Numpy-discussion] NumPy beta release plan

[Charles R H. <cha...@gm...>]

Hi,

On 7/9/06, Robert Kern <rob...@gm...> wrote:
>
> Christian Kristukat wrote:
> > Robert Kern <robert.kern <at> gmail.com> writes:
> >
> >> I believe that Debian recently changed its configuration to default to
> >> /usr/local (for good reason!). Perhaps that is causing what you see.
> >
> > I just found out that this is feature/bug of opensuse 10.1. I'm
> beginning to
> > like it but can you tell what you have to do to force it install to
> /usr/lib?


Suse does that, but so does python by default if you compile it from
scratch; Suse is just following the path of least resistence. I don't like
it much, I think distributions should leave /usr/local empty, but when you
compile your own stuff it should arguably end up in /usr/local by default.

Chuck

Re: [Numpy-discussion] Testing a self-compiled numpy

[Bill B. <wb...@gm...>]

Thanks for the reply Keith.

On 7/10/06, Keith Goodman <kwg...@gm...> wrote:

> One quick hack is to install the new numpy somewhere else and then
> rename the directory containing 0.9.8 to numpySTOP. Then you don't
> have to worry about the ordering of the path.


The  only thing is that the numpy installer built by the windows
instructions on the Wiki doesn't give you an option of where to install
numpy.  It installs straight to {PYTHON_DIR}\lib\site-packages\numpy.  (The
command suggested by the wiki is:

c:\path\to\python.exe setup.py config --compiler=mingw32 build
--compiler=mingw32 bdist_wininst
)

But yeh, in a similar vein I can just rename the current numpy directory to
numpy_98 or something like that before installing, and that seems to work.

I just thought there would be a more sophisticated way to test various
verisons of modules in Python than renaming directories.

I install in /usr/local/scipy/numpy (then it is easy to remove numpy
> without worrying about leaving behind any files) and then I create the
> file /usr/lib/python2.4/site-packages/addlocalpath.pth that contains
> the lines:
>
> /usr/local/scipy/scipy/lib/python2.4/site-packages/
> /usr/local/scipy/numpy/lib/python2.4/site-packages/
>
> Then there is no need to play with the path.
>

Re: [Numpy-discussion] Testing a self-compiled numpy

[Keith G. <kwg...@gm...>]

On 7/9/06, Bill Baxter <wb...@gm...> wrote:
> I got numpy compiled according the the instruction on the Wiki, but is there
> some way to try it out without wiping out my stable install of 0.9.8?
>
> I tried modifying my PYTHONPATH to put the new numpy build directory first,
> but 'import numpy' still picks up the installed 0.9.8 version.

One quick hack is to install the new numpy somewhere else and then
rename the directory containing 0.9.8 to numpySTOP. Then you don't
have to worry about the ordering of the path.

I install in /usr/local/scipy/numpy (then it is easy to remove numpy
without worrying about leaving behind any files) and then I create the
file /usr/lib/python2.4/site-packages/addlocalpath.pth that contains
the lines:

/usr/local/scipy/scipy/lib/python2.4/site-packages/
/usr/local/scipy/numpy/lib/python2.4/site-packages/

Then there is no need to play with the path.

[Numpy-discussion] Testing a self-compiled numpy

[Bill B. <wb...@gm...>]

I got numpy compiled according the the instruction on the Wiki, but is there
some way to try it out without wiping out my stable install of 0.9.8?

I tried modifying my PYTHONPATH to put the new numpy build directory first,
but 'import numpy' still picks up the installed 0.9.8 version.

I also tried running python from the build directory.  Then 'import numpy'
prints out "Running from numpy source directory", but the numpy thus
imported seems not to have any attributes.

Suggestions?
--bill

Re: [Numpy-discussion] NumPy beta release plan

[Robert K. <rob...@gm...>]

Christian Kristukat wrote:
> Robert Kern <robert.kern <at> gmail.com> writes:
> 
>> I believe that Debian recently changed its configuration to default to 
>> /usr/local (for good reason!). Perhaps that is causing what you see.
> 
> I just found out that this is feature/bug of opensuse 10.1. I'm beginning to
> like it but can you tell what you have to do to force it install to /usr/lib?

It's probably a good idea to leave it as-is. OS distributions like to control 
all files in /usr (except /usr/local) and leave /usr/local for sysadmins and users.

But if you need more control:

http://docs.python.org/inst/alt-install-windows.html (ignore the inappropriate 
filename; it talks about alternate installation locations for all platforms)
http://docs.python.org/inst/config-syntax.html

> Btw. (OFF TOPIC) have you noticed that the scipy mailing list is just
> swallowing mails but not spreading them?

No. That could be a problem on our end. Please let Jeff Strunk 
<js...@en...> know about it. If you can provide details like a local 
copy of the email that got sent and swallowed, that would be very good.

-- 
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

Re: [Numpy-discussion] NumPy beta release plan

[Christian K. <ck...@ho...>]

Robert Kern <robert.kern <at> gmail.com> writes:

> I believe that Debian recently changed its configuration to default to 
> /usr/local (for good reason!). Perhaps that is causing what you see.
> 

I just found out that this is feature/bug of opensuse 10.1. I'm beginning to
like it but can you tell what you have to do to force it install to /usr/lib?
Btw. (OFF TOPIC) have you noticed that the scipy mailing list is just
swallowing mails but not spreading them?

Regards, Christian

Re: [Numpy-discussion] NumPy beta release plan

[Robert K. <rob...@gm...>]

Christian Kristukat wrote:
> Travis Oliphant <oliphant.travis <at> ieee.org> writes:
> 
>> Some of you may have noticed that things have been changing rapidly in 
>> the NumPy world (if you were out of the office in June then all the 
>> activity may seem overwhelming). 
>>
>> All of this activity is based on the fact that the upcoming beta release 
>> will mean a feature freeze for NumPy. 
> 
> Recently numpy.distutils switched to install to /usr/local/lib instead of
> /usr/lib. Is that intended? I'd prefer to have it back at /usr/lib in
> 1.0beta.

It shouldn't have. It shouldn't be doing anything different in that respect than 
core distutils. Are other distutils packages installing to /usr/lib? Nothing in 
the code should be making that choice. It is up to the configuration of Python 
(whatever prefix that the interpreter was installed to) or overridden by system 
or user configuration files.

I believe that Debian recently changed its configuration to default to 
/usr/local (for good reason!). Perhaps that is causing what you see.

-- 
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

Re: [Numpy-discussion] building ATLAS on Win32 - endless compile loop

[Bill B. <wb...@gm...>]

I did some searching on the web and found that Pentium M is more or less a
Pentium III.
After selecting "Pentium III" in the ATLAS setup, the build worked.  Still,
on my ~1GHz laptop took several hours, nothing like the 15 minutes
advertised on the Wiki.   (I updated the wiki accordingly)

Just out of curiostiy what processor is the official Numpy win32
distribution built for?  Or does it just not use optimized blas/lapack?

--Bill


On 7/8/06, Peter S=F8ndergaard <pe...@so...> wrote:
>
>
> > My laptop is a Pentium M, which isn't one of the options on the
> > architecture list.  So I picked "unknown".
> >
>
>

Re: [Numpy-discussion] NumPy beta release plan

[Christian K. <ck...@ho...>]

Travis Oliphant <oliphant.travis <at> ieee.org> writes:

> 
> 
> Some of you may have noticed that things have been changing rapidly in 
> the NumPy world (if you were out of the office in June then all the 
> activity may seem overwhelming). 
> 
> All of this activity is based on the fact that the upcoming beta release 
> will mean a feature freeze for NumPy. 

Recently numpy.distutils switched to install to /usr/local/lib instead of
/usr/lib. Is that intended? I'd prefer to have it back at /usr/lib in
1.0beta.

Anyway, I'm really looking forward to seeing a 1.0 release. Keep up the good
work.

Regards, Christian

[Numpy-discussion] numpy dtype str is '<i4' instead of 'int'

[Sebastian H. <ha...@ms...>]

Hi Travis,
Is it possible to change dtype str() [and repr() ?]
of "standard types" to a more user friendly string:
Example: instead of '<i4' 'int':
 >>> N.array([1,2])
[1 2]
 >>> _.dtype
'<i4'


and so on ?

I think it would be much more readable.

(I just build from todays SVN)

Thanks for the great work !!

- Sebastian Haase

Re: [Numpy-discussion] build problem: numpy with cygwin mingw

[Sebastian H. <ha...@ms...>]

Steve Lianoglou wrote:
> On Jul 9, 2006, at 4:09 PM, Sebastian Haase wrote:
> 
>> Hi all,
>> I was to quick with my last reply.
>> The patch in ticket 114 
>> (http://projects.scipy.org/scipy/numpy/ticket/114)
>> refers (among others) to a file
>> distutils/system_info.py
>> but my windows python (version 2.4.3) does not contain any file like 
>> that in
>> C:\Python24\Lib\distutils
>>
>> What am I missing this time !?
> 
> Perhaps it's referring to the distutils folder in the numpy package .. 
> should be in:
> /path/to/numpy/checkout/numpy/distutils/system_info.py
> 
Hi Steve,
Thanks for the hint. Before I was looking for numpy/distutils (which did 
not exist) and now I found it as numpy/numpy/distutils.
Done. Worked - thanks.


Now, I was trying to build SciPy - without getting through the 
ATALS/Lapack precedure ! So I get the expected Warnings (... NOT 
AVAILABLE)  but then (right after those) I get an error:
   File "C:\Python24\Lib\site-packages\numpy\distutils\system_info.py", 
line 403,
  in get_info
     raise self.notfounderror,self.notfounderror.__doc__
numpy.distutils.system_info.NotFoundError: Some third-party program or 
library is not found.

Does SciPy not come anymore with a fall back non-Lapack version included !?

Thanks,
Sebastian Haase

Re: [Numpy-discussion] build problem: numpy with cygwin mingw

[Steve L. <lis...@ar...>]

On Jul 9, 2006, at 4:09 PM, Sebastian Haase wrote:

> Hi all,
> I was to quick with my last reply.
> The patch in ticket 114 (http://projects.scipy.org/scipy/numpy/ 
> ticket/114)
> refers (among others) to a file
> distutils/system_info.py
> but my windows python (version 2.4.3) does not contain any file  
> like that in
> C:\Python24\Lib\distutils
>
> What am I missing this time !?

Perhaps it's referring to the distutils folder in the numpy  
package .. should be in:
/path/to/numpy/checkout/numpy/distutils/system_info.py

-steve

Re: [Numpy-discussion] build problem: numpy with cygwin mingw

[Sebastian H. <ha...@ms...>]

Hi all,
I was to quick with my last reply.
The patch in ticket 114 (http://projects.scipy.org/scipy/numpy/ticket/114)
refers (among others) to a file
distutils/system_info.py
but my windows python (version 2.4.3) does not contain any file like that in
C:\Python24\Lib\distutils

What am I missing this time !?

Thanks,
Sebastian Haase


Sebastian Haase wrote:
> Hi Stephan,
> thanks a lot ! Of course I did NOT read the small print at the top  ;-)
> 
> Now I just have to learn how to apply a patch ;-)
> (Funny, that after more than ten years of Linux I still don't know this 
> ... )
> 
> Thanks again - I'm sure it will work now.
> (I hope)
> - Sebastian
> 
> 
> Stephan Tolksdorf wrote:
>> Hi Sebastian,
>>
>>  > I just tried my first build  from a svn checkout on windows using
>>  > cygwin. I want to use the non cygwin python - i.e. the non-cygwin
>>  > (mingw) compiler more.
>>  > I get a presumably very basic error:
>>  > Even though I follow the simple instructions on
>>  > http://www.scipy.org/Installing_SciPy/Windows
>>
>> did you apply the patch from ticket #114, as mentioned on top of that 
>> page? The Cygwin build is known not to work otherwise (due to incorrect 
>> compiler flags, as you noticed)...
>>
>> Stephan
> 
> 
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] build problem: numpy with cygwin mingw

[Sebastian H. <ha...@ms...>]

Hi Stephan,
thanks a lot ! Of course I did NOT read the small print at the top  ;-)

Now I just have to learn how to apply a patch ;-)
(Funny, that after more than ten years of Linux I still don't know this 
... )

Thanks again - I'm sure it will work now.
(I hope)
- Sebastian


Stephan Tolksdorf wrote:
> Hi Sebastian,
> 
>  > I just tried my first build  from a svn checkout on windows using
>  > cygwin. I want to use the non cygwin python - i.e. the non-cygwin
>  > (mingw) compiler more.
>  > I get a presumably very basic error:
>  > Even though I follow the simple instructions on
>  > http://www.scipy.org/Installing_SciPy/Windows
> 
> did you apply the patch from ticket #114, as mentioned on top of that 
> page? The Cygwin build is known not to work otherwise (due to incorrect 
> compiler flags, as you noticed)...
> 
> Stephan