From aisaac at american.edu Mon Aug 2 02:09:34 2004 From: aisaac at american.edu (Alan G Isaac) Date: Mon, 2 Aug 2004 02:09:34 -0400 (Eastern Daylight Time) Subject: [SciPy-dev] pyPlot.size proposal Message-ID: I'm using gplt and while good it seems sometimes to needlessly restrict access to gnuplot commands. Please consider a small change in the definition of size. Something like the following would be *very* helpful. def size(self,size=(1.,1.)) : if type(size) == StringType : cmd = 'set size ' + size else : cmd = 'set size %f,%f' % size self._replot(cmd) Please consider a general purpose communication command to set global gnuplot options. E.g., def replot(self,plotstr=""): if type(plotstr) == StringType : self._replot(plotstr) Thank you for this nice package! Alan Isaac From aisaac at american.edu Tue Aug 3 12:29:40 2004 From: aisaac at american.edu (Alan G Isaac) Date: Tue, 3 Aug 2004 12:29:40 -0400 (Eastern Daylight Time) Subject: [SciPy-dev] Re: plot_func In-Reply-To: References: Message-ID: On Sun, 1 Aug 2004 Alan G Isaac apparently wrote: > I noticed that pyPlot.py has: > def plot_func(self,func): > self._init_plot() > if(type(func) == StringType): > self._send('plot '+ func) > else: > print 'error: requires a function as a string' > but gplt.plot_func is not available. OK, I've confirmed that if I make an instance of scipy.gplt.pyPlot.Plot then the plot_func method works fine for this instance. I don't know enough about Python to guess why gplt is not giving us access to this. Can anyone help? Thank you, Alan Isaac From aisaac at american.edu Wed Aug 4 11:14:27 2004 From: aisaac at american.edu (Alan G Isaac) Date: Wed, 4 Aug 2004 11:14:27 -0400 (Eastern Daylight Time) Subject: [SciPy-dev] scipy choice of defaults for matrix manipulation Message-ID: 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 From rkern at ucsd.edu Wed Aug 4 18:07:25 2004 From: rkern at ucsd.edu (Robert Kern) Date: Wed, 04 Aug 2004 17:07:25 -0500 Subject: [SciPy-dev] Re: [SciPy-user] scipy choice of defaults for matrix manipulation In-Reply-To: References: Message-ID: <41115E1D.4010205@ucsd.edu> Alan G Isaac wrote: > 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?? Implementation feature; documentation bug. Numeric's functions have various, inconsistent ("schizophrenic" as you say) choices for the default axis. An attempt, albeit incomplete as you note, was made with SciPy to standardize on always using axis=-1. I'm fairly positive this was documented somewhere at some point, but probably only on the old website. The tutorial really should be updated to prominently note this convention. -- 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 bhoel at web.de Thu Aug 5 15:14:47 2004 From: bhoel at web.de (=?iso-8859-1?q?Berthold_H=F6llmann?=) Date: Thu, 05 Aug 2004 21:14:47 +0200 Subject: [SciPy-dev] Re: Building Debug extrensions with scipy_distutils on WinXP In-Reply-To: ( =?iso-8859-1?q?Berthold_H=F6llmann's_message_of?= "Tue, 27 Jul 2004 17:23:30 +0200") References: Message-ID: Berthold H?llmann writes: > Berthold H?llmann writes: > >> Hello, > ... > > I finaly found the patch > > hoel at donau:scipy cvs -q diff scipy_core/scipy_distutils/compaqfcompiler.py > Index: scipy_core/scipy_distutils/compaqfcompiler.py > =================================================================== > RCS file: /home/cvsroot/world/scipy_core/scipy_distutils/compaqfcompiler.py,v > retrieving revision 1.5 > diff -r1.5 compaqfcompiler.py > 86a87,95 >> def _get_cc_args(self, pp_opts, debug, before): >> cc_args = pp_opts >> if debug: >> cc_args[:0] = self.get_flags_debug() >> if before: >> cc_args[:0] = before >> return cc_args >> >> > > which allows me to build debug extension modules under WinXP using > Visual Studio 6.0 and Compaq Visual Fortran 6.1 A. Can anybody comment on this patch. We do need debugging support for Windows and I would like to hear of some scipy developer if there's a chance for this or a similar patch to get into the CVS and later an official release. Kind regards Berthold H?llmann -- bhoel at web.de / http://starship.python.net/crew/bhoel/ From aisaac at american.edu Thu Aug 5 00:37:31 2004 From: aisaac at american.edu (Alan G Isaac) Date: Thu, 5 Aug 2004 00:37:31 -0400 (Eastern Daylight Time) Subject: [SciPy-dev] Re[2]: [SciPy-user] scipy choice of defaults for matrix manipulation In-Reply-To: <41115E1D.4010205@ucsd.edu> References: <41115E1D.4010205@ucsd.edu> Message-ID: Alan wrote: >> 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?? On Wed, 04 Aug 2004, Robert Kern apparently wrote: > Implementation feature; documentation bug. Numeric's functions have > various, inconsistent ("schizophrenic" as you say) choices for the > default axis. An attempt, albeit incomplete as you note, was made with > SciPy to standardize on always using axis=-1. I'm fairly positive this > was documented somewhere at some point, but probably only on the old > website. The tutorial really should be updated to prominently note this > convention. Looking at briefly at Numeric and numarray, it seems they have made an effort to standardize on axis=0. This is also true in the Matlab module. Wouldn't it be wise for SciPy to join the parade? (I.e., shouldn't these closely related and interdependent packages share a convention? Otherwise, this is going to be VERY confusing for users. (As it was for me.) Now when I call a such a function, I have to remember: is it a SciPy function, or a Numeric/numarray function? Not a good situation, right? Thanks, Alan From aisaac at american.edu Thu Aug 5 20:12:50 2004 From: aisaac at american.edu (Alan G Isaac) Date: Thu, 5 Aug 2004 20:12:50 -0400 (Eastern Daylight Time) Subject: [SciPy-dev] Re[2]: [SciPy-user] Re: plot_func In-Reply-To: References: Message-ID: 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 From rkern at ucsd.edu Thu Aug 5 21:26:39 2004 From: rkern at ucsd.edu (Robert Kern) Date: Thu, 05 Aug 2004 20:26:39 -0500 Subject: [SciPy-dev] Re: [SciPy-user] scipy choice of defaults for matrix manipulation In-Reply-To: References: <41115E1D.4010205@ucsd.edu> Message-ID: <4112DE4F.7060008@ucsd.edu> Alan G Isaac wrote: [snip] > Looking at briefly at Numeric and numarray, it seems they > have made an effort to standardize on axis=0. No, they don't. It's a fairly even mix of axis=0 and axis=-1. > This is also > true in the Matlab module. Wouldn't it be wise for SciPy > to join the parade? Not at this time. There's too much SciPy code that would need to be rewritten, namely SciPy itself. The axis=-1 convention will be staying. > (I.e., shouldn't these closely related > and interdependent packages share a convention? > Otherwise, this is going to be VERY confusing for users. > (As it was for me.) Now when I call a such a function, > I have to remember: is it a SciPy function, or a > Numeric/numarray function? Well, if it's SciPy, axis=-1 almost always (the deviations usually being the functions which shadow Numeric functions). If it's Numeric, you also have to remember if it's axis=0 or axis=-1. If it's numarray, then you have other problems since SciPy is currently all-Numeric. The real question you have to ask yourself when coding is "did SciPy overwrite this Numeric function?", a question that needs to be asked for reasons other than the choice of default axis. I would also note that having a terminal running IPython is invaluable when coding. The ? and ?? magic is usually better than a reference manual. > Not a good situation, right? It's arguable that SciPy functions which shadow Numeric functions should have the same defaults. It is also arguable that SciPy functions should be internally consistent, so when a Numeric function is overwritten (to add genericity or whatever) it should follow the SciPy convention. Neither choice has been rigorously implemented although after I poked around in IPython for a minute or two, cumsum() appears to be the only deviation from the first option. This might qualify as a bug. > Thanks, > Alan -- 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 oliphant at ee.byu.edu Thu Aug 5 23:15:05 2004 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Thu, 05 Aug 2004 21:15:05 -0600 Subject: [SciPy-dev] Re[2]: [SciPy-user] Re: plot_func In-Reply-To: References: Message-ID: <4112F7B9.7050909@ee.byu.edu> Alan G Isaac wrote: >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. > > I'm not sure who is using pyPlot (it was something of a stop-gap) and I would highly recommend using matplotlib at this point. There may be a case for including it in the Enthon distribution but Enthought would have to comment on that. I'm still using xplt heavily (on Linux mostly) and so I know it works there. Changes to SciPy are always welcome. If you just have a few you can post bug reports at http://www.scipy.net/roundup/scipy/index --- you might want to post on scipy-dev as well if it's a serious bug. Patches, or code-snippets that fix the problem are always appreciated and can be sent to scipy-dev at scipy.org General complaints are also welcome and will be attended to as soon as a developer gets time. If you would like to become a developer, don't hesitate to ask about getting CVS access so you can make changes directly. -Travis O. From aisaac at american.edu Fri Aug 6 11:20:39 2004 From: aisaac at american.edu (Alan G Isaac) Date: Fri, 6 Aug 2004 11:20:39 -0400 (Eastern Daylight Time) Subject: [SciPy-dev] Re[2]: [SciPy-user] scipy choice of defaults for matrix manipulation In-Reply-To: <4112F595.4050007@ee.byu.edu> References: <41115E1D.4010205@ucsd.edu> <4112F595.4050007@ee.byu.edu> Message-ID: 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 From aisaac at american.edu Fri Aug 6 12:14:12 2004 From: aisaac at american.edu (Alan G Isaac) Date: Fri, 6 Aug 2004 12:14:12 -0400 (Eastern Daylight Time) Subject: [SciPy-dev] Re[2]: [SciPy-user] Re: plot_func In-Reply-To: <4112F7B9.7050909@ee.byu.edu> References: <4112F7B9.7050909@ee.byu.edu> Message-ID: On Thu, 05 Aug 2004, Travis Oliphant apparently wrote: > I'm not sure who is using pyPlot (it was something of a stop-gap) and I > would highly recommend using matplotlib at this point. There may be a > case for including it in the Enthon distribution but Enthought would > have to comment on that. I'm still using xplt heavily (on Linux mostly) > and so I know it works there. > Changes to SciPy are always welcome. If you just have a few you can > post bug reports at > http://www.scipy.net/roundup/scipy/index --- you might want to post on > scipy-dev as well if it's a serious bug. > General complaints are also welcome and will be attended to as soon as a > developer gets time. If you would like to become a developer, don't > hesitate to ask about getting CVS access so you can make changes directly. 1. Code snippets To gplt/pyPlot.py please add: def replot(self,cmd=''): self._replot(cmd) To gplt/interface.py please add: def replot(cmd=''): _validate_active() _active.replot(cmd) This will give general access to the gnuplot command line. (I would gladly make these changes myself, if I am given CVS access.) 2. Offer/query: If SciPy has a commitment to maintaining gplt's pyPlot module, and *if* there is at least one good reason not to promote Gnuplot.py instead, I can spend a little time on pyPlot. It sounds to me, however, that SciPy is currently promoting a shift to matplotlib and that interest in gplt has died, so that users interested in gnuplot should shift to Gnuplot.py. Please let me know. 3. Possibility: If SciPy is no longer interested in pyPlot, perhaps it should nevertheless retain its interest in gnuplot. (I am personally a strong gnuplot admirer.) In which case, perhaps the gplt interface should be to Gnuplot.py instead of pyPlot.py. If so, I would consider working on this. (However, I haven't tried out Gnuplot.py yet.) Thank you, Alan Isaac From david.grant at telus.net Mon Aug 9 13:32:45 2004 From: david.grant at telus.net (David Grant) Date: Mon, 09 Aug 2004 10:32:45 -0700 Subject: [SciPy-dev] scipy crashing on Message-ID: <4117B53D.7080805@telus.net> 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 From sean at duke.edu Fri Aug 13 15:39:51 2004 From: sean at duke.edu (Sean Dilda) Date: Fri, 13 Aug 2004 15:39:51 -0400 Subject: [SciPy-dev] RPMS on www.scipy.org Message-ID: <1092425991.4356.31.camel@pel> 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 From joe at enthought.com Fri Aug 13 15:53:11 2004 From: joe at enthought.com (Joe Cooper) Date: Fri, 13 Aug 2004 14:53:11 -0500 Subject: [SciPy-dev] RPMS on www.scipy.org In-Reply-To: <1092425991.4356.31.camel@pel> References: <1092425991.4356.31.camel@pel> Message-ID: <411D1C27.3070205@enthought.com> Sean Dilda wrote: > 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. They're available, just not very public. ;-) http://www.enthought.com/python/fedora/1/SRPMS/ And actually they're quite old now, as I've been distracted by other work at Enthought (I'm the RPM guy for SciPy). > 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? Probably mislabelled... The RPMs are in dire need of some cleaning up and updating, which might come next week. The ugliest bit is the dependency on atlas during build. I haven't figured out a clean way to handle that yet. From eric at enthought.com Mon Aug 16 13:42:11 2004 From: eric at enthought.com (eric jones) Date: Mon, 16 Aug 2004 12:42:11 -0500 Subject: [SciPy-dev] ANN: Python/Scientific Job openings at Enthought Message-ID: <4120F1F3.4020006@enthought.com> 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 From aisaac at american.edu Fri Aug 20 10:56:47 2004 From: aisaac at american.edu (Alan G Isaac) Date: Fri, 20 Aug 2004 14:56:47 -0000 Subject: [SciPy-dev] suggested SciPy inclusion Message-ID: 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 From rkern at ucsd.edu Fri Aug 20 12:07:48 2004 From: rkern at ucsd.edu (Robert Kern) Date: Fri, 20 Aug 2004 11:07:48 -0500 Subject: [SciPy-dev] suggested SciPy inclusion In-Reply-To: References: Message-ID: <412621D4.6090402@ucsd.edu> Alan G Isaac wrote: > 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) It's GPL so it's a non-starter. > This would really help expand the statistical routines > available from SciPy. > > fwiw, > Alan -- 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 rkern at ucsd.edu Thu Aug 26 17:03:52 2004 From: rkern at ucsd.edu (Robert Kern) Date: Thu, 26 Aug 2004 16:03:52 -0500 Subject: [SciPy-dev] Random integers Message-ID: <412E5038.70109@ucsd.edu> 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 at ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From charles.harris at sdl.usu.edu Fri Aug 27 09:20:37 2004 From: charles.harris at sdl.usu.edu (Charles Harris) Date: Fri, 27 Aug 2004 07:20:37 -0600 Subject: [SciPy-dev] Random integers Message-ID: <1885D1238A4FFE40B113CEB26F87872B1183B7@cobra.usurf.usu.edu> 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 at 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 at 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 at scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 2696 bytes Desc: not available URL: From charles.harris at sdl.usu.edu Fri Aug 27 10:20:04 2004 From: charles.harris at sdl.usu.edu (Charles Harris) Date: Fri, 27 Aug 2004 08:20:04 -0600 Subject: [SciPy-dev] Random integers Message-ID: <1885D1238A4FFE40B113CEB26F87872B1183B8@cobra.usurf.usu.edu> Discussion and fix can be found here: http://sourceforge.net/tracker/index.php?func=detail&aid=1009309&group_id=1369&atid=450446 -----Original Message----- From: Robert Kern [mailto:rkern at 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 at 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 at scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 2700 bytes Desc: not available URL: From rkern at ucsd.edu Fri Aug 27 12:12:46 2004 From: rkern at ucsd.edu (Robert Kern) Date: Fri, 27 Aug 2004 11:12:46 -0500 Subject: [SciPy-dev] Random integers In-Reply-To: <1885D1238A4FFE40B113CEB26F87872B1183B7@cobra.usurf.usu.edu> References: <1885D1238A4FFE40B113CEB26F87872B1183B7@cobra.usurf.usu.edu> Message-ID: <412F5D7E.5060401@ucsd.edu> Charles Harris wrote: > 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. Thank you! Your fix seems to work. > Chuck -- 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