Mailman 3 August 2004 - SciPy-Dev

RE: [SciPy-dev] Random integers
by Charles Harris 28 Aug '04

28 Aug '04

If it is the same package, it comes from casting a double to float by rounding. It is compiler dependent. This is fixed this in numarray cvs. Chuck -----Original Message----- From: Robert Kern [mailto:rkern@ucsd.edu] Sent: Thu 8/26/2004 3:03 PM To: SciPy Developers List Cc: Subject: [SciPy-dev] Random integers stats.randint.rvs(min, max) doesn't always do the right thing. Namely, it will occasionally give a number equal to max. Numeric's RandomArray.randint(min, max) doesn't seem to have this problem (or at least the sample size needed to show it is rather higher than that for stats.randint). Oddly enough, they seem to do the same computation. Any thoughts? -- Robert Kern rkern(a)ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter _______________________________________________ Scipy-dev mailing list Scipy-dev(a)scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev

2 1

RE: [SciPy-dev] Random integers
by Charles Harris 27 Aug '04

27 Aug '04

Discussion and fix can be found here: http://sourceforge.net/tracker/index.php?func=detail&aid=1009309&group_id=1… -----Original Message----- From: Robert Kern [mailto:rkern@ucsd.edu] Sent: Thu 8/26/2004 3:03 PM To: SciPy Developers List Cc: Subject: [SciPy-dev] Random integers stats.randint.rvs(min, max) doesn't always do the right thing. Namely, it will occasionally give a number equal to max. Numeric's RandomArray.randint(min, max) doesn't seem to have this problem (or at least the sample size needed to show it is rather higher than that for stats.randint). Oddly enough, they seem to do the same computation. Any thoughts? -- Robert Kern rkern(a)ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter _______________________________________________ Scipy-dev mailing list Scipy-dev(a)scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev

1 0

Random integers
by Robert Kern 27 Aug '04

27 Aug '04

stats.randint.rvs(min, max) doesn't always do the right thing. Namely, it will occasionally give a number equal to max. Numeric's RandomArray.randint(min, max) doesn't seem to have this problem (or at least the sample size needed to show it is rather higher than that for stats.randint). Oddly enough, they seem to do the same computation. Any thoughts? -- Robert Kern rkern(a)ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter

1 0

suggested SciPy inclusion
by Alan G Isaac 21 Aug '04

21 Aug '04

I'm ignorant of any licensing issues, but if possible it would be great to include in SciPy: Walter Moreira's RPy module (needs pyWin32 under Windows) This would really help expand the statistical routines available from SciPy. fwiw, Alan

2 1

ANN: Python/Scientific Job openings at Enthought
by eric jones 17 Aug '04

17 Aug '04

Hey Folks, Enthought continues to grow, and we're hiring again. There are several positions open, and most of them involve python+scientific computing. A couple of the positions also involve support of SciPy. I'm very interested in finding a person for the "scientist" job posting that is both able to work well with our customers and also has the personality and interest to work with the SciPy community to help push the library forward. More information is available on our web site. http://www.enthought.com/careers.htm Our current development efforts are in the areas of electromagnetics, geophysics, and graphics (2D and 3D). If you have any questions, please feel free to contact me. Please forward the link to anyone you feel might be interested. thanks, eric

1 0

RPMS on www.scipy.org
by Sean Dilda 14 Aug '04

14 Aug '04

I was looking at the rpms that are provided on scipy.org, and am thinking about using them. Unfortunately, I noticed that most of the src.rpm's are missing. (There's one for SciPy, but not scipy_core, F2PY or Numeric) We have a policy where we don't install any rpms without saving a copy of the SRPM, in case we need to recreate the rpm with slight changes. If you could make your src rpms available, I'd really appreciate it. I also noticed that the F2PY rpm you have up is for python 2.2, while all of the other packages are for python 2.3. Was this intentional? Thanks, Sean

2 1

scipy crashing on
by David Grant 10 Aug '04

10 Aug '04

Has there been any progress made on fixing the following bugs? Which are all basically dupes as far as I can tell: http://www.scipy.net/roundup/scipy/issue178 http://www.scipy.net/roundup/scipy/issue163 http://www.scipy.net/roundup/scipy/issue138 I'm really desperate for any workaround...or any possible reasons (specific to my system) which may be the culprit. Thanks, David

