Mailman 3 January 2006 - SciPy-User

Bug report - unwrap function error
by Hugo Gamboa Jan. 4, 2006

Jan. 4, 2006

Hello, I have the a recent svn version (1501), and when trying to use the unwrap function it gave me the error transcribed above. In a move to correct the bug to continue my work, I could not found the definition of the mod function. I know that it exists in scipy.mod but was unable to track the function. If someone could help this beginner to simply track a function in scipy, I would be very appreciated. Thanks in advance for your help. Hugo Gamboa The error reported in a ipython session In [13]: scipy.unwrap([1,2,3,4]) --------------------------------------------------------------------------- exceptions.NameError Traceback (most recent call last) /usr/lib/python2.4/site-packages/scipy/base/function_base.py in unwrap(p, discont, axis) 480 slice1 = [slice(None, None)]*nd # full slices 481 slice1[axis] = slice(1, None) --> 482 ddmod = mod(dd+pi, 2*pi)-pi 483 _nx.putmask(ddmod, (ddmod==-pi) & (dd > 0), pi) 484 ph_correct = ddmod - dd; NameError: global name 'mod' is not defined

7 8

Error importing
by Rob Managan Jan. 4, 2006

Jan. 4, 2006

I just updated to the latest svn and after doing a full rebuild and install I get this error. I probably did something stupid but a pointer would be helpful. Thanks!! [mangrove:~/Documents/devel/scipy] managan% python Python 2.4.1 (#2, Mar 31 2005, 00:05:10) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import scipy Traceback (most recent call last): File "<stdin>", line 1, in ? File "/Users/managan/Documents/local/lib/python2.4/site-packages/scipy/__init__.py", line 335, in ? pkgload(verbose=SCIPY_IMPORT_VERBOSE,postpone=True) File "/Users/managan/Documents/local/lib/python2.4/site-packages/scipy/__init__.py", line 216, in __call__ self.warn('Overwriting %s=%s (was %s)' \ AttributeError: PackageLoader instance has no attribute '_obj2str' >>> -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Rob Managan email managan at llnl.gov LLNL phone: 925-423-0903 P.O. Box 808, L-095 FAX: 925-422-3389 Livermore, CA 94551-0808

2 2

Re: [SciPy-user] Renaming scipy_core: here we go again
by O'Keefe, Michael Jan. 4, 2006

Jan. 4, 2006

I'd like to cast my vote for #2 "scicore" though I personally wouldn't mind "scipycore" either. -Michael -----Original Message----- From: scipy-user-bounces(a)scipy.net [mailto:scipy-user-bounces@scipy.net] On Behalf Of Travis Oliphant Sent: Tuesday, January 03, 2006 18:09 To: SciPy Developers List; SciPy Users List Subject: [SciPy-user] Renaming scipy_core: here we go again Please give feedback on the following names: 1. psipi 2. scicore 3. muscle 4. numstar We have to move from numerix due to trademark concerns (I don't want to have any that I can obviously avoid). -Travis

1 0

Re: [SciPy-user] Renaming scipy_core: here we go again
by Randewijk P-J <pjrandew＠sun.ac.za> Jan. 4, 2006

Jan. 4, 2006

What about a name to compliment python, i.e. a name of some sort of snake... but that also sounds somewhat mathematical... My first choice would by, our deadly: 1) pufadder thought sounding not "mathematical", but still a snake, 2) mamba 3) cobra could also be considered... Also with the chief author's surname sounding very... South African... a deadly (South) African snake name would be imho very appropriate... but maybe I'm biased... PJR > -----Original Message----- > From: scipy-user-bounces(a)scipy.net > [mailto:scipy-user-bounces@scipy.net] On Behalf Of Fernando Perez > Sent: 04 January 2006 07:36 > To: SciPy Users List > Subject: Re: [SciPy-user] Renaming scipy_core: here we go again ... > Several of us have already admitted we suck at coming up with > good names. And > we've been burning time on this issue, when Travis could be > renaming code and > setting up the new repo. > > So how about, instead of criticizing on something we already > know, you simply > make useful suggestions OF BETTER NAMES? We already admitted > we don't know > how to do better, so by all means help. > > Best, > > f > > _______________________________________________ > SciPy-user mailing list > SciPy-user(a)scipy.net http://www.scipy.net/mailman/listinfo/scipy-user >

