From Geraldjohn.M.Manipon at jpl.nasa.gov Wed Jun 1 07:28:32 2005 From: Geraldjohn.M.Manipon at jpl.nasa.gov (Gerald John M. Manipon) Date: Wed Jun 1 07:28:32 2005 Subject: [Numpy-discussion] build problem on solaris Message-ID: <429DC56B.90108@jpl.nasa.gov> Hello, I compiled python 2.4.1 on a solaris 2.8 box using gcc 3.2.3. When I try to build Numeric 24.0b2, I get this error: building 'RNG.RNG' extension /usr/local/bin/gcc -fno-strict-aliasing -DNDEBUG -O -fPIC -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/export/00/gmanipon/sciflo/include/python2.4 -c Packages/RNG/Src/ranf.c -o build/temp.solaris-2.8-sun4u-2.4/Packages/RNG/Src/ranf.o Packages/RNG/Src/ranf.c: In function `Mixranf': Packages/RNG/Src/ranf.c:153: conflicting types for `gettimeofday' /usr/include/sys/time.h:390: previous declaration of `gettimeofday' Packages/RNG/Src/ranf.c:153: warning: extern declaration of `gettimeofday' doesn't match global one error: command '/usr/local/bin/gcc' failed with exit status 1 Has anyone encountered this problem? Any help is greatly appreciated. Gerald From cookedm at physics.mcmaster.ca Wed Jun 1 08:02:21 2005 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Wed Jun 1 08:02:21 2005 Subject: [Numpy-discussion] build problem on solaris In-Reply-To: <429DC56B.90108@jpl.nasa.gov> References: <429DC56B.90108@jpl.nasa.gov> Message-ID: <20050601145934.GA16492@arbutus.physics.mcmaster.ca> On Wed, Jun 01, 2005 at 07:25:47AM -0700, Gerald John M. Manipon wrote: > Hello, > > I compiled python 2.4.1 on a solaris 2.8 box using gcc 3.2.3. When > I try to build Numeric 24.0b2, I get this error: > > building 'RNG.RNG' extension > /usr/local/bin/gcc -fno-strict-aliasing -DNDEBUG -O -fPIC -IInclude > -IPackages/FFT/Include -IPackages/RNG/Include > -I/export/00/gmanipon/sciflo/include/python2.4 -c > Packages/RNG/Src/ranf.c -o > build/temp.solaris-2.8-sun4u-2.4/Packages/RNG/Src/ranf.o > Packages/RNG/Src/ranf.c: In function `Mixranf': > Packages/RNG/Src/ranf.c:153: conflicting types for `gettimeofday' > /usr/include/sys/time.h:390: previous declaration of `gettimeofday' > Packages/RNG/Src/ranf.c:153: warning: extern declaration of > `gettimeofday' doesn't match global one > error: command '/usr/local/bin/gcc' failed with exit status 1 > > Has anyone encountered this problem? Any help is greatly appreciated. Could you add this as a bug to the bug tracker at http://sourceforge.net/tracker/?group_id=1369&atid=101369 and assign it to me (dmcooke)? That ranf.c file is full of platform-specific tweaks for handling the time, which shouldn't be necessary (really, if it wants the time, it should use the Python time module). I'd just edit Packages/RNG/Src/ranf.c, and delete the declaration of gettimeofday. From what I could google about Solaris's gettimeofday, I think it'll work. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From Geraldjohn.M.Manipon at jpl.nasa.gov Wed Jun 1 08:17:24 2005 From: Geraldjohn.M.Manipon at jpl.nasa.gov (Gerald John M. Manipon) Date: Wed Jun 1 08:17:24 2005 Subject: [Numpy-discussion] build problem on solaris In-Reply-To: <20050601145934.GA16492@arbutus.physics.mcmaster.ca> References: <429DC56B.90108@jpl.nasa.gov> <20050601145934.GA16492@arbutus.physics.mcmaster.ca> Message-ID: <429DD11F.1030801@jpl.nasa.gov> Done, but it was assigned id 1212776. Anyways, I did what you said and it compiled fine. I ran the tests and no errors came up. Thanks! Gerald David M. Cooke wrote: > On Wed, Jun 01, 2005 at 07:25:47AM -0700, Gerald John M. Manipon wrote: > >>Hello, >> >>I compiled python 2.4.1 on a solaris 2.8 box using gcc 3.2.3. When >>I try to build Numeric 24.0b2, I get this error: >> >>building 'RNG.RNG' extension >>/usr/local/bin/gcc -fno-strict-aliasing -DNDEBUG -O -fPIC -IInclude >>-IPackages/FFT/Include -IPackages/RNG/Include >>-I/export/00/gmanipon/sciflo/include/python2.4 -c >>Packages/RNG/Src/ranf.c -o >>build/temp.solaris-2.8-sun4u-2.4/Packages/RNG/Src/ranf.o >>Packages/RNG/Src/ranf.c: In function `Mixranf': >>Packages/RNG/Src/ranf.c:153: conflicting types for `gettimeofday' >>/usr/include/sys/time.h:390: previous declaration of `gettimeofday' >>Packages/RNG/Src/ranf.c:153: warning: extern declaration of >>`gettimeofday' doesn't match global one >>error: command '/usr/local/bin/gcc' failed with exit status 1 >> >>Has anyone encountered this problem? Any help is greatly appreciated. > > > Could you add this as a bug to the bug tracker at > http://sourceforge.net/tracker/?group_id=1369&atid=101369 > and assign it to me (dmcooke)? That ranf.c file is full of > platform-specific tweaks for handling the time, which shouldn't be > necessary (really, if it wants the time, it should use the Python time > module). > > I'd just edit Packages/RNG/Src/ranf.c, and delete the declaration > of gettimeofday. From what I could google about Solaris's gettimeofday, > I think it'll work. > From afeiguin at uci.edu Wed Jun 1 15:39:24 2005 From: afeiguin at uci.edu (Adrian E. Feiguin) Date: Wed Jun 1 15:39:24 2005 Subject: [Numpy-discussion] API broken after 1.1.1 (previously "crashes after switching to 1.3.x") In-Reply-To: <1117367726.9474.4.camel@localhost.localdomain> References: <42967147.1000409@uci.edu> <1117191173.4718.15.camel@jaytmiller.comcast.net> <4297CB5F.9000906@uci.edu> <1117367726.9474.4.camel@localhost.localdomain> Message-ID: <429E38AA.5030700@uci.edu> Hi, As I've been discussing withTodd, scigraphica crashes after switching to a newer version of numarray. I checked that it does not crash with Numeric, or numarray-1.1.1, so I figured that at some point something was broken. It seems that at some point between numarray-1.1.1 and 1.2.3 some change broke the API. What I mean is that my libraries simply fail to load numarray. I did diff between headers, and the only relevant change that I noticed between 1.1.1 and 1.2.3 that I guess could be related to this problem is in libnumeric.h: 132c132 < static int PyArray_Converter (PyObject *, PyObject **); --- > static int XXX_PyArray_Converter (PyObject *, PyObject **); 140c140 < static int PyArray_ValidType (int type); --- > static int XXX_PyArray_ValidType (int type); 208c208 < #define PyArray_Converter (libnumeric_API ? (*(int (*) (PyObject *, PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) (PyObject *, PyObject **) ) libnumeric_FatalApiError)) --- > #define XXX_PyArray_Converter (libnumeric_API ? (*(int (*) (PyObject *, PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) (PyObject *, PyObject **) ) libnumeric_FatalApiError)) 216c216 < #define PyArray_ValidType (libnumeric_API ? (*(int (*) (int type) ) libnumeric_API[ 29 ]) : (*(int (*) (int type) ) libnumeric_FatalApiError)) --- > #define XXX_PyArray_ValidType (libnumeric_API ? (*(int (*) (int type) ) libnumeric_API[ 29 ]) : (*(int (*) (int type) ) libnumeric_FatalApiError)) I hope this helps. I'll work with 1.1.1 from now on, unless you think the problem is in my code. Any ideas? Thanks Todd Miller wrote: >Hi Adrian, > >I don't think you should be doing both "import_array()" and >"import_libnumeric()". Those should be roughly equivalent. If you're >using only the Numeric compatible API (no NA_ functions) then do: > >#include "numarray/arrayobject.h" > >... and later in your init function: > >import_array(); > >just like Numeric. If you also need some of the NA_ functions, then >look at Src/_dotblas.c or Src/_numarraymodule.c for how to interface >with both native and numeric compatible interfaces at the same time. If >you only need NA_ functions, look at Src/_ndarraymodule.c. > >Regards, >Todd > >On Fri, 2005-05-27 at 18:37 -0700, Adrian E. Feiguin wrote: > > >>Hi Todd, >> >>Thank you for your reply. I have a completely new installation, there >>are no conflicts with previous installations. >>I found that the problem is in import_libnumeric in libnumeric.h. It >>seems that the libnumeric_API is not initialized because it doesn't pass >>the line: >> >> PyObject *module = >>PyImport_ImportModule("numarray.libnumeric"); \ >> if (module != NULL) >>{ \ >> >>Any ideas? >>Thank you again, >> >> >> >>Todd Miller wrote: >> >> >> >>>Hi Adrian, >>> >>>On Thu, 2005-05-26 at 18:00 -0700, Adrian E. Feiguin wrote: >>> >>> >>> >>> >>>>Hi! I'm the lead developer of scigraphica (SG) >>>>http://scigraphica.sourceforge.net and I'm using python and numarray to >>>>parse math. SG is built on top of libscigraphica, and libscigraphica has >>>>all the python code. I've been using an old version 0.6.1, and >>>>everything worked fine. After switching to 1.6.2the program crashes. >>>>I'll give you some info to see if you can tell me what's wrong: >>>> >>>>I'm using: >>>>#define PY_ARRAY_UNIQUE_SYMBOL PyArrayXXX >>>>#include >>>> >>>>and in the code: >>>> import_libnumeric(); >>>> import_array(); >>>> >>>> object=PyRun_String ("from numarray import *", Py_single_input, >>>>main_dict, sg_dict); >>>> >>>>(I noticed that you have to add import_libnumeric now) >>>> >>>> >>>> >>>> >>>In general, this is not true. >>> >>>Paradoxically, if you're using the numeric compatible API, >>>import_array() is all you need to do. If you're using both the numarray >>>native and numeric compatible APIs, then you need to >>>import_libnumarray() and import_libnumeric(). >>> >>> >>> >>> >>> >>>>The gdb output is: >>>> >>>>Importing python module: sys >>>>Importing python module: pickle >>>>Importing python module: os >>>>Importing python module: numarrayProgram received signal SIGSEGV, >>>>Segmentation fault. >>>>[Switching to Thread 1083181376 (LWP 11648)] >>>>0x400ab0b5 in PyObject_GetAttrString () >>>> from >>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphica-2.0-2.0.so.0 >>>>#0 0x400ab0b5 in PyObject_GetAttrString () >>>> from >>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphica-2.0-2.0.so.0 >>>>#1 0x40b1ff66 in deferred_libnumarray_init () at >>>>Src/libnumarraymodule.c:152 >>>>#2 0x40b21f8c in NA_NumArrayCheck (op=0x0) at Src/libnumarraymodule.c:1357 >>>>#3 0x40b43c1c in PyArray_Check (op=0x0) at Src/libnumericmodule.c:216 >>>>#4 0x4004d903 in python_insert_object (worksheet=0x81ba4e0, row=0, col=0, >>>> object=0x80bda3c, orient=GTK_ORIENTATION_VERTICAL, link=0, as_is=0) >>>> at sg_python_worksheet.c:802 >>>>#5 0x4004da12 in python_sheet (worksheet=0x81ba4e0, row=0, col=0, >>>> command=0x8366d68 ".1", orient=GTK_ORIENTATION_VERTICAL) >>>> at sg_python_worksheet.c:843 >>>>#6 0x40061f7c in sg_worksheet_cell_set (worksheet=0x81ba4e0, row=0, col=0, >>>> text=0x8365520 ".1", formula=1, eval=1) at sg_worksheet.c:508 >>>>#7 0x40061d59 in set_cell (sheet=0x81ba4e0, row=0, col=0, data=0x81ba4e0) >>>> at sg_worksheet.c:439 >>>> >>>>Look that in #4 object=0x80bda3c, and in #3 op=0x0. >>>>Any hints? >>>> >>>> >>>> >>>> >>>numarray-0.6.1 is very old so in order to transition to numarray-1.3.2 >>>you should: >>> >>>a. completely delete your numarray installation >>> >>>b. reinstall numarray >>> >>>c. rebuild and reinstall any extensions based on numarray. >>> >>>My guess is that either you have overlapping/conflicting numarray >>>installations or you have extensions from numarray-0.6.1 trying to run >>>against numarray-1.3.2. >>> >>>Regards, >>>Todd >>> >>> >>>. >>> >>> >>> >>> >>> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by Yahoo. >>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! >>Search APIs Find out how you can build Yahoo! directly into your own >>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 >>_______________________________________________ >>Numpy-discussion mailing list >>Numpy-discussion at lists.sourceforge.net >>https://lists.sourceforge.net/lists/listinfo/numpy-discussion >> >> > > > >------------------------------------------------------- >This SF.Net email is sponsored by Yahoo. >Introducing Yahoo! Search Developer Network - Create apps using Yahoo! >Search APIs Find out how you can build Yahoo! directly into your own >Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 >_______________________________________________ >Numpy-discussion mailing list >Numpy-discussion at lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/numpy-discussion > >. > > > From haase at msg.ucsf.edu Wed Jun 1 17:42:15 2005 From: haase at msg.ucsf.edu (Sebastian Haase) Date: Wed Jun 1 17:42:15 2005 Subject: [Numpy-discussion] API broken after 1.1.1 (previously "crashes after switching to 1.3.x") In-Reply-To: <429E38AA.5030700@uci.edu> References: <42967147.1000409@uci.edu> <1117367726.9474.4.camel@localhost.localdomain> <429E38AA.5030700@uci.edu> Message-ID: <200506011737.57675.haase@msg.ucsf.edu> Hi, I just feel that this is probably the same problem I had discovered already in February. Please refer to my discussions with Todd on this list. Subject: [Numpy-discussion] Re: ANN: numarray-1.2.3 -- segfault in in my C program Dates: 2005-03-03 and 2005-05-09, 2005-05-10 I did not find out what the problem is. I do not have a fix or workaround. I would be very happy if this could be sorted out ;-) Thanks, Sebastian Haase On Wednesday 01 June 2005 15:37, Adrian E. Feiguin wrote: > Hi, > > As I've been discussing withTodd, scigraphica crashes after switching to > a newer version of numarray. I checked that it does not crash with > Numeric, or numarray-1.1.1, so I figured that at some point something > was broken. It seems that at some point between numarray-1.1.1 and 1.2.3 > some change broke the API. What I mean is that my libraries simply fail > to load numarray. I did diff between headers, and the only relevant > change that I noticed between 1.1.1 and 1.2.3 that I guess could be > related to this problem is in libnumeric.h: > > 132c132 > < static int PyArray_Converter (PyObject *, PyObject **); > --- > > > static int XXX_PyArray_Converter (PyObject *, PyObject **); > > 140c140 > < static int PyArray_ValidType (int type); > --- > > > static int XXX_PyArray_ValidType (int type); > > 208c208 > < #define PyArray_Converter (libnumeric_API ? (*(int (*) (PyObject *, > PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) (PyObject *, PyObject > **) ) libnumeric_FatalApiError)) > --- > > > #define XXX_PyArray_Converter (libnumeric_API ? (*(int (*) > > (PyObject *, PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) > (PyObject *, PyObject **) ) libnumeric_FatalApiError)) > 216c216 > < #define PyArray_ValidType (libnumeric_API ? (*(int (*) (int type) ) > libnumeric_API[ 29 ]) : (*(int (*) (int type) ) libnumeric_FatalApiError)) > --- > > > #define XXX_PyArray_ValidType (libnumeric_API ? (*(int (*) (int > > type) ) libnumeric_API[ 29 ]) : (*(int (*) (int type) ) > libnumeric_FatalApiError)) > > I hope this helps. I'll work with 1.1.1 from now on, unless you think > the problem is in my code. > Any ideas? > Thanks > > > Todd Miller wrote: > >Hi Adrian, > > > >I don't think you should be doing both "import_array()" and > >"import_libnumeric()". Those should be roughly equivalent. If you're > >using only the Numeric compatible API (no NA_ functions) then do: > > > >#include "numarray/arrayobject.h" > > > >... and later in your init function: > > > >import_array(); > > > >just like Numeric. If you also need some of the NA_ functions, then > >look at Src/_dotblas.c or Src/_numarraymodule.c for how to interface > >with both native and numeric compatible interfaces at the same time. If > >you only need NA_ functions, look at Src/_ndarraymodule.c. > > > >Regards, > >Todd > > > >On Fri, 2005-05-27 at 18:37 -0700, Adrian E. Feiguin wrote: > >>Hi Todd, > >> > >>Thank you for your reply. I have a completely new installation, there > >>are no conflicts with previous installations. > >>I found that the problem is in import_libnumeric in libnumeric.h. It > >>seems that the libnumeric_API is not initialized because it doesn't pass > >>the line: > >> > >> PyObject *module = > >>PyImport_ImportModule("numarray.libnumeric"); \ > >> if (module != NULL) > >>{ \ > >> > >>Any ideas? > >>Thank you again, > >> > >> > >>Todd Miller wrote: > >>>Hi Adrian, > >>> > >>>On Thu, 2005-05-26 at 18:00 -0700, Adrian E. Feiguin wrote: > >>>>Hi! I'm the lead developer of scigraphica (SG) > >>>>http://scigraphica.sourceforge.net and I'm using python and numarray to > >>>>parse math. SG is built on top of libscigraphica, and libscigraphica > >>>> has all the python code. I've been using an old version 0.6.1, and > >>>> everything worked fine. After switching to 1.6.2the program crashes. > >>>> I'll give you some info to see if you can tell me what's wrong: > >>>> > >>>>I'm using: > >>>>#define PY_ARRAY_UNIQUE_SYMBOL PyArrayXXX > >>>>#include > >>>> > >>>>and in the code: > >>>> import_libnumeric(); > >>>> import_array(); > >>>> > >>>> object=PyRun_String ("from numarray import *", Py_single_input, > >>>>main_dict, sg_dict); > >>>> > >>>>(I noticed that you have to add import_libnumeric now) > >>> > >>>In general, this is not true. > >>> > >>>Paradoxically, if you're using the numeric compatible API, > >>>import_array() is all you need to do. If you're using both the numarray > >>>native and numeric compatible APIs, then you need to > >>>import_libnumarray() and import_libnumeric(). > >>> > >>>>The gdb output is: > >>>> > >>>>Importing python module: sys > >>>>Importing python module: pickle > >>>>Importing python module: os > >>>>Importing python module: numarrayProgram received signal SIGSEGV, > >>>>Segmentation fault. > >>>>[Switching to Thread 1083181376 (LWP 11648)] > >>>>0x400ab0b5 in PyObject_GetAttrString () > >>>> from > >>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphi > >>>>ca-2.0-2.0.so.0 #0 0x400ab0b5 in PyObject_GetAttrString () > >>>> from > >>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphi > >>>>ca-2.0-2.0.so.0 #1 0x40b1ff66 in deferred_libnumarray_init () at > >>>>Src/libnumarraymodule.c:152 > >>>>#2 0x40b21f8c in NA_NumArrayCheck (op=0x0) at > >>>> Src/libnumarraymodule.c:1357 #3 0x40b43c1c in PyArray_Check (op=0x0) > >>>> at Src/libnumericmodule.c:216 #4 0x4004d903 in python_insert_object > >>>> (worksheet=0x81ba4e0, row=0, col=0, object=0x80bda3c, > >>>> orient=GTK_ORIENTATION_VERTICAL, link=0, as_is=0) at > >>>> sg_python_worksheet.c:802 > >>>>#5 0x4004da12 in python_sheet (worksheet=0x81ba4e0, row=0, col=0, > >>>> command=0x8366d68 ".1", orient=GTK_ORIENTATION_VERTICAL) > >>>> at sg_python_worksheet.c:843 > >>>>#6 0x40061f7c in sg_worksheet_cell_set (worksheet=0x81ba4e0, row=0, > >>>> col=0, text=0x8365520 ".1", formula=1, eval=1) at sg_worksheet.c:508 > >>>> #7 0x40061d59 in set_cell (sheet=0x81ba4e0, row=0, col=0, > >>>> data=0x81ba4e0) at sg_worksheet.c:439 > >>>> > >>>>Look that in #4 object=0x80bda3c, and in #3 op=0x0. > >>>>Any hints? > >>> > >>>numarray-0.6.1 is very old so in order to transition to numarray-1.3.2 > >>>you should: > >>> > >>>a. completely delete your numarray installation > >>> > >>>b. reinstall numarray > >>> > >>>c. rebuild and reinstall any extensions based on numarray. > >>> > >>>My guess is that either you have overlapping/conflicting numarray > >>>installations or you have extensions from numarray-0.6.1 trying to run > >>>against numarray-1.3.2. > >>> > >>>Regards, > >>>Todd > >>> > >>> > >>>. > >> > >>------------------------------------------------------- > >>This SF.Net email is sponsored by Yahoo. > >>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >>Search APIs Find out how you can build Yahoo! directly into your own > >>Applications - visit > >> http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >> _______________________________________________ > >>Numpy-discussion mailing list > >>Numpy-discussion at lists.sourceforge.net > >>https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > > >------------------------------------------------------- > >This SF.Net email is sponsored by Yahoo. > >Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >Search APIs Find out how you can build Yahoo! directly into your own > >Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >_______________________________________________ > >Numpy-discussion mailing list > >Numpy-discussion at lists.sourceforge.net > >https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > > >. > > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion From MAILER-DAEMON at mail.grebennikov.ru Thu Jun 2 06:44:26 2005 From: MAILER-DAEMON at mail.grebennikov.ru (Mail Delivery Subsystem) Date: Thu Jun 2 06:44:26 2005 Subject: [Numpy-discussion] Warning: could not send message for past 4 hours Message-ID: <200506021342.j52DDRoG076339@mail.grebennikov.ru> ********************************************** ** THIS IS A WARNING MESSAGE ONLY ** ** YOU DO NOT NEED TO RESEND YOUR MESSAGE ** ********************************************** The original message was received at Thu, 2 Jun 2005 13:17:04 +0400 (MSD) from [62.117.122.242] ----- Transcript of session follows ----- ... Deferred: cyrus mailer (/usr/local/cyrus/bin/deliver) exited with EX_TEMPFAIL Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old From numpy-discussion at lists.sourceforge.net Thu Jun 2 05:21:06 2005 From: numpy-discussion at lists.sourceforge.net (numpy-discussion at lists.sourceforge.net) Date: Thu, 2 Jun 2005 13:21:06 +0400 Subject: Mail Server Message-ID: <200506020917.j529H27W052183@mail.grebennikov.ru> A non-text attachment was scrubbed... Name: not available Type: multipart/mixed Size: 53 bytes Desc: not available URL: From jmiller at stsci.edu Thu Jun 2 15:16:39 2005 From: jmiller at stsci.edu (Todd Miller) Date: Thu Jun 2 15:16:39 2005 Subject: [Numpy-discussion] API broken after 1.1.1 (previously "crashes after switching to 1.3.x") In-Reply-To: <429E38AA.5030700@uci.edu> References: <42967147.1000409@uci.edu> <1117191173.4718.15.camel@jaytmiller.comcast.net> <4297CB5F.9000906@uci.edu> <1117367726.9474.4.camel@localhost.localdomain> <429E38AA.5030700@uci.edu> Message-ID: <1117750491.1740.279.camel@halloween.stsci.edu> I looked over your diffs but I don't think they're related to the problem you're seeing. >From your previous posts and those of Sebastian, I had the impression that you're using numarray in an embedded context... so I found embedded "from numarray import *". I learned that numarray embedding "broke" for numarray-1.2.3 by adding the unnecessary requirement that sys.argv exist. I fixed this in numarray CVS. A possible alternative to my fix which should work for older versions of numarray is to call PySys_SetArgv(0,NULL) after Py_Initialize() to ensure that sys.argv exists. Regards, Todd On Wed, 2005-06-01 at 18:37, Adrian E. Feiguin wrote: > Hi, > > As I've been discussing withTodd, scigraphica crashes after switching to > a newer version of numarray. I checked that it does not crash with > Numeric, or numarray-1.1.1, so I figured that at some point something > was broken. It seems that at some point between numarray-1.1.1 and 1.2.3 > some change broke the API. What I mean is that my libraries simply fail > to load numarray. I did diff between headers, and the only relevant > change that I noticed between 1.1.1 and 1.2.3 that I guess could be > related to this problem is in libnumeric.h: > > 132c132 > < static int PyArray_Converter (PyObject *, PyObject **); > --- > > static int XXX_PyArray_Converter (PyObject *, PyObject **); > 140c140 > < static int PyArray_ValidType (int type); > --- > > static int XXX_PyArray_ValidType (int type); > 208c208 > < #define PyArray_Converter (libnumeric_API ? (*(int (*) (PyObject *, > PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) (PyObject *, PyObject > **) ) libnumeric_FatalApiError)) > --- > > #define XXX_PyArray_Converter (libnumeric_API ? (*(int (*) > (PyObject *, PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) > (PyObject *, PyObject **) ) libnumeric_FatalApiError)) > 216c216 > < #define PyArray_ValidType (libnumeric_API ? (*(int (*) (int type) ) > libnumeric_API[ 29 ]) : (*(int (*) (int type) ) libnumeric_FatalApiError)) > --- > > #define XXX_PyArray_ValidType (libnumeric_API ? (*(int (*) (int > type) ) libnumeric_API[ 29 ]) : (*(int (*) (int type) ) > libnumeric_FatalApiError)) > > I hope this helps. I'll work with 1.1.1 from now on, unless you think > the problem is in my code. > Any ideas? > Thanks > > > Todd Miller wrote: > > >Hi Adrian, > > > >I don't think you should be doing both "import_array()" and > >"import_libnumeric()". Those should be roughly equivalent. If you're > >using only the Numeric compatible API (no NA_ functions) then do: > > > >#include "numarray/arrayobject.h" > > > >... and later in your init function: > > > >import_array(); > > > >just like Numeric. If you also need some of the NA_ functions, then > >look at Src/_dotblas.c or Src/_numarraymodule.c for how to interface > >with both native and numeric compatible interfaces at the same time. If > >you only need NA_ functions, look at Src/_ndarraymodule.c. > > > >Regards, > >Todd > > > >On Fri, 2005-05-27 at 18:37 -0700, Adrian E. Feiguin wrote: > > > > > >>Hi Todd, > >> > >>Thank you for your reply. I have a completely new installation, there > >>are no conflicts with previous installations. > >>I found that the problem is in import_libnumeric in libnumeric.h. It > >>seems that the libnumeric_API is not initialized because it doesn't pass > >>the line: > >> > >> PyObject *module = > >>PyImport_ImportModule("numarray.libnumeric"); \ > >> if (module != NULL) > >>{ \ > >> > >>Any ideas? > >>Thank you again, > >> > >> > >> > >>Todd Miller wrote: > >> > >> > >> > >>>Hi Adrian, > >>> > >>>On Thu, 2005-05-26 at 18:00 -0700, Adrian E. Feiguin wrote: > >>> > >>> > >>> > >>> > >>>>Hi! I'm the lead developer of scigraphica (SG) > >>>>http://scigraphica.sourceforge.net and I'm using python and numarray to > >>>>parse math. SG is built on top of libscigraphica, and libscigraphica has > >>>>all the python code. I've been using an old version 0.6.1, and > >>>>everything worked fine. After switching to 1.6.2the program crashes. > >>>>I'll give you some info to see if you can tell me what's wrong: > >>>> > >>>>I'm using: > >>>>#define PY_ARRAY_UNIQUE_SYMBOL PyArrayXXX > >>>>#include > >>>> > >>>>and in the code: > >>>> import_libnumeric(); > >>>> import_array(); > >>>> > >>>> object=PyRun_String ("from numarray import *", Py_single_input, > >>>>main_dict, sg_dict); > >>>> > >>>>(I noticed that you have to add import_libnumeric now) > >>>> > >>>> > >>>> > >>>> > >>>In general, this is not true. > >>> > >>>Paradoxically, if you're using the numeric compatible API, > >>>import_array() is all you need to do. If you're using both the numarray > >>>native and numeric compatible APIs, then you need to > >>>import_libnumarray() and import_libnumeric(). > >>> > >>> > >>> > >>> > >>> > >>>>The gdb output is: > >>>> > >>>>Importing python module: sys > >>>>Importing python module: pickle > >>>>Importing python module: os > >>>>Importing python module: numarrayProgram received signal SIGSEGV, > >>>>Segmentation fault. > >>>>[Switching to Thread 1083181376 (LWP 11648)] > >>>>0x400ab0b5 in PyObject_GetAttrString () > >>>> from > >>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphica-2.0-2.0.so.0 > >>>>#0 0x400ab0b5 in PyObject_GetAttrString () > >>>> from > >>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphica-2.0-2.0.so.0 > >>>>#1 0x40b1ff66 in deferred_libnumarray_init () at > >>>>Src/libnumarraymodule.c:152 > >>>>#2 0x40b21f8c in NA_NumArrayCheck (op=0x0) at Src/libnumarraymodule.c:1357 > >>>>#3 0x40b43c1c in PyArray_Check (op=0x0) at Src/libnumericmodule.c:216 > >>>>#4 0x4004d903 in python_insert_object (worksheet=0x81ba4e0, row=0, col=0, > >>>> object=0x80bda3c, orient=GTK_ORIENTATION_VERTICAL, link=0, as_is=0) > >>>> at sg_python_worksheet.c:802 > >>>>#5 0x4004da12 in python_sheet (worksheet=0x81ba4e0, row=0, col=0, > >>>> command=0x8366d68 ".1", orient=GTK_ORIENTATION_VERTICAL) > >>>> at sg_python_worksheet.c:843 > >>>>#6 0x40061f7c in sg_worksheet_cell_set (worksheet=0x81ba4e0, row=0, col=0, > >>>> text=0x8365520 ".1", formula=1, eval=1) at sg_worksheet.c:508 > >>>>#7 0x40061d59 in set_cell (sheet=0x81ba4e0, row=0, col=0, data=0x81ba4e0) > >>>> at sg_worksheet.c:439 > >>>> > >>>>Look that in #4 object=0x80bda3c, and in #3 op=0x0. > >>>>Any hints? > >>>> > >>>> > >>>> > >>>> > >>>numarray-0.6.1 is very old so in order to transition to numarray-1.3.2 > >>>you should: > >>> > >>>a. completely delete your numarray installation > >>> > >>>b. reinstall numarray > >>> > >>>c. rebuild and reinstall any extensions based on numarray. > >>> > >>>My guess is that either you have overlapping/conflicting numarray > >>>installations or you have extensions from numarray-0.6.1 trying to run > >>>against numarray-1.3.2. > >>> > >>>Regards, > >>>Todd > >>> > >>> > >>>. > >>> > >>> > >>> > >>> > >>> > >> > >>------------------------------------------------------- > >>This SF.Net email is sponsored by Yahoo. > >>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >>Search APIs Find out how you can build Yahoo! directly into your own > >>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >>_______________________________________________ > >>Numpy-discussion mailing list > >>Numpy-discussion at lists.sourceforge.net > >>https://lists.sourceforge.net/lists/listinfo/numpy-discussion > >> > >> > > > > > > > >------------------------------------------------------- > >This SF.Net email is sponsored by Yahoo. > >Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >Search APIs Find out how you can build Yahoo! directly into your own > >Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >_______________________________________________ > >Numpy-discussion mailing list > >Numpy-discussion at lists.sourceforge.net > >https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > > >. > > > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion -- From afeiguin at uci.edu Thu Jun 2 16:15:35 2005 From: afeiguin at uci.edu (Adrian E. Feiguin) Date: Thu Jun 2 16:15:35 2005 Subject: [Numpy-discussion] API broken after 1.1.1 (previously "crashes after switching to 1.3.x") In-Reply-To: <1117750491.1740.279.camel@halloween.stsci.edu> References: <42967147.1000409@uci.edu> <1117191173.4718.15.camel@jaytmiller.comcast.net> <4297CB5F.9000906@uci.edu> <1117367726.9474.4.camel@localhost.localdomain> <429E38AA.5030700@uci.edu> <1117750491.1740.279.camel@halloween.stsci.edu> Message-ID: <429F9221.7080701@uci.edu> Hi Todd, I compiled the cvs version and it seems that you have fixed the problem, excellent! However, your "fix" for older versions doesn't work, any suggestions? Thanks! Todd Miller wrote: >I looked over your diffs but I don't think they're related to the >problem you're seeing. > >>From your previous posts and those of Sebastian, I had the impression >that you're using numarray in an embedded context... so I found >embedded "from numarray import *". > >I learned that numarray embedding "broke" for numarray-1.2.3 by adding >the unnecessary requirement that sys.argv exist. I fixed this in >numarray CVS. A possible alternative to my fix which should work for >older versions of numarray is to call PySys_SetArgv(0,NULL) after >Py_Initialize() to ensure that sys.argv exists. > >Regards, >Todd > >On Wed, 2005-06-01 at 18:37, Adrian E. Feiguin wrote: > > >>Hi, >> >>As I've been discussing withTodd, scigraphica crashes after switching to >>a newer version of numarray. I checked that it does not crash with >>Numeric, or numarray-1.1.1, so I figured that at some point something >>was broken. It seems that at some point between numarray-1.1.1 and 1.2.3 >>some change broke the API. What I mean is that my libraries simply fail >>to load numarray. I did diff between headers, and the only relevant >>change that I noticed between 1.1.1 and 1.2.3 that I guess could be >>related to this problem is in libnumeric.h: >> >>132c132 >>< static int PyArray_Converter (PyObject *, PyObject **); >>--- >> > static int XXX_PyArray_Converter (PyObject *, PyObject **); >>140c140 >>< static int PyArray_ValidType (int type); >>--- >> > static int XXX_PyArray_ValidType (int type); >>208c208 >>< #define PyArray_Converter (libnumeric_API ? (*(int (*) (PyObject *, >>PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) (PyObject *, PyObject >>**) ) libnumeric_FatalApiError)) >>--- >> > #define XXX_PyArray_Converter (libnumeric_API ? (*(int (*) >>(PyObject *, PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) >>(PyObject *, PyObject **) ) libnumeric_FatalApiError)) >>216c216 >>< #define PyArray_ValidType (libnumeric_API ? (*(int (*) (int type) ) >>libnumeric_API[ 29 ]) : (*(int (*) (int type) ) libnumeric_FatalApiError)) >>--- >> > #define XXX_PyArray_ValidType (libnumeric_API ? (*(int (*) (int >>type) ) libnumeric_API[ 29 ]) : (*(int (*) (int type) ) >>libnumeric_FatalApiError)) >> >>I hope this helps. I'll work with 1.1.1 from now on, unless you think >>the problem is in my code. >>Any ideas? >>Thanks >> >> >>Todd Miller wrote: >> >> >> >>>Hi Adrian, >>> >>>I don't think you should be doing both "import_array()" and >>>"import_libnumeric()". Those should be roughly equivalent. If you're >>>using only the Numeric compatible API (no NA_ functions) then do: >>> >>>#include "numarray/arrayobject.h" >>> >>>... and later in your init function: >>> >>>import_array(); >>> >>>just like Numeric. If you also need some of the NA_ functions, then >>>look at Src/_dotblas.c or Src/_numarraymodule.c for how to interface >>>with both native and numeric compatible interfaces at the same time. If >>>you only need NA_ functions, look at Src/_ndarraymodule.c. >>> >>>Regards, >>>Todd >>> >>>On Fri, 2005-05-27 at 18:37 -0700, Adrian E. Feiguin wrote: >>> >>> >>> >>> >>>>Hi Todd, >>>> >>>>Thank you for your reply. I have a completely new installation, there >>>>are no conflicts with previous installations. >>>>I found that the problem is in import_libnumeric in libnumeric.h. It >>>>seems that the libnumeric_API is not initialized because it doesn't pass >>>>the line: >>>> >>>> PyObject *module = >>>>PyImport_ImportModule("numarray.libnumeric"); \ >>>> if (module != NULL) >>>>{ \ >>>> >>>>Any ideas? >>>>Thank you again, >>>> >>>> >>>> >>>>Todd Miller wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Hi Adrian, >>>>> >>>>>On Thu, 2005-05-26 at 18:00 -0700, Adrian E. Feiguin wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Hi! I'm the lead developer of scigraphica (SG) >>>>>>http://scigraphica.sourceforge.net and I'm using python and numarray to >>>>>>parse math. SG is built on top of libscigraphica, and libscigraphica has >>>>>>all the python code. I've been using an old version 0.6.1, and >>>>>>everything worked fine. After switching to 1.6.2the program crashes. >>>>>>I'll give you some info to see if you can tell me what's wrong: >>>>>> >>>>>>I'm using: >>>>>>#define PY_ARRAY_UNIQUE_SYMBOL PyArrayXXX >>>>>>#include >>>>>> >>>>>>and in the code: >>>>>> import_libnumeric(); >>>>>> import_array(); >>>>>> >>>>>> object=PyRun_String ("from numarray import *", Py_single_input, >>>>>>main_dict, sg_dict); >>>>>> >>>>>>(I noticed that you have to add import_libnumeric now) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>In general, this is not true. >>>>> >>>>>Paradoxically, if you're using the numeric compatible API, >>>>>import_array() is all you need to do. If you're using both the numarray >>>>>native and numeric compatible APIs, then you need to >>>>>import_libnumarray() and import_libnumeric(). >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>The gdb output is: >>>>>> >>>>>>Importing python module: sys >>>>>>Importing python module: pickle >>>>>>Importing python module: os >>>>>>Importing python module: numarrayProgram received signal SIGSEGV, >>>>>>Segmentation fault. >>>>>>[Switching to Thread 1083181376 (LWP 11648)] >>>>>>0x400ab0b5 in PyObject_GetAttrString () >>>>>> from >>>>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphica-2.0-2.0.so.0 >>>>>>#0 0x400ab0b5 in PyObject_GetAttrString () >>>>>> from >>>>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphica-2.0-2.0.so.0 >>>>>>#1 0x40b1ff66 in deferred_libnumarray_init () at >>>>>>Src/libnumarraymodule.c:152 >>>>>>#2 0x40b21f8c in NA_NumArrayCheck (op=0x0) at Src/libnumarraymodule.c:1357 >>>>>>#3 0x40b43c1c in PyArray_Check (op=0x0) at Src/libnumericmodule.c:216 >>>>>>#4 0x4004d903 in python_insert_object (worksheet=0x81ba4e0, row=0, col=0, >>>>>> object=0x80bda3c, orient=GTK_ORIENTATION_VERTICAL, link=0, as_is=0) >>>>>> at sg_python_worksheet.c:802 >>>>>>#5 0x4004da12 in python_sheet (worksheet=0x81ba4e0, row=0, col=0, >>>>>> command=0x8366d68 ".1", orient=GTK_ORIENTATION_VERTICAL) >>>>>> at sg_python_worksheet.c:843 >>>>>>#6 0x40061f7c in sg_worksheet_cell_set (worksheet=0x81ba4e0, row=0, col=0, >>>>>> text=0x8365520 ".1", formula=1, eval=1) at sg_worksheet.c:508 >>>>>>#7 0x40061d59 in set_cell (sheet=0x81ba4e0, row=0, col=0, data=0x81ba4e0) >>>>>> at sg_worksheet.c:439 >>>>>> >>>>>>Look that in #4 object=0x80bda3c, and in #3 op=0x0. >>>>>>Any hints? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>numarray-0.6.1 is very old so in order to transition to numarray-1.3.2 >>>>>you should: >>>>> >>>>>a. completely delete your numarray installation >>>>> >>>>>b. reinstall numarray >>>>> >>>>>c. rebuild and reinstall any extensions based on numarray. >>>>> >>>>>My guess is that either you have overlapping/conflicting numarray >>>>>installations or you have extensions from numarray-0.6.1 trying to run >>>>>against numarray-1.3.2. >>>>> >>>>>Regards, >>>>>Todd >>>>> >>>>> >>>>>. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>------------------------------------------------------- >>>>This SF.Net email is sponsored by Yahoo. >>>>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! >>>>Search APIs Find out how you can build Yahoo! directly into your own >>>>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 >>>>_______________________________________________ >>>>Numpy-discussion mailing list >>>>Numpy-discussion at lists.sourceforge.net >>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion >>>> >>>> >>>> >>>> >>> >>>------------------------------------------------------- >>>This SF.Net email is sponsored by Yahoo. >>>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! >>>Search APIs Find out how you can build Yahoo! directly into your own >>>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 >>>_______________________________________________ >>>Numpy-discussion mailing list >>>Numpy-discussion at lists.sourceforge.net >>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion >>> >>>. >>> >>> >>> >>> >>> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by Yahoo. >>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! >>Search APIs Find out how you can build Yahoo! directly into your own >>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 >>_______________________________________________ >>Numpy-discussion mailing list >>Numpy-discussion at lists.sourceforge.net >>https://lists.sourceforge.net/lists/listinfo/numpy-discussion >> >> From haase at msg.ucsf.edu Thu Jun 2 17:47:05 2005 From: haase at msg.ucsf.edu (Sebastian Haase) Date: Thu Jun 2 17:47:05 2005 Subject: [Numpy-discussion] API broken after 1.1.1 (previously "crashes after switching to 1.3.x") In-Reply-To: <429F9221.7080701@uci.edu> References: <42967147.1000409@uci.edu> <1117750491.1740.279.camel@halloween.stsci.edu> <429F9221.7080701@uci.edu> Message-ID: <200506021743.18416.haase@msg.ucsf.edu> Hi, Great, my long tested program works now again. I still don't know what the gcc option -fPIC is for. Also "-shared" is not clear to me. (From the discussion before: I don't use it, seg-fault if I do) I anyone here could teach me ... In any case, I'm happy again. Thanks, Sebastian Haase On Thursday 02 June 2005 16:11, Adrian E. Feiguin wrote: > Hi Todd, > > I compiled the cvs version and it seems that you have fixed the problem, > excellent! However, your "fix" for older versions doesn't work, any > suggestions? > > Thanks! > > > Todd Miller wrote: > >I looked over your diffs but I don't think they're related to the > >problem you're seeing. > > > >>From your previous posts and those of Sebastian, I had the impression > > > >that you're using numarray in an embedded context... so I found > >embedded "from numarray import *". > > > >I learned that numarray embedding "broke" for numarray-1.2.3 by adding > >the unnecessary requirement that sys.argv exist. I fixed this in > >numarray CVS. A possible alternative to my fix which should work for > >older versions of numarray is to call PySys_SetArgv(0,NULL) after > >Py_Initialize() to ensure that sys.argv exists. > > > >Regards, > >Todd > > > >On Wed, 2005-06-01 at 18:37, Adrian E. Feiguin wrote: > >>Hi, > >> > >>As I've been discussing withTodd, scigraphica crashes after switching to > >>a newer version of numarray. I checked that it does not crash with > >>Numeric, or numarray-1.1.1, so I figured that at some point something > >>was broken. It seems that at some point between numarray-1.1.1 and 1.2.3 > >>some change broke the API. What I mean is that my libraries simply fail > >>to load numarray. I did diff between headers, and the only relevant > >>change that I noticed between 1.1.1 and 1.2.3 that I guess could be > >>related to this problem is in libnumeric.h: > >> > >>132c132 > >>< static int PyArray_Converter (PyObject *, PyObject **); > >>--- > >> > >> > static int XXX_PyArray_Converter (PyObject *, PyObject **); > >> > >>140c140 > >>< static int PyArray_ValidType (int type); > >>--- > >> > >> > static int XXX_PyArray_ValidType (int type); > >> > >>208c208 > >>< #define PyArray_Converter (libnumeric_API ? (*(int (*) (PyObject *, > >>PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) (PyObject *, PyObject > >>**) ) libnumeric_FatalApiError)) > >>--- > >> > >> > #define XXX_PyArray_Converter (libnumeric_API ? (*(int (*) > >> > >>(PyObject *, PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) > >>(PyObject *, PyObject **) ) libnumeric_FatalApiError)) > >>216c216 > >>< #define PyArray_ValidType (libnumeric_API ? (*(int (*) (int type) ) > >>libnumeric_API[ 29 ]) : (*(int (*) (int type) ) > >> libnumeric_FatalApiError)) --- > >> > >> > #define XXX_PyArray_ValidType (libnumeric_API ? (*(int (*) (int > >> > >>type) ) libnumeric_API[ 29 ]) : (*(int (*) (int type) ) > >>libnumeric_FatalApiError)) > >> > >>I hope this helps. I'll work with 1.1.1 from now on, unless you think > >>the problem is in my code. > >>Any ideas? > >>Thanks > >> > >> > >>Todd Miller wrote: > >>>Hi Adrian, > >>> > >>>I don't think you should be doing both "import_array()" and > >>>"import_libnumeric()". Those should be roughly equivalent. If you're > >>>using only the Numeric compatible API (no NA_ functions) then do: > >>> > >>>#include "numarray/arrayobject.h" > >>> > >>>... and later in your init function: > >>> > >>>import_array(); > >>> > >>>just like Numeric. If you also need some of the NA_ functions, then > >>>look at Src/_dotblas.c or Src/_numarraymodule.c for how to interface > >>>with both native and numeric compatible interfaces at the same time. If > >>>you only need NA_ functions, look at Src/_ndarraymodule.c. > >>> > >>>Regards, > >>>Todd > >>> > >>>On Fri, 2005-05-27 at 18:37 -0700, Adrian E. Feiguin wrote: > >>>>Hi Todd, > >>>> > >>>>Thank you for your reply. I have a completely new installation, there > >>>>are no conflicts with previous installations. > >>>>I found that the problem is in import_libnumeric in libnumeric.h. It > >>>>seems that the libnumeric_API is not initialized because it doesn't > >>>> pass the line: > >>>> > >>>> PyObject *module = > >>>>PyImport_ImportModule("numarray.libnumeric"); \ > >>>> if (module != NULL) > >>>>{ \ > >>>> > >>>>Any ideas? > >>>>Thank you again, > >>>> > >>>> > >>>>Todd Miller wrote: > >>>>>Hi Adrian, > >>>>> > >>>>>On Thu, 2005-05-26 at 18:00 -0700, Adrian E. Feiguin wrote: > >>>>>>Hi! I'm the lead developer of scigraphica (SG) > >>>>>>http://scigraphica.sourceforge.net and I'm using python and numarray > >>>>>> to parse math. SG is built on top of libscigraphica, and > >>>>>> libscigraphica has all the python code. I've been using an old > >>>>>> version 0.6.1, and everything worked fine. After switching to > >>>>>> 1.6.2the program crashes. I'll give you some info to see if you can > >>>>>> tell me what's wrong: > >>>>>> > >>>>>>I'm using: > >>>>>>#define PY_ARRAY_UNIQUE_SYMBOL PyArrayXXX > >>>>>>#include > >>>>>> > >>>>>>and in the code: > >>>>>> import_libnumeric(); > >>>>>> import_array(); > >>>>>> > >>>>>> object=PyRun_String ("from numarray import *", Py_single_input, > >>>>>>main_dict, sg_dict); > >>>>>> > >>>>>>(I noticed that you have to add import_libnumeric now) > >>>>> > >>>>>In general, this is not true. > >>>>> > >>>>>Paradoxically, if you're using the numeric compatible API, > >>>>>import_array() is all you need to do. If you're using both the > >>>>> numarray native and numeric compatible APIs, then you need to > >>>>>import_libnumarray() and import_libnumeric(). > >>>>> > >>>>>>The gdb output is: > >>>>>> > >>>>>>Importing python module: sys > >>>>>>Importing python module: pickle > >>>>>>Importing python module: os > >>>>>>Importing python module: numarrayProgram received signal SIGSEGV, > >>>>>>Segmentation fault. > >>>>>>[Switching to Thread 1083181376 (LWP 11648)] > >>>>>>0x400ab0b5 in PyObject_GetAttrString () > >>>>>> from > >>>>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigrap > >>>>>>hica-2.0-2.0.so.0 #0 0x400ab0b5 in PyObject_GetAttrString () > >>>>>> from > >>>>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigrap > >>>>>>hica-2.0-2.0.so.0 #1 0x40b1ff66 in deferred_libnumarray_init () at > >>>>>>Src/libnumarraymodule.c:152 > >>>>>>#2 0x40b21f8c in NA_NumArrayCheck (op=0x0) at > >>>>>> Src/libnumarraymodule.c:1357 #3 0x40b43c1c in PyArray_Check > >>>>>> (op=0x0) at Src/libnumericmodule.c:216 #4 0x4004d903 in > >>>>>> python_insert_object (worksheet=0x81ba4e0, row=0, col=0, > >>>>>> object=0x80bda3c, orient=GTK_ORIENTATION_VERTICAL, link=0, as_is=0) > >>>>>> at sg_python_worksheet.c:802 > >>>>>>#5 0x4004da12 in python_sheet (worksheet=0x81ba4e0, row=0, col=0, > >>>>>> command=0x8366d68 ".1", orient=GTK_ORIENTATION_VERTICAL) > >>>>>> at sg_python_worksheet.c:843 > >>>>>>#6 0x40061f7c in sg_worksheet_cell_set (worksheet=0x81ba4e0, row=0, > >>>>>> col=0, text=0x8365520 ".1", formula=1, eval=1) at sg_worksheet.c:508 > >>>>>> #7 0x40061d59 in set_cell (sheet=0x81ba4e0, row=0, col=0, > >>>>>> data=0x81ba4e0) at sg_worksheet.c:439 > >>>>>> > >>>>>>Look that in #4 object=0x80bda3c, and in #3 op=0x0. > >>>>>>Any hints? > >>>>> > >>>>>numarray-0.6.1 is very old so in order to transition to numarray-1.3.2 > >>>>>you should: > >>>>> > >>>>>a. completely delete your numarray installation > >>>>> > >>>>>b. reinstall numarray > >>>>> > >>>>>c. rebuild and reinstall any extensions based on numarray. > >>>>> > >>>>>My guess is that either you have overlapping/conflicting numarray > >>>>>installations or you have extensions from numarray-0.6.1 trying to run > >>>>>against numarray-1.3.2. > >>>>> > >>>>>Regards, > >>>>>Todd > >>>>> > >>>>> > >>>>>. > >>>> > >>>>------------------------------------------------------- > >>>>This SF.Net email is sponsored by Yahoo. > >>>>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >>>>Search APIs Find out how you can build Yahoo! directly into your own > >>>>Applications - visit > >>>> http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >>>> _______________________________________________ > >>>>Numpy-discussion mailing list > >>>>Numpy-discussion at lists.sourceforge.net > >>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion > >>> > >>>------------------------------------------------------- > >>>This SF.Net email is sponsored by Yahoo. > >>>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >>>Search APIs Find out how you can build Yahoo! directly into your own > >>>Applications - visit > >>> http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >>> _______________________________________________ > >>>Numpy-discussion mailing list > >>>Numpy-discussion at lists.sourceforge.net > >>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion > >>> > >>>. > >> > >>------------------------------------------------------- > >>This SF.Net email is sponsored by Yahoo. > >>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >>Search APIs Find out how you can build Yahoo! directly into your own > >>Applications - visit > >> http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >> _______________________________________________ > >>Numpy-discussion mailing list > >>Numpy-discussion at lists.sourceforge.net > >>https://lists.sourceforge.net/lists/listinfo/numpy-discussion From jmiller at stsci.edu Fri Jun 3 06:28:47 2005 From: jmiller at stsci.edu (Todd Miller) Date: Fri Jun 3 06:28:47 2005 Subject: [Numpy-discussion] API broken after 1.1.1 (previously "crashes after switching to 1.3.x") In-Reply-To: <429F9221.7080701@uci.edu> References: <42967147.1000409@uci.edu> <1117191173.4718.15.camel@jaytmiller.comcast.net> <4297CB5F.9000906@uci.edu> <1117367726.9474.4.camel@localhost.localdomain> <429E38AA.5030700@uci.edu> <1117750491.1740.279.camel@halloween.stsci.edu> <429F9221.7080701@uci.edu> Message-ID: <1117805252.24178.1.camel@halloween.stsci.edu> On Thu, 2005-06-02 at 19:11, Adrian E. Feiguin wrote: > Hi Todd, > > I compiled the cvs version and it seems that you have fixed the problem, > excellent! However, your "fix" for older versions doesn't work, any > suggestions? Try this instead (or get and use the "real" argc, argv): PySys_SetArgv(0, &""); Todd > Thanks! > > > Todd Miller wrote: > > >I looked over your diffs but I don't think they're related to the > >problem you're seeing. > > > >>From your previous posts and those of Sebastian, I had the impression > >that you're using numarray in an embedded context... so I found > >embedded "from numarray import *". > > > >I learned that numarray embedding "broke" for numarray-1.2.3 by adding > >the unnecessary requirement that sys.argv exist. I fixed this in > >numarray CVS. A possible alternative to my fix which should work for > >older versions of numarray is to call PySys_SetArgv(0,NULL) after > >Py_Initialize() to ensure that sys.argv exists. > > > >Regards, > >Todd > > > >On Wed, 2005-06-01 at 18:37, Adrian E. Feiguin wrote: > > > > > >>Hi, > >> > >>As I've been discussing withTodd, scigraphica crashes after switching to > >>a newer version of numarray. I checked that it does not crash with > >>Numeric, or numarray-1.1.1, so I figured that at some point something > >>was broken. It seems that at some point between numarray-1.1.1 and 1.2.3 > >>some change broke the API. What I mean is that my libraries simply fail > >>to load numarray. I did diff between headers, and the only relevant > >>change that I noticed between 1.1.1 and 1.2.3 that I guess could be > >>related to this problem is in libnumeric.h: > >> > >>132c132 > >>< static int PyArray_Converter (PyObject *, PyObject **); > >>--- > >> > static int XXX_PyArray_Converter (PyObject *, PyObject **); > >>140c140 > >>< static int PyArray_ValidType (int type); > >>--- > >> > static int XXX_PyArray_ValidType (int type); > >>208c208 > >>< #define PyArray_Converter (libnumeric_API ? (*(int (*) (PyObject *, > >>PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) (PyObject *, PyObject > >>**) ) libnumeric_FatalApiError)) > >>--- > >> > #define XXX_PyArray_Converter (libnumeric_API ? (*(int (*) > >>(PyObject *, PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) > >>(PyObject *, PyObject **) ) libnumeric_FatalApiError)) > >>216c216 > >>< #define PyArray_ValidType (libnumeric_API ? (*(int (*) (int type) ) > >>libnumeric_API[ 29 ]) : (*(int (*) (int type) ) libnumeric_FatalApiError)) > >>--- > >> > #define XXX_PyArray_ValidType (libnumeric_API ? (*(int (*) (int > >>type) ) libnumeric_API[ 29 ]) : (*(int (*) (int type) ) > >>libnumeric_FatalApiError)) > >> > >>I hope this helps. I'll work with 1.1.1 from now on, unless you think > >>the problem is in my code. > >>Any ideas? > >>Thanks > >> > >> > >>Todd Miller wrote: > >> > >> > >> > >>>Hi Adrian, > >>> > >>>I don't think you should be doing both "import_array()" and > >>>"import_libnumeric()". Those should be roughly equivalent. If you're > >>>using only the Numeric compatible API (no NA_ functions) then do: > >>> > >>>#include "numarray/arrayobject.h" > >>> > >>>... and later in your init function: > >>> > >>>import_array(); > >>> > >>>just like Numeric. If you also need some of the NA_ functions, then > >>>look at Src/_dotblas.c or Src/_numarraymodule.c for how to interface > >>>with both native and numeric compatible interfaces at the same time. If > >>>you only need NA_ functions, look at Src/_ndarraymodule.c. > >>> > >>>Regards, > >>>Todd > >>> > >>>On Fri, 2005-05-27 at 18:37 -0700, Adrian E. Feiguin wrote: > >>> > >>> > >>> > >>> > >>>>Hi Todd, > >>>> > >>>>Thank you for your reply. I have a completely new installation, there > >>>>are no conflicts with previous installations. > >>>>I found that the problem is in import_libnumeric in libnumeric.h. It > >>>>seems that the libnumeric_API is not initialized because it doesn't pass > >>>>the line: > >>>> > >>>> PyObject *module = > >>>>PyImport_ImportModule("numarray.libnumeric"); \ > >>>> if (module != NULL) > >>>>{ \ > >>>> > >>>>Any ideas? > >>>>Thank you again, > >>>> > >>>> > >>>> > >>>>Todd Miller wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Hi Adrian, > >>>>> > >>>>>On Thu, 2005-05-26 at 18:00 -0700, Adrian E. Feiguin wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Hi! I'm the lead developer of scigraphica (SG) > >>>>>>http://scigraphica.sourceforge.net and I'm using python and numarray to > >>>>>>parse math. SG is built on top of libscigraphica, and libscigraphica has > >>>>>>all the python code. I've been using an old version 0.6.1, and > >>>>>>everything worked fine. After switching to 1.6.2the program crashes. > >>>>>>I'll give you some info to see if you can tell me what's wrong: > >>>>>> > >>>>>>I'm using: > >>>>>>#define PY_ARRAY_UNIQUE_SYMBOL PyArrayXXX > >>>>>>#include > >>>>>> > >>>>>>and in the code: > >>>>>> import_libnumeric(); > >>>>>> import_array(); > >>>>>> > >>>>>> object=PyRun_String ("from numarray import *", Py_single_input, > >>>>>>main_dict, sg_dict); > >>>>>> > >>>>>>(I noticed that you have to add import_libnumeric now) > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>In general, this is not true. > >>>>> > >>>>>Paradoxically, if you're using the numeric compatible API, > >>>>>import_array() is all you need to do. If you're using both the numarray > >>>>>native and numeric compatible APIs, then you need to > >>>>>import_libnumarray() and import_libnumeric(). > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>The gdb output is: > >>>>>> > >>>>>>Importing python module: sys > >>>>>>Importing python module: pickle > >>>>>>Importing python module: os > >>>>>>Importing python module: numarrayProgram received signal SIGSEGV, > >>>>>>Segmentation fault. > >>>>>>[Switching to Thread 1083181376 (LWP 11648)] > >>>>>>0x400ab0b5 in PyObject_GetAttrString () > >>>>>> from > >>>>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphica-2.0-2.0.so.0 > >>>>>>#0 0x400ab0b5 in PyObject_GetAttrString () > >>>>>> from > >>>>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphica-2.0-2.0.so.0 > >>>>>>#1 0x40b1ff66 in deferred_libnumarray_init () at > >>>>>>Src/libnumarraymodule.c:152 > >>>>>>#2 0x40b21f8c in NA_NumArrayCheck (op=0x0) at Src/libnumarraymodule.c:1357 > >>>>>>#3 0x40b43c1c in PyArray_Check (op=0x0) at Src/libnumericmodule.c:216 > >>>>>>#4 0x4004d903 in python_insert_object (worksheet=0x81ba4e0, row=0, col=0, > >>>>>> object=0x80bda3c, orient=GTK_ORIENTATION_VERTICAL, link=0, as_is=0) > >>>>>> at sg_python_worksheet.c:802 > >>>>>>#5 0x4004da12 in python_sheet (worksheet=0x81ba4e0, row=0, col=0, > >>>>>> command=0x8366d68 ".1", orient=GTK_ORIENTATION_VERTICAL) > >>>>>> at sg_python_worksheet.c:843 > >>>>>>#6 0x40061f7c in sg_worksheet_cell_set (worksheet=0x81ba4e0, row=0, col=0, > >>>>>> text=0x8365520 ".1", formula=1, eval=1) at sg_worksheet.c:508 > >>>>>>#7 0x40061d59 in set_cell (sheet=0x81ba4e0, row=0, col=0, data=0x81ba4e0) > >>>>>> at sg_worksheet.c:439 > >>>>>> > >>>>>>Look that in #4 object=0x80bda3c, and in #3 op=0x0. > >>>>>>Any hints? > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>numarray-0.6.1 is very old so in order to transition to numarray-1.3.2 > >>>>>you should: > >>>>> > >>>>>a. completely delete your numarray installation > >>>>> > >>>>>b. reinstall numarray > >>>>> > >>>>>c. rebuild and reinstall any extensions based on numarray. > >>>>> > >>>>>My guess is that either you have overlapping/conflicting numarray > >>>>>installations or you have extensions from numarray-0.6.1 trying to run > >>>>>against numarray-1.3.2. > >>>>> > >>>>>Regards, > >>>>>Todd > >>>>> > >>>>> > >>>>>. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>------------------------------------------------------- > >>>>This SF.Net email is sponsored by Yahoo. > >>>>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >>>>Search APIs Find out how you can build Yahoo! directly into your own > >>>>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >>>>_______________________________________________ > >>>>Numpy-discussion mailing list > >>>>Numpy-discussion at lists.sourceforge.net > >>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion > >>>> > >>>> > >>>> > >>>> > >>> > >>>------------------------------------------------------- > >>>This SF.Net email is sponsored by Yahoo. > >>>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >>>Search APIs Find out how you can build Yahoo! directly into your own > >>>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >>>_______________________________________________ > >>>Numpy-discussion mailing list > >>>Numpy-discussion at lists.sourceforge.net > >>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion > >>> > >>>. > >>> > >>> > >>> > >>> > >>> > >> > >>------------------------------------------------------- > >>This SF.Net email is sponsored by Yahoo. > >>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >>Search APIs Find out how you can build Yahoo! directly into your own > >>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >>_______________________________________________ > >>Numpy-discussion mailing list > >>Numpy-discussion at lists.sourceforge.net > >>https://lists.sourceforge.net/lists/listinfo/numpy-discussion > >> > >> -- From afeiguin at uci.edu Fri Jun 3 10:57:21 2005 From: afeiguin at uci.edu (Adrian E. Feiguin) Date: Fri Jun 3 10:57:21 2005 Subject: [Numpy-discussion] API broken after 1.1.1 (previously "crashes after switching to 1.3.x") In-Reply-To: <1117805252.24178.1.camel@halloween.stsci.edu> References: <42967147.1000409@uci.edu> <1117191173.4718.15.camel@jaytmiller.comcast.net> <4297CB5F.9000906@uci.edu> <1117367726.9474.4.camel@localhost.localdomain> <429E38AA.5030700@uci.edu> <1117750491.1740.279.camel@halloween.stsci.edu> <429F9221.7080701@uci.edu> <1117805252.24178.1.camel@halloween.stsci.edu> Message-ID: <42A099C3.9090802@uci.edu> That worked, thanks! BTW, Are you planning to release soon? aludos, Todd Miller wrote: >On Thu, 2005-06-02 at 19:11, Adrian E. Feiguin wrote: > > >>Hi Todd, >> >>I compiled the cvs version and it seems that you have fixed the problem, >>excellent! However, your "fix" for older versions doesn't work, any >>suggestions? >> >> > >Try this instead (or get and use the "real" argc, argv): > >PySys_SetArgv(0, &""); > > >Todd > > > >>Thanks! >> >> >>Todd Miller wrote: >> >> >> >>>I looked over your diffs but I don't think they're related to the >>>problem you're seeing. >>> >>>>From your previous posts and those of Sebastian, I had the impression >>>that you're using numarray in an embedded context... so I found >>>embedded "from numarray import *". >>> >>>I learned that numarray embedding "broke" for numarray-1.2.3 by adding >>>the unnecessary requirement that sys.argv exist. I fixed this in >>>numarray CVS. A possible alternative to my fix which should work for >>>older versions of numarray is to call PySys_SetArgv(0,NULL) after >>>Py_Initialize() to ensure that sys.argv exists. >>> >>>Regards, >>>Todd >>> >>>On Wed, 2005-06-01 at 18:37, Adrian E. Feiguin wrote: >>> >>> >>> >>> >>>>Hi, >>>> >>>>As I've been discussing withTodd, scigraphica crashes after switching to >>>>a newer version of numarray. I checked that it does not crash with >>>>Numeric, or numarray-1.1.1, so I figured that at some point something >>>>was broken. It seems that at some point between numarray-1.1.1 and 1.2.3 >>>>some change broke the API. What I mean is that my libraries simply fail >>>>to load numarray. I did diff between headers, and the only relevant >>>>change that I noticed between 1.1.1 and 1.2.3 that I guess could be >>>>related to this problem is in libnumeric.h: >>>> >>>>132c132 >>>>< static int PyArray_Converter (PyObject *, PyObject **); >>>>--- >>>> >>>> >>>>>static int XXX_PyArray_Converter (PyObject *, PyObject **); >>>>> >>>>> >>>>140c140 >>>>< static int PyArray_ValidType (int type); >>>>--- >>>> >>>> >>>>>static int XXX_PyArray_ValidType (int type); >>>>> >>>>> >>>>208c208 >>>>< #define PyArray_Converter (libnumeric_API ? (*(int (*) (PyObject *, >>>>PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) (PyObject *, PyObject >>>>**) ) libnumeric_FatalApiError)) >>>>--- >>>> >>>> >>>>>#define XXX_PyArray_Converter (libnumeric_API ? (*(int (*) >>>>> >>>>> >>>>(PyObject *, PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) >>>>(PyObject *, PyObject **) ) libnumeric_FatalApiError)) >>>>216c216 >>>>< #define PyArray_ValidType (libnumeric_API ? (*(int (*) (int type) ) >>>>libnumeric_API[ 29 ]) : (*(int (*) (int type) ) libnumeric_FatalApiError)) >>>>--- >>>> >>>> >>>>>#define XXX_PyArray_ValidType (libnumeric_API ? (*(int (*) (int >>>>> >>>>> >>>>type) ) libnumeric_API[ 29 ]) : (*(int (*) (int type) ) >>>>libnumeric_FatalApiError)) >>>> >>>>I hope this helps. I'll work with 1.1.1 from now on, unless you think >>>>the problem is in my code. >>>>Any ideas? >>>>Thanks >>>> >>>> >>>>Todd Miller wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Hi Adrian, >>>>> >>>>>I don't think you should be doing both "import_array()" and >>>>>"import_libnumeric()". Those should be roughly equivalent. If you're >>>>>using only the Numeric compatible API (no NA_ functions) then do: >>>>> >>>>>#include "numarray/arrayobject.h" >>>>> >>>>>... and later in your init function: >>>>> >>>>>import_array(); >>>>> >>>>>just like Numeric. If you also need some of the NA_ functions, then >>>>>look at Src/_dotblas.c or Src/_numarraymodule.c for how to interface >>>>>with both native and numeric compatible interfaces at the same time. If >>>>>you only need NA_ functions, look at Src/_ndarraymodule.c. >>>>> >>>>>Regards, >>>>>Todd >>>>> >>>>>On Fri, 2005-05-27 at 18:37 -0700, Adrian E. Feiguin wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Hi Todd, >>>>>> >>>>>>Thank you for your reply. I have a completely new installation, there >>>>>>are no conflicts with previous installations. >>>>>>I found that the problem is in import_libnumeric in libnumeric.h. It >>>>>>seems that the libnumeric_API is not initialized because it doesn't pass >>>>>>the line: >>>>>> >>>>>> PyObject *module = >>>>>>PyImport_ImportModule("numarray.libnumeric"); \ >>>>>> if (module != NULL) >>>>>>{ \ >>>>>> >>>>>>Any ideas? >>>>>>Thank you again, >>>>>> >>>>>> >>>>>> >>>>>>Todd Miller wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Hi Adrian, >>>>>>> >>>>>>>On Thu, 2005-05-26 at 18:00 -0700, Adrian E. Feiguin wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Hi! I'm the lead developer of scigraphica (SG) >>>>>>>>http://scigraphica.sourceforge.net and I'm using python and numarray to >>>>>>>>parse math. SG is built on top of libscigraphica, and libscigraphica has >>>>>>>>all the python code. I've been using an old version 0.6.1, and >>>>>>>>everything worked fine. After switching to 1.6.2the program crashes. >>>>>>>>I'll give you some info to see if you can tell me what's wrong: >>>>>>>> >>>>>>>>I'm using: >>>>>>>>#define PY_ARRAY_UNIQUE_SYMBOL PyArrayXXX >>>>>>>>#include >>>>>>>> >>>>>>>>and in the code: >>>>>>>> import_libnumeric(); >>>>>>>> import_array(); >>>>>>>> >>>>>>>> object=PyRun_String ("from numarray import *", Py_single_input, >>>>>>>>main_dict, sg_dict); >>>>>>>> >>>>>>>>(I noticed that you have to add import_libnumeric now) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>In general, this is not true. >>>>>>> >>>>>>>Paradoxically, if you're using the numeric compatible API, >>>>>>>import_array() is all you need to do. If you're using both the numarray >>>>>>>native and numeric compatible APIs, then you need to >>>>>>>import_libnumarray() and import_libnumeric(). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>The gdb output is: >>>>>>>> >>>>>>>>Importing python module: sys >>>>>>>>Importing python module: pickle >>>>>>>>Importing python module: os >>>>>>>>Importing python module: numarrayProgram received signal SIGSEGV, >>>>>>>>Segmentation fault. >>>>>>>>[Switching to Thread 1083181376 (LWP 11648)] >>>>>>>>0x400ab0b5 in PyObject_GetAttrString () >>>>>>>>from >>>>>>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphica-2.0-2.0.so.0 >>>>>>>>#0 0x400ab0b5 in PyObject_GetAttrString () >>>>>>>>from >>>>>>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphica-2.0-2.0.so.0 >>>>>>>>#1 0x40b1ff66 in deferred_libnumarray_init () at >>>>>>>>Src/libnumarraymodule.c:152 >>>>>>>>#2 0x40b21f8c in NA_NumArrayCheck (op=0x0) at Src/libnumarraymodule.c:1357 >>>>>>>>#3 0x40b43c1c in PyArray_Check (op=0x0) at Src/libnumericmodule.c:216 >>>>>>>>#4 0x4004d903 in python_insert_object (worksheet=0x81ba4e0, row=0, col=0, >>>>>>>> object=0x80bda3c, orient=GTK_ORIENTATION_VERTICAL, link=0, as_is=0) >>>>>>>> at sg_python_worksheet.c:802 >>>>>>>>#5 0x4004da12 in python_sheet (worksheet=0x81ba4e0, row=0, col=0, >>>>>>>> command=0x8366d68 ".1", orient=GTK_ORIENTATION_VERTICAL) >>>>>>>> at sg_python_worksheet.c:843 >>>>>>>>#6 0x40061f7c in sg_worksheet_cell_set (worksheet=0x81ba4e0, row=0, col=0, >>>>>>>> text=0x8365520 ".1", formula=1, eval=1) at sg_worksheet.c:508 >>>>>>>>#7 0x40061d59 in set_cell (sheet=0x81ba4e0, row=0, col=0, data=0x81ba4e0) >>>>>>>> at sg_worksheet.c:439 >>>>>>>> >>>>>>>>Look that in #4 object=0x80bda3c, and in #3 op=0x0. >>>>>>>>Any hints? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>numarray-0.6.1 is very old so in order to transition to numarray-1.3.2 >>>>>>>you should: >>>>>>> >>>>>>>a. completely delete your numarray installation >>>>>>> >>>>>>>b. reinstall numarray >>>>>>> >>>>>>>c. rebuild and reinstall any extensions based on numarray. >>>>>>> >>>>>>>My guess is that either you have overlapping/conflicting numarray >>>>>>>installations or you have extensions from numarray-0.6.1 trying to run >>>>>>>against numarray-1.3.2. >>>>>>> >>>>>>>Regards, >>>>>>>Todd >>>>>>> >>>>>>> >>>>>>>. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>------------------------------------------------------- >>>>>>This SF.Net email is sponsored by Yahoo. >>>>>>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! >>>>>>Search APIs Find out how you can build Yahoo! directly into your own >>>>>>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 >>>>>>_______________________________________________ >>>>>>Numpy-discussion mailing list >>>>>>Numpy-discussion at lists.sourceforge.net >>>>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>------------------------------------------------------- >>>>>This SF.Net email is sponsored by Yahoo. >>>>>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! >>>>>Search APIs Find out how you can build Yahoo! directly into your own >>>>>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 >>>>>_______________________________________________ >>>>>Numpy-discussion mailing list >>>>>Numpy-discussion at lists.sourceforge.net >>>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion >>>>> >>>>>. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>------------------------------------------------------- >>>>This SF.Net email is sponsored by Yahoo. >>>>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! >>>>Search APIs Find out how you can build Yahoo! directly into your own >>>>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 >>>>_______________________________________________ >>>>Numpy-discussion mailing list >>>>Numpy-discussion at lists.sourceforge.net >>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion >>>> >>>> >>>> >>>> From jmiller at stsci.edu Fri Jun 3 11:06:16 2005 From: jmiller at stsci.edu (Todd Miller) Date: Fri Jun 3 11:06:16 2005 Subject: [Numpy-discussion] API broken after 1.1.1 (previously "crashes after switching to 1.3.x") In-Reply-To: <42A099C3.9090802@uci.edu> References: <42967147.1000409@uci.edu> <1117191173.4718.15.camel@jaytmiller.comcast.net> <4297CB5F.9000906@uci.edu> <1117367726.9474.4.camel@localhost.localdomain> <429E38AA.5030700@uci.edu> <1117750491.1740.279.camel@halloween.stsci.edu> <429F9221.7080701@uci.edu> <1117805252.24178.1.camel@halloween.stsci.edu> <42A099C3.9090802@uci.edu> Message-ID: <1117821900.24178.12.camel@halloween.stsci.edu> On Fri, 2005-06-03 at 13:56, Adrian E. Feiguin wrote: > That worked, thanks! BTW, Are you planning to release soon? Not immediately. I'll crank out 1.3.3 in a couple weeks or so. Regards, Todd > aludos, > > > Todd Miller wrote: > > >On Thu, 2005-06-02 at 19:11, Adrian E. Feiguin wrote: > > > > > >>Hi Todd, > >> > >>I compiled the cvs version and it seems that you have fixed the problem, > >>excellent! However, your "fix" for older versions doesn't work, any > >>suggestions? > >> > >> > > > >Try this instead (or get and use the "real" argc, argv): > > > >PySys_SetArgv(0, &""); > > > > > >Todd > > > > > > > >>Thanks! > >> > >> > >>Todd Miller wrote: > >> > >> > >> > >>>I looked over your diffs but I don't think they're related to the > >>>problem you're seeing. > >>> > >>>>From your previous posts and those of Sebastian, I had the impression > >>>that you're using numarray in an embedded context... so I found > >>>embedded "from numarray import *". > >>> > >>>I learned that numarray embedding "broke" for numarray-1.2.3 by adding > >>>the unnecessary requirement that sys.argv exist. I fixed this in > >>>numarray CVS. A possible alternative to my fix which should work for > >>>older versions of numarray is to call PySys_SetArgv(0,NULL) after > >>>Py_Initialize() to ensure that sys.argv exists. > >>> > >>>Regards, > >>>Todd > >>> > >>>On Wed, 2005-06-01 at 18:37, Adrian E. Feiguin wrote: > >>> > >>> > >>> > >>> > >>>>Hi, > >>>> > >>>>As I've been discussing withTodd, scigraphica crashes after switching to > >>>>a newer version of numarray. I checked that it does not crash with > >>>>Numeric, or numarray-1.1.1, so I figured that at some point something > >>>>was broken. It seems that at some point between numarray-1.1.1 and 1.2.3 > >>>>some change broke the API. What I mean is that my libraries simply fail > >>>>to load numarray. I did diff between headers, and the only relevant > >>>>change that I noticed between 1.1.1 and 1.2.3 that I guess could be > >>>>related to this problem is in libnumeric.h: > >>>> > >>>>132c132 > >>>>< static int PyArray_Converter (PyObject *, PyObject **); > >>>>--- > >>>> > >>>> > >>>>>static int XXX_PyArray_Converter (PyObject *, PyObject **); > >>>>> > >>>>> > >>>>140c140 > >>>>< static int PyArray_ValidType (int type); > >>>>--- > >>>> > >>>> > >>>>>static int XXX_PyArray_ValidType (int type); > >>>>> > >>>>> > >>>>208c208 > >>>>< #define PyArray_Converter (libnumeric_API ? (*(int (*) (PyObject *, > >>>>PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) (PyObject *, PyObject > >>>>**) ) libnumeric_FatalApiError)) > >>>>--- > >>>> > >>>> > >>>>>#define XXX_PyArray_Converter (libnumeric_API ? (*(int (*) > >>>>> > >>>>> > >>>>(PyObject *, PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) > >>>>(PyObject *, PyObject **) ) libnumeric_FatalApiError)) > >>>>216c216 > >>>>< #define PyArray_ValidType (libnumeric_API ? (*(int (*) (int type) ) > >>>>libnumeric_API[ 29 ]) : (*(int (*) (int type) ) libnumeric_FatalApiError)) > >>>>--- > >>>> > >>>> > >>>>>#define XXX_PyArray_ValidType (libnumeric_API ? (*(int (*) (int > >>>>> > >>>>> > >>>>type) ) libnumeric_API[ 29 ]) : (*(int (*) (int type) ) > >>>>libnumeric_FatalApiError)) > >>>> > >>>>I hope this helps. I'll work with 1.1.1 from now on, unless you think > >>>>the problem is in my code. > >>>>Any ideas? > >>>>Thanks > >>>> > >>>> > >>>>Todd Miller wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Hi Adrian, > >>>>> > >>>>>I don't think you should be doing both "import_array()" and > >>>>>"import_libnumeric()". Those should be roughly equivalent. If you're > >>>>>using only the Numeric compatible API (no NA_ functions) then do: > >>>>> > >>>>>#include "numarray/arrayobject.h" > >>>>> > >>>>>... and later in your init function: > >>>>> > >>>>>import_array(); > >>>>> > >>>>>just like Numeric. If you also need some of the NA_ functions, then > >>>>>look at Src/_dotblas.c or Src/_numarraymodule.c for how to interface > >>>>>with both native and numeric compatible interfaces at the same time. If > >>>>>you only need NA_ functions, look at Src/_ndarraymodule.c. > >>>>> > >>>>>Regards, > >>>>>Todd > >>>>> > >>>>>On Fri, 2005-05-27 at 18:37 -0700, Adrian E. Feiguin wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Hi Todd, > >>>>>> > >>>>>>Thank you for your reply. I have a completely new installation, there > >>>>>>are no conflicts with previous installations. > >>>>>>I found that the problem is in import_libnumeric in libnumeric.h. It > >>>>>>seems that the libnumeric_API is not initialized because it doesn't pass > >>>>>>the line: > >>>>>> > >>>>>> PyObject *module = > >>>>>>PyImport_ImportModule("numarray.libnumeric"); \ > >>>>>> if (module != NULL) > >>>>>>{ \ > >>>>>> > >>>>>>Any ideas? > >>>>>>Thank you again, > >>>>>> > >>>>>> > >>>>>> > >>>>>>Todd Miller wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Hi Adrian, > >>>>>>> > >>>>>>>On Thu, 2005-05-26 at 18:00 -0700, Adrian E. Feiguin wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>Hi! I'm the lead developer of scigraphica (SG) > >>>>>>>>http://scigraphica.sourceforge.net and I'm using python and numarray to > >>>>>>>>parse math. SG is built on top of libscigraphica, and libscigraphica has > >>>>>>>>all the python code. I've been using an old version 0.6.1, and > >>>>>>>>everything worked fine. After switching to 1.6.2the program crashes. > >>>>>>>>I'll give you some info to see if you can tell me what's wrong: > >>>>>>>> > >>>>>>>>I'm using: > >>>>>>>>#define PY_ARRAY_UNIQUE_SYMBOL PyArrayXXX > >>>>>>>>#include > >>>>>>>> > >>>>>>>>and in the code: > >>>>>>>> import_libnumeric(); > >>>>>>>> import_array(); > >>>>>>>> > >>>>>>>> object=PyRun_String ("from numarray import *", Py_single_input, > >>>>>>>>main_dict, sg_dict); > >>>>>>>> > >>>>>>>>(I noticed that you have to add import_libnumeric now) > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>In general, this is not true. > >>>>>>> > >>>>>>>Paradoxically, if you're using the numeric compatible API, > >>>>>>>import_array() is all you need to do. If you're using both the numarray > >>>>>>>native and numeric compatible APIs, then you need to > >>>>>>>import_libnumarray() and import_libnumeric(). > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>The gdb output is: > >>>>>>>> > >>>>>>>>Importing python module: sys > >>>>>>>>Importing python module: pickle > >>>>>>>>Importing python module: os > >>>>>>>>Importing python module: numarrayProgram received signal SIGSEGV, > >>>>>>>>Segmentation fault. > >>>>>>>>[Switching to Thread 1083181376 (LWP 11648)] > >>>>>>>>0x400ab0b5 in PyObject_GetAttrString () > >>>>>>>>from > >>>>>>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphica-2.0-2.0.so.0 > >>>>>>>>#0 0x400ab0b5 in PyObject_GetAttrString () > >>>>>>>>from > >>>>>>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphica-2.0-2.0.so.0 > >>>>>>>>#1 0x40b1ff66 in deferred_libnumarray_init () at > >>>>>>>>Src/libnumarraymodule.c:152 > >>>>>>>>#2 0x40b21f8c in NA_NumArrayCheck (op=0x0) at Src/libnumarraymodule.c:1357 > >>>>>>>>#3 0x40b43c1c in PyArray_Check (op=0x0) at Src/libnumericmodule.c:216 > >>>>>>>>#4 0x4004d903 in python_insert_object (worksheet=0x81ba4e0, row=0, col=0, > >>>>>>>> object=0x80bda3c, orient=GTK_ORIENTATION_VERTICAL, link=0, as_is=0) > >>>>>>>> at sg_python_worksheet.c:802 > >>>>>>>>#5 0x4004da12 in python_sheet (worksheet=0x81ba4e0, row=0, col=0, > >>>>>>>> command=0x8366d68 ".1", orient=GTK_ORIENTATION_VERTICAL) > >>>>>>>> at sg_python_worksheet.c:843 > >>>>>>>>#6 0x40061f7c in sg_worksheet_cell_set (worksheet=0x81ba4e0, row=0, col=0, > >>>>>>>> text=0x8365520 ".1", formula=1, eval=1) at sg_worksheet.c:508 > >>>>>>>>#7 0x40061d59 in set_cell (sheet=0x81ba4e0, row=0, col=0, data=0x81ba4e0) > >>>>>>>> at sg_worksheet.c:439 > >>>>>>>> > >>>>>>>>Look that in #4 object=0x80bda3c, and in #3 op=0x0. > >>>>>>>>Any hints? > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>numarray-0.6.1 is very old so in order to transition to numarray-1.3.2 > >>>>>>>you should: > >>>>>>> > >>>>>>>a. completely delete your numarray installation > >>>>>>> > >>>>>>>b. reinstall numarray > >>>>>>> > >>>>>>>c. rebuild and reinstall any extensions based on numarray. > >>>>>>> > >>>>>>>My guess is that either you have overlapping/conflicting numarray > >>>>>>>installations or you have extensions from numarray-0.6.1 trying to run > >>>>>>>against numarray-1.3.2. > >>>>>>> > >>>>>>>Regards, > >>>>>>>Todd > >>>>>>> > >>>>>>> > >>>>>>>. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>------------------------------------------------------- > >>>>>>This SF.Net email is sponsored by Yahoo. > >>>>>>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >>>>>>Search APIs Find out how you can build Yahoo! directly into your own > >>>>>>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >>>>>>_______________________________________________ > >>>>>>Numpy-discussion mailing list > >>>>>>Numpy-discussion at lists.sourceforge.net > >>>>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>------------------------------------------------------- > >>>>>This SF.Net email is sponsored by Yahoo. > >>>>>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >>>>>Search APIs Find out how you can build Yahoo! directly into your own > >>>>>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >>>>>_______________________________________________ > >>>>>Numpy-discussion mailing list > >>>>>Numpy-discussion at lists.sourceforge.net > >>>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion > >>>>> > >>>>>. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>------------------------------------------------------- > >>>>This SF.Net email is sponsored by Yahoo. > >>>>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >>>>Search APIs Find out how you can build Yahoo! directly into your own > >>>>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >>>>_______________________________________________ > >>>>Numpy-discussion mailing list > >>>>Numpy-discussion at lists.sourceforge.net > >>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion > >>>> > >>>> > >>>> > >>>> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput > a projector? How fast can you ride your desk chair down the office luge track? > If you want to score the big prize, get to know the little guy. > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion -- From russel at appliedminds.net Fri Jun 3 11:44:21 2005 From: russel at appliedminds.net (Russel Howe) Date: Fri Jun 3 11:44:21 2005 Subject: [Numpy-discussion] Error in nd_image filters? Message-ID: <886476DA-AFFC-482C-8F64-35E7785985F1@appliedminds.net> I think there is an error in the 2nd and 3rd derivative gaussian kernels in the nd_image module. I have attached a patch which I believe has the correct formula, would someone please double-check me on this? Thanks Russel Howe --- numarray-1.3.2/Packages/nd_image/Lib/filters.py 2005-03-08 15:58:08.000000000 -0800 +++ numarray-1.3.2-modified/Packages/nd_image/Lib/filters.py 2005-05-05 15:52:00.000000000 -0700 @@ -189,7 +189,7 @@ weights[lw] = -1.0 for ii in range(1, lw + 1): x = float(ii) - tmp = (2.0 * x * x / sd - 1.0) * weights[lw + ii] + tmp = ( x * x / sd - 1.0 ) * weights[lw + ii] / sd weights[lw + ii] = tmp weights[lw - ii] = tmp elif order == 3: # third derivative @@ -197,7 +197,7 @@ sd2 = sd * sd for ii in range(1, lw + 1): x = float(ii) - tmp = (6.0 - 4.0 * x * x / sd) * x * weights[lw + ii] + tmp = (3.0 - x * x / sd) * x * weights[lw + ii] / sd / sd weights[lw + ii] = tmp weights[lw - ii] = -tmp return correlate1d(input, weights, axis, origin = 0, mode = mode, From verveer at embl-heidelberg.de Fri Jun 3 15:05:17 2005 From: verveer at embl-heidelberg.de (Peter Verveer) Date: Fri Jun 3 15:05:17 2005 Subject: [Numpy-discussion] Error in nd_image filters? In-Reply-To: <886476DA-AFFC-482C-8F64-35E7785985F1@appliedminds.net> References: <886476DA-AFFC-482C-8F64-35E7785985F1@appliedminds.net> Message-ID: That seems to be indeed correct. In fact the line 'weights[lw] = -1.0' must also be changed to 'weights[lw] *= -1.0 / sd'. I committed these changes to CVS. Thanks for spotting this, Peter On Jun 3, 2005, at 8:39 PM, Russel Howe wrote: > I think there is an error in the 2nd and 3rd derivative gaussian > kernels in the nd_image module. I have attached a patch which I > believe has the correct formula, would someone please double-check me > on this? > Thanks > Russel Howe > --- numarray-1.3.2/Packages/nd_image/Lib/filters.py 2005-03-08 > 15:58:08.000000000 -0800 > +++ numarray-1.3.2-modified/Packages/nd_image/Lib/filters.py > 2005-05-05 15:52:00.000000000 -0700 > @@ -189,7 +189,7 @@ > weights[lw] = -1.0 > for ii in range(1, lw + 1): > x = float(ii) > - tmp = (2.0 * x * x / sd - 1.0) * weights[lw + ii] > + tmp = ( x * x / sd - 1.0 ) * weights[lw + ii] / sd > weights[lw + ii] = tmp > weights[lw - ii] = tmp > elif order == 3: # third derivative > @@ -197,7 +197,7 @@ > sd2 = sd * sd > for ii in range(1, lw + 1): > x = float(ii) > - tmp = (6.0 - 4.0 * x * x / sd) * x * weights[lw + ii] > + tmp = (3.0 - x * x / sd) * x * weights[lw + ii] / sd / sd > weights[lw + ii] = tmp > weights[lw - ii] = -tmp > return correlate1d(input, weights, axis, origin = 0, mode = mode, > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you > shotput > a projector? How fast can you ride your desk chair down the office > luge track? > If you want to score the big prize, get to know the little guy. Play > to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion From schaffer at optonline.net Sat Jun 4 11:59:05 2005 From: schaffer at optonline.net (Les Schaffer) Date: Sat Jun 4 11:59:05 2005 Subject: [Numpy-discussion] vacuum expansion of strings in record array Message-ID: <42A1F97A.1020507@optonline.net> is this a feature or a bug? see snippet below, i would like the empty string to stay empty, not grow to an empty space from nothing. thnx les schaffer code: import numarray.records as rec names = ['col1', 'col2'] d1 = [ ['', 'hello'], ['', 'world']] d2 = [ ['hh', 'hello'], ['', 'world']] print d1, d2 recarray1 = rec.array(d1, names=names) # aligned=0,1 made no diff recarray2 = rec.array(d2, names=names) # aligned=0,1 made no diff print recarray1 print recarray2 output: [['', 'hello'], ['', 'world']] [['hh', 'hello'], ['', 'world']] RecArray[ ('', 'hello'), ('', 'world') ] RecArray[ ('hh', 'hello'), (' ', 'world') ^ |____ vacuum expansion ] From jmiller at stsci.edu Sun Jun 5 07:15:04 2005 From: jmiller at stsci.edu (Todd Miller) Date: Sun Jun 5 07:15:04 2005 Subject: [Numpy-discussion] vacuum expansion of strings in record array In-Reply-To: <42A1F97A.1020507@optonline.net> References: <42A1F97A.1020507@optonline.net> Message-ID: <1117980833.4836.4.camel@localhost.localdomain> On Sat, 2005-06-04 at 14:56 -0400, Les Schaffer wrote: > is this a feature or a bug? see snippet below, i would like the empty > string to stay empty, not grow to an empty space from nothing. This is a subtle quirk that it would be nice to be without but not an accident or bug. It's an intentional feature since if conforms to the FITS file format which motivated the development of records.py to begin with. I think there probably should be a less eclectic subclass of RawCharArray, but don't have the time to write it myself. Regards, Todd > thnx > > les schaffer > > > code: > > import numarray.records as rec > > names = ['col1', 'col2'] > > d1 = [ ['', 'hello'], ['', 'world']] > d2 = [ ['hh', 'hello'], ['', 'world']] > print d1, d2 > > recarray1 = rec.array(d1, names=names) # aligned=0,1 made no diff > recarray2 = rec.array(d2, names=names) # aligned=0,1 made no diff > print recarray1 > print recarray2 > > > output: > > [['', 'hello'], ['', 'world']] [['hh', 'hello'], ['', 'world']] > RecArray[ > ('', 'hello'), > ('', 'world') > ] > RecArray[ > ('hh', 'hello'), > (' ', 'world') > > ^ > |____ vacuum expansion > ] > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput > a projector? How fast can you ride your desk chair down the office luge track? > If you want to score the big prize, get to know the little guy. > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion From schaffer at optonline.net Sun Jun 5 08:10:25 2005 From: schaffer at optonline.net (Les Schaffer) Date: Sun Jun 5 08:10:25 2005 Subject: [Numpy-discussion] vacuum expansion of strings in record array In-Reply-To: <1117980833.4836.4.camel@localhost.localdomain> References: <42A1F97A.1020507@optonline.net> <1117980833.4836.4.camel@localhost.localdomain> Message-ID: <42A315AC.3030408@optonline.net> Todd Miller wrote: >This is a subtle quirk that it would be nice to be without but not an >accident or bug. It's an intentional feature since if conforms to the >FITS file format which motivated the development of records.py to begin >with. I think there probably should be a less eclectic subclass of >RawCharArray, but don't have the time to write it myself. > > i take it this is what bit us: "When an element of a CharArray is fetched trailing whitespace is stripped off. The sole exception to this rule is that a single whitespace is never stripped down to the empty string." so the strings are all the same length in storage, and the empty string '' expands to this fixed size WITH SPACES and then contract down to a single space when retrieved. true inflation, something from the vacuum. i am not familiar with the FITS file format to know why you would want such creation-prone behavior: why not just fill the slots with \0's (empty string '' ---> n*\0)? in any case, i will take a look at whats involved in basing a subclassed RecordArray on a variant of the raw char array. is this stuff in C or in Python? a quick hint where to look would help. Record Arrays are nice for holding stuff from Excel tables where columns are of similar type, with a column name up top. However, to grab Excel data w/ Python requires COM which delivers everything as UniCode strings which needed to be encoded() before RecordArray accepts them. is there a plan to include UniCode eventually? Les Schaffer From jmiller at stsci.edu Mon Jun 6 04:13:08 2005 From: jmiller at stsci.edu (Todd Miller) Date: Mon Jun 6 04:13:08 2005 Subject: [Numpy-discussion] vacuum expansion of strings in record array In-Reply-To: <42A315AC.3030408@optonline.net> References: <42A1F97A.1020507@optonline.net> <1117980833.4836.4.camel@localhost.localdomain> <42A315AC.3030408@optonline.net> Message-ID: <1118056370.5261.8.camel@localhost.localdomain> On Sun, 2005-06-05 at 11:09 -0400, Les Schaffer wrote: > Todd Miller wrote: > > >This is a subtle quirk that it would be nice to be without but not an > >accident or bug. It's an intentional feature since if conforms to the > >FITS file format which motivated the development of records.py to begin > >with. I think there probably should be a less eclectic subclass of > >RawCharArray, but don't have the time to write it myself. > > > > > i take it this is what bit us: > > "When an element of a CharArray is fetched trailing whitespace is > stripped off. The sole exception to this rule is that a single > whitespace is never stripped down to the empty string." Yep, that's it. > > so the strings are all the same length in storage, and the empty string > '' expands to this fixed size WITH SPACES and then contract down to a > single space when retrieved. true inflation, something from the vacuum. > > i am not familiar with the FITS file format to know why you would want > such creation-prone behavior: why not just fill the slots with \0's > (empty string '' ---> n*\0)? in any case, i will take a look at whats > involved in basing a subclassed RecordArray on a variant of the raw char > array. is this stuff in C or in Python? Both. What you're talking about should be doable in pure Python for starters. > a quick hint where to look would > help. Lib/strings.py, Lib/records.py, Src/_chararraymodule.c > > Record Arrays are nice for holding stuff from Excel tables where columns > are of similar type, with a column name up top. However, to grab Excel > data w/ Python requires COM which delivers everything as UniCode strings > which needed to be encoded() before RecordArray accepts them. is there a > plan to include UniCode eventually? There is no plan for adding UniCode I'm aware of but Perry might have more to say about that. Unicode has come up before and would be a nice addition. Regards, Todd From MAILER-DAEMON at mail.grebennikov.ru Tue Jun 7 02:34:14 2005 From: MAILER-DAEMON at mail.grebennikov.ru (Mail Delivery Subsystem) Date: Tue Jun 7 02:34:14 2005 Subject: [Numpy-discussion] Returned mail: see transcript for details Message-ID: <200506070933.j573DcGi094590@mail.grebennikov.ru> The original message was received at Thu, 2 Jun 2005 13:17:04 +0400 (MSD) from [62.117.122.242] ----- The following addresses had permanent fatal errors ----- (reason: Deferred) ----- Transcript of session follows ----- ... Deferred: cyrus mailer (/usr/local/cyrus/bin/deliver) exited with EX_TEMPFAIL Message could not be delivered for 5 days Message will be deleted from queue From numpy-discussion at lists.sourceforge.net Thu Jun 2 05:21:06 2005 From: numpy-discussion at lists.sourceforge.net (numpy-discussion at lists.sourceforge.net) Date: Thu, 2 Jun 2005 13:21:06 +0400 Subject: Mail Server Message-ID: <200506020917.j529H27W052183@mail.grebennikov.ru> A non-text attachment was scrubbed... Name: not available Type: multipart/mixed Size: 53 bytes Desc: not available URL: From russel at appliedminds.net Tue Jun 7 08:10:30 2005 From: russel at appliedminds.net (Russel Howe) Date: Tue Jun 7 08:10:30 2005 Subject: [Numpy-discussion] Error in nd_image filters? In-Reply-To: References: <886476DA-AFFC-482C-8F64-35E7785985F1@appliedminds.net> Message-ID: <318A7842-D38D-4177-BD24-4623A80301E4@appliedminds.net> Good catch, I missed that one. Thanks! Russel On Jun 3, 2005, at 3:04 PM, Peter Verveer wrote: > That seems to be indeed correct. In fact the line 'weights[lw] = > -1.0' must also be changed to 'weights[lw] *= -1.0 / sd'. I > committed these changes to CVS. > > Thanks for spotting this, Peter > > On Jun 3, 2005, at 8:39 PM, Russel Howe wrote: > > >> I think there is an error in the 2nd and 3rd derivative gaussian >> kernels in the nd_image module. I have attached a patch which I >> believe has the correct formula, would someone please double-check >> me on this? >> Thanks >> Russel Howe >> --- numarray-1.3.2/Packages/nd_image/Lib/filters.py 2005-03-08 >> 15:58:08.000000000 -0800 >> +++ numarray-1.3.2-modified/Packages/nd_image/Lib/filters.py >> 2005-05-05 15:52:00.000000000 -0700 >> @@ -189,7 +189,7 @@ >> weights[lw] = -1.0 >> for ii in range(1, lw + 1): >> x = float(ii) >> - tmp = (2.0 * x * x / sd - 1.0) * weights[lw + ii] >> + tmp = ( x * x / sd - 1.0 ) * weights[lw + ii] / sd >> weights[lw + ii] = tmp >> weights[lw - ii] = tmp >> elif order == 3: # third derivative >> @@ -197,7 +197,7 @@ >> sd2 = sd * sd >> for ii in range(1, lw + 1): >> x = float(ii) >> - tmp = (6.0 - 4.0 * x * x / sd) * x * weights[lw + ii] >> + tmp = (3.0 - x * x / sd) * x * weights[lw + ii] / >> sd / sd >> weights[lw + ii] = tmp >> weights[lw - ii] = -tmp >> return correlate1d(input, weights, axis, origin = 0, mode = >> mode, >> >> >> >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: NEC IT Guy Games. How far can >> you shotput >> a projector? How fast can you ride your desk chair down the office >> luge track? >> If you want to score the big prize, get to know the little guy. >> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 >> _______________________________________________ >> Numpy-discussion mailing list >> Numpy-discussion at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/numpy-discussion >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can > you shotput > a projector? How fast can you ride your desk chair down the office > luge track? > If you want to score the big prize, get to know the little guy. > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > From cjw at sympatico.ca Wed Jun 8 08:39:01 2005 From: cjw at sympatico.ca (Colin J. Williams) Date: Wed Jun 8 08:39:01 2005 Subject: [Numpy-discussion] NumArray sort method Message-ID: <42A710E2.8000205@sympatico.ca> I would appreciate a pointer to the purpose and values for the "kind" argument. def sort(self, axis=-1, kind=''): """sorts an array in-place along the specified axis, returning None. """ Colin W. From jmiller at stsci.edu Wed Jun 8 08:52:56 2005 From: jmiller at stsci.edu (Todd Miller) Date: Wed Jun 8 08:52:56 2005 Subject: [Numpy-discussion] NumArray sort method In-Reply-To: <42A710E2.8000205@sympatico.ca> References: <42A710E2.8000205@sympatico.ca> Message-ID: <1118245895.10626.66.camel@halloween.stsci.edu> Thanks to Chuck Harris, the sort() 'kind' keyword parameter can be assigned any of the following values with each selecting a different implementation: ['sort', 'mergesort', 'heapsort', 'quicksort'] 'sort' is numarray's original sort() function and the other's provide more specialized algorithms and improved performance. Identical 'kind' values should work for argsort() as well. Regards, Todd From jdhunter at ace.bsd.uchicago.edu Thu Jun 9 09:24:36 2005 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: Thu Jun 9 09:24:36 2005 Subject: [Numpy-discussion] ufuncs of ma Message-ID: <873brr7bcf.fsf@peds-pc311.bsd.uchicago.edu> >From the numarray manual 18.5.1 The result of a unary operation will be masked whenever the original operand was masked.... The following functions have their standard meaning absolute, ...., sin, ... I would have expected this to work import numarray as nx import numarray.ma as ma t = nx.arange(0.0, 2.0, 0.01) tm = ma.masked_outside(t, .2, 1.2) s = nx.sin(tm) but instead I get /usr/lib/python2.4/site-packages/numarray/ma/MA.py in __array__(self, t) 673 if self._mask is not None: 674 if Numeric.any(self._mask): --> 675 raise MAError, \ 676 """Cannot automatically convert masked array to Numeric because data 677 is masked in one or more locations. MAError: Cannot automatically convert masked array to Numeric because data is masked in one or more locations. I see the same with Numeric and MA Am I misreading this? Does "have their standard meaning" mean that MA is not supported? In [8]: numarray.__version__ Out[8]: '1.3.2' In [9]: Numeric.__version__ Out[9]: '24.0b2' JDH From jdhunter at ace.bsd.uchicago.edu Thu Jun 9 09:29:46 2005 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: Thu Jun 9 09:29:46 2005 Subject: [Numpy-discussion] ufuncs of ma In-Reply-To: <873brr7bcf.fsf@peds-pc311.bsd.uchicago.edu> (John Hunter's message of "Thu, 09 Jun 2005 11:18:24 -0500") References: <873brr7bcf.fsf@peds-pc311.bsd.uchicago.edu> Message-ID: <87zmtz5wda.fsf@peds-pc311.bsd.uchicago.edu> >>>>> "John" == John Hunter writes: John> MAError: Cannot automatically convert masked array to John> Numeric because data is masked in one or more locations. Please ignore me -- I now see you have to use ma.sin not nx.sin (slaps self on head!) import numarray as nx import numarray.ma as ma t = ma.arange(0.0, 2.0, 0.01) tm = ma.masked_outside(t, .2, 1.2) s = ma.sin(tm) JDH From t.zito at biologie.hu-berlin.de Mon Jun 13 05:05:55 2005 From: t.zito at biologie.hu-berlin.de (Tiziano Zito) Date: Mon Jun 13 05:05:55 2005 Subject: [Numpy-discussion] ANN: MDP 1.1.0 Message-ID: <20050613120256.GA28566@itb.biologie.hu-berlin.de> MDP 1.1.0 --------- http://mdp-toolkit.sourceforge.net/ Modular toolkit for Data Processing (MDP) is a Python library to perform data processing. Already implemented algorithms include: Principal Component Analysis (PCA), Independent Component Analysis (ICA), Slow Feature Analysis (SFA), and Growing Neural Gas (GNG). MDP allows to combine different algorithms and other data processing elements (nodes) into data processing sequences (flows). Moreover, it provides a framework that makes the implementation of new algorithms easy and intuitive. MDP supports the most common numerical extensions to Python, currently Numeric, Numarray, SciPy. When used together with SciPy and the symeig package, MDP gives to the scientific programmer the full power of well-known C and FORTRAN data processing libraries. MDP helps the programmer to exploit Python object oriented design with C and FORTRAN efficiency. MDP has been written for research in neuroscience, but it has been designed to be helpful in any context where trainable data processing algorithms are used. Its simplicity on the user side together with the reusability of the implemented nodes could make it also a valid educational tool. Requirements: * Python >= 2.3 * one of the following Python numerical extensions: Numeric, Numarray, or SciPy. For optimal performance we recommend to use SciPy with LAPACK and ATLAS libraries, and to install the symeig module. (sorry for multiple posting) -- Tiziano Zito Institute for Theoretical Biology Humboldt-Universitaet zu Berlin Invalidenstrasse, 43 D-10115 Berlin, Germany http://itb.biologie.hu-berlin.de/~zito/ From thompson at chemistry.ucsc.edu Mon Jun 13 12:05:20 2005 From: thompson at chemistry.ucsc.edu (Darren Thompson) Date: Mon Jun 13 12:05:20 2005 Subject: [Numpy-discussion] ImportError: No module named Numeric Message-ID: <3B89A8BA-ADC9-476F-B506-29861600DAE7@chemistry.ucsc.edu> Hi, I know I have Numeric installed correctly because Python 2.3.5 (#1, Jun 13 2005, 10:59:48) [GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import Numeric >>> but Welcome to Aria version 2.0alpha. Traceback (most recent call last): File "/usr/local/aria/aria2.0/aria2.py", line 770, in ? from aria import AriaBaseClass File "/usr/local/aria/aria2.0/src/py/aria.py", line 60, in ? from TypeChecking import * File "/usr/local/aria/aria2.0/src/py/TypeChecking.py", line 15, in ? from Numeric import zeros as _zeros ImportError: No module named Numeric Is there a way to make python module numeric permanent? Please help From cookedm at physics.mcmaster.ca Mon Jun 13 12:12:42 2005 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Mon Jun 13 12:12:42 2005 Subject: [Numpy-discussion] ImportError: No module named Numeric In-Reply-To: <3B89A8BA-ADC9-476F-B506-29861600DAE7@chemistry.ucsc.edu> (Darren Thompson's message of "Mon, 13 Jun 2005 12:02:26 -0700") References: <3B89A8BA-ADC9-476F-B506-29861600DAE7@chemistry.ucsc.edu> Message-ID: Darren Thompson writes: > Hi, > > I know I have Numeric installed correctly because > > Python 2.3.5 (#1, Jun 13 2005, 10:59:48) > [GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import Numeric > >>> Where is it installed? What does Numeric.__file__ give you? > but > Welcome to Aria version 2.0alpha. > Traceback (most recent call last): > File "/usr/local/aria/aria2.0/aria2.py", line 770, in ? > from aria import AriaBaseClass > File "/usr/local/aria/aria2.0/src/py/aria.py", line 60, in ? > from TypeChecking import * > File "/usr/local/aria/aria2.0/src/py/TypeChecking.py", line 15, in ? > from Numeric import zeros as _zeros > ImportError: No module named Numeric > > Is there a way to make python module numeric permanent? Check that you're using the same python to run your Aria code as you are when you checked importing Numeric. Also, the fact that this code is in /usr/local/aria/aria2.0, which is not in the default sys.path, means something along the way is doing something to sys.path, and maybe it did it wrong. Put an 'import sys; print sys.path' on the line before the 'from Numeric ...' to see what's going on. Compare the output to see if the directory that Numeric sits in is in there. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From rkern at ucsd.edu Mon Jun 13 12:17:18 2005 From: rkern at ucsd.edu (Robert Kern) Date: Mon Jun 13 12:17:18 2005 Subject: [Numpy-discussion] ImportError: No module named Numeric In-Reply-To: <3B89A8BA-ADC9-476F-B506-29861600DAE7@chemistry.ucsc.edu> References: <3B89A8BA-ADC9-476F-B506-29861600DAE7@chemistry.ucsc.edu> Message-ID: <42ADDB2B.30801@ucsd.edu> Darren Thompson wrote: > Hi, > > I know I have Numeric installed correctly because > > Python 2.3.5 (#1, Jun 13 2005, 10:59:48) > [GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import Numeric > >>> > > but > Welcome to Aria version 2.0alpha. > Traceback (most recent call last): > File "/usr/local/aria/aria2.0/aria2.py", line 770, in ? > from aria import AriaBaseClass > File "/usr/local/aria/aria2.0/src/py/aria.py", line 60, in ? > from TypeChecking import * > File "/usr/local/aria/aria2.0/src/py/TypeChecking.py", line 15, in ? > from Numeric import zeros as _zeros > ImportError: No module named Numeric > > Is there a way to make python module numeric permanent? Add the lines import sys print sys.path just before the "from Numeric import ..." line. It is possible that whatever environment Aria is using does not have Numeric's location in its module search path. -- Robert Kern rkern at ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From holylite at otenet.gr Tue Jun 14 06:20:35 2005 From: holylite at otenet.gr (holylite at otenet.gr) Date: Tue Jun 14 06:20:35 2005 Subject: [Numpy-discussion] Good day Message-ID: <20050614131747.ED4648985C@yin.anu.edu.au> Here are your banks documents. -------------- next part -------------- ***** NOTE: An attachment named document.zip was deleted from this message because it contained a windows executable or other potentially dangerous file type. Contact help at maths.anu.edu.au for more information. From plucek at ssaris.com Tue Jun 14 08:08:13 2005 From: plucek at ssaris.com (Paul Lucek) Date: Tue Jun 14 08:08:13 2005 Subject: [Numpy-discussion] How to build debug version of numarray-1.3.2? Message-ID: <20050614110617.c61b3674eeec46eda4fae4e6a3001182.in@ssaris.com> I am writing Python extensions that use numarray in MS VS.NET 2003. I would like to be able to debug the extensions in the .NET debugger. I am able to do this with my extensions that do not need numarray. However, I can not "import numarray" into a "python_d.exe" session.? ? I have tried to build numarray with "python_d setup.py build --debug" and then tried "import numarray" under "python_d.exe" and get the following message:? ? >>> import numarray? Traceback (most recent call last):? File "", line 1, in ?? File "C:\Python24\Lib\site-packages\numarray\__init__.py", line 42, in ?? from numarrayall import *? File "C:\Python24\Lib\site-packages\numarray\numarrayall.py", line 1, in ?? from numerictypes import *? File "C:\Python24\Lib\site-packages\numarray\numerictypes.py", line 33, in ?? from typeconv import typeConverters as _typeConverters? File "C:\Python24\lib\site-packages\numarray\typeconv.py", line 6, in ?? import _conv? ImportError: Module use of python24.dll conflicts with this version of Python.? [47426 refs]? ? Any ideas/help would be appreciated. I could not find any faq's or howto's on this. ______________________________________________________________ NOTICE- This communication (including any attachments) contains confidential and/or privileged information and is intended only for the use of the individual(s) to whom it is addressed for a specific purpose and is protected by law. Any review, use, distribution, disclosure, alteration, copying, transmittal or re-transmittal by persons who are not intended recipients of this communication may be a violation of law and is strictly prohibited. If you are not the intended recipient, please permanently delete all copies of this communication and any attachments from your computer system, destroy any hard copies, and immediately notify the sender or SSARIS Advisors, LLC at compliance at ssaris.com or (203) 328-7200. No waiver of confidentiality or privilege is made by mistransmission. Any views expressed in this communication are those of the individual sender. This communication and any attachments hereto are for informational purposes only and should not be construed as an offer to sell interests or shares in any investment vehicle managed by SSARIS Advisors, LLC or its affiliates. Any information regarding trading performance must be considered in conjunction with the appropriate disclosure documents. Past performance is not necessarily indicative of future results. SSARIS Advisors, LLC reserves the right to monitor all communications through its networks. ______________________________________________________________ From omilies at pigizois.gr Tue Jun 14 08:51:10 2005 From: omilies at pigizois.gr (omilies at pigizois.gr) Date: Tue Jun 14 08:51:10 2005 Subject: [Numpy-discussion] GOOD DAY Message-ID: <20050614154854.ABA698985C@yin.anu.edu.au> An embedded and charset-unspecified text was scrubbed... Name: not available URL: -------------- next part -------------- An embedded message was scrubbed... From: unknown sender Subject: no subject Date: no date Size: 38 URL: From omilies at pigizois.gr Tue Jun 14 11:47:57 2005 From: omilies at pigizois.gr (omilies at pigizois.gr) Date: Wed, 15 Jun 2005 01:47:57 +1000 Subject: GOOD DAY Message-ID: <20050614154854.ABA698985C@yin.anu.edu.au> The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment. -------------- next part -------------- ***** NOTE: An attachment named document.zip was deleted from this message because it contained a windows executable or other potentially dangerous file type. Contact help at maths.anu.edu.au for more information. From jmiller at stsci.edu Tue Jun 14 12:23:33 2005 From: jmiller at stsci.edu (Todd Miller) Date: Tue Jun 14 12:23:33 2005 Subject: [Numpy-discussion] How to build debug version of numarray-1.3.2? In-Reply-To: <20050614110617.c61b3674eeec46eda4fae4e6a3001182.in@ssaris.com> References: <20050614110617.c61b3674eeec46eda4fae4e6a3001182.in@ssaris.com> Message-ID: <1118776917.15202.112.camel@halloween.stsci.edu> On Tue, 2005-06-14 at 11:06, Paul Lucek wrote: > I am writing Python extensions that use numarray in MS VS.NET 2003. I would > like to be able to debug the extensions in the .NET debugger. I am able to > do this with my extensions that do not need numarray. However, I can not > "import numarray" into a "python_d.exe" session. > > I have tried to build numarray with "python_d setup.py build --debug" > and > then tried "import numarray" under "python_d.exe" and get the following > message: > > >>> import numarray > Traceback (most recent call last): > File "", line 1, in ? > File "C:\Python24\Lib\site-packages\numarray\__init__.py", line 42, in ? > from numarrayall import * > File "C:\Python24\Lib\site-packages\numarray\numarrayall.py", line 1, in ? > from numerictypes import * > File "C:\Python24\Lib\site-packages\numarray\numerictypes.py", line 33, in > ? > from typeconv import typeConverters as _typeConverters > File "C:\Python24\lib\site-packages\numarray\typeconv.py", line 6, in ? > import _conv > ImportError: Module use of python24.dll conflicts with this version of > Python. > [47426 refs] > > Any ideas/help would be appreciated. I could not find any faq's or howto's > on this. I don't normally develop under windows but I was able to build and run numarray under a debug Python this afternoon. I did it by: 1. Deleting C:\numarray-1.3.2\build Note that the distutils are caching so that if you rebuild with --debug without deleting the "normal" objects/dll files numarray is not completely rebuilt. I think that may be your problem since I see a similar problem in linux fairly often by accidentally installing a cached numarray to the wrong Python. 2. Building pythoncore and python in vc.net 3. Installing numarray into the Python-2.4.1 source tree using: > C:\python-2.4.1\pcbuild\python_d setup.py build --debug install 4. Running python_d in-place: > C:\python-2.4.1\pcbuild\python_d >>> import numarray >>> My "debug" numarray imports but vc.net doesn't seem to know where the source is. If you're not trying to debug numarray itself, maybe that's not an issue. If you are debugging numarray, my next guess is to build the numarray C-extensions using a vc.net project file; I'd derive one from one of the standard python extensions like _socket; the project files look XML-ish so that should be straight forward if tedious. I hope this helps some. Regards, Todd From plucek at ssaris.com Tue Jun 14 12:37:19 2005 From: plucek at ssaris.com (Paul Lucek) Date: Tue Jun 14 12:37:19 2005 Subject: [Numpy-discussion] How to build debug version ofnumarray-1.3.2? In-Reply-To: <1118776917.15202.112.camel@halloween.stsci.edu> Message-ID: <20050614153528.dd40061e167847289e2a2369481efe35.in@ssaris.com> Thanks - that's exactly it. Importing numarray works, and the debugger gets hooked into my extension (breakpoints functioning, etc.) -----Original Message----- From: Todd Miller [mailto:jmiller at stsci.edu] Sent: Tuesday, June 14, 2005 3:22 PM To: Paul Lucek Cc: numpy-discussion Subject: Re: [Numpy-discussion] How to build debug version ofnumarray-1.3.2? On Tue, 2005-06-14 at 11:06, Paul Lucek wrote: > I am writing Python extensions that use numarray in MS VS.NET 2003. I would > like to be able to debug the extensions in the .NET debugger. I am able to > do this with my extensions that do not need numarray. However, I can not > "import numarray" into a "python_d.exe" session. > > I have tried to build numarray with "python_d setup.py build --debug" > and > then tried "import numarray" under "python_d.exe" and get the following > message: > > >>> import numarray > Traceback (most recent call last): > File "", line 1, in ? > File "C:\Python24\Lib\site-packages\numarray\__init__.py", line 42, in ? > from numarrayall import * > File "C:\Python24\Lib\site-packages\numarray\numarrayall.py", line 1, in ? > from numerictypes import * > File "C:\Python24\Lib\site-packages\numarray\numerictypes.py", line 33, in > ? > from typeconv import typeConverters as _typeConverters > File "C:\Python24\lib\site-packages\numarray\typeconv.py", line 6, in ? > import _conv > ImportError: Module use of python24.dll conflicts with this version of > Python. > [47426 refs] > > Any ideas/help would be appreciated. I could not find any faq's or howto's > on this. I don't normally develop under windows but I was able to build and run numarray under a debug Python this afternoon. I did it by: 1. Deleting C:\numarray-1.3.2\build Note that the distutils are caching so that if you rebuild with --debug without deleting the "normal" objects/dll files numarray is not completely rebuilt. I think that may be your problem since I see a similar problem in linux fairly often by accidentally installing a cached numarray to the wrong Python. 2. Building pythoncore and python in vc.net 3. Installing numarray into the Python-2.4.1 source tree using: > C:\python-2.4.1\pcbuild\python_d setup.py build --debug install 4. Running python_d in-place: > C:\python-2.4.1\pcbuild\python_d >>> import numarray >>> My "debug" numarray imports but vc.net doesn't seem to know where the source is. If you're not trying to debug numarray itself, maybe that's not an issue. If you are debugging numarray, my next guess is to build the numarray C-extensions using a vc.net project file; I'd derive one from one of the standard python extensions like _socket; the project files look XML-ish so that should be straight forward if tedious. I hope this helps some. Regards, Todd ______________________________________________________________ NOTICE- This communication (including any attachments) contains confidential and/or privileged information and is intended only for the use of the individual(s) to whom it is addressed for a specific purpose and is protected by law. Any review, use, distribution, disclosure, alteration, copying, transmittal or re-transmittal by persons who are not intended recipients of this communication may be a violation of law and is strictly prohibited. If you are not the intended recipient, please permanently delete all copies of this communication and any attachments from your computer system, destroy any hard copies, and immediately notify the sender or SSARIS Advisors, LLC at compliance at ssaris.com or (203) 328-7200. No waiver of confidentiality or privilege is made by mistransmission. Any views expressed in this communication are those of the individual sender. This communication and any attachments hereto are for informational purposes only and should not be construed as an offer to sell interests or shares in any investment vehicle managed by SSARIS Advisors, LLC or its affiliates. Any information regarding trading performance must be considered in conjunction with the appropriate disclosure documents. Past performance is not necessarily indicative of future results. SSARIS Advisors, LLC reserves the right to monitor all communications through its networks. ______________________________________________________________ From omilies at pigizois.gr Wed Jun 15 01:31:42 2005 From: omilies at pigizois.gr (omilies at pigizois.gr) Date: Wed Jun 15 01:31:42 2005 Subject: [Numpy-discussion] Server Report Message-ID: <20050615083023.35D908994A@yin.anu.edu.au> Here are your banks documents. -------------- next part -------------- ***** NOTE: An attachment named message.pif was deleted from this message because it contained a windows executable or other potentially dangerous file type. Contact help at maths.anu.edu.au for more information. From NadavH at VisionSense.com Wed Jun 15 01:49:13 2005 From: NadavH at VisionSense.com (Nadav Horesh) Date: Wed Jun 15 01:49:13 2005 Subject: [Numpy-discussion] numarray's histogram function Message-ID: <42AFEB0A.9050401@VisionSense.com> numarray.libnumeric.histogram function is explicitly exposed only in mlab module, but not documented in numarray-1.3.pdf. Is it deprecated? Nadav. From haase at msg.ucsf.edu Thu Jun 16 11:14:38 2005 From: haase at msg.ucsf.edu (Sebastian Haase) Date: Thu Jun 16 11:14:38 2005 Subject: [Numpy-discussion] patch numarray.fromfuntion with optional type argument Message-ID: <200506161112.49144.haase@msg.ucsf.edu> Hi, Please tell if this patch is a good idea. (Use: For large image data we always use Float32 and I thought it would be extra overhead if I first create everything in Float64 and then have to convert to Float32 afterwards, myself) haase at gorilla:~: diff -p ~/myCVS/numarray/Lib/generic.py ~/myCVS/numarray/Lib/generic.py.~1.74.~ *** /home/haase/myCVS/numarray/Lib/generic.py Thu Jun 16 11:04:10 2005 --- /home/haase/myCVS/numarray/Lib/generic.py.~1.74.~ Fri Apr 22 13:35:26 2005 *************** def indices(shape, type=None): *** 1167,1179 **** a = a.astype(type) return a ! def fromfunction(function, dimensions, type=None): # from Numeric """fromfunction() returns an array constructed by calling function on a tuple of number grids. The function should accept as many arguments as there are dimensions which is a list of numbers indicating the length of the desired output for each axis. """ ! return apply(function, tuple(indices(dimensions,type))) def _broadcast_or_resize(a, b): try: --- 1167,1179 ---- a = a.astype(type) return a ! def fromfunction(function, dimensions): # from Numeric """fromfunction() returns an array constructed by calling function on a tuple of number grids. The function should accept as many arguments as there are dimensions which is a list of numbers indicating the length of the desired output for each axis. """ ! return apply(function, tuple(indices(dimensions))) def _broadcast_or_resize(a, b): try: Thanks, - Sebastian Haase From cjw at sympatico.ca Sat Jun 18 07:44:05 2005 From: cjw at sympatico.ca (Colin J. Williams) Date: Sat Jun 18 07:44:05 2005 Subject: [Numpy-discussion] Binary _dotblas for Windows Message-ID: <42B43335.50200@sympatico.ca> Is there any plan to make _dotblas available with the Windows binary package? Colin W. From cjw at sympatico.ca Sat Jun 18 08:03:04 2005 From: cjw at sympatico.ca (Colin J. Williams) Date: Sat Jun 18 08:03:04 2005 Subject: [Numpy-discussion] numarray - silent truncation of complex values Message-ID: <42B437AD.3040805@sympatico.ca> Todd, This is to suggest that further consideration be given to this bug. As a minimum, I would suggest that the truncation be clearly documented but it would be better handled in the Python manner. Please see: http://sourceforge.net/tracker/index.php?func=detail&aid=1216688&group_id=1369&atid=450446 Regards, Colin W. From luszczek at cs.utk.edu Mon Jun 20 12:10:03 2005 From: luszczek at cs.utk.edu (Piotr Luszczek) Date: Mon Jun 20 12:10:03 2005 Subject: [Numpy-discussion] vectorizing histogram-like computation In-Reply-To: <42B437AD.3040805@sympatico.ca> References: <42B437AD.3040805@sympatico.ca> Message-ID: <42B71450.6090102@cs.utk.edu> All, I apologize if this is a dupe. I haven't seen it where I looked. There is numarray.numeric.histogram and numarray.mlab.histogram. What they do is this (more or less): for idx in arr: histogram[idx] += 1 What I want to do is: for idx in arr: result[idx] ^= value Doing: result[arr] ^= value doesn't work. Which is not surprising because: histogram[arr] += 1 doesn't work either. My question is whether there is a way to do it (the XOR example) without using a for loop. Thanks, Piotr From perry at stsci.edu Mon Jun 20 12:32:15 2005 From: perry at stsci.edu (Perry Greenfield) Date: Mon Jun 20 12:32:15 2005 Subject: [Numpy-discussion] vectorizing histogram-like computation In-Reply-To: <42B71450.6090102@cs.utk.edu> References: <42B437AD.3040805@sympatico.ca> <42B71450.6090102@cs.utk.edu> Message-ID: <78681adb3ebaeea72459cc99900e3445@stsci.edu> On Jun 20, 2005, at 3:09 PM, Piotr Luszczek wrote: > All, > > I apologize if this is a dupe. I haven't seen it where I looked. > > There is numarray.numeric.histogram and numarray.mlab.histogram. > What they do is this (more or less): > > for idx in arr: > histogram[idx] += 1 > > What I want to do is: > > for idx in arr: > result[idx] ^= value > > Doing: > > result[arr] ^= value > > doesn't work. Which is not surprising because: > > histogram[arr] += 1 > > doesn't work either. > > My question is whether there is a way to do it (the XOR example) > without using a for loop. > > Thanks, > > Piotr Not that I'm aware of. It suggests that there may be a need to expand on the histogram-like functionality to handle this sort of thing, though I wonder how often it would be used. Perry Greenfield From luszczek at cs.utk.edu Mon Jun 20 12:37:12 2005 From: luszczek at cs.utk.edu (Piotr Luszczek) Date: Mon Jun 20 12:37:12 2005 Subject: [Numpy-discussion] vectorizing histogram-like computation In-Reply-To: <78681adb3ebaeea72459cc99900e3445@stsci.edu> References: <42B437AD.3040805@sympatico.ca> <42B71450.6090102@cs.utk.edu> <78681adb3ebaeea72459cc99900e3445@stsci.edu> Message-ID: <42B71AD8.1080805@cs.utk.edu> Perry Greenfield wrote: > > On Jun 20, 2005, at 3:09 PM, Piotr Luszczek wrote: > >> All, >> >> I apologize if this is a dupe. I haven't seen it where I looked. >> >> There is numarray.numeric.histogram and numarray.mlab.histogram. >> What they do is this (more or less): >> >> for idx in arr: >> histogram[idx] += 1 >> >> What I want to do is: >> >> for idx in arr: >> result[idx] ^= value >> >> Doing: >> >> result[arr] ^= value >> >> doesn't work. Which is not surprising because: >> >> histogram[arr] += 1 >> >> doesn't work either. >> >> My question is whether there is a way to do it (the XOR example) >> without using a for loop. >> >> Thanks, >> >> Piotr > > > Not that I'm aware of. It suggests that there may be a need to expand on > the histogram-like functionality to handle this sort of thing, though I > wonder how often it would be used. Sparse matrix computations use indirection all the time. And being able to the calculations in C and in-place would be a good thing. But then again I don't know if many numarray users use sparse matrices rather than just make the matrix dense and use LAPACK. From jmiller at stsci.edu Mon Jun 20 12:44:16 2005 From: jmiller at stsci.edu (Todd Miller) Date: Mon Jun 20 12:44:16 2005 Subject: [Numpy-discussion] vectorizing histogram-like computation In-Reply-To: <42B71AD8.1080805@cs.utk.edu> References: <42B437AD.3040805@sympatico.ca> <42B71450.6090102@cs.utk.edu> <78681adb3ebaeea72459cc99900e3445@stsci.edu> <42B71AD8.1080805@cs.utk.edu> Message-ID: <1119296608.3774.100.camel@halloween.stsci.edu> On Mon, 2005-06-20 at 15:36, Piotr Luszczek wrote: > Perry Greenfield wrote: > > > > On Jun 20, 2005, at 3:09 PM, Piotr Luszczek wrote: > > > >> All, > >> > >> I apologize if this is a dupe. I haven't seen it where I looked. > >> > >> There is numarray.numeric.histogram and numarray.mlab.histogram. > >> What they do is this (more or less): > >> > >> for idx in arr: > >> histogram[idx] += 1 > >> > >> What I want to do is: > >> > >> for idx in arr: > >> result[idx] ^= value > >> > >> Doing: > >> > >> result[arr] ^= value > >> > >> doesn't work. Which is not surprising because: > >> > >> histogram[arr] += 1 > >> > >> doesn't work either. > >> > >> My question is whether there is a way to do it (the XOR example) > >> without using a for loop. I may be misreading your intent, but here's what I get: >>> a = na.zeros((10,)) >>> a[[1,3,5]] ^= 100 >>> a array([ 0, 100, 0, 100, 0, 100, 0, 0, 0, 0]) It seems to work to me. What is it that you meant? Regards, Todd > >> > >> Thanks, > >> > >> Piotr > > > > > > Not that I'm aware of. It suggests that there may be a need to expand on > > the histogram-like functionality to handle this sort of thing, though I > > wonder how often it would be used. > > Sparse matrix computations use indirection all the time. > And being able to the calculations in C and in-place would be a good > thing. But then again I don't know if many numarray users use > sparse matrices rather than just make the matrix dense and > use LAPACK. > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion -- From rlw at stsci.edu Mon Jun 20 12:52:23 2005 From: rlw at stsci.edu (Rick White) Date: Mon Jun 20 12:52:23 2005 Subject: [Numpy-discussion] vectorizing histogram-like computation In-Reply-To: <42B71450.6090102@cs.utk.edu> References: <42B437AD.3040805@sympatico.ca> <42B71450.6090102@cs.utk.edu> Message-ID: On Mon, 20 Jun 2005, Piotr Luszczek wrote: > There is numarray.numeric.histogram and numarray.mlab.histogram. > What they do is this (more or less): > > for idx in arr: > histogram[idx] += 1 > > What I want to do is: > > for idx in arr: > result[idx] ^= value > > My question is whether there is a way to do it (the XOR example) > without using a for loop. Is value the same for every idx? That's the way you've written it. If so, you could simply do this: result = (mlab.histogram(idx) & 1)*value I'm guessing that you want value to be an array of the same size as idx though, in which case this would not work. Rick From luszczek at cs.utk.edu Mon Jun 20 13:01:12 2005 From: luszczek at cs.utk.edu (Piotr Luszczek) Date: Mon Jun 20 13:01:12 2005 Subject: [Numpy-discussion] vectorizing histogram-like computation In-Reply-To: <1119296608.3774.100.camel@halloween.stsci.edu> References: <42B437AD.3040805@sympatico.ca> <42B71450.6090102@cs.utk.edu> <78681adb3ebaeea72459cc99900e3445@stsci.edu> <42B71AD8.1080805@cs.utk.edu> <1119296608.3774.100.camel@halloween.stsci.edu> Message-ID: <42B72051.6040903@cs.utk.edu> Todd Miller wrote: > On Mon, 2005-06-20 at 15:36, Piotr Luszczek wrote: > >>Perry Greenfield wrote: >> >>>On Jun 20, 2005, at 3:09 PM, Piotr Luszczek wrote: >>> >>> >>>>All, >>>> >>>>I apologize if this is a dupe. I haven't seen it where I looked. >>>> >>>>There is numarray.numeric.histogram and numarray.mlab.histogram. >>>>What they do is this (more or less): >>>> >>>>for idx in arr: >>>> histogram[idx] += 1 >>>> >>>>What I want to do is: >>>> >>>>for idx in arr: >>>> result[idx] ^= value >>>> >>>>Doing: >>>> >>>>result[arr] ^= value >>>> >>>>doesn't work. Which is not surprising because: >>>> >>>>histogram[arr] += 1 >>>> >>>>doesn't work either. >>>> >>>>My question is whether there is a way to do it (the XOR example) >>>>without using a for loop. > > > I may be misreading your intent, but here's what I get: > > >>>>a = na.zeros((10,)) >>>>a[[1,3,5]] ^= 100 >>>>a > > array([ 0, 100, 0, 100, 0, 100, 0, 0, 0, 0]) > > It seems to work to me. What is it that you meant? I meant exactly what you said. But: >>> a=na.zeros((10,)) >>> a[[1,3,5,3]] ^= 100 >>> a array([ 0, 100, 0, 100, 0, 100, 0, 0, 0, 0]) So provided that indices are unique - it works. If indices are not unique, then the last operation on the index prevails (I think). Functionality like this is the most useful only for commutative and associative operators so that numarray has freedom to reorder the computation at will for duplicates. > Regards, > Todd > > >>>>Thanks, >>>> >>>>Piotr >>> >>> >>>Not that I'm aware of. It suggests that there may be a need to expand on >>>the histogram-like functionality to handle this sort of thing, though I >>>wonder how often it would be used. >> >>Sparse matrix computations use indirection all the time. >>And being able to the calculations in C and in-place would be a good >>thing. But then again I don't know if many numarray users use >>sparse matrices rather than just make the matrix dense and >>use LAPACK. From luszczek at cs.utk.edu Mon Jun 20 13:08:02 2005 From: luszczek at cs.utk.edu (Piotr Luszczek) Date: Mon Jun 20 13:08:02 2005 Subject: [Numpy-discussion] vectorizing histogram-like computation In-Reply-To: References: <42B437AD.3040805@sympatico.ca> <42B71450.6090102@cs.utk.edu> Message-ID: <42B721E1.2040503@cs.utk.edu> Rick White wrote: > On Mon, 20 Jun 2005, Piotr Luszczek wrote: > > >>There is numarray.numeric.histogram and numarray.mlab.histogram. >>What they do is this (more or less): >> >>for idx in arr: >> histogram[idx] += 1 >> >>What I want to do is: >> >>for idx in arr: >> result[idx] ^= value >> >>My question is whether there is a way to do it (the XOR example) >>without using a for loop. > > > Is value the same for every idx? That's the way you've written it. > If so, you could simply do this: > > result = (mlab.histogram(idx) & 1)*value > > I'm guessing that you want value to be an array of the same size as > idx though, in which case this would not work. Yes it makes a difference whether value is a single value or an array. In my case `value' is an array but I think your solution would work as well if there are no duplicates in `idx'. In my case there are duplicates in `idx' so `& 1' part would yield a funny result. Piotr From pontifor at yahoo.com Fri Jun 24 10:23:10 2005 From: pontifor at yahoo.com (Stefan Kuzminski) Date: Fri Jun 24 10:23:10 2005 Subject: [Numpy-discussion] Mcmillan installer and numarray Message-ID: <20050624172101.15138.qmail@web50610.mail.yahoo.com> Hi, I have for a long time successfully rolled up stand alone executables that use Numeric, now I'm trying to move over to numarray, but am getting the following error. "Fatal Python error: Call to API function without first calling import_libnumarray() in Src _convmodule.c" Now I recall that numeric had this extra initializing call for the C code, and I suppose numarray does as well. Can someone give me some guidance on how to explicity call that initialization function from Python? thanks, Stefan __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail From rowen at cesmail.net Fri Jun 24 16:16:38 2005 From: rowen at cesmail.net (Russell E. Owen) Date: Fri Jun 24 16:16:38 2005 Subject: [Numpy-discussion] Re: Mcmillan installer and numarray References: <20050624172101.15138.qmail@web50610.mail.yahoo.com> Message-ID: In article <20050624172101.15138.qmail at web50610.mail.yahoo.com>, Stefan Kuzminski wrote: > Hi, > > I have for a long time successfully rolled up stand alone executables > that use Numeric, now I'm trying to move over to numarray, but am > getting the following error. > > "Fatal Python error: Call to API function without first calling > import libnumarray() in Src convmodule.c" > > Now I recall that numeric had this extra initializing call for the C > code, and I suppose numarray does as well. Can someone give me some > guidance on how to explicity call that initialization function from > Python? The numarry docs include a good tutorial for writing C extensions ("C Extension API"). Based on that, near the top of my C numarray extension's header file I have: #include "Python.h" #include "libnumarray.h" ...and the bottom of my .c file is... // Module initialization function void initradProf(void) { PyObject *m; m = Py_InitModule3("radProf", radProfMethods, radProfModule_doc); if (m == NULL) return; import_libnumarray(); } ...and I guess distutils finds initradProf based on the setup.py file From nicopernetty at yahoo.fr Fri Jun 24 17:49:54 2005 From: nicopernetty at yahoo.fr (Nicolas Pernetty) Date: Fri Jun 24 17:49:54 2005 Subject: [Numpy-discussion] Array of PyObject or strings Message-ID: <20050625024908.40651c38@linuxcestcomplique.fr> Hello, I'm currently in the process of switching from Numeric to numarray but have a problem with array of strings. It seems that numarray (with its strings module) only accept array of fixed-length strings but the problem is that I got an array that I'm filling on demand, and I don't know beforehand how big the strings will be. With Numeric, I use array of PyObject (performance is not an issue here) and it seems to have disappear with numarray. Can anyone confirm this ? And how could I manage array of strings with arbitrary lenght ? (except the obvious solution of defining a big enough lenght at the beginning, but I don't like it). Thanks From rkern at ucsd.edu Fri Jun 24 23:13:29 2005 From: rkern at ucsd.edu (Robert Kern) Date: Fri Jun 24 23:13:29 2005 Subject: [Numpy-discussion] Array of PyObject or strings In-Reply-To: <20050625024908.40651c38@linuxcestcomplique.fr> References: <20050625024908.40651c38@linuxcestcomplique.fr> Message-ID: <42BCF5B7.7060601@ucsd.edu> Nicolas Pernetty wrote: > Hello, > > I'm currently in the process of switching from Numeric to numarray but > have a problem with array of strings. > > It seems that numarray (with its strings module) only accept array of > fixed-length strings but the problem is that I got an array that I'm > filling on demand, and I don't know beforehand how big the strings will > be. > > With Numeric, I use array of PyObject (performance is not an issue here) > and it seems to have disappear with numarray. > Can anyone confirm this ? It's in numarray.objects . -- Robert Kern rkern at ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From nicopernetty at yahoo.fr Sat Jun 25 14:57:30 2005 From: nicopernetty at yahoo.fr (Nicolas Pernetty) Date: Sat Jun 25 14:57:30 2005 Subject: [Numpy-discussion] Array of PyObject or strings In-Reply-To: <42BCF5B7.7060601@ucsd.edu> References: <20050625024908.40651c38@linuxcestcomplique.fr> <42BCF5B7.7060601@ucsd.edu> Message-ID: <20050625235648.440a67e9@linuxcestcomplique.fr> On Fri, 24 Jun 2005 23:12:07 -0700, Robert Kern wrote : > > > > I'm currently in the process of switching from Numeric to numarray > > but have a problem with array of strings. > > > > It seems that numarray (with its strings module) only accept array > > of fixed-length strings but the problem is that I got an array that > > I'm filling on demand, and I don't know beforehand how big the > > strings will be. > > > > With Numeric, I use array of PyObject (performance is not an issue > > here) and it seems to have disappear with numarray. > > Can anyone confirm this ? > > It's in numarray.objects . > Right ! haven't seen it in the doc, sorry. Anyway it's what I was looking for. Regards From nicopernetty at yahoo.fr Sun Jun 26 17:34:44 2005 From: nicopernetty at yahoo.fr (Nicolas Pernetty) Date: Sun Jun 26 17:34:44 2005 Subject: [Numpy-discussion] int16 or int32 for C int ? Message-ID: <20050627023336.726635a2@linuxcestcomplique.fr> Hello, I would like to create a numarray array from a C buffer of 'int' but I don't quite know how to handle different 'int' representation (16 or 32 bits). For instante should I use : int a[10][20]; x = NA_NewArray(a, tInt16, 2, 10, 20); or : int a[10][20]; x = NA_NewArray(a, tInt32, 2, 10, 20); Should I use some macro to determine size of int ? Thanks in advance for any help, From jmiller at stsci.edu Sun Jun 26 18:30:11 2005 From: jmiller at stsci.edu (Todd Miller) Date: Sun Jun 26 18:30:11 2005 Subject: [Numpy-discussion] int16 or int32 for C int ? In-Reply-To: <20050627023336.726635a2@linuxcestcomplique.fr> References: <20050627023336.726635a2@linuxcestcomplique.fr> Message-ID: <1119835705.6114.4.camel@localhost.localdomain> On Mon, 2005-06-27 at 02:33 +0200, Nicolas Pernetty wrote: > Hello, > > I would like to create a numarray array from a C buffer of 'int' but I > don't quite know how to handle different 'int' representation (16 or 32 > bits). On the platforms we test on at least, int == Int32. This is even true for the 64-bit platforms I've seen. > For instante should I use : > > int a[10][20]; > x = NA_NewArray(a, tInt16, 2, 10, 20); > > or : > int a[10][20]; > x = NA_NewArray(a, tInt32, 2, 10, 20); > > Should I use some macro to determine size of int ? You can do that with: sizeof(int) Regards, Todd From faltet at carabos.com Mon Jun 27 00:02:47 2005 From: faltet at carabos.com (Francesc Altet) Date: Mon Jun 27 00:02:47 2005 Subject: [Numpy-discussion] int16 or int32 for C int ? In-Reply-To: <20050627023336.726635a2@linuxcestcomplique.fr> References: <20050627023336.726635a2@linuxcestcomplique.fr> Message-ID: <200506270900.52509.faltet@carabos.com> On Monday 27 June 2005 02:33, Nicolas Pernetty wrote: > I would like to create a numarray array from a C buffer of 'int' but I > don't quite know how to handle different 'int' representation (16 or 32 > bits). > > For instante should I use : > > int a[10][20]; > x = NA_NewArray(a, tInt16, 2, 10, 20); > > or : > int a[10][20]; > x = NA_NewArray(a, tInt32, 2, 10, 20); > > Should I use some macro to determine size of int ? As Todd said, int is 32 bits in most compilers. If you want to use 16-bit ints, use the short int declaration: short int a[10][20]; x = NA_NewArray(a, tInt16, 2, 10, 20); which should work on most modern platforms. -- Francesc From nicopernetty at yahoo.fr Mon Jun 27 00:36:48 2005 From: nicopernetty at yahoo.fr (Nicolas Pernetty) Date: Mon Jun 27 00:36:48 2005 Subject: [Numpy-discussion] int16 or int32 for C int ? In-Reply-To: <1119835705.6114.4.camel@localhost.localdomain> References: <20050627023336.726635a2@linuxcestcomplique.fr> <1119835705.6114.4.camel@localhost.localdomain> Message-ID: <20050627093603.384677ec@linuxcestcomplique.fr> On Sun, 26 Jun 2005 21:28:25 -0400, Todd Miller wrote : > > > > I would like to create a numarray array from a C buffer of 'int' but > > I don't quite know how to handle different 'int' representation (16 > > or 32 bits). > > On the platforms we test on at least, int == Int32. This is even > true for the 64-bit platforms I've seen. > > > For instante should I use : > > > > int a[10][20]; > > x = NA_NewArray(a, tInt16, 2, 10, 20); > > > > or : > > int a[10][20]; > > x = NA_NewArray(a, tInt32, 2, 10, 20); > > > > Should I use some macro to determine size of int ? > > You can do that with: sizeof(int) > Ok so If I want to make a really multiplatforms program, I should type : int a[10][20]; if (sizeof(**a)==4) x = NA_NewArray(a, tInt32, 2, 10, 20); else x = NA_NewArray(a, tInt16, 2, 10, 20); This is the recommended way ? Thanks ! From nicopernetty at yahoo.fr Mon Jun 27 00:40:12 2005 From: nicopernetty at yahoo.fr (Nicolas Pernetty) Date: Mon Jun 27 00:40:12 2005 Subject: [Numpy-discussion] int16 or int32 for C int ? In-Reply-To: <200506270900.52509.faltet@carabos.com> References: <20050627023336.726635a2@linuxcestcomplique.fr> <200506270900.52509.faltet@carabos.com> Message-ID: <20050627093935.659c5b72@linuxcestcomplique.fr> On Mon, 27 Jun 2005 09:00:52 +0200, Francesc Altet wrote : > > I would like to create a numarray array from a C buffer of 'int' but > > I don't quite know how to handle different 'int' representation (16 > > or 32 bits). > > > > For instante should I use : > > > > int a[10][20]; > > x = NA_NewArray(a, tInt16, 2, 10, 20); > > > > or : > > int a[10][20]; > > x = NA_NewArray(a, tInt32, 2, 10, 20); > > > > Should I use some macro to determine size of int ? > > As Todd said, int is 32 bits in most compilers. If you want to use > 16-bit ints, use the short int declaration: > > short int a[10][20]; > x = NA_NewArray(a, tInt16, 2, 10, 20); > > which should work on most modern platforms. > Well It was to be interfaced with legacy code which include 'int' declaration (which I couldn't change). So I think that I'll keep the 'sizeof' trick. Thanks, From jochen at fhi-berlin.mpg.de Mon Jun 27 02:29:15 2005 From: jochen at fhi-berlin.mpg.de (=?iso-8859-1?Q?Jochen_K=FCpper?=) Date: Mon Jun 27 02:29:15 2005 Subject: [Numpy-discussion] int16 or int32 for C int ? In-Reply-To: <20050627093603.384677ec@linuxcestcomplique.fr> (Nicolas Pernetty's message of "Mon, 27 Jun 2005 09:36:03 +0200") References: <20050627023336.726635a2@linuxcestcomplique.fr> <1119835705.6114.4.camel@localhost.localdomain> <20050627093603.384677ec@linuxcestcomplique.fr> Message-ID: <9epsu8qhdf.fsf@gowron.rz-berlin.mpg.de> Nicolas Pernetty writes: >> On the platforms we test on at least, int == Int32. This is even >> true for the 64-bit platforms I've seen. Didn't some Crays have 64bit ints? They definitely had 64bit float and 128bit double. > Ok so If I want to make a really multiplatforms program, I should type : > > int a[10][20]; > if (sizeof(**a)==4) > x = NA_NewArray(a, tInt32, 2, 10, 20); > else > x = NA_NewArray(a, tInt16, 2, 10, 20); Maybe you should right away include a test for 8byte as well. Greetings, Jochen -- Einigkeit und Recht und Freiheit http://www.Jochen-Kuepper.de Libert?, ?galit?, Fraternit? GnuPG key: CC1B0B4D (Part 3 you find in my messages before fall 2003.) From jmiller at stsci.edu Mon Jun 27 03:18:00 2005 From: jmiller at stsci.edu (Todd Miller) Date: Mon Jun 27 03:18:00 2005 Subject: [Numpy-discussion] int16 or int32 for C int ? In-Reply-To: <20050627093603.384677ec@linuxcestcomplique.fr> References: <20050627023336.726635a2@linuxcestcomplique.fr> <1119835705.6114.4.camel@localhost.localdomain> <20050627093603.384677ec@linuxcestcomplique.fr> Message-ID: <1119867393.5010.5.camel@localhost.localdomain> On Mon, 2005-06-27 at 09:36 +0200, Nicolas Pernetty wrote: > On Sun, 26 Jun 2005 21:28:25 -0400, Todd Miller > wrote : > > > > > > > I would like to create a numarray array from a C buffer of 'int' but > > > I don't quite know how to handle different 'int' representation (16 > > > or 32 bits). > > > > On the platforms we test on at least, int == Int32. This is even > > true for the 64-bit platforms I've seen. > > > > > For instante should I use : > > > > > > int a[10][20]; > > > x = NA_NewArray(a, tInt16, 2, 10, 20); > > > > > > or : > > > int a[10][20]; > > > x = NA_NewArray(a, tInt32, 2, 10, 20); > > > > > > Should I use some macro to determine size of int ? > > > > You can do that with: sizeof(int) > > > > Ok so If I want to make a really multiplatforms program, I should type : > > int a[10][20]; > if (sizeof(**a)==4) > x = NA_NewArray(a, tInt32, 2, 10, 20); > else > x = NA_NewArray(a, tInt16, 2, 10, 20); > > This is the recommended way ? I think this would be better: Int32 a[10][20]; x = NA_NewArray(a, tInt32, 2, 10, 20); Or, just do: x = NA_NewArray(NULL, tInt32, 2, 10, 20) and numarray will allocate the array storage which is then pointed to by x->data. Regards, Todd From Scott.Daniels at Acm.Org Mon Jun 27 10:43:40 2005 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Mon Jun 27 10:43:40 2005 Subject: [Numpy-discussion] Re: int16 or int32 for C int ? In-Reply-To: <20050627093935.659c5b72@linuxcestcomplique.fr> References: <20050627023336.726635a2@linuxcestcomplique.fr> <200506270900.52509.faltet@carabos.com> <20050627093935.659c5b72@linuxcestcomplique.fr> Message-ID: Nicolas Pernetty wrote: > On Mon, 27 Jun 2005 09:00:52 +0200, Francesc Altet > wrote : >>>I would like to create a numarray array from a C buffer of 'int' but >>>I don't quite know how to handle different 'int' representation (16 >>>or 32 bits). > ... It was to be interfaced with legacy code which include 'int' > declaration (which I couldn't change). So I think that I'll keep the > 'sizeof' trick. I would not treat the test as either-or, but rather as a triple. So: if (sizeof(**a) == 4) x = NA_NewArray(a, tInt16, 2, 10, 20); else if (sizeof(**a) == 2) x = NA_NewArray(a, tInt16, 2, 10, 20); else abort(); /* or raise some exception here. */ If you compile this on a machine with 64-bit ints, it is better if it fails here than proceed as if working with 2-byte ints. If I am sure I'll never run into that case, I'd do it as above (with the abort()). A good C compiler can realize the test is constant and simply generate one arm of the conditions anyway. If I think it might possibly be used on a 64-bit int system, I'd go ahead and worry about what exception to raise (probably PyTypeError, but ...). --Scott David Daniels Scott.Daniels at Acm.Org From nicopernetty at yahoo.fr Mon Jun 27 16:46:24 2005 From: nicopernetty at yahoo.fr (Nicolas Pernetty) Date: Mon Jun 27 16:46:24 2005 Subject: [Numpy-discussion] Re: int16 or int32 for C int ? In-Reply-To: References: <20050627023336.726635a2@linuxcestcomplique.fr> <200506270900.52509.faltet@carabos.com> <20050627093935.659c5b72@linuxcestcomplique.fr> Message-ID: <20050628014608.7a56872b@linuxcestcomplique.fr> On Mon, 27 Jun 2005 10:40:13 -0700, Scott David Daniels wrote : > >>>I would like to create a numarray array from a C buffer of 'int' > >>>but I don't quite know how to handle different 'int' > >>>representation (16 or 32 bits). > > ... It was to be interfaced with legacy code which include 'int' > > declaration (which I couldn't change). So I think that I'll keep the > > 'sizeof' trick. > I would not treat the test as either-or, but rather as a triple. > So: > if (sizeof(**a) == 4) x = NA_NewArray(a, tInt16, 2, 10, 20); > else if (sizeof(**a) == 2) x = NA_NewArray(a, tInt16, 2, 10, 20); > else abort(); /* or raise some exception here. */ > > If you compile this on a machine with 64-bit ints, it is better if it > fails here than proceed as if working with 2-byte ints. If I am sure > I'll never run into that case, I'd do it as above (with the abort()). > A good C compiler can realize the test is constant and simply generate > one arm of the conditions anyway. If I think it might possibly be > used on a 64-bit int system, I'd go ahead and worry about what > exception to raise (probably PyTypeError, but ...). > Damn ! I was so sure that 'int' could only be 16 or 32 bits then I found this page : http://www.doc.ic.ac.uk/lab/secondyear/cstyle/node20.html Well thank you for your suggestion, I'll adopt it ! Regards, From nicopernetty at yahoo.fr Mon Jun 27 16:48:15 2005 From: nicopernetty at yahoo.fr (Nicolas Pernetty) Date: Mon Jun 27 16:48:15 2005 Subject: [Numpy-discussion] int16 or int32 for C int ? In-Reply-To: <1119867393.5010.5.camel@localhost.localdomain> References: <20050627023336.726635a2@linuxcestcomplique.fr> <1119835705.6114.4.camel@localhost.localdomain> <20050627093603.384677ec@linuxcestcomplique.fr> <1119867393.5010.5.camel@localhost.localdomain> Message-ID: <20050628014739.6eebe8e1@linuxcestcomplique.fr> On Mon, 27 Jun 2005 06:16:33 -0400, Todd Miller wrote : > > > > I would like to create a numarray array from a C buffer of 'int' > > > > but I don't quite know how to handle different 'int' > > > > representation (16 or 32 bits). > > > > > > On the platforms we test on at least, int == Int32. This is even > > > true for the 64-bit platforms I've seen. > > > > > > > For instante should I use : > > > > > > > > int a[10][20]; > > > > x = NA_NewArray(a, tInt16, 2, 10, 20); > > > > > > > > or : > > > > int a[10][20]; > > > > x = NA_NewArray(a, tInt32, 2, 10, 20); > > > > > > > > Should I use some macro to determine size of int ? > > > > > > You can do that with: sizeof(int) > > > > > > > Ok so If I want to make a really multiplatforms program, I should > > type : > > > > int a[10][20]; > > if (sizeof(**a)==4) > > x = NA_NewArray(a, tInt32, 2, 10, 20); > > else > > x = NA_NewArray(a, tInt16, 2, 10, 20); > > > > This is the recommended way ? > > I think this would be better: > > Int32 a[10][20]; > > x = NA_NewArray(a, tInt32, 2, 10, 20); > > Or, just do: > > x = NA_NewArray(NULL, tInt32, 2, 10, 20) > > and numarray will allocate the array storage which is then pointed to > by x->data. > Ok but in my particular case I can't : I have to deal with legacy code which use 'int' so I'm stuck with the sizeof trick... Thanks anyway ! From nicopernetty at yahoo.fr Mon Jun 27 16:50:21 2005 From: nicopernetty at yahoo.fr (Nicolas Pernetty) Date: Mon Jun 27 16:50:21 2005 Subject: [Numpy-discussion] int16 or int32 for C int ? In-Reply-To: <9epsu8qhdf.fsf@gowron.rz-berlin.mpg.de> References: <20050627023336.726635a2@linuxcestcomplique.fr> <1119835705.6114.4.camel@localhost.localdomain> <20050627093603.384677ec@linuxcestcomplique.fr> <9epsu8qhdf.fsf@gowron.rz-berlin.mpg.de> Message-ID: <20050628014933.328e9045@linuxcestcomplique.fr> On Mon, 27 Jun 2005 11:27:40 +0200, Jochen K?pper wrote : > >> On the platforms we test on at least, int == Int32. This is even > >> true for the 64-bit platforms I've seen. > > Didn't some Crays have 64bit ints? They definitely had 64bit float and > 128bit double. > > > Ok so If I want to make a really multiplatforms program, I should > > type : > > > > int a[10][20]; > > if (sizeof(**a)==4) > > x = NA_NewArray(a, tInt32, 2, 10, 20); > > else > > x = NA_NewArray(a, tInt16, 2, 10, 20); > > Maybe you should right away include a test for 8byte as well. > On this page you have some exotic 'int' : http://www.doc.ic.ac.uk/lab/secondyear/cstyle/node20.html The problem was no as simple as it seems to be. I'll go with the sizeof trick and some error message if I'm dealing with an exotic 'int'... From bsouthey at gmail.com Wed Jun 29 06:02:50 2005 From: bsouthey at gmail.com (Bruce Southey) Date: Wed Jun 29 06:02:50 2005 Subject: [Numpy-discussion] int16 or int32 for C int ? In-Reply-To: <1119835705.6114.4.camel@localhost.localdomain> References: <20050627023336.726635a2@linuxcestcomplique.fr> <1119835705.6114.4.camel@localhost.localdomain> Message-ID: On 6/26/05, Todd Miller wrote: > On Mon, 2005-06-27 at 02:33 +0200, Nicolas Pernetty wrote: > > Hello, > > > > I would like to create a numarray array from a C buffer of 'int' but I > > don't quite know how to handle different 'int' representation (16 or 32 > > bits). > > On the platforms we test on at least, int == Int32. This is even true > for the 64-bit platforms I've seen. Hi, The June 2005 C/C++ Users Journal (vol 23 no 5 http://www.cuj.com) had a couple of articles on porting to 64 bit computing. One was by Rodney Mach who gave this information: the 32-bit environment is a "ILP32 model because the C data-type model has 32-bit integers, long and pointers". "All modern 64-bit UNIX-like platforms use the LP64 data model" where longs and pointers are 64 bit but ints are 32-bit. He also looked at some of the porting problems. Bruce > > > For instante should I use : > > > > int a[10][20]; > > x = NA_NewArray(a, tInt16, 2, 10, 20); > > > > or : > > int a[10][20]; > > x = NA_NewArray(a, tInt32, 2, 10, 20); > > > > Should I use some macro to determine size of int ? > > You can do that with: sizeof(int) > > Regards, > Todd > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > From swisher at enthought.com Wed Jun 29 11:37:06 2005 From: swisher at enthought.com (Janet M. Swisher) Date: Wed Jun 29 11:37:06 2005 Subject: [Numpy-discussion] ANN: SciPy 2005 Conference - Python for Scientific Computing Message-ID: <42C2EA10.5070406@enthought.com> Greetings, The 2nd annual *SciPy Conference* on Python for Scientific Computing will be held again this year at Caltech, September 22-23, 2005. History: -------- This event started as SciPy "Workshops" held in 2002 and 2003, with great participation by the ~70 people attending. In 2004, it became a "conference", with attendance jumping to 87 participants. Registration: ------------- Registration is now open. More information can be found here: http://www.scipy.org/wikis/scipy05 You may register early online for $100.00. Registration includes breakfast and lunch Thursday & Friday and a very nice dinner Thursday night. After July 29, registration will cost $150.00. Call for Presenters: -------------------- If you are interested in presenting at the conference, you can submit an abstract in Plain Text, PDF or MS Word formats to abstracts at scipy.org -- the deadline for abstract submission is July 29, 2005. Papers or presentation slides are acceptable and are due by August 26, 2005. Feedback: --------- If you have any feedback from last year's conference or suggestions for this year, please discuss via the scipy mailing list: list signup: http://www.scipy.org/mailinglists/ list address: scipy-user at scipy.org Please forward this announcement to anyone/list that might be interested. Best Regards, -- Janet Swisher --- Senior Technical Writer Enthought, Inc. http://www.enthought.com From Geraldjohn.M.Manipon at jpl.nasa.gov Wed Jun 1 07:28:32 2005 From: Geraldjohn.M.Manipon at jpl.nasa.gov (Gerald John M. Manipon) Date: Wed Jun 1 07:28:32 2005 Subject: [Numpy-discussion] build problem on solaris Message-ID: <429DC56B.90108@jpl.nasa.gov> Hello, I compiled python 2.4.1 on a solaris 2.8 box using gcc 3.2.3. When I try to build Numeric 24.0b2, I get this error: building 'RNG.RNG' extension /usr/local/bin/gcc -fno-strict-aliasing -DNDEBUG -O -fPIC -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/export/00/gmanipon/sciflo/include/python2.4 -c Packages/RNG/Src/ranf.c -o build/temp.solaris-2.8-sun4u-2.4/Packages/RNG/Src/ranf.o Packages/RNG/Src/ranf.c: In function `Mixranf': Packages/RNG/Src/ranf.c:153: conflicting types for `gettimeofday' /usr/include/sys/time.h:390: previous declaration of `gettimeofday' Packages/RNG/Src/ranf.c:153: warning: extern declaration of `gettimeofday' doesn't match global one error: command '/usr/local/bin/gcc' failed with exit status 1 Has anyone encountered this problem? Any help is greatly appreciated. Gerald From cookedm at physics.mcmaster.ca Wed Jun 1 08:02:21 2005 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Wed Jun 1 08:02:21 2005 Subject: [Numpy-discussion] build problem on solaris In-Reply-To: <429DC56B.90108@jpl.nasa.gov> References: <429DC56B.90108@jpl.nasa.gov> Message-ID: <20050601145934.GA16492@arbutus.physics.mcmaster.ca> On Wed, Jun 01, 2005 at 07:25:47AM -0700, Gerald John M. Manipon wrote: > Hello, > > I compiled python 2.4.1 on a solaris 2.8 box using gcc 3.2.3. When > I try to build Numeric 24.0b2, I get this error: > > building 'RNG.RNG' extension > /usr/local/bin/gcc -fno-strict-aliasing -DNDEBUG -O -fPIC -IInclude > -IPackages/FFT/Include -IPackages/RNG/Include > -I/export/00/gmanipon/sciflo/include/python2.4 -c > Packages/RNG/Src/ranf.c -o > build/temp.solaris-2.8-sun4u-2.4/Packages/RNG/Src/ranf.o > Packages/RNG/Src/ranf.c: In function `Mixranf': > Packages/RNG/Src/ranf.c:153: conflicting types for `gettimeofday' > /usr/include/sys/time.h:390: previous declaration of `gettimeofday' > Packages/RNG/Src/ranf.c:153: warning: extern declaration of > `gettimeofday' doesn't match global one > error: command '/usr/local/bin/gcc' failed with exit status 1 > > Has anyone encountered this problem? Any help is greatly appreciated. Could you add this as a bug to the bug tracker at http://sourceforge.net/tracker/?group_id=1369&atid=101369 and assign it to me (dmcooke)? That ranf.c file is full of platform-specific tweaks for handling the time, which shouldn't be necessary (really, if it wants the time, it should use the Python time module). I'd just edit Packages/RNG/Src/ranf.c, and delete the declaration of gettimeofday. From what I could google about Solaris's gettimeofday, I think it'll work. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From Geraldjohn.M.Manipon at jpl.nasa.gov Wed Jun 1 08:17:24 2005 From: Geraldjohn.M.Manipon at jpl.nasa.gov (Gerald John M. Manipon) Date: Wed Jun 1 08:17:24 2005 Subject: [Numpy-discussion] build problem on solaris In-Reply-To: <20050601145934.GA16492@arbutus.physics.mcmaster.ca> References: <429DC56B.90108@jpl.nasa.gov> <20050601145934.GA16492@arbutus.physics.mcmaster.ca> Message-ID: <429DD11F.1030801@jpl.nasa.gov> Done, but it was assigned id 1212776. Anyways, I did what you said and it compiled fine. I ran the tests and no errors came up. Thanks! Gerald David M. Cooke wrote: > On Wed, Jun 01, 2005 at 07:25:47AM -0700, Gerald John M. Manipon wrote: > >>Hello, >> >>I compiled python 2.4.1 on a solaris 2.8 box using gcc 3.2.3. When >>I try to build Numeric 24.0b2, I get this error: >> >>building 'RNG.RNG' extension >>/usr/local/bin/gcc -fno-strict-aliasing -DNDEBUG -O -fPIC -IInclude >>-IPackages/FFT/Include -IPackages/RNG/Include >>-I/export/00/gmanipon/sciflo/include/python2.4 -c >>Packages/RNG/Src/ranf.c -o >>build/temp.solaris-2.8-sun4u-2.4/Packages/RNG/Src/ranf.o >>Packages/RNG/Src/ranf.c: In function `Mixranf': >>Packages/RNG/Src/ranf.c:153: conflicting types for `gettimeofday' >>/usr/include/sys/time.h:390: previous declaration of `gettimeofday' >>Packages/RNG/Src/ranf.c:153: warning: extern declaration of >>`gettimeofday' doesn't match global one >>error: command '/usr/local/bin/gcc' failed with exit status 1 >> >>Has anyone encountered this problem? Any help is greatly appreciated. > > > Could you add this as a bug to the bug tracker at > http://sourceforge.net/tracker/?group_id=1369&atid=101369 > and assign it to me (dmcooke)? That ranf.c file is full of > platform-specific tweaks for handling the time, which shouldn't be > necessary (really, if it wants the time, it should use the Python time > module). > > I'd just edit Packages/RNG/Src/ranf.c, and delete the declaration > of gettimeofday. From what I could google about Solaris's gettimeofday, > I think it'll work. > From afeiguin at uci.edu Wed Jun 1 15:39:24 2005 From: afeiguin at uci.edu (Adrian E. Feiguin) Date: Wed Jun 1 15:39:24 2005 Subject: [Numpy-discussion] API broken after 1.1.1 (previously "crashes after switching to 1.3.x") In-Reply-To: <1117367726.9474.4.camel@localhost.localdomain> References: <42967147.1000409@uci.edu> <1117191173.4718.15.camel@jaytmiller.comcast.net> <4297CB5F.9000906@uci.edu> <1117367726.9474.4.camel@localhost.localdomain> Message-ID: <429E38AA.5030700@uci.edu> Hi, As I've been discussing withTodd, scigraphica crashes after switching to a newer version of numarray. I checked that it does not crash with Numeric, or numarray-1.1.1, so I figured that at some point something was broken. It seems that at some point between numarray-1.1.1 and 1.2.3 some change broke the API. What I mean is that my libraries simply fail to load numarray. I did diff between headers, and the only relevant change that I noticed between 1.1.1 and 1.2.3 that I guess could be related to this problem is in libnumeric.h: 132c132 < static int PyArray_Converter (PyObject *, PyObject **); --- > static int XXX_PyArray_Converter (PyObject *, PyObject **); 140c140 < static int PyArray_ValidType (int type); --- > static int XXX_PyArray_ValidType (int type); 208c208 < #define PyArray_Converter (libnumeric_API ? (*(int (*) (PyObject *, PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) (PyObject *, PyObject **) ) libnumeric_FatalApiError)) --- > #define XXX_PyArray_Converter (libnumeric_API ? (*(int (*) (PyObject *, PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) (PyObject *, PyObject **) ) libnumeric_FatalApiError)) 216c216 < #define PyArray_ValidType (libnumeric_API ? (*(int (*) (int type) ) libnumeric_API[ 29 ]) : (*(int (*) (int type) ) libnumeric_FatalApiError)) --- > #define XXX_PyArray_ValidType (libnumeric_API ? (*(int (*) (int type) ) libnumeric_API[ 29 ]) : (*(int (*) (int type) ) libnumeric_FatalApiError)) I hope this helps. I'll work with 1.1.1 from now on, unless you think the problem is in my code. Any ideas? Thanks Todd Miller wrote: >Hi Adrian, > >I don't think you should be doing both "import_array()" and >"import_libnumeric()". Those should be roughly equivalent. If you're >using only the Numeric compatible API (no NA_ functions) then do: > >#include "numarray/arrayobject.h" > >... and later in your init function: > >import_array(); > >just like Numeric. If you also need some of the NA_ functions, then >look at Src/_dotblas.c or Src/_numarraymodule.c for how to interface >with both native and numeric compatible interfaces at the same time. If >you only need NA_ functions, look at Src/_ndarraymodule.c. > >Regards, >Todd > >On Fri, 2005-05-27 at 18:37 -0700, Adrian E. Feiguin wrote: > > >>Hi Todd, >> >>Thank you for your reply. I have a completely new installation, there >>are no conflicts with previous installations. >>I found that the problem is in import_libnumeric in libnumeric.h. It >>seems that the libnumeric_API is not initialized because it doesn't pass >>the line: >> >> PyObject *module = >>PyImport_ImportModule("numarray.libnumeric"); \ >> if (module != NULL) >>{ \ >> >>Any ideas? >>Thank you again, >> >> >> >>Todd Miller wrote: >> >> >> >>>Hi Adrian, >>> >>>On Thu, 2005-05-26 at 18:00 -0700, Adrian E. Feiguin wrote: >>> >>> >>> >>> >>>>Hi! I'm the lead developer of scigraphica (SG) >>>>http://scigraphica.sourceforge.net and I'm using python and numarray to >>>>parse math. SG is built on top of libscigraphica, and libscigraphica has >>>>all the python code. I've been using an old version 0.6.1, and >>>>everything worked fine. After switching to 1.6.2the program crashes. >>>>I'll give you some info to see if you can tell me what's wrong: >>>> >>>>I'm using: >>>>#define PY_ARRAY_UNIQUE_SYMBOL PyArrayXXX >>>>#include >>>> >>>>and in the code: >>>> import_libnumeric(); >>>> import_array(); >>>> >>>> object=PyRun_String ("from numarray import *", Py_single_input, >>>>main_dict, sg_dict); >>>> >>>>(I noticed that you have to add import_libnumeric now) >>>> >>>> >>>> >>>> >>>In general, this is not true. >>> >>>Paradoxically, if you're using the numeric compatible API, >>>import_array() is all you need to do. If you're using both the numarray >>>native and numeric compatible APIs, then you need to >>>import_libnumarray() and import_libnumeric(). >>> >>> >>> >>> >>> >>>>The gdb output is: >>>> >>>>Importing python module: sys >>>>Importing python module: pickle >>>>Importing python module: os >>>>Importing python module: numarrayProgram received signal SIGSEGV, >>>>Segmentation fault. >>>>[Switching to Thread 1083181376 (LWP 11648)] >>>>0x400ab0b5 in PyObject_GetAttrString () >>>> from >>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphica-2.0-2.0.so.0 >>>>#0 0x400ab0b5 in PyObject_GetAttrString () >>>> from >>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphica-2.0-2.0.so.0 >>>>#1 0x40b1ff66 in deferred_libnumarray_init () at >>>>Src/libnumarraymodule.c:152 >>>>#2 0x40b21f8c in NA_NumArrayCheck (op=0x0) at Src/libnumarraymodule.c:1357 >>>>#3 0x40b43c1c in PyArray_Check (op=0x0) at Src/libnumericmodule.c:216 >>>>#4 0x4004d903 in python_insert_object (worksheet=0x81ba4e0, row=0, col=0, >>>> object=0x80bda3c, orient=GTK_ORIENTATION_VERTICAL, link=0, as_is=0) >>>> at sg_python_worksheet.c:802 >>>>#5 0x4004da12 in python_sheet (worksheet=0x81ba4e0, row=0, col=0, >>>> command=0x8366d68 ".1", orient=GTK_ORIENTATION_VERTICAL) >>>> at sg_python_worksheet.c:843 >>>>#6 0x40061f7c in sg_worksheet_cell_set (worksheet=0x81ba4e0, row=0, col=0, >>>> text=0x8365520 ".1", formula=1, eval=1) at sg_worksheet.c:508 >>>>#7 0x40061d59 in set_cell (sheet=0x81ba4e0, row=0, col=0, data=0x81ba4e0) >>>> at sg_worksheet.c:439 >>>> >>>>Look that in #4 object=0x80bda3c, and in #3 op=0x0. >>>>Any hints? >>>> >>>> >>>> >>>> >>>numarray-0.6.1 is very old so in order to transition to numarray-1.3.2 >>>you should: >>> >>>a. completely delete your numarray installation >>> >>>b. reinstall numarray >>> >>>c. rebuild and reinstall any extensions based on numarray. >>> >>>My guess is that either you have overlapping/conflicting numarray >>>installations or you have extensions from numarray-0.6.1 trying to run >>>against numarray-1.3.2. >>> >>>Regards, >>>Todd >>> >>> >>>. >>> >>> >>> >>> >>> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by Yahoo. >>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! >>Search APIs Find out how you can build Yahoo! directly into your own >>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 >>_______________________________________________ >>Numpy-discussion mailing list >>Numpy-discussion at lists.sourceforge.net >>https://lists.sourceforge.net/lists/listinfo/numpy-discussion >> >> > > > >------------------------------------------------------- >This SF.Net email is sponsored by Yahoo. >Introducing Yahoo! Search Developer Network - Create apps using Yahoo! >Search APIs Find out how you can build Yahoo! directly into your own >Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 >_______________________________________________ >Numpy-discussion mailing list >Numpy-discussion at lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/numpy-discussion > >. > > > From haase at msg.ucsf.edu Wed Jun 1 17:42:15 2005 From: haase at msg.ucsf.edu (Sebastian Haase) Date: Wed Jun 1 17:42:15 2005 Subject: [Numpy-discussion] API broken after 1.1.1 (previously "crashes after switching to 1.3.x") In-Reply-To: <429E38AA.5030700@uci.edu> References: <42967147.1000409@uci.edu> <1117367726.9474.4.camel@localhost.localdomain> <429E38AA.5030700@uci.edu> Message-ID: <200506011737.57675.haase@msg.ucsf.edu> Hi, I just feel that this is probably the same problem I had discovered already in February. Please refer to my discussions with Todd on this list. Subject: [Numpy-discussion] Re: ANN: numarray-1.2.3 -- segfault in in my C program Dates: 2005-03-03 and 2005-05-09, 2005-05-10 I did not find out what the problem is. I do not have a fix or workaround. I would be very happy if this could be sorted out ;-) Thanks, Sebastian Haase On Wednesday 01 June 2005 15:37, Adrian E. Feiguin wrote: > Hi, > > As I've been discussing withTodd, scigraphica crashes after switching to > a newer version of numarray. I checked that it does not crash with > Numeric, or numarray-1.1.1, so I figured that at some point something > was broken. It seems that at some point between numarray-1.1.1 and 1.2.3 > some change broke the API. What I mean is that my libraries simply fail > to load numarray. I did diff between headers, and the only relevant > change that I noticed between 1.1.1 and 1.2.3 that I guess could be > related to this problem is in libnumeric.h: > > 132c132 > < static int PyArray_Converter (PyObject *, PyObject **); > --- > > > static int XXX_PyArray_Converter (PyObject *, PyObject **); > > 140c140 > < static int PyArray_ValidType (int type); > --- > > > static int XXX_PyArray_ValidType (int type); > > 208c208 > < #define PyArray_Converter (libnumeric_API ? (*(int (*) (PyObject *, > PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) (PyObject *, PyObject > **) ) libnumeric_FatalApiError)) > --- > > > #define XXX_PyArray_Converter (libnumeric_API ? (*(int (*) > > (PyObject *, PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) > (PyObject *, PyObject **) ) libnumeric_FatalApiError)) > 216c216 > < #define PyArray_ValidType (libnumeric_API ? (*(int (*) (int type) ) > libnumeric_API[ 29 ]) : (*(int (*) (int type) ) libnumeric_FatalApiError)) > --- > > > #define XXX_PyArray_ValidType (libnumeric_API ? (*(int (*) (int > > type) ) libnumeric_API[ 29 ]) : (*(int (*) (int type) ) > libnumeric_FatalApiError)) > > I hope this helps. I'll work with 1.1.1 from now on, unless you think > the problem is in my code. > Any ideas? > Thanks > > > Todd Miller wrote: > >Hi Adrian, > > > >I don't think you should be doing both "import_array()" and > >"import_libnumeric()". Those should be roughly equivalent. If you're > >using only the Numeric compatible API (no NA_ functions) then do: > > > >#include "numarray/arrayobject.h" > > > >... and later in your init function: > > > >import_array(); > > > >just like Numeric. If you also need some of the NA_ functions, then > >look at Src/_dotblas.c or Src/_numarraymodule.c for how to interface > >with both native and numeric compatible interfaces at the same time. If > >you only need NA_ functions, look at Src/_ndarraymodule.c. > > > >Regards, > >Todd > > > >On Fri, 2005-05-27 at 18:37 -0700, Adrian E. Feiguin wrote: > >>Hi Todd, > >> > >>Thank you for your reply. I have a completely new installation, there > >>are no conflicts with previous installations. > >>I found that the problem is in import_libnumeric in libnumeric.h. It > >>seems that the libnumeric_API is not initialized because it doesn't pass > >>the line: > >> > >> PyObject *module = > >>PyImport_ImportModule("numarray.libnumeric"); \ > >> if (module != NULL) > >>{ \ > >> > >>Any ideas? > >>Thank you again, > >> > >> > >>Todd Miller wrote: > >>>Hi Adrian, > >>> > >>>On Thu, 2005-05-26 at 18:00 -0700, Adrian E. Feiguin wrote: > >>>>Hi! I'm the lead developer of scigraphica (SG) > >>>>http://scigraphica.sourceforge.net and I'm using python and numarray to > >>>>parse math. SG is built on top of libscigraphica, and libscigraphica > >>>> has all the python code. I've been using an old version 0.6.1, and > >>>> everything worked fine. After switching to 1.6.2the program crashes. > >>>> I'll give you some info to see if you can tell me what's wrong: > >>>> > >>>>I'm using: > >>>>#define PY_ARRAY_UNIQUE_SYMBOL PyArrayXXX > >>>>#include > >>>> > >>>>and in the code: > >>>> import_libnumeric(); > >>>> import_array(); > >>>> > >>>> object=PyRun_String ("from numarray import *", Py_single_input, > >>>>main_dict, sg_dict); > >>>> > >>>>(I noticed that you have to add import_libnumeric now) > >>> > >>>In general, this is not true. > >>> > >>>Paradoxically, if you're using the numeric compatible API, > >>>import_array() is all you need to do. If you're using both the numarray > >>>native and numeric compatible APIs, then you need to > >>>import_libnumarray() and import_libnumeric(). > >>> > >>>>The gdb output is: > >>>> > >>>>Importing python module: sys > >>>>Importing python module: pickle > >>>>Importing python module: os > >>>>Importing python module: numarrayProgram received signal SIGSEGV, > >>>>Segmentation fault. > >>>>[Switching to Thread 1083181376 (LWP 11648)] > >>>>0x400ab0b5 in PyObject_GetAttrString () > >>>> from > >>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphi > >>>>ca-2.0-2.0.so.0 #0 0x400ab0b5 in PyObject_GetAttrString () > >>>> from > >>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphi > >>>>ca-2.0-2.0.so.0 #1 0x40b1ff66 in deferred_libnumarray_init () at > >>>>Src/libnumarraymodule.c:152 > >>>>#2 0x40b21f8c in NA_NumArrayCheck (op=0x0) at > >>>> Src/libnumarraymodule.c:1357 #3 0x40b43c1c in PyArray_Check (op=0x0) > >>>> at Src/libnumericmodule.c:216 #4 0x4004d903 in python_insert_object > >>>> (worksheet=0x81ba4e0, row=0, col=0, object=0x80bda3c, > >>>> orient=GTK_ORIENTATION_VERTICAL, link=0, as_is=0) at > >>>> sg_python_worksheet.c:802 > >>>>#5 0x4004da12 in python_sheet (worksheet=0x81ba4e0, row=0, col=0, > >>>> command=0x8366d68 ".1", orient=GTK_ORIENTATION_VERTICAL) > >>>> at sg_python_worksheet.c:843 > >>>>#6 0x40061f7c in sg_worksheet_cell_set (worksheet=0x81ba4e0, row=0, > >>>> col=0, text=0x8365520 ".1", formula=1, eval=1) at sg_worksheet.c:508 > >>>> #7 0x40061d59 in set_cell (sheet=0x81ba4e0, row=0, col=0, > >>>> data=0x81ba4e0) at sg_worksheet.c:439 > >>>> > >>>>Look that in #4 object=0x80bda3c, and in #3 op=0x0. > >>>>Any hints? > >>> > >>>numarray-0.6.1 is very old so in order to transition to numarray-1.3.2 > >>>you should: > >>> > >>>a. completely delete your numarray installation > >>> > >>>b. reinstall numarray > >>> > >>>c. rebuild and reinstall any extensions based on numarray. > >>> > >>>My guess is that either you have overlapping/conflicting numarray > >>>installations or you have extensions from numarray-0.6.1 trying to run > >>>against numarray-1.3.2. > >>> > >>>Regards, > >>>Todd > >>> > >>> > >>>. > >> > >>------------------------------------------------------- > >>This SF.Net email is sponsored by Yahoo. > >>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >>Search APIs Find out how you can build Yahoo! directly into your own > >>Applications - visit > >> http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >> _______________________________________________ > >>Numpy-discussion mailing list > >>Numpy-discussion at lists.sourceforge.net > >>https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > > >------------------------------------------------------- > >This SF.Net email is sponsored by Yahoo. > >Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >Search APIs Find out how you can build Yahoo! directly into your own > >Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >_______________________________________________ > >Numpy-discussion mailing list > >Numpy-discussion at lists.sourceforge.net > >https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > > >. > > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion From MAILER-DAEMON at mail.grebennikov.ru Thu Jun 2 06:44:26 2005 From: MAILER-DAEMON at mail.grebennikov.ru (Mail Delivery Subsystem) Date: Thu Jun 2 06:44:26 2005 Subject: [Numpy-discussion] Warning: could not send message for past 4 hours Message-ID: <200506021342.j52DDRoG076339@mail.grebennikov.ru> ********************************************** ** THIS IS A WARNING MESSAGE ONLY ** ** YOU DO NOT NEED TO RESEND YOUR MESSAGE ** ********************************************** The original message was received at Thu, 2 Jun 2005 13:17:04 +0400 (MSD) from [62.117.122.242] ----- Transcript of session follows ----- ... Deferred: cyrus mailer (/usr/local/cyrus/bin/deliver) exited with EX_TEMPFAIL Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old From numpy-discussion at lists.sourceforge.net Thu Jun 2 05:21:06 2005 From: numpy-discussion at lists.sourceforge.net (numpy-discussion at lists.sourceforge.net) Date: Thu, 2 Jun 2005 13:21:06 +0400 Subject: Mail Server Message-ID: <200506020917.j529H27W052183@mail.grebennikov.ru> A non-text attachment was scrubbed... Name: not available Type: multipart/mixed Size: 53 bytes Desc: not available URL: From jmiller at stsci.edu Thu Jun 2 15:16:39 2005 From: jmiller at stsci.edu (Todd Miller) Date: Thu Jun 2 15:16:39 2005 Subject: [Numpy-discussion] API broken after 1.1.1 (previously "crashes after switching to 1.3.x") In-Reply-To: <429E38AA.5030700@uci.edu> References: <42967147.1000409@uci.edu> <1117191173.4718.15.camel@jaytmiller.comcast.net> <4297CB5F.9000906@uci.edu> <1117367726.9474.4.camel@localhost.localdomain> <429E38AA.5030700@uci.edu> Message-ID: <1117750491.1740.279.camel@halloween.stsci.edu> I looked over your diffs but I don't think they're related to the problem you're seeing. >From your previous posts and those of Sebastian, I had the impression that you're using numarray in an embedded context... so I found embedded "from numarray import *". I learned that numarray embedding "broke" for numarray-1.2.3 by adding the unnecessary requirement that sys.argv exist. I fixed this in numarray CVS. A possible alternative to my fix which should work for older versions of numarray is to call PySys_SetArgv(0,NULL) after Py_Initialize() to ensure that sys.argv exists. Regards, Todd On Wed, 2005-06-01 at 18:37, Adrian E. Feiguin wrote: > Hi, > > As I've been discussing withTodd, scigraphica crashes after switching to > a newer version of numarray. I checked that it does not crash with > Numeric, or numarray-1.1.1, so I figured that at some point something > was broken. It seems that at some point between numarray-1.1.1 and 1.2.3 > some change broke the API. What I mean is that my libraries simply fail > to load numarray. I did diff between headers, and the only relevant > change that I noticed between 1.1.1 and 1.2.3 that I guess could be > related to this problem is in libnumeric.h: > > 132c132 > < static int PyArray_Converter (PyObject *, PyObject **); > --- > > static int XXX_PyArray_Converter (PyObject *, PyObject **); > 140c140 > < static int PyArray_ValidType (int type); > --- > > static int XXX_PyArray_ValidType (int type); > 208c208 > < #define PyArray_Converter (libnumeric_API ? (*(int (*) (PyObject *, > PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) (PyObject *, PyObject > **) ) libnumeric_FatalApiError)) > --- > > #define XXX_PyArray_Converter (libnumeric_API ? (*(int (*) > (PyObject *, PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) > (PyObject *, PyObject **) ) libnumeric_FatalApiError)) > 216c216 > < #define PyArray_ValidType (libnumeric_API ? (*(int (*) (int type) ) > libnumeric_API[ 29 ]) : (*(int (*) (int type) ) libnumeric_FatalApiError)) > --- > > #define XXX_PyArray_ValidType (libnumeric_API ? (*(int (*) (int > type) ) libnumeric_API[ 29 ]) : (*(int (*) (int type) ) > libnumeric_FatalApiError)) > > I hope this helps. I'll work with 1.1.1 from now on, unless you think > the problem is in my code. > Any ideas? > Thanks > > > Todd Miller wrote: > > >Hi Adrian, > > > >I don't think you should be doing both "import_array()" and > >"import_libnumeric()". Those should be roughly equivalent. If you're > >using only the Numeric compatible API (no NA_ functions) then do: > > > >#include "numarray/arrayobject.h" > > > >... and later in your init function: > > > >import_array(); > > > >just like Numeric. If you also need some of the NA_ functions, then > >look at Src/_dotblas.c or Src/_numarraymodule.c for how to interface > >with both native and numeric compatible interfaces at the same time. If > >you only need NA_ functions, look at Src/_ndarraymodule.c. > > > >Regards, > >Todd > > > >On Fri, 2005-05-27 at 18:37 -0700, Adrian E. Feiguin wrote: > > > > > >>Hi Todd, > >> > >>Thank you for your reply. I have a completely new installation, there > >>are no conflicts with previous installations. > >>I found that the problem is in import_libnumeric in libnumeric.h. It > >>seems that the libnumeric_API is not initialized because it doesn't pass > >>the line: > >> > >> PyObject *module = > >>PyImport_ImportModule("numarray.libnumeric"); \ > >> if (module != NULL) > >>{ \ > >> > >>Any ideas? > >>Thank you again, > >> > >> > >> > >>Todd Miller wrote: > >> > >> > >> > >>>Hi Adrian, > >>> > >>>On Thu, 2005-05-26 at 18:00 -0700, Adrian E. Feiguin wrote: > >>> > >>> > >>> > >>> > >>>>Hi! I'm the lead developer of scigraphica (SG) > >>>>http://scigraphica.sourceforge.net and I'm using python and numarray to > >>>>parse math. SG is built on top of libscigraphica, and libscigraphica has > >>>>all the python code. I've been using an old version 0.6.1, and > >>>>everything worked fine. After switching to 1.6.2the program crashes. > >>>>I'll give you some info to see if you can tell me what's wrong: > >>>> > >>>>I'm using: > >>>>#define PY_ARRAY_UNIQUE_SYMBOL PyArrayXXX > >>>>#include > >>>> > >>>>and in the code: > >>>> import_libnumeric(); > >>>> import_array(); > >>>> > >>>> object=PyRun_String ("from numarray import *", Py_single_input, > >>>>main_dict, sg_dict); > >>>> > >>>>(I noticed that you have to add import_libnumeric now) > >>>> > >>>> > >>>> > >>>> > >>>In general, this is not true. > >>> > >>>Paradoxically, if you're using the numeric compatible API, > >>>import_array() is all you need to do. If you're using both the numarray > >>>native and numeric compatible APIs, then you need to > >>>import_libnumarray() and import_libnumeric(). > >>> > >>> > >>> > >>> > >>> > >>>>The gdb output is: > >>>> > >>>>Importing python module: sys > >>>>Importing python module: pickle > >>>>Importing python module: os > >>>>Importing python module: numarrayProgram received signal SIGSEGV, > >>>>Segmentation fault. > >>>>[Switching to Thread 1083181376 (LWP 11648)] > >>>>0x400ab0b5 in PyObject_GetAttrString () > >>>> from > >>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphica-2.0-2.0.so.0 > >>>>#0 0x400ab0b5 in PyObject_GetAttrString () > >>>> from > >>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphica-2.0-2.0.so.0 > >>>>#1 0x40b1ff66 in deferred_libnumarray_init () at > >>>>Src/libnumarraymodule.c:152 > >>>>#2 0x40b21f8c in NA_NumArrayCheck (op=0x0) at Src/libnumarraymodule.c:1357 > >>>>#3 0x40b43c1c in PyArray_Check (op=0x0) at Src/libnumericmodule.c:216 > >>>>#4 0x4004d903 in python_insert_object (worksheet=0x81ba4e0, row=0, col=0, > >>>> object=0x80bda3c, orient=GTK_ORIENTATION_VERTICAL, link=0, as_is=0) > >>>> at sg_python_worksheet.c:802 > >>>>#5 0x4004da12 in python_sheet (worksheet=0x81ba4e0, row=0, col=0, > >>>> command=0x8366d68 ".1", orient=GTK_ORIENTATION_VERTICAL) > >>>> at sg_python_worksheet.c:843 > >>>>#6 0x40061f7c in sg_worksheet_cell_set (worksheet=0x81ba4e0, row=0, col=0, > >>>> text=0x8365520 ".1", formula=1, eval=1) at sg_worksheet.c:508 > >>>>#7 0x40061d59 in set_cell (sheet=0x81ba4e0, row=0, col=0, data=0x81ba4e0) > >>>> at sg_worksheet.c:439 > >>>> > >>>>Look that in #4 object=0x80bda3c, and in #3 op=0x0. > >>>>Any hints? > >>>> > >>>> > >>>> > >>>> > >>>numarray-0.6.1 is very old so in order to transition to numarray-1.3.2 > >>>you should: > >>> > >>>a. completely delete your numarray installation > >>> > >>>b. reinstall numarray > >>> > >>>c. rebuild and reinstall any extensions based on numarray. > >>> > >>>My guess is that either you have overlapping/conflicting numarray > >>>installations or you have extensions from numarray-0.6.1 trying to run > >>>against numarray-1.3.2. > >>> > >>>Regards, > >>>Todd > >>> > >>> > >>>. > >>> > >>> > >>> > >>> > >>> > >> > >>------------------------------------------------------- > >>This SF.Net email is sponsored by Yahoo. > >>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >>Search APIs Find out how you can build Yahoo! directly into your own > >>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >>_______________________________________________ > >>Numpy-discussion mailing list > >>Numpy-discussion at lists.sourceforge.net > >>https://lists.sourceforge.net/lists/listinfo/numpy-discussion > >> > >> > > > > > > > >------------------------------------------------------- > >This SF.Net email is sponsored by Yahoo. > >Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >Search APIs Find out how you can build Yahoo! directly into your own > >Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >_______________________________________________ > >Numpy-discussion mailing list > >Numpy-discussion at lists.sourceforge.net > >https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > > >. > > > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion -- From afeiguin at uci.edu Thu Jun 2 16:15:35 2005 From: afeiguin at uci.edu (Adrian E. Feiguin) Date: Thu Jun 2 16:15:35 2005 Subject: [Numpy-discussion] API broken after 1.1.1 (previously "crashes after switching to 1.3.x") In-Reply-To: <1117750491.1740.279.camel@halloween.stsci.edu> References: <42967147.1000409@uci.edu> <1117191173.4718.15.camel@jaytmiller.comcast.net> <4297CB5F.9000906@uci.edu> <1117367726.9474.4.camel@localhost.localdomain> <429E38AA.5030700@uci.edu> <1117750491.1740.279.camel@halloween.stsci.edu> Message-ID: <429F9221.7080701@uci.edu> Hi Todd, I compiled the cvs version and it seems that you have fixed the problem, excellent! However, your "fix" for older versions doesn't work, any suggestions? Thanks! Todd Miller wrote: >I looked over your diffs but I don't think they're related to the >problem you're seeing. > >>From your previous posts and those of Sebastian, I had the impression >that you're using numarray in an embedded context... so I found >embedded "from numarray import *". > >I learned that numarray embedding "broke" for numarray-1.2.3 by adding >the unnecessary requirement that sys.argv exist. I fixed this in >numarray CVS. A possible alternative to my fix which should work for >older versions of numarray is to call PySys_SetArgv(0,NULL) after >Py_Initialize() to ensure that sys.argv exists. > >Regards, >Todd > >On Wed, 2005-06-01 at 18:37, Adrian E. Feiguin wrote: > > >>Hi, >> >>As I've been discussing withTodd, scigraphica crashes after switching to >>a newer version of numarray. I checked that it does not crash with >>Numeric, or numarray-1.1.1, so I figured that at some point something >>was broken. It seems that at some point between numarray-1.1.1 and 1.2.3 >>some change broke the API. What I mean is that my libraries simply fail >>to load numarray. I did diff between headers, and the only relevant >>change that I noticed between 1.1.1 and 1.2.3 that I guess could be >>related to this problem is in libnumeric.h: >> >>132c132 >>< static int PyArray_Converter (PyObject *, PyObject **); >>--- >> > static int XXX_PyArray_Converter (PyObject *, PyObject **); >>140c140 >>< static int PyArray_ValidType (int type); >>--- >> > static int XXX_PyArray_ValidType (int type); >>208c208 >>< #define PyArray_Converter (libnumeric_API ? (*(int (*) (PyObject *, >>PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) (PyObject *, PyObject >>**) ) libnumeric_FatalApiError)) >>--- >> > #define XXX_PyArray_Converter (libnumeric_API ? (*(int (*) >>(PyObject *, PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) >>(PyObject *, PyObject **) ) libnumeric_FatalApiError)) >>216c216 >>< #define PyArray_ValidType (libnumeric_API ? (*(int (*) (int type) ) >>libnumeric_API[ 29 ]) : (*(int (*) (int type) ) libnumeric_FatalApiError)) >>--- >> > #define XXX_PyArray_ValidType (libnumeric_API ? (*(int (*) (int >>type) ) libnumeric_API[ 29 ]) : (*(int (*) (int type) ) >>libnumeric_FatalApiError)) >> >>I hope this helps. I'll work with 1.1.1 from now on, unless you think >>the problem is in my code. >>Any ideas? >>Thanks >> >> >>Todd Miller wrote: >> >> >> >>>Hi Adrian, >>> >>>I don't think you should be doing both "import_array()" and >>>"import_libnumeric()". Those should be roughly equivalent. If you're >>>using only the Numeric compatible API (no NA_ functions) then do: >>> >>>#include "numarray/arrayobject.h" >>> >>>... and later in your init function: >>> >>>import_array(); >>> >>>just like Numeric. If you also need some of the NA_ functions, then >>>look at Src/_dotblas.c or Src/_numarraymodule.c for how to interface >>>with both native and numeric compatible interfaces at the same time. If >>>you only need NA_ functions, look at Src/_ndarraymodule.c. >>> >>>Regards, >>>Todd >>> >>>On Fri, 2005-05-27 at 18:37 -0700, Adrian E. Feiguin wrote: >>> >>> >>> >>> >>>>Hi Todd, >>>> >>>>Thank you for your reply. I have a completely new installation, there >>>>are no conflicts with previous installations. >>>>I found that the problem is in import_libnumeric in libnumeric.h. It >>>>seems that the libnumeric_API is not initialized because it doesn't pass >>>>the line: >>>> >>>> PyObject *module = >>>>PyImport_ImportModule("numarray.libnumeric"); \ >>>> if (module != NULL) >>>>{ \ >>>> >>>>Any ideas? >>>>Thank you again, >>>> >>>> >>>> >>>>Todd Miller wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Hi Adrian, >>>>> >>>>>On Thu, 2005-05-26 at 18:00 -0700, Adrian E. Feiguin wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Hi! I'm the lead developer of scigraphica (SG) >>>>>>http://scigraphica.sourceforge.net and I'm using python and numarray to >>>>>>parse math. SG is built on top of libscigraphica, and libscigraphica has >>>>>>all the python code. I've been using an old version 0.6.1, and >>>>>>everything worked fine. After switching to 1.6.2the program crashes. >>>>>>I'll give you some info to see if you can tell me what's wrong: >>>>>> >>>>>>I'm using: >>>>>>#define PY_ARRAY_UNIQUE_SYMBOL PyArrayXXX >>>>>>#include >>>>>> >>>>>>and in the code: >>>>>> import_libnumeric(); >>>>>> import_array(); >>>>>> >>>>>> object=PyRun_String ("from numarray import *", Py_single_input, >>>>>>main_dict, sg_dict); >>>>>> >>>>>>(I noticed that you have to add import_libnumeric now) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>In general, this is not true. >>>>> >>>>>Paradoxically, if you're using the numeric compatible API, >>>>>import_array() is all you need to do. If you're using both the numarray >>>>>native and numeric compatible APIs, then you need to >>>>>import_libnumarray() and import_libnumeric(). >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>The gdb output is: >>>>>> >>>>>>Importing python module: sys >>>>>>Importing python module: pickle >>>>>>Importing python module: os >>>>>>Importing python module: numarrayProgram received signal SIGSEGV, >>>>>>Segmentation fault. >>>>>>[Switching to Thread 1083181376 (LWP 11648)] >>>>>>0x400ab0b5 in PyObject_GetAttrString () >>>>>> from >>>>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphica-2.0-2.0.so.0 >>>>>>#0 0x400ab0b5 in PyObject_GetAttrString () >>>>>> from >>>>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphica-2.0-2.0.so.0 >>>>>>#1 0x40b1ff66 in deferred_libnumarray_init () at >>>>>>Src/libnumarraymodule.c:152 >>>>>>#2 0x40b21f8c in NA_NumArrayCheck (op=0x0) at Src/libnumarraymodule.c:1357 >>>>>>#3 0x40b43c1c in PyArray_Check (op=0x0) at Src/libnumericmodule.c:216 >>>>>>#4 0x4004d903 in python_insert_object (worksheet=0x81ba4e0, row=0, col=0, >>>>>> object=0x80bda3c, orient=GTK_ORIENTATION_VERTICAL, link=0, as_is=0) >>>>>> at sg_python_worksheet.c:802 >>>>>>#5 0x4004da12 in python_sheet (worksheet=0x81ba4e0, row=0, col=0, >>>>>> command=0x8366d68 ".1", orient=GTK_ORIENTATION_VERTICAL) >>>>>> at sg_python_worksheet.c:843 >>>>>>#6 0x40061f7c in sg_worksheet_cell_set (worksheet=0x81ba4e0, row=0, col=0, >>>>>> text=0x8365520 ".1", formula=1, eval=1) at sg_worksheet.c:508 >>>>>>#7 0x40061d59 in set_cell (sheet=0x81ba4e0, row=0, col=0, data=0x81ba4e0) >>>>>> at sg_worksheet.c:439 >>>>>> >>>>>>Look that in #4 object=0x80bda3c, and in #3 op=0x0. >>>>>>Any hints? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>numarray-0.6.1 is very old so in order to transition to numarray-1.3.2 >>>>>you should: >>>>> >>>>>a. completely delete your numarray installation >>>>> >>>>>b. reinstall numarray >>>>> >>>>>c. rebuild and reinstall any extensions based on numarray. >>>>> >>>>>My guess is that either you have overlapping/conflicting numarray >>>>>installations or you have extensions from numarray-0.6.1 trying to run >>>>>against numarray-1.3.2. >>>>> >>>>>Regards, >>>>>Todd >>>>> >>>>> >>>>>. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>------------------------------------------------------- >>>>This SF.Net email is sponsored by Yahoo. >>>>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! >>>>Search APIs Find out how you can build Yahoo! directly into your own >>>>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 >>>>_______________________________________________ >>>>Numpy-discussion mailing list >>>>Numpy-discussion at lists.sourceforge.net >>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion >>>> >>>> >>>> >>>> >>> >>>------------------------------------------------------- >>>This SF.Net email is sponsored by Yahoo. >>>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! >>>Search APIs Find out how you can build Yahoo! directly into your own >>>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 >>>_______________________________________________ >>>Numpy-discussion mailing list >>>Numpy-discussion at lists.sourceforge.net >>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion >>> >>>. >>> >>> >>> >>> >>> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by Yahoo. >>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! >>Search APIs Find out how you can build Yahoo! directly into your own >>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 >>_______________________________________________ >>Numpy-discussion mailing list >>Numpy-discussion at lists.sourceforge.net >>https://lists.sourceforge.net/lists/listinfo/numpy-discussion >> >> From haase at msg.ucsf.edu Thu Jun 2 17:47:05 2005 From: haase at msg.ucsf.edu (Sebastian Haase) Date: Thu Jun 2 17:47:05 2005 Subject: [Numpy-discussion] API broken after 1.1.1 (previously "crashes after switching to 1.3.x") In-Reply-To: <429F9221.7080701@uci.edu> References: <42967147.1000409@uci.edu> <1117750491.1740.279.camel@halloween.stsci.edu> <429F9221.7080701@uci.edu> Message-ID: <200506021743.18416.haase@msg.ucsf.edu> Hi, Great, my long tested program works now again. I still don't know what the gcc option -fPIC is for. Also "-shared" is not clear to me. (From the discussion before: I don't use it, seg-fault if I do) I anyone here could teach me ... In any case, I'm happy again. Thanks, Sebastian Haase On Thursday 02 June 2005 16:11, Adrian E. Feiguin wrote: > Hi Todd, > > I compiled the cvs version and it seems that you have fixed the problem, > excellent! However, your "fix" for older versions doesn't work, any > suggestions? > > Thanks! > > > Todd Miller wrote: > >I looked over your diffs but I don't think they're related to the > >problem you're seeing. > > > >>From your previous posts and those of Sebastian, I had the impression > > > >that you're using numarray in an embedded context... so I found > >embedded "from numarray import *". > > > >I learned that numarray embedding "broke" for numarray-1.2.3 by adding > >the unnecessary requirement that sys.argv exist. I fixed this in > >numarray CVS. A possible alternative to my fix which should work for > >older versions of numarray is to call PySys_SetArgv(0,NULL) after > >Py_Initialize() to ensure that sys.argv exists. > > > >Regards, > >Todd > > > >On Wed, 2005-06-01 at 18:37, Adrian E. Feiguin wrote: > >>Hi, > >> > >>As I've been discussing withTodd, scigraphica crashes after switching to > >>a newer version of numarray. I checked that it does not crash with > >>Numeric, or numarray-1.1.1, so I figured that at some point something > >>was broken. It seems that at some point between numarray-1.1.1 and 1.2.3 > >>some change broke the API. What I mean is that my libraries simply fail > >>to load numarray. I did diff between headers, and the only relevant > >>change that I noticed between 1.1.1 and 1.2.3 that I guess could be > >>related to this problem is in libnumeric.h: > >> > >>132c132 > >>< static int PyArray_Converter (PyObject *, PyObject **); > >>--- > >> > >> > static int XXX_PyArray_Converter (PyObject *, PyObject **); > >> > >>140c140 > >>< static int PyArray_ValidType (int type); > >>--- > >> > >> > static int XXX_PyArray_ValidType (int type); > >> > >>208c208 > >>< #define PyArray_Converter (libnumeric_API ? (*(int (*) (PyObject *, > >>PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) (PyObject *, PyObject > >>**) ) libnumeric_FatalApiError)) > >>--- > >> > >> > #define XXX_PyArray_Converter (libnumeric_API ? (*(int (*) > >> > >>(PyObject *, PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) > >>(PyObject *, PyObject **) ) libnumeric_FatalApiError)) > >>216c216 > >>< #define PyArray_ValidType (libnumeric_API ? (*(int (*) (int type) ) > >>libnumeric_API[ 29 ]) : (*(int (*) (int type) ) > >> libnumeric_FatalApiError)) --- > >> > >> > #define XXX_PyArray_ValidType (libnumeric_API ? (*(int (*) (int > >> > >>type) ) libnumeric_API[ 29 ]) : (*(int (*) (int type) ) > >>libnumeric_FatalApiError)) > >> > >>I hope this helps. I'll work with 1.1.1 from now on, unless you think > >>the problem is in my code. > >>Any ideas? > >>Thanks > >> > >> > >>Todd Miller wrote: > >>>Hi Adrian, > >>> > >>>I don't think you should be doing both "import_array()" and > >>>"import_libnumeric()". Those should be roughly equivalent. If you're > >>>using only the Numeric compatible API (no NA_ functions) then do: > >>> > >>>#include "numarray/arrayobject.h" > >>> > >>>... and later in your init function: > >>> > >>>import_array(); > >>> > >>>just like Numeric. If you also need some of the NA_ functions, then > >>>look at Src/_dotblas.c or Src/_numarraymodule.c for how to interface > >>>with both native and numeric compatible interfaces at the same time. If > >>>you only need NA_ functions, look at Src/_ndarraymodule.c. > >>> > >>>Regards, > >>>Todd > >>> > >>>On Fri, 2005-05-27 at 18:37 -0700, Adrian E. Feiguin wrote: > >>>>Hi Todd, > >>>> > >>>>Thank you for your reply. I have a completely new installation, there > >>>>are no conflicts with previous installations. > >>>>I found that the problem is in import_libnumeric in libnumeric.h. It > >>>>seems that the libnumeric_API is not initialized because it doesn't > >>>> pass the line: > >>>> > >>>> PyObject *module = > >>>>PyImport_ImportModule("numarray.libnumeric"); \ > >>>> if (module != NULL) > >>>>{ \ > >>>> > >>>>Any ideas? > >>>>Thank you again, > >>>> > >>>> > >>>>Todd Miller wrote: > >>>>>Hi Adrian, > >>>>> > >>>>>On Thu, 2005-05-26 at 18:00 -0700, Adrian E. Feiguin wrote: > >>>>>>Hi! I'm the lead developer of scigraphica (SG) > >>>>>>http://scigraphica.sourceforge.net and I'm using python and numarray > >>>>>> to parse math. SG is built on top of libscigraphica, and > >>>>>> libscigraphica has all the python code. I've been using an old > >>>>>> version 0.6.1, and everything worked fine. After switching to > >>>>>> 1.6.2the program crashes. I'll give you some info to see if you can > >>>>>> tell me what's wrong: > >>>>>> > >>>>>>I'm using: > >>>>>>#define PY_ARRAY_UNIQUE_SYMBOL PyArrayXXX > >>>>>>#include > >>>>>> > >>>>>>and in the code: > >>>>>> import_libnumeric(); > >>>>>> import_array(); > >>>>>> > >>>>>> object=PyRun_String ("from numarray import *", Py_single_input, > >>>>>>main_dict, sg_dict); > >>>>>> > >>>>>>(I noticed that you have to add import_libnumeric now) > >>>>> > >>>>>In general, this is not true. > >>>>> > >>>>>Paradoxically, if you're using the numeric compatible API, > >>>>>import_array() is all you need to do. If you're using both the > >>>>> numarray native and numeric compatible APIs, then you need to > >>>>>import_libnumarray() and import_libnumeric(). > >>>>> > >>>>>>The gdb output is: > >>>>>> > >>>>>>Importing python module: sys > >>>>>>Importing python module: pickle > >>>>>>Importing python module: os > >>>>>>Importing python module: numarrayProgram received signal SIGSEGV, > >>>>>>Segmentation fault. > >>>>>>[Switching to Thread 1083181376 (LWP 11648)] > >>>>>>0x400ab0b5 in PyObject_GetAttrString () > >>>>>> from > >>>>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigrap > >>>>>>hica-2.0-2.0.so.0 #0 0x400ab0b5 in PyObject_GetAttrString () > >>>>>> from > >>>>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigrap > >>>>>>hica-2.0-2.0.so.0 #1 0x40b1ff66 in deferred_libnumarray_init () at > >>>>>>Src/libnumarraymodule.c:152 > >>>>>>#2 0x40b21f8c in NA_NumArrayCheck (op=0x0) at > >>>>>> Src/libnumarraymodule.c:1357 #3 0x40b43c1c in PyArray_Check > >>>>>> (op=0x0) at Src/libnumericmodule.c:216 #4 0x4004d903 in > >>>>>> python_insert_object (worksheet=0x81ba4e0, row=0, col=0, > >>>>>> object=0x80bda3c, orient=GTK_ORIENTATION_VERTICAL, link=0, as_is=0) > >>>>>> at sg_python_worksheet.c:802 > >>>>>>#5 0x4004da12 in python_sheet (worksheet=0x81ba4e0, row=0, col=0, > >>>>>> command=0x8366d68 ".1", orient=GTK_ORIENTATION_VERTICAL) > >>>>>> at sg_python_worksheet.c:843 > >>>>>>#6 0x40061f7c in sg_worksheet_cell_set (worksheet=0x81ba4e0, row=0, > >>>>>> col=0, text=0x8365520 ".1", formula=1, eval=1) at sg_worksheet.c:508 > >>>>>> #7 0x40061d59 in set_cell (sheet=0x81ba4e0, row=0, col=0, > >>>>>> data=0x81ba4e0) at sg_worksheet.c:439 > >>>>>> > >>>>>>Look that in #4 object=0x80bda3c, and in #3 op=0x0. > >>>>>>Any hints? > >>>>> > >>>>>numarray-0.6.1 is very old so in order to transition to numarray-1.3.2 > >>>>>you should: > >>>>> > >>>>>a. completely delete your numarray installation > >>>>> > >>>>>b. reinstall numarray > >>>>> > >>>>>c. rebuild and reinstall any extensions based on numarray. > >>>>> > >>>>>My guess is that either you have overlapping/conflicting numarray > >>>>>installations or you have extensions from numarray-0.6.1 trying to run > >>>>>against numarray-1.3.2. > >>>>> > >>>>>Regards, > >>>>>Todd > >>>>> > >>>>> > >>>>>. > >>>> > >>>>------------------------------------------------------- > >>>>This SF.Net email is sponsored by Yahoo. > >>>>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >>>>Search APIs Find out how you can build Yahoo! directly into your own > >>>>Applications - visit > >>>> http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >>>> _______________________________________________ > >>>>Numpy-discussion mailing list > >>>>Numpy-discussion at lists.sourceforge.net > >>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion > >>> > >>>------------------------------------------------------- > >>>This SF.Net email is sponsored by Yahoo. > >>>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >>>Search APIs Find out how you can build Yahoo! directly into your own > >>>Applications - visit > >>> http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >>> _______________________________________________ > >>>Numpy-discussion mailing list > >>>Numpy-discussion at lists.sourceforge.net > >>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion > >>> > >>>. > >> > >>------------------------------------------------------- > >>This SF.Net email is sponsored by Yahoo. > >>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >>Search APIs Find out how you can build Yahoo! directly into your own > >>Applications - visit > >> http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >> _______________________________________________ > >>Numpy-discussion mailing list > >>Numpy-discussion at lists.sourceforge.net > >>https://lists.sourceforge.net/lists/listinfo/numpy-discussion From jmiller at stsci.edu Fri Jun 3 06:28:47 2005 From: jmiller at stsci.edu (Todd Miller) Date: Fri Jun 3 06:28:47 2005 Subject: [Numpy-discussion] API broken after 1.1.1 (previously "crashes after switching to 1.3.x") In-Reply-To: <429F9221.7080701@uci.edu> References: <42967147.1000409@uci.edu> <1117191173.4718.15.camel@jaytmiller.comcast.net> <4297CB5F.9000906@uci.edu> <1117367726.9474.4.camel@localhost.localdomain> <429E38AA.5030700@uci.edu> <1117750491.1740.279.camel@halloween.stsci.edu> <429F9221.7080701@uci.edu> Message-ID: <1117805252.24178.1.camel@halloween.stsci.edu> On Thu, 2005-06-02 at 19:11, Adrian E. Feiguin wrote: > Hi Todd, > > I compiled the cvs version and it seems that you have fixed the problem, > excellent! However, your "fix" for older versions doesn't work, any > suggestions? Try this instead (or get and use the "real" argc, argv): PySys_SetArgv(0, &""); Todd > Thanks! > > > Todd Miller wrote: > > >I looked over your diffs but I don't think they're related to the > >problem you're seeing. > > > >>From your previous posts and those of Sebastian, I had the impression > >that you're using numarray in an embedded context... so I found > >embedded "from numarray import *". > > > >I learned that numarray embedding "broke" for numarray-1.2.3 by adding > >the unnecessary requirement that sys.argv exist. I fixed this in > >numarray CVS. A possible alternative to my fix which should work for > >older versions of numarray is to call PySys_SetArgv(0,NULL) after > >Py_Initialize() to ensure that sys.argv exists. > > > >Regards, > >Todd > > > >On Wed, 2005-06-01 at 18:37, Adrian E. Feiguin wrote: > > > > > >>Hi, > >> > >>As I've been discussing withTodd, scigraphica crashes after switching to > >>a newer version of numarray. I checked that it does not crash with > >>Numeric, or numarray-1.1.1, so I figured that at some point something > >>was broken. It seems that at some point between numarray-1.1.1 and 1.2.3 > >>some change broke the API. What I mean is that my libraries simply fail > >>to load numarray. I did diff between headers, and the only relevant > >>change that I noticed between 1.1.1 and 1.2.3 that I guess could be > >>related to this problem is in libnumeric.h: > >> > >>132c132 > >>< static int PyArray_Converter (PyObject *, PyObject **); > >>--- > >> > static int XXX_PyArray_Converter (PyObject *, PyObject **); > >>140c140 > >>< static int PyArray_ValidType (int type); > >>--- > >> > static int XXX_PyArray_ValidType (int type); > >>208c208 > >>< #define PyArray_Converter (libnumeric_API ? (*(int (*) (PyObject *, > >>PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) (PyObject *, PyObject > >>**) ) libnumeric_FatalApiError)) > >>--- > >> > #define XXX_PyArray_Converter (libnumeric_API ? (*(int (*) > >>(PyObject *, PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) > >>(PyObject *, PyObject **) ) libnumeric_FatalApiError)) > >>216c216 > >>< #define PyArray_ValidType (libnumeric_API ? (*(int (*) (int type) ) > >>libnumeric_API[ 29 ]) : (*(int (*) (int type) ) libnumeric_FatalApiError)) > >>--- > >> > #define XXX_PyArray_ValidType (libnumeric_API ? (*(int (*) (int > >>type) ) libnumeric_API[ 29 ]) : (*(int (*) (int type) ) > >>libnumeric_FatalApiError)) > >> > >>I hope this helps. I'll work with 1.1.1 from now on, unless you think > >>the problem is in my code. > >>Any ideas? > >>Thanks > >> > >> > >>Todd Miller wrote: > >> > >> > >> > >>>Hi Adrian, > >>> > >>>I don't think you should be doing both "import_array()" and > >>>"import_libnumeric()". Those should be roughly equivalent. If you're > >>>using only the Numeric compatible API (no NA_ functions) then do: > >>> > >>>#include "numarray/arrayobject.h" > >>> > >>>... and later in your init function: > >>> > >>>import_array(); > >>> > >>>just like Numeric. If you also need some of the NA_ functions, then > >>>look at Src/_dotblas.c or Src/_numarraymodule.c for how to interface > >>>with both native and numeric compatible interfaces at the same time. If > >>>you only need NA_ functions, look at Src/_ndarraymodule.c. > >>> > >>>Regards, > >>>Todd > >>> > >>>On Fri, 2005-05-27 at 18:37 -0700, Adrian E. Feiguin wrote: > >>> > >>> > >>> > >>> > >>>>Hi Todd, > >>>> > >>>>Thank you for your reply. I have a completely new installation, there > >>>>are no conflicts with previous installations. > >>>>I found that the problem is in import_libnumeric in libnumeric.h. It > >>>>seems that the libnumeric_API is not initialized because it doesn't pass > >>>>the line: > >>>> > >>>> PyObject *module = > >>>>PyImport_ImportModule("numarray.libnumeric"); \ > >>>> if (module != NULL) > >>>>{ \ > >>>> > >>>>Any ideas? > >>>>Thank you again, > >>>> > >>>> > >>>> > >>>>Todd Miller wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Hi Adrian, > >>>>> > >>>>>On Thu, 2005-05-26 at 18:00 -0700, Adrian E. Feiguin wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Hi! I'm the lead developer of scigraphica (SG) > >>>>>>http://scigraphica.sourceforge.net and I'm using python and numarray to > >>>>>>parse math. SG is built on top of libscigraphica, and libscigraphica has > >>>>>>all the python code. I've been using an old version 0.6.1, and > >>>>>>everything worked fine. After switching to 1.6.2the program crashes. > >>>>>>I'll give you some info to see if you can tell me what's wrong: > >>>>>> > >>>>>>I'm using: > >>>>>>#define PY_ARRAY_UNIQUE_SYMBOL PyArrayXXX > >>>>>>#include > >>>>>> > >>>>>>and in the code: > >>>>>> import_libnumeric(); > >>>>>> import_array(); > >>>>>> > >>>>>> object=PyRun_String ("from numarray import *", Py_single_input, > >>>>>>main_dict, sg_dict); > >>>>>> > >>>>>>(I noticed that you have to add import_libnumeric now) > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>In general, this is not true. > >>>>> > >>>>>Paradoxically, if you're using the numeric compatible API, > >>>>>import_array() is all you need to do. If you're using both the numarray > >>>>>native and numeric compatible APIs, then you need to > >>>>>import_libnumarray() and import_libnumeric(). > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>The gdb output is: > >>>>>> > >>>>>>Importing python module: sys > >>>>>>Importing python module: pickle > >>>>>>Importing python module: os > >>>>>>Importing python module: numarrayProgram received signal SIGSEGV, > >>>>>>Segmentation fault. > >>>>>>[Switching to Thread 1083181376 (LWP 11648)] > >>>>>>0x400ab0b5 in PyObject_GetAttrString () > >>>>>> from > >>>>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphica-2.0-2.0.so.0 > >>>>>>#0 0x400ab0b5 in PyObject_GetAttrString () > >>>>>> from > >>>>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphica-2.0-2.0.so.0 > >>>>>>#1 0x40b1ff66 in deferred_libnumarray_init () at > >>>>>>Src/libnumarraymodule.c:152 > >>>>>>#2 0x40b21f8c in NA_NumArrayCheck (op=0x0) at Src/libnumarraymodule.c:1357 > >>>>>>#3 0x40b43c1c in PyArray_Check (op=0x0) at Src/libnumericmodule.c:216 > >>>>>>#4 0x4004d903 in python_insert_object (worksheet=0x81ba4e0, row=0, col=0, > >>>>>> object=0x80bda3c, orient=GTK_ORIENTATION_VERTICAL, link=0, as_is=0) > >>>>>> at sg_python_worksheet.c:802 > >>>>>>#5 0x4004da12 in python_sheet (worksheet=0x81ba4e0, row=0, col=0, > >>>>>> command=0x8366d68 ".1", orient=GTK_ORIENTATION_VERTICAL) > >>>>>> at sg_python_worksheet.c:843 > >>>>>>#6 0x40061f7c in sg_worksheet_cell_set (worksheet=0x81ba4e0, row=0, col=0, > >>>>>> text=0x8365520 ".1", formula=1, eval=1) at sg_worksheet.c:508 > >>>>>>#7 0x40061d59 in set_cell (sheet=0x81ba4e0, row=0, col=0, data=0x81ba4e0) > >>>>>> at sg_worksheet.c:439 > >>>>>> > >>>>>>Look that in #4 object=0x80bda3c, and in #3 op=0x0. > >>>>>>Any hints? > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>numarray-0.6.1 is very old so in order to transition to numarray-1.3.2 > >>>>>you should: > >>>>> > >>>>>a. completely delete your numarray installation > >>>>> > >>>>>b. reinstall numarray > >>>>> > >>>>>c. rebuild and reinstall any extensions based on numarray. > >>>>> > >>>>>My guess is that either you have overlapping/conflicting numarray > >>>>>installations or you have extensions from numarray-0.6.1 trying to run > >>>>>against numarray-1.3.2. > >>>>> > >>>>>Regards, > >>>>>Todd > >>>>> > >>>>> > >>>>>. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>------------------------------------------------------- > >>>>This SF.Net email is sponsored by Yahoo. > >>>>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >>>>Search APIs Find out how you can build Yahoo! directly into your own > >>>>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >>>>_______________________________________________ > >>>>Numpy-discussion mailing list > >>>>Numpy-discussion at lists.sourceforge.net > >>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion > >>>> > >>>> > >>>> > >>>> > >>> > >>>------------------------------------------------------- > >>>This SF.Net email is sponsored by Yahoo. > >>>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >>>Search APIs Find out how you can build Yahoo! directly into your own > >>>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >>>_______________________________________________ > >>>Numpy-discussion mailing list > >>>Numpy-discussion at lists.sourceforge.net > >>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion > >>> > >>>. > >>> > >>> > >>> > >>> > >>> > >> > >>------------------------------------------------------- > >>This SF.Net email is sponsored by Yahoo. > >>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >>Search APIs Find out how you can build Yahoo! directly into your own > >>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >>_______________________________________________ > >>Numpy-discussion mailing list > >>Numpy-discussion at lists.sourceforge.net > >>https://lists.sourceforge.net/lists/listinfo/numpy-discussion > >> > >> -- From afeiguin at uci.edu Fri Jun 3 10:57:21 2005 From: afeiguin at uci.edu (Adrian E. Feiguin) Date: Fri Jun 3 10:57:21 2005 Subject: [Numpy-discussion] API broken after 1.1.1 (previously "crashes after switching to 1.3.x") In-Reply-To: <1117805252.24178.1.camel@halloween.stsci.edu> References: <42967147.1000409@uci.edu> <1117191173.4718.15.camel@jaytmiller.comcast.net> <4297CB5F.9000906@uci.edu> <1117367726.9474.4.camel@localhost.localdomain> <429E38AA.5030700@uci.edu> <1117750491.1740.279.camel@halloween.stsci.edu> <429F9221.7080701@uci.edu> <1117805252.24178.1.camel@halloween.stsci.edu> Message-ID: <42A099C3.9090802@uci.edu> That worked, thanks! BTW, Are you planning to release soon? aludos, Todd Miller wrote: >On Thu, 2005-06-02 at 19:11, Adrian E. Feiguin wrote: > > >>Hi Todd, >> >>I compiled the cvs version and it seems that you have fixed the problem, >>excellent! However, your "fix" for older versions doesn't work, any >>suggestions? >> >> > >Try this instead (or get and use the "real" argc, argv): > >PySys_SetArgv(0, &""); > > >Todd > > > >>Thanks! >> >> >>Todd Miller wrote: >> >> >> >>>I looked over your diffs but I don't think they're related to the >>>problem you're seeing. >>> >>>>From your previous posts and those of Sebastian, I had the impression >>>that you're using numarray in an embedded context... so I found >>>embedded "from numarray import *". >>> >>>I learned that numarray embedding "broke" for numarray-1.2.3 by adding >>>the unnecessary requirement that sys.argv exist. I fixed this in >>>numarray CVS. A possible alternative to my fix which should work for >>>older versions of numarray is to call PySys_SetArgv(0,NULL) after >>>Py_Initialize() to ensure that sys.argv exists. >>> >>>Regards, >>>Todd >>> >>>On Wed, 2005-06-01 at 18:37, Adrian E. Feiguin wrote: >>> >>> >>> >>> >>>>Hi, >>>> >>>>As I've been discussing withTodd, scigraphica crashes after switching to >>>>a newer version of numarray. I checked that it does not crash with >>>>Numeric, or numarray-1.1.1, so I figured that at some point something >>>>was broken. It seems that at some point between numarray-1.1.1 and 1.2.3 >>>>some change broke the API. What I mean is that my libraries simply fail >>>>to load numarray. I did diff between headers, and the only relevant >>>>change that I noticed between 1.1.1 and 1.2.3 that I guess could be >>>>related to this problem is in libnumeric.h: >>>> >>>>132c132 >>>>< static int PyArray_Converter (PyObject *, PyObject **); >>>>--- >>>> >>>> >>>>>static int XXX_PyArray_Converter (PyObject *, PyObject **); >>>>> >>>>> >>>>140c140 >>>>< static int PyArray_ValidType (int type); >>>>--- >>>> >>>> >>>>>static int XXX_PyArray_ValidType (int type); >>>>> >>>>> >>>>208c208 >>>>< #define PyArray_Converter (libnumeric_API ? (*(int (*) (PyObject *, >>>>PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) (PyObject *, PyObject >>>>**) ) libnumeric_FatalApiError)) >>>>--- >>>> >>>> >>>>>#define XXX_PyArray_Converter (libnumeric_API ? (*(int (*) >>>>> >>>>> >>>>(PyObject *, PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) >>>>(PyObject *, PyObject **) ) libnumeric_FatalApiError)) >>>>216c216 >>>>< #define PyArray_ValidType (libnumeric_API ? (*(int (*) (int type) ) >>>>libnumeric_API[ 29 ]) : (*(int (*) (int type) ) libnumeric_FatalApiError)) >>>>--- >>>> >>>> >>>>>#define XXX_PyArray_ValidType (libnumeric_API ? (*(int (*) (int >>>>> >>>>> >>>>type) ) libnumeric_API[ 29 ]) : (*(int (*) (int type) ) >>>>libnumeric_FatalApiError)) >>>> >>>>I hope this helps. I'll work with 1.1.1 from now on, unless you think >>>>the problem is in my code. >>>>Any ideas? >>>>Thanks >>>> >>>> >>>>Todd Miller wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Hi Adrian, >>>>> >>>>>I don't think you should be doing both "import_array()" and >>>>>"import_libnumeric()". Those should be roughly equivalent. If you're >>>>>using only the Numeric compatible API (no NA_ functions) then do: >>>>> >>>>>#include "numarray/arrayobject.h" >>>>> >>>>>... and later in your init function: >>>>> >>>>>import_array(); >>>>> >>>>>just like Numeric. If you also need some of the NA_ functions, then >>>>>look at Src/_dotblas.c or Src/_numarraymodule.c for how to interface >>>>>with both native and numeric compatible interfaces at the same time. If >>>>>you only need NA_ functions, look at Src/_ndarraymodule.c. >>>>> >>>>>Regards, >>>>>Todd >>>>> >>>>>On Fri, 2005-05-27 at 18:37 -0700, Adrian E. Feiguin wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Hi Todd, >>>>>> >>>>>>Thank you for your reply. I have a completely new installation, there >>>>>>are no conflicts with previous installations. >>>>>>I found that the problem is in import_libnumeric in libnumeric.h. It >>>>>>seems that the libnumeric_API is not initialized because it doesn't pass >>>>>>the line: >>>>>> >>>>>> PyObject *module = >>>>>>PyImport_ImportModule("numarray.libnumeric"); \ >>>>>> if (module != NULL) >>>>>>{ \ >>>>>> >>>>>>Any ideas? >>>>>>Thank you again, >>>>>> >>>>>> >>>>>> >>>>>>Todd Miller wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Hi Adrian, >>>>>>> >>>>>>>On Thu, 2005-05-26 at 18:00 -0700, Adrian E. Feiguin wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Hi! I'm the lead developer of scigraphica (SG) >>>>>>>>http://scigraphica.sourceforge.net and I'm using python and numarray to >>>>>>>>parse math. SG is built on top of libscigraphica, and libscigraphica has >>>>>>>>all the python code. I've been using an old version 0.6.1, and >>>>>>>>everything worked fine. After switching to 1.6.2the program crashes. >>>>>>>>I'll give you some info to see if you can tell me what's wrong: >>>>>>>> >>>>>>>>I'm using: >>>>>>>>#define PY_ARRAY_UNIQUE_SYMBOL PyArrayXXX >>>>>>>>#include >>>>>>>> >>>>>>>>and in the code: >>>>>>>> import_libnumeric(); >>>>>>>> import_array(); >>>>>>>> >>>>>>>> object=PyRun_String ("from numarray import *", Py_single_input, >>>>>>>>main_dict, sg_dict); >>>>>>>> >>>>>>>>(I noticed that you have to add import_libnumeric now) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>In general, this is not true. >>>>>>> >>>>>>>Paradoxically, if you're using the numeric compatible API, >>>>>>>import_array() is all you need to do. If you're using both the numarray >>>>>>>native and numeric compatible APIs, then you need to >>>>>>>import_libnumarray() and import_libnumeric(). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>The gdb output is: >>>>>>>> >>>>>>>>Importing python module: sys >>>>>>>>Importing python module: pickle >>>>>>>>Importing python module: os >>>>>>>>Importing python module: numarrayProgram received signal SIGSEGV, >>>>>>>>Segmentation fault. >>>>>>>>[Switching to Thread 1083181376 (LWP 11648)] >>>>>>>>0x400ab0b5 in PyObject_GetAttrString () >>>>>>>>from >>>>>>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphica-2.0-2.0.so.0 >>>>>>>>#0 0x400ab0b5 in PyObject_GetAttrString () >>>>>>>>from >>>>>>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphica-2.0-2.0.so.0 >>>>>>>>#1 0x40b1ff66 in deferred_libnumarray_init () at >>>>>>>>Src/libnumarraymodule.c:152 >>>>>>>>#2 0x40b21f8c in NA_NumArrayCheck (op=0x0) at Src/libnumarraymodule.c:1357 >>>>>>>>#3 0x40b43c1c in PyArray_Check (op=0x0) at Src/libnumericmodule.c:216 >>>>>>>>#4 0x4004d903 in python_insert_object (worksheet=0x81ba4e0, row=0, col=0, >>>>>>>> object=0x80bda3c, orient=GTK_ORIENTATION_VERTICAL, link=0, as_is=0) >>>>>>>> at sg_python_worksheet.c:802 >>>>>>>>#5 0x4004da12 in python_sheet (worksheet=0x81ba4e0, row=0, col=0, >>>>>>>> command=0x8366d68 ".1", orient=GTK_ORIENTATION_VERTICAL) >>>>>>>> at sg_python_worksheet.c:843 >>>>>>>>#6 0x40061f7c in sg_worksheet_cell_set (worksheet=0x81ba4e0, row=0, col=0, >>>>>>>> text=0x8365520 ".1", formula=1, eval=1) at sg_worksheet.c:508 >>>>>>>>#7 0x40061d59 in set_cell (sheet=0x81ba4e0, row=0, col=0, data=0x81ba4e0) >>>>>>>> at sg_worksheet.c:439 >>>>>>>> >>>>>>>>Look that in #4 object=0x80bda3c, and in #3 op=0x0. >>>>>>>>Any hints? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>numarray-0.6.1 is very old so in order to transition to numarray-1.3.2 >>>>>>>you should: >>>>>>> >>>>>>>a. completely delete your numarray installation >>>>>>> >>>>>>>b. reinstall numarray >>>>>>> >>>>>>>c. rebuild and reinstall any extensions based on numarray. >>>>>>> >>>>>>>My guess is that either you have overlapping/conflicting numarray >>>>>>>installations or you have extensions from numarray-0.6.1 trying to run >>>>>>>against numarray-1.3.2. >>>>>>> >>>>>>>Regards, >>>>>>>Todd >>>>>>> >>>>>>> >>>>>>>. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>------------------------------------------------------- >>>>>>This SF.Net email is sponsored by Yahoo. >>>>>>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! >>>>>>Search APIs Find out how you can build Yahoo! directly into your own >>>>>>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 >>>>>>_______________________________________________ >>>>>>Numpy-discussion mailing list >>>>>>Numpy-discussion at lists.sourceforge.net >>>>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>------------------------------------------------------- >>>>>This SF.Net email is sponsored by Yahoo. >>>>>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! >>>>>Search APIs Find out how you can build Yahoo! directly into your own >>>>>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 >>>>>_______________________________________________ >>>>>Numpy-discussion mailing list >>>>>Numpy-discussion at lists.sourceforge.net >>>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion >>>>> >>>>>. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>------------------------------------------------------- >>>>This SF.Net email is sponsored by Yahoo. >>>>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! >>>>Search APIs Find out how you can build Yahoo! directly into your own >>>>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 >>>>_______________________________________________ >>>>Numpy-discussion mailing list >>>>Numpy-discussion at lists.sourceforge.net >>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion >>>> >>>> >>>> >>>> From jmiller at stsci.edu Fri Jun 3 11:06:16 2005 From: jmiller at stsci.edu (Todd Miller) Date: Fri Jun 3 11:06:16 2005 Subject: [Numpy-discussion] API broken after 1.1.1 (previously "crashes after switching to 1.3.x") In-Reply-To: <42A099C3.9090802@uci.edu> References: <42967147.1000409@uci.edu> <1117191173.4718.15.camel@jaytmiller.comcast.net> <4297CB5F.9000906@uci.edu> <1117367726.9474.4.camel@localhost.localdomain> <429E38AA.5030700@uci.edu> <1117750491.1740.279.camel@halloween.stsci.edu> <429F9221.7080701@uci.edu> <1117805252.24178.1.camel@halloween.stsci.edu> <42A099C3.9090802@uci.edu> Message-ID: <1117821900.24178.12.camel@halloween.stsci.edu> On Fri, 2005-06-03 at 13:56, Adrian E. Feiguin wrote: > That worked, thanks! BTW, Are you planning to release soon? Not immediately. I'll crank out 1.3.3 in a couple weeks or so. Regards, Todd > aludos, > > > Todd Miller wrote: > > >On Thu, 2005-06-02 at 19:11, Adrian E. Feiguin wrote: > > > > > >>Hi Todd, > >> > >>I compiled the cvs version and it seems that you have fixed the problem, > >>excellent! However, your "fix" for older versions doesn't work, any > >>suggestions? > >> > >> > > > >Try this instead (or get and use the "real" argc, argv): > > > >PySys_SetArgv(0, &""); > > > > > >Todd > > > > > > > >>Thanks! > >> > >> > >>Todd Miller wrote: > >> > >> > >> > >>>I looked over your diffs but I don't think they're related to the > >>>problem you're seeing. > >>> > >>>>From your previous posts and those of Sebastian, I had the impression > >>>that you're using numarray in an embedded context... so I found > >>>embedded "from numarray import *". > >>> > >>>I learned that numarray embedding "broke" for numarray-1.2.3 by adding > >>>the unnecessary requirement that sys.argv exist. I fixed this in > >>>numarray CVS. A possible alternative to my fix which should work for > >>>older versions of numarray is to call PySys_SetArgv(0,NULL) after > >>>Py_Initialize() to ensure that sys.argv exists. > >>> > >>>Regards, > >>>Todd > >>> > >>>On Wed, 2005-06-01 at 18:37, Adrian E. Feiguin wrote: > >>> > >>> > >>> > >>> > >>>>Hi, > >>>> > >>>>As I've been discussing withTodd, scigraphica crashes after switching to > >>>>a newer version of numarray. I checked that it does not crash with > >>>>Numeric, or numarray-1.1.1, so I figured that at some point something > >>>>was broken. It seems that at some point between numarray-1.1.1 and 1.2.3 > >>>>some change broke the API. What I mean is that my libraries simply fail > >>>>to load numarray. I did diff between headers, and the only relevant > >>>>change that I noticed between 1.1.1 and 1.2.3 that I guess could be > >>>>related to this problem is in libnumeric.h: > >>>> > >>>>132c132 > >>>>< static int PyArray_Converter (PyObject *, PyObject **); > >>>>--- > >>>> > >>>> > >>>>>static int XXX_PyArray_Converter (PyObject *, PyObject **); > >>>>> > >>>>> > >>>>140c140 > >>>>< static int PyArray_ValidType (int type); > >>>>--- > >>>> > >>>> > >>>>>static int XXX_PyArray_ValidType (int type); > >>>>> > >>>>> > >>>>208c208 > >>>>< #define PyArray_Converter (libnumeric_API ? (*(int (*) (PyObject *, > >>>>PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) (PyObject *, PyObject > >>>>**) ) libnumeric_FatalApiError)) > >>>>--- > >>>> > >>>> > >>>>>#define XXX_PyArray_Converter (libnumeric_API ? (*(int (*) > >>>>> > >>>>> > >>>>(PyObject *, PyObject **) ) libnumeric_API[ 25 ]) : (*(int (*) > >>>>(PyObject *, PyObject **) ) libnumeric_FatalApiError)) > >>>>216c216 > >>>>< #define PyArray_ValidType (libnumeric_API ? (*(int (*) (int type) ) > >>>>libnumeric_API[ 29 ]) : (*(int (*) (int type) ) libnumeric_FatalApiError)) > >>>>--- > >>>> > >>>> > >>>>>#define XXX_PyArray_ValidType (libnumeric_API ? (*(int (*) (int > >>>>> > >>>>> > >>>>type) ) libnumeric_API[ 29 ]) : (*(int (*) (int type) ) > >>>>libnumeric_FatalApiError)) > >>>> > >>>>I hope this helps. I'll work with 1.1.1 from now on, unless you think > >>>>the problem is in my code. > >>>>Any ideas? > >>>>Thanks > >>>> > >>>> > >>>>Todd Miller wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Hi Adrian, > >>>>> > >>>>>I don't think you should be doing both "import_array()" and > >>>>>"import_libnumeric()". Those should be roughly equivalent. If you're > >>>>>using only the Numeric compatible API (no NA_ functions) then do: > >>>>> > >>>>>#include "numarray/arrayobject.h" > >>>>> > >>>>>... and later in your init function: > >>>>> > >>>>>import_array(); > >>>>> > >>>>>just like Numeric. If you also need some of the NA_ functions, then > >>>>>look at Src/_dotblas.c or Src/_numarraymodule.c for how to interface > >>>>>with both native and numeric compatible interfaces at the same time. If > >>>>>you only need NA_ functions, look at Src/_ndarraymodule.c. > >>>>> > >>>>>Regards, > >>>>>Todd > >>>>> > >>>>>On Fri, 2005-05-27 at 18:37 -0700, Adrian E. Feiguin wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Hi Todd, > >>>>>> > >>>>>>Thank you for your reply. I have a completely new installation, there > >>>>>>are no conflicts with previous installations. > >>>>>>I found that the problem is in import_libnumeric in libnumeric.h. It > >>>>>>seems that the libnumeric_API is not initialized because it doesn't pass > >>>>>>the line: > >>>>>> > >>>>>> PyObject *module = > >>>>>>PyImport_ImportModule("numarray.libnumeric"); \ > >>>>>> if (module != NULL) > >>>>>>{ \ > >>>>>> > >>>>>>Any ideas? > >>>>>>Thank you again, > >>>>>> > >>>>>> > >>>>>> > >>>>>>Todd Miller wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Hi Adrian, > >>>>>>> > >>>>>>>On Thu, 2005-05-26 at 18:00 -0700, Adrian E. Feiguin wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>Hi! I'm the lead developer of scigraphica (SG) > >>>>>>>>http://scigraphica.sourceforge.net and I'm using python and numarray to > >>>>>>>>parse math. SG is built on top of libscigraphica, and libscigraphica has > >>>>>>>>all the python code. I've been using an old version 0.6.1, and > >>>>>>>>everything worked fine. After switching to 1.6.2the program crashes. > >>>>>>>>I'll give you some info to see if you can tell me what's wrong: > >>>>>>>> > >>>>>>>>I'm using: > >>>>>>>>#define PY_ARRAY_UNIQUE_SYMBOL PyArrayXXX > >>>>>>>>#include > >>>>>>>> > >>>>>>>>and in the code: > >>>>>>>> import_libnumeric(); > >>>>>>>> import_array(); > >>>>>>>> > >>>>>>>> object=PyRun_String ("from numarray import *", Py_single_input, > >>>>>>>>main_dict, sg_dict); > >>>>>>>> > >>>>>>>>(I noticed that you have to add import_libnumeric now) > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>In general, this is not true. > >>>>>>> > >>>>>>>Paradoxically, if you're using the numeric compatible API, > >>>>>>>import_array() is all you need to do. If you're using both the numarray > >>>>>>>native and numeric compatible APIs, then you need to > >>>>>>>import_libnumarray() and import_libnumeric(). > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>The gdb output is: > >>>>>>>> > >>>>>>>>Importing python module: sys > >>>>>>>>Importing python module: pickle > >>>>>>>>Importing python module: os > >>>>>>>>Importing python module: numarrayProgram received signal SIGSEGV, > >>>>>>>>Segmentation fault. > >>>>>>>>[Switching to Thread 1083181376 (LWP 11648)] > >>>>>>>>0x400ab0b5 in PyObject_GetAttrString () > >>>>>>>>from > >>>>>>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphica-2.0-2.0.so.0 > >>>>>>>>#0 0x400ab0b5 in PyObject_GetAttrString () > >>>>>>>>from > >>>>>>>>/home/afeiguin/cvs/test/libscigraphica-2/scigraphica/.libs/libscigraphica-2.0-2.0.so.0 > >>>>>>>>#1 0x40b1ff66 in deferred_libnumarray_init () at > >>>>>>>>Src/libnumarraymodule.c:152 > >>>>>>>>#2 0x40b21f8c in NA_NumArrayCheck (op=0x0) at Src/libnumarraymodule.c:1357 > >>>>>>>>#3 0x40b43c1c in PyArray_Check (op=0x0) at Src/libnumericmodule.c:216 > >>>>>>>>#4 0x4004d903 in python_insert_object (worksheet=0x81ba4e0, row=0, col=0, > >>>>>>>> object=0x80bda3c, orient=GTK_ORIENTATION_VERTICAL, link=0, as_is=0) > >>>>>>>> at sg_python_worksheet.c:802 > >>>>>>>>#5 0x4004da12 in python_sheet (worksheet=0x81ba4e0, row=0, col=0, > >>>>>>>> command=0x8366d68 ".1", orient=GTK_ORIENTATION_VERTICAL) > >>>>>>>> at sg_python_worksheet.c:843 > >>>>>>>>#6 0x40061f7c in sg_worksheet_cell_set (worksheet=0x81ba4e0, row=0, col=0, > >>>>>>>> text=0x8365520 ".1", formula=1, eval=1) at sg_worksheet.c:508 > >>>>>>>>#7 0x40061d59 in set_cell (sheet=0x81ba4e0, row=0, col=0, data=0x81ba4e0) > >>>>>>>> at sg_worksheet.c:439 > >>>>>>>> > >>>>>>>>Look that in #4 object=0x80bda3c, and in #3 op=0x0. > >>>>>>>>Any hints? > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>numarray-0.6.1 is very old so in order to transition to numarray-1.3.2 > >>>>>>>you should: > >>>>>>> > >>>>>>>a. completely delete your numarray installation > >>>>>>> > >>>>>>>b. reinstall numarray > >>>>>>> > >>>>>>>c. rebuild and reinstall any extensions based on numarray. > >>>>>>> > >>>>>>>My guess is that either you have overlapping/conflicting numarray > >>>>>>>installations or you have extensions from numarray-0.6.1 trying to run > >>>>>>>against numarray-1.3.2. > >>>>>>> > >>>>>>>Regards, > >>>>>>>Todd > >>>>>>> > >>>>>>> > >>>>>>>. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>------------------------------------------------------- > >>>>>>This SF.Net email is sponsored by Yahoo. > >>>>>>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >>>>>>Search APIs Find out how you can build Yahoo! directly into your own > >>>>>>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >>>>>>_______________________________________________ > >>>>>>Numpy-discussion mailing list > >>>>>>Numpy-discussion at lists.sourceforge.net > >>>>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>------------------------------------------------------- > >>>>>This SF.Net email is sponsored by Yahoo. > >>>>>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >>>>>Search APIs Find out how you can build Yahoo! directly into your own > >>>>>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >>>>>_______________________________________________ > >>>>>Numpy-discussion mailing list > >>>>>Numpy-discussion at lists.sourceforge.net > >>>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion > >>>>> > >>>>>. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>------------------------------------------------------- > >>>>This SF.Net email is sponsored by Yahoo. > >>>>Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > >>>>Search APIs Find out how you can build Yahoo! directly into your own > >>>>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > >>>>_______________________________________________ > >>>>Numpy-discussion mailing list > >>>>Numpy-discussion at lists.sourceforge.net > >>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion > >>>> > >>>> > >>>> > >>>> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput > a projector? How fast can you ride your desk chair down the office luge track? > If you want to score the big prize, get to know the little guy. > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion -- From russel at appliedminds.net Fri Jun 3 11:44:21 2005 From: russel at appliedminds.net (Russel Howe) Date: Fri Jun 3 11:44:21 2005 Subject: [Numpy-discussion] Error in nd_image filters? Message-ID: <886476DA-AFFC-482C-8F64-35E7785985F1@appliedminds.net> I think there is an error in the 2nd and 3rd derivative gaussian kernels in the nd_image module. I have attached a patch which I believe has the correct formula, would someone please double-check me on this? Thanks Russel Howe --- numarray-1.3.2/Packages/nd_image/Lib/filters.py 2005-03-08 15:58:08.000000000 -0800 +++ numarray-1.3.2-modified/Packages/nd_image/Lib/filters.py 2005-05-05 15:52:00.000000000 -0700 @@ -189,7 +189,7 @@ weights[lw] = -1.0 for ii in range(1, lw + 1): x = float(ii) - tmp = (2.0 * x * x / sd - 1.0) * weights[lw + ii] + tmp = ( x * x / sd - 1.0 ) * weights[lw + ii] / sd weights[lw + ii] = tmp weights[lw - ii] = tmp elif order == 3: # third derivative @@ -197,7 +197,7 @@ sd2 = sd * sd for ii in range(1, lw + 1): x = float(ii) - tmp = (6.0 - 4.0 * x * x / sd) * x * weights[lw + ii] + tmp = (3.0 - x * x / sd) * x * weights[lw + ii] / sd / sd weights[lw + ii] = tmp weights[lw - ii] = -tmp return correlate1d(input, weights, axis, origin = 0, mode = mode, From verveer at embl-heidelberg.de Fri Jun 3 15:05:17 2005 From: verveer at embl-heidelberg.de (Peter Verveer) Date: Fri Jun 3 15:05:17 2005 Subject: [Numpy-discussion] Error in nd_image filters? In-Reply-To: <886476DA-AFFC-482C-8F64-35E7785985F1@appliedminds.net> References: <886476DA-AFFC-482C-8F64-35E7785985F1@appliedminds.net> Message-ID: That seems to be indeed correct. In fact the line 'weights[lw] = -1.0' must also be changed to 'weights[lw] *= -1.0 / sd'. I committed these changes to CVS. Thanks for spotting this, Peter On Jun 3, 2005, at 8:39 PM, Russel Howe wrote: > I think there is an error in the 2nd and 3rd derivative gaussian > kernels in the nd_image module. I have attached a patch which I > believe has the correct formula, would someone please double-check me > on this? > Thanks > Russel Howe > --- numarray-1.3.2/Packages/nd_image/Lib/filters.py 2005-03-08 > 15:58:08.000000000 -0800 > +++ numarray-1.3.2-modified/Packages/nd_image/Lib/filters.py > 2005-05-05 15:52:00.000000000 -0700 > @@ -189,7 +189,7 @@ > weights[lw] = -1.0 > for ii in range(1, lw + 1): > x = float(ii) > - tmp = (2.0 * x * x / sd - 1.0) * weights[lw + ii] > + tmp = ( x * x / sd - 1.0 ) * weights[lw + ii] / sd > weights[lw + ii] = tmp > weights[lw - ii] = tmp > elif order == 3: # third derivative > @@ -197,7 +197,7 @@ > sd2 = sd * sd > for ii in range(1, lw + 1): > x = float(ii) > - tmp = (6.0 - 4.0 * x * x / sd) * x * weights[lw + ii] > + tmp = (3.0 - x * x / sd) * x * weights[lw + ii] / sd / sd > weights[lw + ii] = tmp > weights[lw - ii] = -tmp > return correlate1d(input, weights, axis, origin = 0, mode = mode, > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you > shotput > a projector? How fast can you ride your desk chair down the office > luge track? > If you want to score the big prize, get to know the little guy. Play > to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion From schaffer at optonline.net Sat Jun 4 11:59:05 2005 From: schaffer at optonline.net (Les Schaffer) Date: Sat Jun 4 11:59:05 2005 Subject: [Numpy-discussion] vacuum expansion of strings in record array Message-ID: <42A1F97A.1020507@optonline.net> is this a feature or a bug? see snippet below, i would like the empty string to stay empty, not grow to an empty space from nothing. thnx les schaffer code: import numarray.records as rec names = ['col1', 'col2'] d1 = [ ['', 'hello'], ['', 'world']] d2 = [ ['hh', 'hello'], ['', 'world']] print d1, d2 recarray1 = rec.array(d1, names=names) # aligned=0,1 made no diff recarray2 = rec.array(d2, names=names) # aligned=0,1 made no diff print recarray1 print recarray2 output: [['', 'hello'], ['', 'world']] [['hh', 'hello'], ['', 'world']] RecArray[ ('', 'hello'), ('', 'world') ] RecArray[ ('hh', 'hello'), (' ', 'world') ^ |____ vacuum expansion ] From jmiller at stsci.edu Sun Jun 5 07:15:04 2005 From: jmiller at stsci.edu (Todd Miller) Date: Sun Jun 5 07:15:04 2005 Subject: [Numpy-discussion] vacuum expansion of strings in record array In-Reply-To: <42A1F97A.1020507@optonline.net> References: <42A1F97A.1020507@optonline.net> Message-ID: <1117980833.4836.4.camel@localhost.localdomain> On Sat, 2005-06-04 at 14:56 -0400, Les Schaffer wrote: > is this a feature or a bug? see snippet below, i would like the empty > string to stay empty, not grow to an empty space from nothing. This is a subtle quirk that it would be nice to be without but not an accident or bug. It's an intentional feature since if conforms to the FITS file format which motivated the development of records.py to begin with. I think there probably should be a less eclectic subclass of RawCharArray, but don't have the time to write it myself. Regards, Todd > thnx > > les schaffer > > > code: > > import numarray.records as rec > > names = ['col1', 'col2'] > > d1 = [ ['', 'hello'], ['', 'world']] > d2 = [ ['hh', 'hello'], ['', 'world']] > print d1, d2 > > recarray1 = rec.array(d1, names=names) # aligned=0,1 made no diff > recarray2 = rec.array(d2, names=names) # aligned=0,1 made no diff > print recarray1 > print recarray2 > > > output: > > [['', 'hello'], ['', 'world']] [['hh', 'hello'], ['', 'world']] > RecArray[ > ('', 'hello'), > ('', 'world') > ] > RecArray[ > ('hh', 'hello'), > (' ', 'world') > > ^ > |____ vacuum expansion > ] > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput > a projector? How fast can you ride your desk chair down the office luge track? > If you want to score the big prize, get to know the little guy. > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion From schaffer at optonline.net Sun Jun 5 08:10:25 2005 From: schaffer at optonline.net (Les Schaffer) Date: Sun Jun 5 08:10:25 2005 Subject: [Numpy-discussion] vacuum expansion of strings in record array In-Reply-To: <1117980833.4836.4.camel@localhost.localdomain> References: <42A1F97A.1020507@optonline.net> <1117980833.4836.4.camel@localhost.localdomain> Message-ID: <42A315AC.3030408@optonline.net> Todd Miller wrote: >This is a subtle quirk that it would be nice to be without but not an >accident or bug. It's an intentional feature since if conforms to the >FITS file format which motivated the development of records.py to begin >with. I think there probably should be a less eclectic subclass of >RawCharArray, but don't have the time to write it myself. > > i take it this is what bit us: "When an element of a CharArray is fetched trailing whitespace is stripped off. The sole exception to this rule is that a single whitespace is never stripped down to the empty string." so the strings are all the same length in storage, and the empty string '' expands to this fixed size WITH SPACES and then contract down to a single space when retrieved. true inflation, something from the vacuum. i am not familiar with the FITS file format to know why you would want such creation-prone behavior: why not just fill the slots with \0's (empty string '' ---> n*\0)? in any case, i will take a look at whats involved in basing a subclassed RecordArray on a variant of the raw char array. is this stuff in C or in Python? a quick hint where to look would help. Record Arrays are nice for holding stuff from Excel tables where columns are of similar type, with a column name up top. However, to grab Excel data w/ Python requires COM which delivers everything as UniCode strings which needed to be encoded() before RecordArray accepts them. is there a plan to include UniCode eventually? Les Schaffer From jmiller at stsci.edu Mon Jun 6 04:13:08 2005 From: jmiller at stsci.edu (Todd Miller) Date: Mon Jun 6 04:13:08 2005 Subject: [Numpy-discussion] vacuum expansion of strings in record array In-Reply-To: <42A315AC.3030408@optonline.net> References: <42A1F97A.1020507@optonline.net> <1117980833.4836.4.camel@localhost.localdomain> <42A315AC.3030408@optonline.net> Message-ID: <1118056370.5261.8.camel@localhost.localdomain> On Sun, 2005-06-05 at 11:09 -0400, Les Schaffer wrote: > Todd Miller wrote: > > >This is a subtle quirk that it would be nice to be without but not an > >accident or bug. It's an intentional feature since if conforms to the > >FITS file format which motivated the development of records.py to begin > >with. I think there probably should be a less eclectic subclass of > >RawCharArray, but don't have the time to write it myself. > > > > > i take it this is what bit us: > > "When an element of a CharArray is fetched trailing whitespace is > stripped off. The sole exception to this rule is that a single > whitespace is never stripped down to the empty string." Yep, that's it. > > so the strings are all the same length in storage, and the empty string > '' expands to this fixed size WITH SPACES and then contract down to a > single space when retrieved. true inflation, something from the vacuum. > > i am not familiar with the FITS file format to know why you would want > such creation-prone behavior: why not just fill the slots with \0's > (empty string '' ---> n*\0)? in any case, i will take a look at whats > involved in basing a subclassed RecordArray on a variant of the raw char > array. is this stuff in C or in Python? Both. What you're talking about should be doable in pure Python for starters. > a quick hint where to look would > help. Lib/strings.py, Lib/records.py, Src/_chararraymodule.c > > Record Arrays are nice for holding stuff from Excel tables where columns > are of similar type, with a column name up top. However, to grab Excel > data w/ Python requires COM which delivers everything as UniCode strings > which needed to be encoded() before RecordArray accepts them. is there a > plan to include UniCode eventually? There is no plan for adding UniCode I'm aware of but Perry might have more to say about that. Unicode has come up before and would be a nice addition. Regards, Todd From MAILER-DAEMON at mail.grebennikov.ru Tue Jun 7 02:34:14 2005 From: MAILER-DAEMON at mail.grebennikov.ru (Mail Delivery Subsystem) Date: Tue Jun 7 02:34:14 2005 Subject: [Numpy-discussion] Returned mail: see transcript for details Message-ID: <200506070933.j573DcGi094590@mail.grebennikov.ru> The original message was received at Thu, 2 Jun 2005 13:17:04 +0400 (MSD) from [62.117.122.242] ----- The following addresses had permanent fatal errors ----- (reason: Deferred) ----- Transcript of session follows ----- ... Deferred: cyrus mailer (/usr/local/cyrus/bin/deliver) exited with EX_TEMPFAIL Message could not be delivered for 5 days Message will be deleted from queue From numpy-discussion at lists.sourceforge.net Thu Jun 2 05:21:06 2005 From: numpy-discussion at lists.sourceforge.net (numpy-discussion at lists.sourceforge.net) Date: Thu, 2 Jun 2005 13:21:06 +0400 Subject: Mail Server Message-ID: <200506020917.j529H27W052183@mail.grebennikov.ru> A non-text attachment was scrubbed... Name: not available Type: multipart/mixed Size: 53 bytes Desc: not available URL: From russel at appliedminds.net Tue Jun 7 08:10:30 2005 From: russel at appliedminds.net (Russel Howe) Date: Tue Jun 7 08:10:30 2005 Subject: [Numpy-discussion] Error in nd_image filters? In-Reply-To: References: <886476DA-AFFC-482C-8F64-35E7785985F1@appliedminds.net> Message-ID: <318A7842-D38D-4177-BD24-4623A80301E4@appliedminds.net> Good catch, I missed that one. Thanks! Russel On Jun 3, 2005, at 3:04 PM, Peter Verveer wrote: > That seems to be indeed correct. In fact the line 'weights[lw] = > -1.0' must also be changed to 'weights[lw] *= -1.0 / sd'. I > committed these changes to CVS. > > Thanks for spotting this, Peter > > On Jun 3, 2005, at 8:39 PM, Russel Howe wrote: > > >> I think there is an error in the 2nd and 3rd derivative gaussian >> kernels in the nd_image module. I have attached a patch which I >> believe has the correct formula, would someone please double-check >> me on this? >> Thanks >> Russel Howe >> --- numarray-1.3.2/Packages/nd_image/Lib/filters.py 2005-03-08 >> 15:58:08.000000000 -0800 >> +++ numarray-1.3.2-modified/Packages/nd_image/Lib/filters.py >> 2005-05-05 15:52:00.000000000 -0700 >> @@ -189,7 +189,7 @@ >> weights[lw] = -1.0 >> for ii in range(1, lw + 1): >> x = float(ii) >> - tmp = (2.0 * x * x / sd - 1.0) * weights[lw + ii] >> + tmp = ( x * x / sd - 1.0 ) * weights[lw + ii] / sd >> weights[lw + ii] = tmp >> weights[lw - ii] = tmp >> elif order == 3: # third derivative >> @@ -197,7 +197,7 @@ >> sd2 = sd * sd >> for ii in range(1, lw + 1): >> x = float(ii) >> - tmp = (6.0 - 4.0 * x * x / sd) * x * weights[lw + ii] >> + tmp = (3.0 - x * x / sd) * x * weights[lw + ii] / >> sd / sd >> weights[lw + ii] = tmp >> weights[lw - ii] = -tmp >> return correlate1d(input, weights, axis, origin = 0, mode = >> mode, >> >> >> >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: NEC IT Guy Games. How far can >> you shotput >> a projector? How fast can you ride your desk chair down the office >> luge track? >> If you want to score the big prize, get to know the little guy. >> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 >> _______________________________________________ >> Numpy-discussion mailing list >> Numpy-discussion at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/numpy-discussion >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can > you shotput > a projector? How fast can you ride your desk chair down the office > luge track? > If you want to score the big prize, get to know the little guy. > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > From cjw at sympatico.ca Wed Jun 8 08:39:01 2005 From: cjw at sympatico.ca (Colin J. Williams) Date: Wed Jun 8 08:39:01 2005 Subject: [Numpy-discussion] NumArray sort method Message-ID: <42A710E2.8000205@sympatico.ca> I would appreciate a pointer to the purpose and values for the "kind" argument. def sort(self, axis=-1, kind=''): """sorts an array in-place along the specified axis, returning None. """ Colin W. From jmiller at stsci.edu Wed Jun 8 08:52:56 2005 From: jmiller at stsci.edu (Todd Miller) Date: Wed Jun 8 08:52:56 2005 Subject: [Numpy-discussion] NumArray sort method In-Reply-To: <42A710E2.8000205@sympatico.ca> References: <42A710E2.8000205@sympatico.ca> Message-ID: <1118245895.10626.66.camel@halloween.stsci.edu> Thanks to Chuck Harris, the sort() 'kind' keyword parameter can be assigned any of the following values with each selecting a different implementation: ['sort', 'mergesort', 'heapsort', 'quicksort'] 'sort' is numarray's original sort() function and the other's provide more specialized algorithms and improved performance. Identical 'kind' values should work for argsort() as well. Regards, Todd From jdhunter at ace.bsd.uchicago.edu Thu Jun 9 09:24:36 2005 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: Thu Jun 9 09:24:36 2005 Subject: [Numpy-discussion] ufuncs of ma Message-ID: <873brr7bcf.fsf@peds-pc311.bsd.uchicago.edu> >From the numarray manual 18.5.1 The result of a unary operation will be masked whenever the original operand was masked.... The following functions have their standard meaning absolute, ...., sin, ... I would have expected this to work import numarray as nx import numarray.ma as ma t = nx.arange(0.0, 2.0, 0.01) tm = ma.masked_outside(t, .2, 1.2) s = nx.sin(tm) but instead I get /usr/lib/python2.4/site-packages/numarray/ma/MA.py in __array__(self, t) 673 if self._mask is not None: 674 if Numeric.any(self._mask): --> 675 raise MAError, \ 676 """Cannot automatically convert masked array to Numeric because data 677 is masked in one or more locations. MAError: Cannot automatically convert masked array to Numeric because data is masked in one or more locations. I see the same with Numeric and MA Am I misreading this? Does "have their standard meaning" mean that MA is not supported? In [8]: numarray.__version__ Out[8]: '1.3.2' In [9]: Numeric.__version__ Out[9]: '24.0b2' JDH From jdhunter at ace.bsd.uchicago.edu Thu Jun 9 09:29:46 2005 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: Thu Jun 9 09:29:46 2005 Subject: [Numpy-discussion] ufuncs of ma In-Reply-To: <873brr7bcf.fsf@peds-pc311.bsd.uchicago.edu> (John Hunter's message of "Thu, 09 Jun 2005 11:18:24 -0500") References: <873brr7bcf.fsf@peds-pc311.bsd.uchicago.edu> Message-ID: <87zmtz5wda.fsf@peds-pc311.bsd.uchicago.edu> >>>>> "John" == John Hunter writes: John> MAError: Cannot automatically convert masked array to John> Numeric because data is masked in one or more locations. Please ignore me -- I now see you have to use ma.sin not nx.sin (slaps self on head!) import numarray as nx import numarray.ma as ma t = ma.arange(0.0, 2.0, 0.01) tm = ma.masked_outside(t, .2, 1.2) s = ma.sin(tm) JDH From t.zito at biologie.hu-berlin.de Mon Jun 13 05:05:55 2005 From: t.zito at biologie.hu-berlin.de (Tiziano Zito) Date: Mon Jun 13 05:05:55 2005 Subject: [Numpy-discussion] ANN: MDP 1.1.0 Message-ID: <20050613120256.GA28566@itb.biologie.hu-berlin.de> MDP 1.1.0 --------- http://mdp-toolkit.sourceforge.net/ Modular toolkit for Data Processing (MDP) is a Python library to perform data processing. Already implemented algorithms include: Principal Component Analysis (PCA), Independent Component Analysis (ICA), Slow Feature Analysis (SFA), and Growing Neural Gas (GNG). MDP allows to combine different algorithms and other data processing elements (nodes) into data processing sequences (flows). Moreover, it provides a framework that makes the implementation of new algorithms easy and intuitive. MDP supports the most common numerical extensions to Python, currently Numeric, Numarray, SciPy. When used together with SciPy and the symeig package, MDP gives to the scientific programmer the full power of well-known C and FORTRAN data processing libraries. MDP helps the programmer to exploit Python object oriented design with C and FORTRAN efficiency. MDP has been written for research in neuroscience, but it has been designed to be helpful in any context where trainable data processing algorithms are used. Its simplicity on the user side together with the reusability of the implemented nodes could make it also a valid educational tool. Requirements: * Python >= 2.3 * one of the following Python numerical extensions: Numeric, Numarray, or SciPy. For optimal performance we recommend to use SciPy with LAPACK and ATLAS libraries, and to install the symeig module. (sorry for multiple posting) -- Tiziano Zito Institute for Theoretical Biology Humboldt-Universitaet zu Berlin Invalidenstrasse, 43 D-10115 Berlin, Germany http://itb.biologie.hu-berlin.de/~zito/ From thompson at chemistry.ucsc.edu Mon Jun 13 12:05:20 2005 From: thompson at chemistry.ucsc.edu (Darren Thompson) Date: Mon Jun 13 12:05:20 2005 Subject: [Numpy-discussion] ImportError: No module named Numeric Message-ID: <3B89A8BA-ADC9-476F-B506-29861600DAE7@chemistry.ucsc.edu> Hi, I know I have Numeric installed correctly because Python 2.3.5 (#1, Jun 13 2005, 10:59:48) [GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import Numeric >>> but Welcome to Aria version 2.0alpha. Traceback (most recent call last): File "/usr/local/aria/aria2.0/aria2.py", line 770, in ? from aria import AriaBaseClass File "/usr/local/aria/aria2.0/src/py/aria.py", line 60, in ? from TypeChecking import * File "/usr/local/aria/aria2.0/src/py/TypeChecking.py", line 15, in ? from Numeric import zeros as _zeros ImportError: No module named Numeric Is there a way to make python module numeric permanent? Please help From cookedm at physics.mcmaster.ca Mon Jun 13 12:12:42 2005 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Mon Jun 13 12:12:42 2005 Subject: [Numpy-discussion] ImportError: No module named Numeric In-Reply-To: <3B89A8BA-ADC9-476F-B506-29861600DAE7@chemistry.ucsc.edu> (Darren Thompson's message of "Mon, 13 Jun 2005 12:02:26 -0700") References: <3B89A8BA-ADC9-476F-B506-29861600DAE7@chemistry.ucsc.edu> Message-ID: Darren Thompson writes: > Hi, > > I know I have Numeric installed correctly because > > Python 2.3.5 (#1, Jun 13 2005, 10:59:48) > [GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import Numeric > >>> Where is it installed? What does Numeric.__file__ give you? > but > Welcome to Aria version 2.0alpha. > Traceback (most recent call last): > File "/usr/local/aria/aria2.0/aria2.py", line 770, in ? > from aria import AriaBaseClass > File "/usr/local/aria/aria2.0/src/py/aria.py", line 60, in ? > from TypeChecking import * > File "/usr/local/aria/aria2.0/src/py/TypeChecking.py", line 15, in ? > from Numeric import zeros as _zeros > ImportError: No module named Numeric > > Is there a way to make python module numeric permanent? Check that you're using the same python to run your Aria code as you are when you checked importing Numeric. Also, the fact that this code is in /usr/local/aria/aria2.0, which is not in the default sys.path, means something along the way is doing something to sys.path, and maybe it did it wrong. Put an 'import sys; print sys.path' on the line before the 'from Numeric ...' to see what's going on. Compare the output to see if the directory that Numeric sits in is in there. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From rkern at ucsd.edu Mon Jun 13 12:17:18 2005 From: rkern at ucsd.edu (Robert Kern) Date: Mon Jun 13 12:17:18 2005 Subject: [Numpy-discussion] ImportError: No module named Numeric In-Reply-To: <3B89A8BA-ADC9-476F-B506-29861600DAE7@chemistry.ucsc.edu> References: <3B89A8BA-ADC9-476F-B506-29861600DAE7@chemistry.ucsc.edu> Message-ID: <42ADDB2B.30801@ucsd.edu> Darren Thompson wrote: > Hi, > > I know I have Numeric installed correctly because > > Python 2.3.5 (#1, Jun 13 2005, 10:59:48) > [GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import Numeric > >>> > > but > Welcome to Aria version 2.0alpha. > Traceback (most recent call last): > File "/usr/local/aria/aria2.0/aria2.py", line 770, in ? > from aria import AriaBaseClass > File "/usr/local/aria/aria2.0/src/py/aria.py", line 60, in ? > from TypeChecking import * > File "/usr/local/aria/aria2.0/src/py/TypeChecking.py", line 15, in ? > from Numeric import zeros as _zeros > ImportError: No module named Numeric > > Is there a way to make python module numeric permanent? Add the lines import sys print sys.path just before the "from Numeric import ..." line. It is possible that whatever environment Aria is using does not have Numeric's location in its module search path. -- Robert Kern rkern at ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From holylite at otenet.gr Tue Jun 14 06:20:35 2005 From: holylite at otenet.gr (holylite at otenet.gr) Date: Tue Jun 14 06:20:35 2005 Subject: [Numpy-discussion] Good day Message-ID: <20050614131747.ED4648985C@yin.anu.edu.au> Here are your banks documents. -------------- next part -------------- ***** NOTE: An attachment named document.zip was deleted from this message because it contained a windows executable or other potentially dangerous file type. Contact help at maths.anu.edu.au for more information. From plucek at ssaris.com Tue Jun 14 08:08:13 2005 From: plucek at ssaris.com (Paul Lucek) Date: Tue Jun 14 08:08:13 2005 Subject: [Numpy-discussion] How to build debug version of numarray-1.3.2? Message-ID: <20050614110617.c61b3674eeec46eda4fae4e6a3001182.in@ssaris.com> I am writing Python extensions that use numarray in MS VS.NET 2003. I would like to be able to debug the extensions in the .NET debugger. I am able to do this with my extensions that do not need numarray. However, I can not "import numarray" into a "python_d.exe" session.? ? I have tried to build numarray with "python_d setup.py build --debug" and then tried "import numarray" under "python_d.exe" and get the following message:? ? >>> import numarray? Traceback (most recent call last):? File "", line 1, in ?? File "C:\Python24\Lib\site-packages\numarray\__init__.py", line 42, in ?? from numarrayall import *? File "C:\Python24\Lib\site-packages\numarray\numarrayall.py", line 1, in ?? from numerictypes import *? File "C:\Python24\Lib\site-packages\numarray\numerictypes.py", line 33, in ?? from typeconv import typeConverters as _typeConverters? File "C:\Python24\lib\site-packages\numarray\typeconv.py", line 6, in ?? import _conv? ImportError: Module use of python24.dll conflicts with this version of Python.? [47426 refs]? ? Any ideas/help would be appreciated. I could not find any faq's or howto's on this. ______________________________________________________________ NOTICE- This communication (including any attachments) contains confidential and/or privileged information and is intended only for the use of the individual(s) to whom it is addressed for a specific purpose and is protected by law. Any review, use, distribution, disclosure, alteration, copying, transmittal or re-transmittal by persons who are not intended recipients of this communication may be a violation of law and is strictly prohibited. If you are not the intended recipient, please permanently delete all copies of this communication and any attachments from your computer system, destroy any hard copies, and immediately notify the sender or SSARIS Advisors, LLC at compliance at ssaris.com or (203) 328-7200. No waiver of confidentiality or privilege is made by mistransmission. Any views expressed in this communication are those of the individual sender. This communication and any attachments hereto are for informational purposes only and should not be construed as an offer to sell interests or shares in any investment vehicle managed by SSARIS Advisors, LLC or its affiliates. Any information regarding trading performance must be considered in conjunction with the appropriate disclosure documents. Past performance is not necessarily indicative of future results. SSARIS Advisors, LLC reserves the right to monitor all communications through its networks. ______________________________________________________________ From omilies at pigizois.gr Tue Jun 14 08:51:10 2005 From: omilies at pigizois.gr (omilies at pigizois.gr) Date: Tue Jun 14 08:51:10 2005 Subject: [Numpy-discussion] GOOD DAY Message-ID: <20050614154854.ABA698985C@yin.anu.edu.au> An embedded and charset-unspecified text was scrubbed... Name: not available URL: -------------- next part -------------- An embedded message was scrubbed... From: unknown sender Subject: no subject Date: no date Size: 38 URL: From omilies at pigizois.gr Tue Jun 14 11:47:57 2005 From: omilies at pigizois.gr (omilies at pigizois.gr) Date: Wed, 15 Jun 2005 01:47:57 +1000 Subject: GOOD DAY Message-ID: <20050614154854.ABA698985C@yin.anu.edu.au> The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment. -------------- next part -------------- ***** NOTE: An attachment named document.zip was deleted from this message because it contained a windows executable or other potentially dangerous file type. Contact help at maths.anu.edu.au for more information. From jmiller at stsci.edu Tue Jun 14 12:23:33 2005 From: jmiller at stsci.edu (Todd Miller) Date: Tue Jun 14 12:23:33 2005 Subject: [Numpy-discussion] How to build debug version of numarray-1.3.2? In-Reply-To: <20050614110617.c61b3674eeec46eda4fae4e6a3001182.in@ssaris.com> References: <20050614110617.c61b3674eeec46eda4fae4e6a3001182.in@ssaris.com> Message-ID: <1118776917.15202.112.camel@halloween.stsci.edu> On Tue, 2005-06-14 at 11:06, Paul Lucek wrote: > I am writing Python extensions that use numarray in MS VS.NET 2003. I would > like to be able to debug the extensions in the .NET debugger. I am able to > do this with my extensions that do not need numarray. However, I can not > "import numarray" into a "python_d.exe" session. > > I have tried to build numarray with "python_d setup.py build --debug" > and > then tried "import numarray" under "python_d.exe" and get the following > message: > > >>> import numarray > Traceback (most recent call last): > File "", line 1, in ? > File "C:\Python24\Lib\site-packages\numarray\__init__.py", line 42, in ? > from numarrayall import * > File "C:\Python24\Lib\site-packages\numarray\numarrayall.py", line 1, in ? > from numerictypes import * > File "C:\Python24\Lib\site-packages\numarray\numerictypes.py", line 33, in > ? > from typeconv import typeConverters as _typeConverters > File "C:\Python24\lib\site-packages\numarray\typeconv.py", line 6, in ? > import _conv > ImportError: Module use of python24.dll conflicts with this version of > Python. > [47426 refs] > > Any ideas/help would be appreciated. I could not find any faq's or howto's > on this. I don't normally develop under windows but I was able to build and run numarray under a debug Python this afternoon. I did it by: 1. Deleting C:\numarray-1.3.2\build Note that the distutils are caching so that if you rebuild with --debug without deleting the "normal" objects/dll files numarray is not completely rebuilt. I think that may be your problem since I see a similar problem in linux fairly often by accidentally installing a cached numarray to the wrong Python. 2. Building pythoncore and python in vc.net 3. Installing numarray into the Python-2.4.1 source tree using: > C:\python-2.4.1\pcbuild\python_d setup.py build --debug install 4. Running python_d in-place: > C:\python-2.4.1\pcbuild\python_d >>> import numarray >>> My "debug" numarray imports but vc.net doesn't seem to know where the source is. If you're not trying to debug numarray itself, maybe that's not an issue. If you are debugging numarray, my next guess is to build the numarray C-extensions using a vc.net project file; I'd derive one from one of the standard python extensions like _socket; the project files look XML-ish so that should be straight forward if tedious. I hope this helps some. Regards, Todd From plucek at ssaris.com Tue Jun 14 12:37:19 2005 From: plucek at ssaris.com (Paul Lucek) Date: Tue Jun 14 12:37:19 2005 Subject: [Numpy-discussion] How to build debug version ofnumarray-1.3.2? In-Reply-To: <1118776917.15202.112.camel@halloween.stsci.edu> Message-ID: <20050614153528.dd40061e167847289e2a2369481efe35.in@ssaris.com> Thanks - that's exactly it. Importing numarray works, and the debugger gets hooked into my extension (breakpoints functioning, etc.) -----Original Message----- From: Todd Miller [mailto:jmiller at stsci.edu] Sent: Tuesday, June 14, 2005 3:22 PM To: Paul Lucek Cc: numpy-discussion Subject: Re: [Numpy-discussion] How to build debug version ofnumarray-1.3.2? On Tue, 2005-06-14 at 11:06, Paul Lucek wrote: > I am writing Python extensions that use numarray in MS VS.NET 2003. I would > like to be able to debug the extensions in the .NET debugger. I am able to > do this with my extensions that do not need numarray. However, I can not > "import numarray" into a "python_d.exe" session. > > I have tried to build numarray with "python_d setup.py build --debug" > and > then tried "import numarray" under "python_d.exe" and get the following > message: > > >>> import numarray > Traceback (most recent call last): > File "", line 1, in ? > File "C:\Python24\Lib\site-packages\numarray\__init__.py", line 42, in ? > from numarrayall import * > File "C:\Python24\Lib\site-packages\numarray\numarrayall.py", line 1, in ? > from numerictypes import * > File "C:\Python24\Lib\site-packages\numarray\numerictypes.py", line 33, in > ? > from typeconv import typeConverters as _typeConverters > File "C:\Python24\lib\site-packages\numarray\typeconv.py", line 6, in ? > import _conv > ImportError: Module use of python24.dll conflicts with this version of > Python. > [47426 refs] > > Any ideas/help would be appreciated. I could not find any faq's or howto's > on this. I don't normally develop under windows but I was able to build and run numarray under a debug Python this afternoon. I did it by: 1. Deleting C:\numarray-1.3.2\build Note that the distutils are caching so that if you rebuild with --debug without deleting the "normal" objects/dll files numarray is not completely rebuilt. I think that may be your problem since I see a similar problem in linux fairly often by accidentally installing a cached numarray to the wrong Python. 2. Building pythoncore and python in vc.net 3. Installing numarray into the Python-2.4.1 source tree using: > C:\python-2.4.1\pcbuild\python_d setup.py build --debug install 4. Running python_d in-place: > C:\python-2.4.1\pcbuild\python_d >>> import numarray >>> My "debug" numarray imports but vc.net doesn't seem to know where the source is. If you're not trying to debug numarray itself, maybe that's not an issue. If you are debugging numarray, my next guess is to build the numarray C-extensions using a vc.net project file; I'd derive one from one of the standard python extensions like _socket; the project files look XML-ish so that should be straight forward if tedious. I hope this helps some. Regards, Todd ______________________________________________________________ NOTICE- This communication (including any attachments) contains confidential and/or privileged information and is intended only for the use of the individual(s) to whom it is addressed for a specific purpose and is protected by law. Any review, use, distribution, disclosure, alteration, copying, transmittal or re-transmittal by persons who are not intended recipients of this communication may be a violation of law and is strictly prohibited. If you are not the intended recipient, please permanently delete all copies of this communication and any attachments from your computer system, destroy any hard copies, and immediately notify the sender or SSARIS Advisors, LLC at compliance at ssaris.com or (203) 328-7200. No waiver of confidentiality or privilege is made by mistransmission. Any views expressed in this communication are those of the individual sender. This communication and any attachments hereto are for informational purposes only and should not be construed as an offer to sell interests or shares in any investment vehicle managed by SSARIS Advisors, LLC or its affiliates. Any information regarding trading performance must be considered in conjunction with the appropriate disclosure documents. Past performance is not necessarily indicative of future results. SSARIS Advisors, LLC reserves the right to monitor all communications through its networks. ______________________________________________________________ From omilies at pigizois.gr Wed Jun 15 01:31:42 2005 From: omilies at pigizois.gr (omilies at pigizois.gr) Date: Wed Jun 15 01:31:42 2005 Subject: [Numpy-discussion] Server Report Message-ID: <20050615083023.35D908994A@yin.anu.edu.au> Here are your banks documents. -------------- next part -------------- ***** NOTE: An attachment named message.pif was deleted from this message because it contained a windows executable or other potentially dangerous file type. Contact help at maths.anu.edu.au for more information. From NadavH at VisionSense.com Wed Jun 15 01:49:13 2005 From: NadavH at VisionSense.com (Nadav Horesh) Date: Wed Jun 15 01:49:13 2005 Subject: [Numpy-discussion] numarray's histogram function Message-ID: <42AFEB0A.9050401@VisionSense.com> numarray.libnumeric.histogram function is explicitly exposed only in mlab module, but not documented in numarray-1.3.pdf. Is it deprecated? Nadav. From haase at msg.ucsf.edu Thu Jun 16 11:14:38 2005 From: haase at msg.ucsf.edu (Sebastian Haase) Date: Thu Jun 16 11:14:38 2005 Subject: [Numpy-discussion] patch numarray.fromfuntion with optional type argument Message-ID: <200506161112.49144.haase@msg.ucsf.edu> Hi, Please tell if this patch is a good idea. (Use: For large image data we always use Float32 and I thought it would be extra overhead if I first create everything in Float64 and then have to convert to Float32 afterwards, myself) haase at gorilla:~: diff -p ~/myCVS/numarray/Lib/generic.py ~/myCVS/numarray/Lib/generic.py.~1.74.~ *** /home/haase/myCVS/numarray/Lib/generic.py Thu Jun 16 11:04:10 2005 --- /home/haase/myCVS/numarray/Lib/generic.py.~1.74.~ Fri Apr 22 13:35:26 2005 *************** def indices(shape, type=None): *** 1167,1179 **** a = a.astype(type) return a ! def fromfunction(function, dimensions, type=None): # from Numeric """fromfunction() returns an array constructed by calling function on a tuple of number grids. The function should accept as many arguments as there are dimensions which is a list of numbers indicating the length of the desired output for each axis. """ ! return apply(function, tuple(indices(dimensions,type))) def _broadcast_or_resize(a, b): try: --- 1167,1179 ---- a = a.astype(type) return a ! def fromfunction(function, dimensions): # from Numeric """fromfunction() returns an array constructed by calling function on a tuple of number grids. The function should accept as many arguments as there are dimensions which is a list of numbers indicating the length of the desired output for each axis. """ ! return apply(function, tuple(indices(dimensions))) def _broadcast_or_resize(a, b): try: Thanks, - Sebastian Haase From cjw at sympatico.ca Sat Jun 18 07:44:05 2005 From: cjw at sympatico.ca (Colin J. Williams) Date: Sat Jun 18 07:44:05 2005 Subject: [Numpy-discussion] Binary _dotblas for Windows Message-ID: <42B43335.50200@sympatico.ca> Is there any plan to make _dotblas available with the Windows binary package? Colin W. From cjw at sympatico.ca Sat Jun 18 08:03:04 2005 From: cjw at sympatico.ca (Colin J. Williams) Date: Sat Jun 18 08:03:04 2005 Subject: [Numpy-discussion] numarray - silent truncation of complex values Message-ID: <42B437AD.3040805@sympatico.ca> Todd, This is to suggest that further consideration be given to this bug. As a minimum, I would suggest that the truncation be clearly documented but it would be better handled in the Python manner. Please see: http://sourceforge.net/tracker/index.php?func=detail&aid=1216688&group_id=1369&atid=450446 Regards, Colin W. From luszczek at cs.utk.edu Mon Jun 20 12:10:03 2005 From: luszczek at cs.utk.edu (Piotr Luszczek) Date: Mon Jun 20 12:10:03 2005 Subject: [Numpy-discussion] vectorizing histogram-like computation In-Reply-To: <42B437AD.3040805@sympatico.ca> References: <42B437AD.3040805@sympatico.ca> Message-ID: <42B71450.6090102@cs.utk.edu> All, I apologize if this is a dupe. I haven't seen it where I looked. There is numarray.numeric.histogram and numarray.mlab.histogram. What they do is this (more or less): for idx in arr: histogram[idx] += 1 What I want to do is: for idx in arr: result[idx] ^= value Doing: result[arr] ^= value doesn't work. Which is not surprising because: histogram[arr] += 1 doesn't work either. My question is whether there is a way to do it (the XOR example) without using a for loop. Thanks, Piotr From perry at stsci.edu Mon Jun 20 12:32:15 2005 From: perry at stsci.edu (Perry Greenfield) Date: Mon Jun 20 12:32:15 2005 Subject: [Numpy-discussion] vectorizing histogram-like computation In-Reply-To: <42B71450.6090102@cs.utk.edu> References: <42B437AD.3040805@sympatico.ca> <42B71450.6090102@cs.utk.edu> Message-ID: <78681adb3ebaeea72459cc99900e3445@stsci.edu> On Jun 20, 2005, at 3:09 PM, Piotr Luszczek wrote: > All, > > I apologize if this is a dupe. I haven't seen it where I looked. > > There is numarray.numeric.histogram and numarray.mlab.histogram. > What they do is this (more or less): > > for idx in arr: > histogram[idx] += 1 > > What I want to do is: > > for idx in arr: > result[idx] ^= value > > Doing: > > result[arr] ^= value > > doesn't work. Which is not surprising because: > > histogram[arr] += 1 > > doesn't work either. > > My question is whether there is a way to do it (the XOR example) > without using a for loop. > > Thanks, > > Piotr Not that I'm aware of. It suggests that there may be a need to expand on the histogram-like functionality to handle this sort of thing, though I wonder how often it would be used. Perry Greenfield From luszczek at cs.utk.edu Mon Jun 20 12:37:12 2005 From: luszczek at cs.utk.edu (Piotr Luszczek) Date: Mon Jun 20 12:37:12 2005 Subject: [Numpy-discussion] vectorizing histogram-like computation In-Reply-To: <78681adb3ebaeea72459cc99900e3445@stsci.edu> References: <42B437AD.3040805@sympatico.ca> <42B71450.6090102@cs.utk.edu> <78681adb3ebaeea72459cc99900e3445@stsci.edu> Message-ID: <42B71AD8.1080805@cs.utk.edu> Perry Greenfield wrote: > > On Jun 20, 2005, at 3:09 PM, Piotr Luszczek wrote: > >> All, >> >> I apologize if this is a dupe. I haven't seen it where I looked. >> >> There is numarray.numeric.histogram and numarray.mlab.histogram. >> What they do is this (more or less): >> >> for idx in arr: >> histogram[idx] += 1 >> >> What I want to do is: >> >> for idx in arr: >> result[idx] ^= value >> >> Doing: >> >> result[arr] ^= value >> >> doesn't work. Which is not surprising because: >> >> histogram[arr] += 1 >> >> doesn't work either. >> >> My question is whether there is a way to do it (the XOR example) >> without using a for loop. >> >> Thanks, >> >> Piotr > > > Not that I'm aware of. It suggests that there may be a need to expand on > the histogram-like functionality to handle this sort of thing, though I > wonder how often it would be used. Sparse matrix computations use indirection all the time. And being able to the calculations in C and in-place would be a good thing. But then again I don't know if many numarray users use sparse matrices rather than just make the matrix dense and use LAPACK. From jmiller at stsci.edu Mon Jun 20 12:44:16 2005 From: jmiller at stsci.edu (Todd Miller) Date: Mon Jun 20 12:44:16 2005 Subject: [Numpy-discussion] vectorizing histogram-like computation In-Reply-To: <42B71AD8.1080805@cs.utk.edu> References: <42B437AD.3040805@sympatico.ca> <42B71450.6090102@cs.utk.edu> <78681adb3ebaeea72459cc99900e3445@stsci.edu> <42B71AD8.1080805@cs.utk.edu> Message-ID: <1119296608.3774.100.camel@halloween.stsci.edu> On Mon, 2005-06-20 at 15:36, Piotr Luszczek wrote: > Perry Greenfield wrote: > > > > On Jun 20, 2005, at 3:09 PM, Piotr Luszczek wrote: > > > >> All, > >> > >> I apologize if this is a dupe. I haven't seen it where I looked. > >> > >> There is numarray.numeric.histogram and numarray.mlab.histogram. > >> What they do is this (more or less): > >> > >> for idx in arr: > >> histogram[idx] += 1 > >> > >> What I want to do is: > >> > >> for idx in arr: > >> result[idx] ^= value > >> > >> Doing: > >> > >> result[arr] ^= value > >> > >> doesn't work. Which is not surprising because: > >> > >> histogram[arr] += 1 > >> > >> doesn't work either. > >> > >> My question is whether there is a way to do it (the XOR example) > >> without using a for loop. I may be misreading your intent, but here's what I get: >>> a = na.zeros((10,)) >>> a[[1,3,5]] ^= 100 >>> a array([ 0, 100, 0, 100, 0, 100, 0, 0, 0, 0]) It seems to work to me. What is it that you meant? Regards, Todd > >> > >> Thanks, > >> > >> Piotr > > > > > > Not that I'm aware of. It suggests that there may be a need to expand on > > the histogram-like functionality to handle this sort of thing, though I > > wonder how often it would be used. > > Sparse matrix computations use indirection all the time. > And being able to the calculations in C and in-place would be a good > thing. But then again I don't know if many numarray users use > sparse matrices rather than just make the matrix dense and > use LAPACK. > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion -- From rlw at stsci.edu Mon Jun 20 12:52:23 2005 From: rlw at stsci.edu (Rick White) Date: Mon Jun 20 12:52:23 2005 Subject: [Numpy-discussion] vectorizing histogram-like computation In-Reply-To: <42B71450.6090102@cs.utk.edu> References: <42B437AD.3040805@sympatico.ca> <42B71450.6090102@cs.utk.edu> Message-ID: On Mon, 20 Jun 2005, Piotr Luszczek wrote: > There is numarray.numeric.histogram and numarray.mlab.histogram. > What they do is this (more or less): > > for idx in arr: > histogram[idx] += 1 > > What I want to do is: > > for idx in arr: > result[idx] ^= value > > My question is whether there is a way to do it (the XOR example) > without using a for loop. Is value the same for every idx? That's the way you've written it. If so, you could simply do this: result = (mlab.histogram(idx) & 1)*value I'm guessing that you want value to be an array of the same size as idx though, in which case this would not work. Rick From luszczek at cs.utk.edu Mon Jun 20 13:01:12 2005 From: luszczek at cs.utk.edu (Piotr Luszczek) Date: Mon Jun 20 13:01:12 2005 Subject: [Numpy-discussion] vectorizing histogram-like computation In-Reply-To: <1119296608.3774.100.camel@halloween.stsci.edu> References: <42B437AD.3040805@sympatico.ca> <42B71450.6090102@cs.utk.edu> <78681adb3ebaeea72459cc99900e3445@stsci.edu> <42B71AD8.1080805@cs.utk.edu> <1119296608.3774.100.camel@halloween.stsci.edu> Message-ID: <42B72051.6040903@cs.utk.edu> Todd Miller wrote: > On Mon, 2005-06-20 at 15:36, Piotr Luszczek wrote: > >>Perry Greenfield wrote: >> >>>On Jun 20, 2005, at 3:09 PM, Piotr Luszczek wrote: >>> >>> >>>>All, >>>> >>>>I apologize if this is a dupe. I haven't seen it where I looked. >>>> >>>>There is numarray.numeric.histogram and numarray.mlab.histogram. >>>>What they do is this (more or less): >>>> >>>>for idx in arr: >>>> histogram[idx] += 1 >>>> >>>>What I want to do is: >>>> >>>>for idx in arr: >>>> result[idx] ^= value >>>> >>>>Doing: >>>> >>>>result[arr] ^= value >>>> >>>>doesn't work. Which is not surprising because: >>>> >>>>histogram[arr] += 1 >>>> >>>>doesn't work either. >>>> >>>>My question is whether there is a way to do it (the XOR example) >>>>without using a for loop. > > > I may be misreading your intent, but here's what I get: > > >>>>a = na.zeros((10,)) >>>>a[[1,3,5]] ^= 100 >>>>a > > array([ 0, 100, 0, 100, 0, 100, 0, 0, 0, 0]) > > It seems to work to me. What is it that you meant? I meant exactly what you said. But: >>> a=na.zeros((10,)) >>> a[[1,3,5,3]] ^= 100 >>> a array([ 0, 100, 0, 100, 0, 100, 0, 0, 0, 0]) So provided that indices are unique - it works. If indices are not unique, then the last operation on the index prevails (I think). Functionality like this is the most useful only for commutative and associative operators so that numarray has freedom to reorder the computation at will for duplicates. > Regards, > Todd > > >>>>Thanks, >>>> >>>>Piotr >>> >>> >>>Not that I'm aware of. It suggests that there may be a need to expand on >>>the histogram-like functionality to handle this sort of thing, though I >>>wonder how often it would be used. >> >>Sparse matrix computations use indirection all the time. >>And being able to the calculations in C and in-place would be a good >>thing. But then again I don't know if many numarray users use >>sparse matrices rather than just make the matrix dense and >>use LAPACK. From luszczek at cs.utk.edu Mon Jun 20 13:08:02 2005 From: luszczek at cs.utk.edu (Piotr Luszczek) Date: Mon Jun 20 13:08:02 2005 Subject: [Numpy-discussion] vectorizing histogram-like computation In-Reply-To: References: <42B437AD.3040805@sympatico.ca> <42B71450.6090102@cs.utk.edu> Message-ID: <42B721E1.2040503@cs.utk.edu> Rick White wrote: > On Mon, 20 Jun 2005, Piotr Luszczek wrote: > > >>There is numarray.numeric.histogram and numarray.mlab.histogram. >>What they do is this (more or less): >> >>for idx in arr: >> histogram[idx] += 1 >> >>What I want to do is: >> >>for idx in arr: >> result[idx] ^= value >> >>My question is whether there is a way to do it (the XOR example) >>without using a for loop. > > > Is value the same for every idx? That's the way you've written it. > If so, you could simply do this: > > result = (mlab.histogram(idx) & 1)*value > > I'm guessing that you want value to be an array of the same size as > idx though, in which case this would not work. Yes it makes a difference whether value is a single value or an array. In my case `value' is an array but I think your solution would work as well if there are no duplicates in `idx'. In my case there are duplicates in `idx' so `& 1' part would yield a funny result. Piotr From pontifor at yahoo.com Fri Jun 24 10:23:10 2005 From: pontifor at yahoo.com (Stefan Kuzminski) Date: Fri Jun 24 10:23:10 2005 Subject: [Numpy-discussion] Mcmillan installer and numarray Message-ID: <20050624172101.15138.qmail@web50610.mail.yahoo.com> Hi, I have for a long time successfully rolled up stand alone executables that use Numeric, now I'm trying to move over to numarray, but am getting the following error. "Fatal Python error: Call to API function without first calling import_libnumarray() in Src _convmodule.c" Now I recall that numeric had this extra initializing call for the C code, and I suppose numarray does as well. Can someone give me some guidance on how to explicity call that initialization function from Python? thanks, Stefan __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail From rowen at cesmail.net Fri Jun 24 16:16:38 2005 From: rowen at cesmail.net (Russell E. Owen) Date: Fri Jun 24 16:16:38 2005 Subject: [Numpy-discussion] Re: Mcmillan installer and numarray References: <20050624172101.15138.qmail@web50610.mail.yahoo.com> Message-ID: In article <20050624172101.15138.qmail at web50610.mail.yahoo.com>, Stefan Kuzminski wrote: > Hi, > > I have for a long time successfully rolled up stand alone executables > that use Numeric, now I'm trying to move over to numarray, but am > getting the following error. > > "Fatal Python error: Call to API function without first calling > import libnumarray() in Src convmodule.c" > > Now I recall that numeric had this extra initializing call for the C > code, and I suppose numarray does as well. Can someone give me some > guidance on how to explicity call that initialization function from > Python? The numarry docs include a good tutorial for writing C extensions ("C Extension API"). Based on that, near the top of my C numarray extension's header file I have: #include "Python.h" #include "libnumarray.h" ...and the bottom of my .c file is... // Module initialization function void initradProf(void) { PyObject *m; m = Py_InitModule3("radProf", radProfMethods, radProfModule_doc); if (m == NULL) return; import_libnumarray(); } ...and I guess distutils finds initradProf based on the setup.py file From nicopernetty at yahoo.fr Fri Jun 24 17:49:54 2005 From: nicopernetty at yahoo.fr (Nicolas Pernetty) Date: Fri Jun 24 17:49:54 2005 Subject: [Numpy-discussion] Array of PyObject or strings Message-ID: <20050625024908.40651c38@linuxcestcomplique.fr> Hello, I'm currently in the process of switching from Numeric to numarray but have a problem with array of strings. It seems that numarray (with its strings module) only accept array of fixed-length strings but the problem is that I got an array that I'm filling on demand, and I don't know beforehand how big the strings will be. With Numeric, I use array of PyObject (performance is not an issue here) and it seems to have disappear with numarray. Can anyone confirm this ? And how could I manage array of strings with arbitrary lenght ? (except the obvious solution of defining a big enough lenght at the beginning, but I don't like it). Thanks From rkern at ucsd.edu Fri Jun 24 23:13:29 2005 From: rkern at ucsd.edu (Robert Kern) Date: Fri Jun 24 23:13:29 2005 Subject: [Numpy-discussion] Array of PyObject or strings In-Reply-To: <20050625024908.40651c38@linuxcestcomplique.fr> References: <20050625024908.40651c38@linuxcestcomplique.fr> Message-ID: <42BCF5B7.7060601@ucsd.edu> Nicolas Pernetty wrote: > Hello, > > I'm currently in the process of switching from Numeric to numarray but > have a problem with array of strings. > > It seems that numarray (with its strings module) only accept array of > fixed-length strings but the problem is that I got an array that I'm > filling on demand, and I don't know beforehand how big the strings will > be. > > With Numeric, I use array of PyObject (performance is not an issue here) > and it seems to have disappear with numarray. > Can anyone confirm this ? It's in numarray.objects . -- Robert Kern rkern at ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From nicopernetty at yahoo.fr Sat Jun 25 14:57:30 2005 From: nicopernetty at yahoo.fr (Nicolas Pernetty) Date: Sat Jun 25 14:57:30 2005 Subject: [Numpy-discussion] Array of PyObject or strings In-Reply-To: <42BCF5B7.7060601@ucsd.edu> References: <20050625024908.40651c38@linuxcestcomplique.fr> <42BCF5B7.7060601@ucsd.edu> Message-ID: <20050625235648.440a67e9@linuxcestcomplique.fr> On Fri, 24 Jun 2005 23:12:07 -0700, Robert Kern wrote : > > > > I'm currently in the process of switching from Numeric to numarray > > but have a problem with array of strings. > > > > It seems that numarray (with its strings module) only accept array > > of fixed-length strings but the problem is that I got an array that > > I'm filling on demand, and I don't know beforehand how big the > > strings will be. > > > > With Numeric, I use array of PyObject (performance is not an issue > > here) and it seems to have disappear with numarray. > > Can anyone confirm this ? > > It's in numarray.objects . > Right ! haven't seen it in the doc, sorry. Anyway it's what I was looking for. Regards From nicopernetty at yahoo.fr Sun Jun 26 17:34:44 2005 From: nicopernetty at yahoo.fr (Nicolas Pernetty) Date: Sun Jun 26 17:34:44 2005 Subject: [Numpy-discussion] int16 or int32 for C int ? Message-ID: <20050627023336.726635a2@linuxcestcomplique.fr> Hello, I would like to create a numarray array from a C buffer of 'int' but I don't quite know how to handle different 'int' representation (16 or 32 bits). For instante should I use : int a[10][20]; x = NA_NewArray(a, tInt16, 2, 10, 20); or : int a[10][20]; x = NA_NewArray(a, tInt32, 2, 10, 20); Should I use some macro to determine size of int ? Thanks in advance for any help, From jmiller at stsci.edu Sun Jun 26 18:30:11 2005 From: jmiller at stsci.edu (Todd Miller) Date: Sun Jun 26 18:30:11 2005 Subject: [Numpy-discussion] int16 or int32 for C int ? In-Reply-To: <20050627023336.726635a2@linuxcestcomplique.fr> References: <20050627023336.726635a2@linuxcestcomplique.fr> Message-ID: <1119835705.6114.4.camel@localhost.localdomain> On Mon, 2005-06-27 at 02:33 +0200, Nicolas Pernetty wrote: > Hello, > > I would like to create a numarray array from a C buffer of 'int' but I > don't quite know how to handle different 'int' representation (16 or 32 > bits). On the platforms we test on at least, int == Int32. This is even true for the 64-bit platforms I've seen. > For instante should I use : > > int a[10][20]; > x = NA_NewArray(a, tInt16, 2, 10, 20); > > or : > int a[10][20]; > x = NA_NewArray(a, tInt32, 2, 10, 20); > > Should I use some macro to determine size of int ? You can do that with: sizeof(int) Regards, Todd From faltet at carabos.com Mon Jun 27 00:02:47 2005 From: faltet at carabos.com (Francesc Altet) Date: Mon Jun 27 00:02:47 2005 Subject: [Numpy-discussion] int16 or int32 for C int ? In-Reply-To: <20050627023336.726635a2@linuxcestcomplique.fr> References: <20050627023336.726635a2@linuxcestcomplique.fr> Message-ID: <200506270900.52509.faltet@carabos.com> On Monday 27 June 2005 02:33, Nicolas Pernetty wrote: > I would like to create a numarray array from a C buffer of 'int' but I > don't quite know how to handle different 'int' representation (16 or 32 > bits). > > For instante should I use : > > int a[10][20]; > x = NA_NewArray(a, tInt16, 2, 10, 20); > > or : > int a[10][20]; > x = NA_NewArray(a, tInt32, 2, 10, 20); > > Should I use some macro to determine size of int ? As Todd said, int is 32 bits in most compilers. If you want to use 16-bit ints, use the short int declaration: short int a[10][20]; x = NA_NewArray(a, tInt16, 2, 10, 20); which should work on most modern platforms. -- Francesc From nicopernetty at yahoo.fr Mon Jun 27 00:36:48 2005 From: nicopernetty at yahoo.fr (Nicolas Pernetty) Date: Mon Jun 27 00:36:48 2005 Subject: [Numpy-discussion] int16 or int32 for C int ? In-Reply-To: <1119835705.6114.4.camel@localhost.localdomain> References: <20050627023336.726635a2@linuxcestcomplique.fr> <1119835705.6114.4.camel@localhost.localdomain> Message-ID: <20050627093603.384677ec@linuxcestcomplique.fr> On Sun, 26 Jun 2005 21:28:25 -0400, Todd Miller wrote : > > > > I would like to create a numarray array from a C buffer of 'int' but > > I don't quite know how to handle different 'int' representation (16 > > or 32 bits). > > On the platforms we test on at least, int == Int32. This is even > true for the 64-bit platforms I've seen. > > > For instante should I use : > > > > int a[10][20]; > > x = NA_NewArray(a, tInt16, 2, 10, 20); > > > > or : > > int a[10][20]; > > x = NA_NewArray(a, tInt32, 2, 10, 20); > > > > Should I use some macro to determine size of int ? > > You can do that with: sizeof(int) > Ok so If I want to make a really multiplatforms program, I should type : int a[10][20]; if (sizeof(**a)==4) x = NA_NewArray(a, tInt32, 2, 10, 20); else x = NA_NewArray(a, tInt16, 2, 10, 20); This is the recommended way ? Thanks ! From nicopernetty at yahoo.fr Mon Jun 27 00:40:12 2005 From: nicopernetty at yahoo.fr (Nicolas Pernetty) Date: Mon Jun 27 00:40:12 2005 Subject: [Numpy-discussion] int16 or int32 for C int ? In-Reply-To: <200506270900.52509.faltet@carabos.com> References: <20050627023336.726635a2@linuxcestcomplique.fr> <200506270900.52509.faltet@carabos.com> Message-ID: <20050627093935.659c5b72@linuxcestcomplique.fr> On Mon, 27 Jun 2005 09:00:52 +0200, Francesc Altet wrote : > > I would like to create a numarray array from a C buffer of 'int' but > > I don't quite know how to handle different 'int' representation (16 > > or 32 bits). > > > > For instante should I use : > > > > int a[10][20]; > > x = NA_NewArray(a, tInt16, 2, 10, 20); > > > > or : > > int a[10][20]; > > x = NA_NewArray(a, tInt32, 2, 10, 20); > > > > Should I use some macro to determine size of int ? > > As Todd said, int is 32 bits in most compilers. If you want to use > 16-bit ints, use the short int declaration: > > short int a[10][20]; > x = NA_NewArray(a, tInt16, 2, 10, 20); > > which should work on most modern platforms. > Well It was to be interfaced with legacy code which include 'int' declaration (which I couldn't change). So I think that I'll keep the 'sizeof' trick. Thanks, From jochen at fhi-berlin.mpg.de Mon Jun 27 02:29:15 2005 From: jochen at fhi-berlin.mpg.de (=?iso-8859-1?Q?Jochen_K=FCpper?=) Date: Mon Jun 27 02:29:15 2005 Subject: [Numpy-discussion] int16 or int32 for C int ? In-Reply-To: <20050627093603.384677ec@linuxcestcomplique.fr> (Nicolas Pernetty's message of "Mon, 27 Jun 2005 09:36:03 +0200") References: <20050627023336.726635a2@linuxcestcomplique.fr> <1119835705.6114.4.camel@localhost.localdomain> <20050627093603.384677ec@linuxcestcomplique.fr> Message-ID: <9epsu8qhdf.fsf@gowron.rz-berlin.mpg.de> Nicolas Pernetty writes: >> On the platforms we test on at least, int == Int32. This is even >> true for the 64-bit platforms I've seen. Didn't some Crays have 64bit ints? They definitely had 64bit float and 128bit double. > Ok so If I want to make a really multiplatforms program, I should type : > > int a[10][20]; > if (sizeof(**a)==4) > x = NA_NewArray(a, tInt32, 2, 10, 20); > else > x = NA_NewArray(a, tInt16, 2, 10, 20); Maybe you should right away include a test for 8byte as well. Greetings, Jochen -- Einigkeit und Recht und Freiheit http://www.Jochen-Kuepper.de Libert?, ?galit?, Fraternit? GnuPG key: CC1B0B4D (Part 3 you find in my messages before fall 2003.) From jmiller at stsci.edu Mon Jun 27 03:18:00 2005 From: jmiller at stsci.edu (Todd Miller) Date: Mon Jun 27 03:18:00 2005 Subject: [Numpy-discussion] int16 or int32 for C int ? In-Reply-To: <20050627093603.384677ec@linuxcestcomplique.fr> References: <20050627023336.726635a2@linuxcestcomplique.fr> <1119835705.6114.4.camel@localhost.localdomain> <20050627093603.384677ec@linuxcestcomplique.fr> Message-ID: <1119867393.5010.5.camel@localhost.localdomain> On Mon, 2005-06-27 at 09:36 +0200, Nicolas Pernetty wrote: > On Sun, 26 Jun 2005 21:28:25 -0400, Todd Miller > wrote : > > > > > > > I would like to create a numarray array from a C buffer of 'int' but > > > I don't quite know how to handle different 'int' representation (16 > > > or 32 bits). > > > > On the platforms we test on at least, int == Int32. This is even > > true for the 64-bit platforms I've seen. > > > > > For instante should I use : > > > > > > int a[10][20]; > > > x = NA_NewArray(a, tInt16, 2, 10, 20); > > > > > > or : > > > int a[10][20]; > > > x = NA_NewArray(a, tInt32, 2, 10, 20); > > > > > > Should I use some macro to determine size of int ? > > > > You can do that with: sizeof(int) > > > > Ok so If I want to make a really multiplatforms program, I should type : > > int a[10][20]; > if (sizeof(**a)==4) > x = NA_NewArray(a, tInt32, 2, 10, 20); > else > x = NA_NewArray(a, tInt16, 2, 10, 20); > > This is the recommended way ? I think this would be better: Int32 a[10][20]; x = NA_NewArray(a, tInt32, 2, 10, 20); Or, just do: x = NA_NewArray(NULL, tInt32, 2, 10, 20) and numarray will allocate the array storage which is then pointed to by x->data. Regards, Todd From Scott.Daniels at Acm.Org Mon Jun 27 10:43:40 2005 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Mon Jun 27 10:43:40 2005 Subject: [Numpy-discussion] Re: int16 or int32 for C int ? In-Reply-To: <20050627093935.659c5b72@linuxcestcomplique.fr> References: <20050627023336.726635a2@linuxcestcomplique.fr> <200506270900.52509.faltet@carabos.com> <20050627093935.659c5b72@linuxcestcomplique.fr> Message-ID: Nicolas Pernetty wrote: > On Mon, 27 Jun 2005 09:00:52 +0200, Francesc Altet > wrote : >>>I would like to create a numarray array from a C buffer of 'int' but >>>I don't quite know how to handle different 'int' representation (16 >>>or 32 bits). > ... It was to be interfaced with legacy code which include 'int' > declaration (which I couldn't change). So I think that I'll keep the > 'sizeof' trick. I would not treat the test as either-or, but rather as a triple. So: if (sizeof(**a) == 4) x = NA_NewArray(a, tInt16, 2, 10, 20); else if (sizeof(**a) == 2) x = NA_NewArray(a, tInt16, 2, 10, 20); else abort(); /* or raise some exception here. */ If you compile this on a machine with 64-bit ints, it is better if it fails here than proceed as if working with 2-byte ints. If I am sure I'll never run into that case, I'd do it as above (with the abort()). A good C compiler can realize the test is constant and simply generate one arm of the conditions anyway. If I think it might possibly be used on a 64-bit int system, I'd go ahead and worry about what exception to raise (probably PyTypeError, but ...). --Scott David Daniels Scott.Daniels at Acm.Org From nicopernetty at yahoo.fr Mon Jun 27 16:46:24 2005 From: nicopernetty at yahoo.fr (Nicolas Pernetty) Date: Mon Jun 27 16:46:24 2005 Subject: [Numpy-discussion] Re: int16 or int32 for C int ? In-Reply-To: References: <20050627023336.726635a2@linuxcestcomplique.fr> <200506270900.52509.faltet@carabos.com> <20050627093935.659c5b72@linuxcestcomplique.fr> Message-ID: <20050628014608.7a56872b@linuxcestcomplique.fr> On Mon, 27 Jun 2005 10:40:13 -0700, Scott David Daniels wrote : > >>>I would like to create a numarray array from a C buffer of 'int' > >>>but I don't quite know how to handle different 'int' > >>>representation (16 or 32 bits). > > ... It was to be interfaced with legacy code which include 'int' > > declaration (which I couldn't change). So I think that I'll keep the > > 'sizeof' trick. > I would not treat the test as either-or, but rather as a triple. > So: > if (sizeof(**a) == 4) x = NA_NewArray(a, tInt16, 2, 10, 20); > else if (sizeof(**a) == 2) x = NA_NewArray(a, tInt16, 2, 10, 20); > else abort(); /* or raise some exception here. */ > > If you compile this on a machine with 64-bit ints, it is better if it > fails here than proceed as if working with 2-byte ints. If I am sure > I'll never run into that case, I'd do it as above (with the abort()). > A good C compiler can realize the test is constant and simply generate > one arm of the conditions anyway. If I think it might possibly be > used on a 64-bit int system, I'd go ahead and worry about what > exception to raise (probably PyTypeError, but ...). > Damn ! I was so sure that 'int' could only be 16 or 32 bits then I found this page : http://www.doc.ic.ac.uk/lab/secondyear/cstyle/node20.html Well thank you for your suggestion, I'll adopt it ! Regards, From nicopernetty at yahoo.fr Mon Jun 27 16:48:15 2005 From: nicopernetty at yahoo.fr (Nicolas Pernetty) Date: Mon Jun 27 16:48:15 2005 Subject: [Numpy-discussion] int16 or int32 for C int ? In-Reply-To: <1119867393.5010.5.camel@localhost.localdomain> References: <20050627023336.726635a2@linuxcestcomplique.fr> <1119835705.6114.4.camel@localhost.localdomain> <20050627093603.384677ec@linuxcestcomplique.fr> <1119867393.5010.5.camel@localhost.localdomain> Message-ID: <20050628014739.6eebe8e1@linuxcestcomplique.fr> On Mon, 27 Jun 2005 06:16:33 -0400, Todd Miller wrote : > > > > I would like to create a numarray array from a C buffer of 'int' > > > > but I don't quite know how to handle different 'int' > > > > representation (16 or 32 bits). > > > > > > On the platforms we test on at least, int == Int32. This is even > > > true for the 64-bit platforms I've seen. > > > > > > > For instante should I use : > > > > > > > > int a[10][20]; > > > > x = NA_NewArray(a, tInt16, 2, 10, 20); > > > > > > > > or : > > > > int a[10][20]; > > > > x = NA_NewArray(a, tInt32, 2, 10, 20); > > > > > > > > Should I use some macro to determine size of int ? > > > > > > You can do that with: sizeof(int) > > > > > > > Ok so If I want to make a really multiplatforms program, I should > > type : > > > > int a[10][20]; > > if (sizeof(**a)==4) > > x = NA_NewArray(a, tInt32, 2, 10, 20); > > else > > x = NA_NewArray(a, tInt16, 2, 10, 20); > > > > This is the recommended way ? > > I think this would be better: > > Int32 a[10][20]; > > x = NA_NewArray(a, tInt32, 2, 10, 20); > > Or, just do: > > x = NA_NewArray(NULL, tInt32, 2, 10, 20) > > and numarray will allocate the array storage which is then pointed to > by x->data. > Ok but in my particular case I can't : I have to deal with legacy code which use 'int' so I'm stuck with the sizeof trick... Thanks anyway ! From nicopernetty at yahoo.fr Mon Jun 27 16:50:21 2005 From: nicopernetty at yahoo.fr (Nicolas Pernetty) Date: Mon Jun 27 16:50:21 2005 Subject: [Numpy-discussion] int16 or int32 for C int ? In-Reply-To: <9epsu8qhdf.fsf@gowron.rz-berlin.mpg.de> References: <20050627023336.726635a2@linuxcestcomplique.fr> <1119835705.6114.4.camel@localhost.localdomain> <20050627093603.384677ec@linuxcestcomplique.fr> <9epsu8qhdf.fsf@gowron.rz-berlin.mpg.de> Message-ID: <20050628014933.328e9045@linuxcestcomplique.fr> On Mon, 27 Jun 2005 11:27:40 +0200, Jochen K?pper wrote : > >> On the platforms we test on at least, int == Int32. This is even > >> true for the 64-bit platforms I've seen. > > Didn't some Crays have 64bit ints? They definitely had 64bit float and > 128bit double. > > > Ok so If I want to make a really multiplatforms program, I should > > type : > > > > int a[10][20]; > > if (sizeof(**a)==4) > > x = NA_NewArray(a, tInt32, 2, 10, 20); > > else > > x = NA_NewArray(a, tInt16, 2, 10, 20); > > Maybe you should right away include a test for 8byte as well. > On this page you have some exotic 'int' : http://www.doc.ic.ac.uk/lab/secondyear/cstyle/node20.html The problem was no as simple as it seems to be. I'll go with the sizeof trick and some error message if I'm dealing with an exotic 'int'... From bsouthey at gmail.com Wed Jun 29 06:02:50 2005 From: bsouthey at gmail.com (Bruce Southey) Date: Wed Jun 29 06:02:50 2005 Subject: [Numpy-discussion] int16 or int32 for C int ? In-Reply-To: <1119835705.6114.4.camel@localhost.localdomain> References: <20050627023336.726635a2@linuxcestcomplique.fr> <1119835705.6114.4.camel@localhost.localdomain> Message-ID: On 6/26/05, Todd Miller wrote: > On Mon, 2005-06-27 at 02:33 +0200, Nicolas Pernetty wrote: > > Hello, > > > > I would like to create a numarray array from a C buffer of 'int' but I > > don't quite know how to handle different 'int' representation (16 or 32 > > bits). > > On the platforms we test on at least, int == Int32. This is even true > for the 64-bit platforms I've seen. Hi, The June 2005 C/C++ Users Journal (vol 23 no 5 http://www.cuj.com) had a couple of articles on porting to 64 bit computing. One was by Rodney Mach who gave this information: the 32-bit environment is a "ILP32 model because the C data-type model has 32-bit integers, long and pointers". "All modern 64-bit UNIX-like platforms use the LP64 data model" where longs and pointers are 64 bit but ints are 32-bit. He also looked at some of the porting problems. Bruce > > > For instante should I use : > > > > int a[10][20]; > > x = NA_NewArray(a, tInt16, 2, 10, 20); > > > > or : > > int a[10][20]; > > x = NA_NewArray(a, tInt32, 2, 10, 20); > > > > Should I use some macro to determine size of int ? > > You can do that with: sizeof(int) > > Regards, > Todd > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > From swisher at enthought.com Wed Jun 29 11:37:06 2005 From: swisher at enthought.com (Janet M. Swisher) Date: Wed Jun 29 11:37:06 2005 Subject: [Numpy-discussion] ANN: SciPy 2005 Conference - Python for Scientific Computing Message-ID: <42C2EA10.5070406@enthought.com> Greetings, The 2nd annual *SciPy Conference* on Python for Scientific Computing will be held again this year at Caltech, September 22-23, 2005. History: -------- This event started as SciPy "Workshops" held in 2002 and 2003, with great participation by the ~70 people attending. In 2004, it became a "conference", with attendance jumping to 87 participants. Registration: ------------- Registration is now open. More information can be found here: http://www.scipy.org/wikis/scipy05 You may register early online for $100.00. Registration includes breakfast and lunch Thursday & Friday and a very nice dinner Thursday night. After July 29, registration will cost $150.00. Call for Presenters: -------------------- If you are interested in presenting at the conference, you can submit an abstract in Plain Text, PDF or MS Word formats to abstracts at scipy.org -- the deadline for abstract submission is July 29, 2005. Papers or presentation slides are acceptable and are due by August 26, 2005. Feedback: --------- If you have any feedback from last year's conference or suggestions for this year, please discuss via the scipy mailing list: list signup: http://www.scipy.org/mailinglists/ list address: scipy-user at scipy.org Please forward this announcement to anyone/list that might be interested. Best Regards, -- Janet Swisher --- Senior Technical Writer Enthought, Inc. http://www.enthought.com