1 0

Re[2]: [SciPy-user] Re: plot_func
by Alan G Isaac 07 Aug '04

07 Aug '04

On Thu, 05 Aug 2004, Matt Kubilus apparently wrote: > I hacked into the pyPlot.py > module and added a function that essentially just sends a command to the > hidden function that actually calls the plotting routines. This allowed me > to use the full functionality of gnuplot which can to way more than just > what scipy.gplt does. Yes, I did the same. To pyPlot.py I added: def replot(self,cmd=''): self._replot(cmd) To interface.py I added: def replot(cmd=''): _validate_active() _active.replot(cmd) This seems to work fine. (Clue me in if it is a bad approach.) BUT Since I want to use SciPy in teaching, this is really pointless unless the developers say they will implement it. I cannot ask students to do such things: they need to use the software as downloaded. Clearly users want this. Can we hear from a developer please? Or can someone tell me if there is a process for submitting such changes. Thank you, Alan Isaac

2 2

Re[2]: [SciPy-user] scipy choice of defaults for matrix manipulation
by Alan G Isaac 06 Aug '04

06 Aug '04

On Thu, 05 Aug 2004, Travis Oliphant apparently wrote: > This is fragmenting the community and is not a good thing in my > opinion. You may make a case for which standard is appropriate but the > axis=-1 was decided on after some deliberation. It is open for discussion. Allow me one last comment on this: It was important to know who was deliberating: engineers, economists, statistitians, etc. To illustrate: in numarray (which seeks Numeric compatibility) we find axis=-1: all of fft stuff sort, argsort, argmin, argmax, trapz, diff axis=0: all of the linear algebra stuff (except diff in mlab.py, which numarray no longer documents) along with repeat, concatenate, compress, reduce, accumulate, average, take, alltrue, sometrue, zreduce, areduce, put I hazard the the linear algebra stuff is the most commonly used module. In the econometrics community, data series are by far most often characterized as columns of a 2D array, and the numarray defaults in the linear algebra module seem natural to us. Since scipy plans sensibly to rely on Numeric and then numarray, it just does not seem workable to use different defaults. This will create widespread confusion. I would urge that the scipy and numarray developers hash this out. But in the meantime, I hope the scipy developers will emphasize compatibility of the default behavior of imported functions. If the axis question seems pressing, good simplicity could be achieved here as follows. For sort, argsort, argmin, argmax, trapz, diff *require* an axis argument, and document this prominently. (Also, lean on the numarray folks to change the defaults behavior of these.) For everything else, use the numarray defaults. The bottom line question is: is it really tenable for users to know that scipy relies of Numeric/numarray while adopting different default behavior? I believe not. Here is an additional consideration: the numarray folks are producing pretty decent documentation, and SciPy will be able to rely on that instead of producing its own documentation for the same functions. Time is scarce. Thanks for thinking about this. I will shut up now. Alan Isaac

1 0

scipy choice of defaults for matrix manipulation
by Alan G Isaac 06 Aug '04

06 Aug '04

The SciPy documentation says: To begin with, all of the Numeric functions have been subsumed into the scipy namespace so that all of those functions are available without additionally importing Numeric. It was therefore unsettling to find that SciPy's function_base defines def cumsum(m,axis=-1): """Returns the cumulative sum of the elements along the given axis """ if axis is None: m = ravel(m) axis = 0 else: m = _asarray1d(m) return add.accumulate(m,axis) This changes the default axis of Numeric and numarray. Bug or feature?? Example: >>> x=[[1,2],[3,4]] >>> from scipy import * >>> print cumsum(x) [[1,3] [3,7]] >>> print Numeric.cumsum(x) [[1,2] [4,6]] I believe this should be considered a serious bug, either in implementation or documentation. Since SciPy is likely to be attracting Numeric and numarray users, I believe it should be considered an implementation bug. Naturally cumprod has the same problem. (I did not try to review the whole list, so there may be others.) There is even a certain schizophrenia: sum and prod choose different axes! It is clear that this has been thought about at some point, since SciPy's sum definition includes a note suggesting that the axis might change in the future (to *conflict* with the choice in Numeric and numarray!!). This is likely to generate great user confusion. It cost me some time. Thank you, Alan Isaac

2 3