1 0

new full scipy binary for windows?
by Fonnesbeck, Chris Jan. 3, 2006

Jan. 3, 2006

I am wondering if there is a relatively recent windows installer for the new full scipy. I am having trouble finding all the build prerequisites for getting it done myself on my old windows laptop (mainly because fftw.org seems to be down). If anyone has a binary sitting on a ftp site somewhere, please send me a pointer -- I did not see one on the sourceforge site. Thanks, C. -- Christopher J. Fonnesbeck Population Ecologist, Marine Mammal Section Fish & Wildlife Research Institute (FWC) St. Petersburg, FL Adjunct Assistant Professor Warnell School of Forest Resources University of Georgia Athens, GA T: 727.235.5570 E: Chris.Fonnesbeck(a)MyFWC.com

1 0

Re: [SciPy-user] [SciPy-dev] default dtype
by Ed Schofield Jan. 2, 2006

Jan. 2, 2006

Francesc Altet wrote: >A Dilluns 02 Gener 2006 03:38, Ed Schofield va escriure: > > >>+5 on changing the default to float. I think we'd look back on this >>decision in several years as difficult but right. >> >> >Sorry, but I don't agree. If we want Python to include the container >for array objects, making the default be double seems to stress the >fact that this object is meant primarily for scientific use (which is >true to some extent). However, for the sake of stablishing a *real* >standard to keep datasets, I'd advocate the default to remain int. In >addition, there are a lot of uses for integer arrays (indices, >images...). IMO, making the double the default would discourage the >use of the object between people not used to write >scientific/technical apps. > >The only issue is the possible confusion in users when they will >receive Int32 arrays in 32-bit platforms and Int64 arrays in 64-bit >ones. I don't know, but perhaps this single reason is strong enough to >change the default to Float64. > > Interesting point. Then what do you think about an integer default that is redefinable by the user? For example: >>> import scicore / whatever >>> scicore.default_dtype = float64 Then zeros(), empty(), and ones() (any others?) would use the new default. I think the flexibility would be nice, and it should be feasible ... Perhaps the most compelling argument against an integer default is the current behaviour with unsafe casting: >>> a = zeros(10) >>> a[0] = 1.159262 >>> a[0] 1 and this argument would evaporate if unsafe casts were required to be more explicit. I promised to provide a patch and run some timings for this, but I haven't done this yet. -- Ed

3 2

Re: [SciPy-user] [SciPy-dev] default dtype
by Fernando Perez Jan. 2, 2006

Jan. 2, 2006

Francesc Altet wrote: > A Dilluns 02 Gener 2006 14:53, Ed Schofield va escriure: > >>Then what do you think about an integer default that is redefinable by >> >>the user? For example: >> >>> import scicore / whatever >> >>> scicore.default_dtype = float64 >> >>Then zeros(), empty(), and ones() (any others?) would use the new >>default. I think the flexibility would be nice, and it should be >>feasible ... > > > Yes. I think this would be really nice to have. That way, the > 64/32-bit dichotomy would disappear. Is this supposed to be a fully global setting? If so, what about import numerix numerix.default_dtype = 'something' import somemodule somemodule.foo() boom! Now, the foo() call either: 1. blows up, because it had unqualified zeros() calls whose dtype has now changed, or 2. resets numerix.default_type back, and your code blows up next. I think this can be handled with a _call_ (numerix.set_default_dtype()), but it requires special stack-handling code so that numerix can know to apply the new default only to calls made from the same module. Cheers, f

1 0

default dtype
by Alan G Isaac Jan. 2, 2006

Jan. 2, 2006

Is an integer data type the obvious default for 'empty'? I expected float. Thanks, Alan Isaac using scipy core version 0.8.4

8 14