matplotlib.mlab.find() not quite like Matlab"s

no, I was a bit wrong. Python functions always return one

    > object, and when it appears that you are returning multiple
    > objects, you are really returning a single tuple with
    > multiple objects in it. Have I got it right this time?

Sounds right to me. Your answer does point to the danger of using
nargout in python

  ret = somefunc()
  i,j = ret

If somefunc is relying on nargout, it will botch it.

I think the only sane use for nargout in python is in auto-conversion
scripts, and then with appropriate warnings.

Thanks said, I would still like to have it, for that reason.

JDH

John Hunter wrote:

"Chris" == Chris Barker <Chris.Barker@...259...> writes:
           
   > no, I was a bit wrong. Python functions always return one
   > object, and when it appears that you are returning multiple
   > objects, you are really returning a single tuple with
   > multiple objects in it. Have I got it right this time?

Sounds right to me. Your answer does point to the danger of using
nargout in python

ret = somefunc()
i,j = ret

If somefunc is relying on nargout, it will botch it.

I think the only sane use for nargout in python is in auto-conversion
scripts, and then with appropriate warnings.

Thanks said, I would still like to have it, for that reason.

Matlab also returns one object- the varargout cell array which is similar to Python's list or tuple. You write a function, and pack varargout with nargout results: [a,b]=matlabfun().

Darren Dale wrote:

Matlab also returns one object- the varargout cell array which is similar to Python's list or tuple. You write a function, and pack varargout with nargout results: [a,b]=matlabfun().

I haven't used Matlab for a while, and not a newer version than 5.*, but IIRC, while the above notation looks, like you are returning a cell array, you could not call that fun with a single return argument. Perhaps that's changed, in which case you shouldn't use nargout in Matlab either!

Anyway, my main point was that kludging a nargout implementation in python was not a good idea. I'd much rather see matplotlib be pythonesque than matlabesque. Perhaps my goals are different than others, but I use Python, rather than Matlab, largely because I like the language better.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...259...

Hi Chris,

Matlab also returns one object- the varargout cell array which is similar to Python's list or tuple. You write a function, and pack varargout with nargout results: [a,b]=matlabfun().

I haven't used Matlab for a while, and not a newer version than 5.*, but IIRC, while the above notation looks, like you are returning a cell array, you could not call that fun with a single return argument. Perhaps that's changed, in which case you shouldn't use nargout in Matlab either!

Maybe my example wasn't clear. There are good reasons for using varargout and nargout in Matlab. If I write a function to fit a peak, I can return the position, height, FWHM and sumResiduals along with some information about how the peakfitting algorithm concluded. If a user calls [p,h,fwhm,sr] = peakfit(x,y), you use nargout to determine that the caller does not want the algorithm report.

Anyway, my main point was that kludging a nargout implementation in python was not a good idea. I'd much rather see matplotlib be pythonesque than matlabesque. Perhaps my goals are different than others, but I use Python, rather than Matlab, largely because I like the language better.

I originally looked into Python because everyone who works with it loves it, and it is free. I felt that the switch could be quick and painless because of John and the other MPL developers efforts with the Matlab interface. I would probably have waited to switch until after graduating if I hadnt googled "Python AND Matlab" one fateful day. (Cornell recently sent me a survey asking whether I felt $230 was fair for a 12 month license!). The matlab interface is already matlabesque. I think *args and Matlab's varargin are equivalent. Let me write up some examples using nargout as it is intended to be used, and I'll submit them to the list in a new thread. This one has strayed a bit from the original topic.

Darren

Hi Darren,

I sometimes return a dict in cases like this:

fit = peakfit(x,y)
print fit['position']
print fit['height']
print fit['FWHM']

and so on...

Sometimes, the results I always want get returned on their own and optionally return all results:

p,h = peakfit(x,y) # return just the basic results
p,h,fit_extras = peakfit(x,y,full_output=True) # return everything
print fit_extras['FHWM']

(I think some scipy functions operate more-or-less like this, too. Perhaps without returning results in a dict, but merely as extra arguments.)

I have to agree with the opinions of Chris Barker and John Hunter cautioning against writing new code using an 'nargout-alike'. (When translating Matlab code to Python I can see that it might be useful.) Furthermore, I often find myself grabbing the results of a function call in one variable, stuffing it somewhere, and later, knowing it's a tuple, examining the elements later. This handy trick would be impossible with an nargout-based implementation.

To me, nargout, like so much of Matlab, is a brutish hack introduced because that language is not as capable or elegant as Python. (To digress further and probably show the era at which I left Matlab to be around 5.x, it seems to me that early design mistakes resulted in terrible backwards compatibility issues, as well. For example, I remember being driven mad trying to figure out whether parentheses were needed when calling certain functions. I guess for some they are required and for others they aren't. I think it would be very difficult to define the syntax for Matlab as done in the Python (Language) Reference Manual. And let's not get into issues of object oriented programming, types and 'everything is a (double precision) matrix'.)

Regardless of whether your sense of aesthetics is different than mine, the kind of low-level shenanigans suggested as a work-around seems, at the very least, brittle and prone to maintenance and portability issues. (Would that even work on IronPython or PyPy?)

Anyhow, if you're not scared by bytecode hacks in your initial toe-dipping forays into Python, I invite you to dive in!

Cheers!
Andrew

···

On Nov 16, 2004, at 4:51 PM, Darren Dale wrote:

Maybe my example wasn't clear. There are good reasons for using varargout and nargout in Matlab. If I write a function to fit a peak, I can return the position, height, FWHM and sumResiduals along with some information about how the peakfitting algorithm concluded. If a user calls [p,h,fwhm,sr] = peakfit(x,y), you use nargout to determine that the caller does not want the algorithm report.