Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
Scripts with functions?

Subject: Scripts with functions?

From: Mark

Date: 31 Jul, 2011 23:28:10

Message: 1 of 40

Is there any way in Matlab to create a script that contains function? In Octave I can do that easily as shown in the example below, but I do not know how to do the same in Matlab. Can anyone please help?

Thanks in advance


%%%%%%%%%%%%%%%%%%%%%%%
#!/usr/bin/octave -qf

1;

%%%%%%%%%%%%%%%%%%%%%%%
function z = xy(A)
...
end

function abc(B)
...
end
%%%%%%%%%%%%%%%%%%%%%%%

nargin=max(size(argv));
if nargin < 2
  fprintf(stderr, "Usage: %s INFILE OUTFILE\n", program_name);
  exit(-1);
end

...

Subject: Scripts with functions?

From: Image Analyst

Date: 31 Jul, 2011 23:40:29

Message: 2 of 40

No. A script can call a function but the function must reside in a different file. A simple workaround is to just make your script a function by having a line like this near the top of your script

function myfunction()

Then list all your other functions after that in the same file. What's the problem with doing that?

Subject: Scripts with functions?

From: Mark

Date: 31 Jul, 2011 23:59:13

Message: 3 of 40

"Image Analyst" wrote in message <j14p5d$hc2$1@newscl02ah.mathworks.com>...
> No. A script can call a function but the function must reside in a different file. A simple workaround is to just make your script a function by having a line like this near the top of your script
>
> function myfunction()
>
> Then list all your other functions after that in the same file. What's the problem with doing that?

The problem is that debugging functions in a pain the a$$ because the variables cease to exist when the function ends or have an error whereas I can take a look at the script's variables if something fails.

Yes, there are a lot of ways around that, and we argue endlessly about what are the preferences of different developers (like yours and mine). The fact remain that the scripts of the sort I describe are very easy to develop and test, and it's possible to have them with Octave. I usually find that Octave does not have a capability in Matlab but not the other way around.

Thanks

Subject: Scripts with functions?

From: Matt J

Date: 1 Aug, 2011 00:38:10

Message: 4 of 40

"Mark" wrote in message <j14q8h$joo$1@newscl02ah.mathworks.com>...
>
>
> The problem is that debugging functions in a pain the a$$ because the variables cease to exist when the function ends or have an error whereas I can take a look at the script's variables if something fails.
===================

That's very easy to deal with. Insert the KEYBOARD command at the bottom of the function and it will stop in the workspace of the function after you execute.

You can also use the command DBSTOP IF ERROR to make it so that an error will trigger the same thing.

Subject: Scripts with functions?

From: Mark

Date: 1 Aug, 2011 00:48:07

Message: 5 of 40

"Matt J" wrote in message <j14shi$or9$1@newscl02ah.mathworks.com>...
> "Mark" wrote in message <j14q8h$joo$1@newscl02ah.mathworks.com>...
> >
> >
> > The problem is that debugging functions in a pain the a$$ because the variables cease to exist when the function ends or have an error whereas I can take a look at the script's variables if something fails.
> ===================
>
> That's very easy to deal with. Insert the KEYBOARD command at the bottom of the function and it will stop in the workspace of the function after you execute.
>
> You can also use the command DBSTOP IF ERROR to make it so that an error will trigger the same thing.

Thanks for the tips, I honestly appreciate your input. I'm sure those commands are useful many times, but inserting them everywhere is burdensome and tiresome. Of course, I can always put the code inside a try catch block, but it's yet another thing to do.

The script with functions approach is very straightforward and easy to maintain. But if it's not available in Matlab, then oh well, I will have to live with that.

Subject: Scripts with functions?

From: dpb

Date: 1 Aug, 2011 01:01:55

Message: 6 of 40

On 7/31/2011 7:48 PM, Mark wrote:
...

> commands are useful many times, but inserting them everywhere is
> burdensome and tiresome. ...

Well, it would seem one additional line of code wouldn't be much effort
in comparison to the rest of writing a function/script. (And, of
course, there's always the use of code templates to have stuff like that
in a template file from which to start so you don't even have to
manually enter it more than the one time).


> The script with functions approach is very straightforward and easy to
> maintain. But if it's not available in Matlab, then oh well, I will have
> to live with that.

You'll have to live with it (at least until you can convince TMW to
change Matlab behavior).

I'd wonder what Octave does about scope in its functions though if
variables within functions are somehow visible in the workspace; that
seems quite easy to have innumerable namespace collisions/confusion.

--

Subject: Scripts with functions?

From: Mark

Date: 1 Aug, 2011 01:41:13

Message: 7 of 40

> Well, it would seem one additional line of code wouldn't be much effort
> in comparison to the rest of writing a function/script. (And, of
> course, there's always the use of code templates to have stuff like that
> in a template file from which to start so you don't even have to
> manually enter it more than the one time).

It's still more effort than the other approach.

> You'll have to live with it (at least until you can convince TMW to
> change Matlab behavior).

Yep, that's what I said if it's indeed the case scripts with functions is not possible in Matlab (which I guess is be the case according to all these answers)

> I'd wonder what Octave does about scope in its functions though if
> variables within functions are somehow visible in the workspace; that
> seems quite easy to have innumerable namespace collisions/confusion.

Same scope rules than Matlab AFAIK. That is, variables inside the function are private, and functions cannot read variables from the script unless they are declared as "global" inside the function. In the type of script I wrote the functions happen to be inside the script file, but apart from that everything should have the same Matlab scope behavior

However, I didn't mention that "variables within functions are somehow visible in the workspace". What I said is that the SCRIPT variables are visible in the workspace and that's why I can examine them after an error in the script is found. I cannot do the same for functions' variables. I will need to either enclose things within try/catch or put the suggested statements (DBSTOP IF ERROR, etc.) so that once an error occur I could examine the function's variables.

Subject: Scripts with functions?

From: dpb

Date: 1 Aug, 2011 01:54:37

Message: 8 of 40

On 7/31/2011 8:41 PM, Mark wrote:
...

> Same scope rules than Matlab AFAIK. That is, variables inside the
> function are private, and functions cannot read variables from the
> script unless they are declared as "global" inside the function. In the
> type of script I wrote the functions happen to be inside the script
> file, but apart from that everything should have the same Matlab scope
> behavior
>
> However, I didn't mention that "variables within functions are somehow
> visible in the workspace". What I said is that the SCRIPT variables are
> visible in the workspace and that's why I can examine them after an
> error in the script is found. I cannot do the same for functions'
> variables. I will need to either enclose things within try/catch or put
> the suggested statements (DBSTOP IF ERROR, etc.) so that once an error
> occur I could examine the function's variables.

Well, what does "The fact remain that the scripts of the sort I describe
are very easy to develop and test, and it's possible to have them with
Octave." mean in comparison to Matlab then?

I don't follow there's any functionality difference then...so the only
complaint is that a script file can't contain functions iow?

That modification is such I guess I'd say the chances aren't zero that
an enhancement request might eventually percolate that modification thru
(otomh I don't see a reason against it but I've not thought about it at
any length at all, though, so it's quite possible it's obvious and I'm
just not thinking of it).

--

Subject: Scripts with functions?

From: Image Analyst

Date: 1 Aug, 2011 03:22:11

Message: 9 of 40

"Mark" wrote in message <j14q8h$joo$1@newscl02ah.mathworks.com>...
[snip]
> Yes, there are a lot of ways around that, and we argue endlessly about what are the preferences of different developers (like yours and mine).
[snip]
================================
I just put a breakpoint somewhere inside the function. That's pretty simple. I don't know how it could be made much simpler. Sure you can let a script execute and then examine variables after it has finished, but it doesn't seem too much of a burden to put a breakpoint on the last line of a function and then examine variables. No big deal - just one extra click.

Subject: Scripts with functions?

From: Mark

Date: 1 Aug, 2011 04:07:10

Message: 10 of 40

"Image Analyst" wrote in message <j15652$h4p$1@newscl02ah.mathworks.com>...
> "Mark" wrote in message <j14q8h$joo$1@newscl02ah.mathworks.com>...
> [snip]
> > Yes, there are a lot of ways around that, and we argue endlessly about what are the preferences of different developers (like yours and mine).
> [snip]
> ================================
> I just put a breakpoint somewhere inside the function. That's pretty simple. I don't know how it could be made much simpler. Sure you can let a script execute and then examine variables after it has finished, but it doesn't seem too much of a burden to put a breakpoint on the last line of a function and then examine variables. No big deal - just one extra click.

As I said, many ways around. I still prefer the script+function solution for several reasons. Apart from the ones already stated, I often open several instances of Matlab to run things and I don't want to be setting breakpoints all the time in each function file. This happens to me often. Other times I am in a hurry to clean things up and issue an "clear all". That wipes out the breakpoints as well. Besides, you won't anticipate all the functions where an error might occur, and I would need to set breakpoints in all of them. That's burdensome.

At any rate, thanks a lot for your helpful feedback

Subject: Scripts with functions?

From: dpb

Date: 1 Aug, 2011 04:17:08

Message: 11 of 40

On 7/31/2011 11:07 PM, Mark wrote:
> "Image Analyst" wrote in message <j15652$h4p$1@newscl02ah.mathworks.com>...
>> "Mark" wrote in message <j14q8h$joo$1@newscl02ah.mathworks.com>...
>> [snip] > Yes, there are a lot of ways around that, and we argue
>> endlessly about what are the preferences of different developers (like
>> yours and mine). [snip]
>> ================================
>> I just put a breakpoint somewhere inside the function. That's pretty
>> simple. I don't know how it could be made much simpler. Sure you can
>> let a script execute and then examine variables after it has finished,
>> but it doesn't seem too much of a burden to put a breakpoint on the
>> last line of a function and then examine variables. No big deal - just
>> one extra click.
>
> As I said, many ways around. I still prefer the script+function solution
> for several reasons. Apart from the ones already stated, I often open
> several instances of Matlab to run things and I don't want to be setting
> breakpoints all the time in each function file. This happens to me
> often. Other times I am in a hurry to clean things up and issue an
> "clear all". That wipes out the breakpoints as well. Besides, you won't
> anticipate all the functions where an error might occur, and I would
> need to set breakpoints in all of them. That's burdensome.
> At any rate, thanks a lot for your helpful feedback

But what, specifically, is different functionally other than the other
file(s) containing the functions instead of within a single file?

You've already said the function scope is the same so when the function
errors it errors...what does whether it's in the same or a different
file do any different?

--

Subject: Scripts with functions?

From: Mark

Date: 1 Aug, 2011 04:38:11

Message: 12 of 40

> But what, specifically, is different functionally other than the other
> file(s) containing the functions instead of within a single file?

Well, for the things I need to do the script contains most of the code that needs to be run, whereas the functions offer a bit of functionality that I use in the script. I don't want to create a lot of function files which is another pain to manage. I only do that for functions I reuse several times in several scripts, not in functions exclusive for a particular script. It is a royal pain to have those little functions in a lot of files. Instead, it's easier to put all the code in a single script file including the functions very specific to that script.

> You've already said the function scope is the same so when the function
> errors it errors...what does whether it's in the same or a different
> file do any different?

Please see above. The code in the functions I create is very short. The code in the script is longer, manages more data, and there is more room for error. If there is an error, it's likely to happen as an unexpected condition in the script code, not in the functions. Thus, I can simply inspect the variables of the script in the main Matlab interface, or even run other scripts without my variables disappearing like in the case of the functions. Since my functions are short and give a very limited and specific functionality, they are easier to code without unexpected conditions. I almost don't spend any time in creating those functions. Most of my time is devoted to the script.

The script+function approach is a huge time saver for me :-(

Subject: Scripts with functions?

From: dpb

Date: 1 Aug, 2011 07:00:12

Message: 13 of 40

On 7/31/2011 11:38 PM, Mark wrote:

...

The first part I get...

> The script+function approach is a huge time saver for me :-(

This I just don't grok how it could be that "huge" given that these
other files are, as you say, so insignificant in development and
testing. A slight annoyance, perhaps, yes..."huge" time coster, no, I
just don't see that.

Put them in the directory and go on; how much time can that take when as
you say you're spending the major fraction of time in
writing/debugging/using the script m-file...

Or use Octave if it indeed is so much more productive owing to this
feature while/until TMW acts on your enhancement request.

Just out of curiosity, though, as I've never used Octave to speak of and
never the specific way you're speaking of (I'd not have thought of it
given that Matlab doesn't do that and Octave is, I thought, an
open-source Matlab workalike so I'd have expected the same behavior),
does Octave expose these functions in these script files to other than
the calling script file in which they are contained? In other words,
are they like subfunctions in scope in Matlab I'm presuming?

That's the only thing keeping you from doing what you wish in Matlab by
wrapping your script as a function and using one of the aforementioned
workarounds to retain visibility/scope on error altho I'll grant that
you don't have quite the same ability after an error since scope is in
whichever is the first script (now function) called instead of the main
workspace.

Unfortunately, to continue to work at the script level as you're used to
entirely I think your options are to use m-files as TMW has designed
Matlab or revert to Octave.

To paraphrase others in another language group I frequent when folks
complain that the particular language of the subject group doesn't do
something as another language does, "LanguageA isn't LanguageB". In
this case apparently "Matlab isn't Octave". :)

--

Subject: Scripts with functions?

From: Mark

Date: 1 Aug, 2011 13:38:25

Message: 14 of 40

> The first part I get...

OK :-)

> > The script+function approach is a huge time saver for me :-(
>
> This I just don't grok how it could be that "huge" given that these
> other files are, as you say, so insignificant in development and
> testing.

They may be small, but if I have to code more than 2 functions it gets annoying.

> A slight annoyance, perhaps, yes..."huge" time coster, no, I
> just don't see that.

It's a big time saver for me. You don't know how easy it is until you get accustomed.

For some people coding in Python is a huge time saver that many Java programmers don't notice or don't "get". This is just an example of course, I am not going to go into religious wars. But you have to get accustomed to something that takes less time (like getting rid of the need of several function files, or be able to inspect the script variables without having to use a lot of try/catch of debugger stop commands, etc.) to see why one doesn't like the absence of the script+functions capability

> Put them in the directory and go on; how much time can that take when as
> you say you're spending the major fraction of time in
> writing/debugging/using the script m-file...

More time than I would spent with the script+functions in a single file. Along with other things, I am not going to say ...

> Or use Octave if it indeed is so much more productive owing to this
> feature while/until TMW acts on your enhancement request.

I do use Octave v3.x under Linux but under Windows doesn't work very well (many crashes). At least the standalone version. Maybe the cygwin version is more stable but I tried an earlier version (2.x) and was slow (e.g., opening files with load). Not sure if that changed.
 
> Just out of curiosity, though, as I've never used Octave to speak of and
> never the specific way you're speaking of (I'd not have thought of it
> given that Matlab doesn't do that and Octave is, I thought, an
> open-source Matlab workalike so I'd have expected the same behavior),
> does Octave expose these functions in these script files to other than
> the calling script file in which they are contained? In other words,
> are they like subfunctions in scope in Matlab I'm presuming?

I don't know but I don't think so. They exist only for those scripts if I am not mistaken. As I said, if there are functions used for more than one script, I simply put them in another file. That sounds justifiable to me.

> To paraphrase others in another language group I frequent when folks
> complain that the particular language of the subject group doesn't do
> something as another language does, "LanguageA isn't LanguageB". In
> this case apparently "Matlab isn't Octave". :)

Wait a second. The reason I asked this question was to know if this was possible. Then after I got a "No" answer, people started trying to convince me that it's no big deal or that it does not save time, which is not true. Then the discussion started to go in a different direction. I already said that if Matlab does not have this capability then I have to live with that. It was never my intention to start a discussion about the virtues of Octave vs Matlab.

Subject: Scripts with functions?

From: dpb

Date: 1 Aug, 2011 14:08:06

Message: 15 of 40

On 8/1/2011 8:38 AM, Mark wrote:
>> The first part I get...
>
> OK :-)
>
>> > The script+function approach is a huge time saver for me :-(
>>
>> This I just don't grok how it could be that "huge" given that these
>> other files are, as you say, so insignificant in development and testing.
>
> They may be small, but if I have to code more than 2 functions it gets
> annoying.
>> A slight annoyance, perhaps, yes..."huge" time coster, no, I just
>> don't see that.
>
> It's a big time saver for me. You don't know how easy it is until you
> get accustomed.

I can see it is easy; I just can't see that it could be _that_ big a
differential.

An annoyance since you're used to the other way, surely; that I grok.
How much actual time otoh...

...

>> does Octave expose these functions in these script files to other than
>> the calling script file in which they are contained? In other words,
>> are they like subfunctions in scope in Matlab I'm presuming?
>
> I don't know but I don't think so. They exist only for those scripts if
> I am not mistaken. As I said, if there are functions used for more than
> one script, I simply put them in another file. That sounds justifiable
> to me.

OK, hmmm....then they behave as do subfunctions in an m-file. You might
explore them in conjunction w/ your scripting; the place I see you have
a problem is the subfunctions are only visible to the exposed function
in that file so you are back (probably) to having to wrap the script
but--_IF_ (the proverbial "big if" :) ) the factoring of using so much
in one file is indeed so great in your work habits, perhaps that overall
large gain would outweigh the added burden of the other workarounds
previously mentioned, I don't know. Just a thought suggestion you might
not have considered.

...

>> this case apparently "Matlab isn't Octave". :)
>
...

> I already said that if Matlab does not have this capability then I have
> to live with that. It was never my intention to start a discussion about
> the virtues of Octave vs Matlab.

NB the smiley...I was _trying_ to be lighthearted but agree that the
situation is one in which "In Rome..." altho agree the discussion was
flavored by my inability to grasp that building an new m-file could be
such a burden as compared to typing the same lines of code into an
existing file.

Anyway, good luck and sorry that ML is not O in this regard... <VBG>

--

Subject: Scripts with functions?

From: dpb

Date: 1 Aug, 2011 15:10:25

Message: 16 of 40

On 8/1/2011 9:08 AM, dpb wrote:
...

> Anyway, good luck and sorry that ML is not O in this regard... <VBG>

OBTW, it _does_ seem to me there's no reason that ML _couldn't_ have
subfunctions in a script file(+); I'd suggest you do follow through with
the enhancement request.

It'll get farther w/ TMW if somebody who has significant usage and can
give concrete examples of the benefits will do so as opposed to the
random "I want".

(+) The calling resolution of looking for the function in the same file
first is apparently pretty straightforward; not sure what TMW runs into
in scoping issues altho it doesn't seem as though that should be a major
revamping there, either, otomh (but again, I've not thought thru this at
all nor do I have any insight into implementation from which to draw
inferences; I'm just winging it here :) ).

--

Subject: Scripts with functions?

From: Shawn Bonneau

Date: 1 Aug, 2011 15:36:56

Message: 17 of 40

Why isn't the DBSTOP IF ERROR option acceptable? It's one command in the
command line and if you don't want to have to do it for each new MATLAB
instance, just add it to your startup.m file.

"Mark " <answer_through@thenewsgroup.thank.you.com> wrote in message
news:j158pe$mrl$1@newscl02ah.mathworks.com...
> "Image Analyst" wrote in message
> <j15652$h4p$1@newscl02ah.mathworks.com>...
>> "Mark" wrote in message <j14q8h$joo$1@newscl02ah.mathworks.com>...
>> [snip]
>> > Yes, there are a lot of ways around that, and we argue endlessly about
>> > what are the preferences of different developers (like yours and mine).
>> [snip]
>> ================================
>> I just put a breakpoint somewhere inside the function. That's pretty
>> simple. I don't know how it could be made much simpler. Sure you can
>> let a script execute and then examine variables after it has finished,
>> but it doesn't seem too much of a burden to put a breakpoint on the last
>> line of a function and then examine variables. No big deal - just one
>> extra click.
>
> As I said, many ways around. I still prefer the script+function solution
> for several reasons. Apart from the ones already stated, I often open
> several instances of Matlab to run things and I don't want to be setting
> breakpoints all the time in each function file. This happens to me often.
> Other times I am in a hurry to clean things up and issue an "clear all".
> That wipes out the breakpoints as well. Besides, you won't anticipate all
> the functions where an error might occur, and I would need to set
> breakpoints in all of them. That's burdensome.
> At any rate, thanks a lot for your helpful feedback

Subject: Scripts with functions?

From: Mark

Date: 1 Aug, 2011 22:38:12

Message: 18 of 40

"Shawn Bonneau" <sbonneau@mathworks.com> wrote in message <j16h6o$3ls$1@newscl01ah.mathworks.com>...
> Why isn't the DBSTOP IF ERROR option acceptable? It's one command in the
> command line and if you don't want to have to do it for each new MATLAB
> instance, just add it to your startup.m file.

OK, I understood that I had to put it in every function I wrote, but if you say that that it's necessary only once, then it sounds much much better.

Regarding the script+functions, I am curious why it is not available in ML? From your email address I guess you work for TMW. Do you know about that? It doesn't seem that there is anything particularly special of allowing that arrangement given that function files can contain sub-functions too.

Subject: Scripts with functions?

From: Steven_Lord

Date: 2 Aug, 2011 15:06:38

Message: 19 of 40



"Mark " <answer_through@thenewsgroup.thank.you.com> wrote in message
news:j158pe$mrl$1@newscl02ah.mathworks.com...
> "Image Analyst" wrote in message
> <j15652$h4p$1@newscl02ah.mathworks.com>...
>> "Mark" wrote in message <j14q8h$joo$1@newscl02ah.mathworks.com>...
>> [snip]
>> > Yes, there are a lot of ways around that, and we argue endlessly about
>> > what are the preferences of different developers (like yours and mine).
>> [snip]
>> ================================
>> I just put a breakpoint somewhere inside the function. That's pretty
>> simple. I don't know how it could be made much simpler. Sure you can
>> let a script execute and then examine variables after it has finished,
>> but it doesn't seem too much of a burden to put a breakpoint on the last
>> line of a function and then examine variables. No big deal - just one
>> extra click.
>
> As I said, many ways around. I still prefer the script+function solution
> for several reasons. Apart from the ones already stated, I often open
> several instances of Matlab to run things and I don't want to be setting
> breakpoints all the time in each function file. This happens to me often.
> Other times I am in a hurry to clean things up and issue an "clear all".
> That wipes out the breakpoints as well. Besides, you won't anticipate all
> the functions where an error might occur, and I would need to set
> breakpoints in all of them. That's burdensome.

That sounds like a time when you'd use an error breakpoint rather than
breakpoints on specific lines.

http://www.mathworks.com/help/techdoc/matlab_env/brqxeeu-175.html#brqxeeu-242

If you want to quickly reenable error breakpoints after clearing, you can
create a script/function/shortcut that does "clear all; dbstop if error" or
the like and invoke that script/function/shortcut instead of CLEAR ALL.

But no, there is no way to create a script file that contains a function nor
is there a way to create a function file that contains a script. The closest
you're going to get is to convert the script into a function or to create
the function as its own file; if you want to limit how "visible" that
separate function is you can make it private or put it in a package.

http://www.mathworks.com/help/techdoc/matlab_prog/f4-70335.html

http://www.mathworks.com/help/techdoc/matlab_oop/brfynt_-1.html

> At any rate, thanks a lot for your helpful feedback

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

Subject: Scripts with functions?

From: Matt J

Date: 2 Aug, 2011 15:32:09

Message: 20 of 40

"Mark" wrote in message <j14t47$q4u$1@newscl02ah.mathworks.com>...
>
> >
> > That's very easy to deal with. Insert the KEYBOARD command at the bottom of the function and it will stop in the workspace of the function after you execute.
> >
> > You can also use the command DBSTOP IF ERROR to make it so that an error will trigger the same thing.
>
> Thanks for the tips, I honestly appreciate your input. I'm sure those commands are useful many times, but inserting them everywhere is burdensome and tiresome. Of course, I can always put the code inside a try catch block, but it's yet another thing to do.
=============

I'm not sure what you meant here by "inserting them everywhere". My suggestion was to insert KEYBOARD at the bottom of the function only (and remove it once you get everything working).

If you meant that you have many such files, you shouldn't be seeking to work with lots of scripts. Scripts are slow and sub-optimal in execution. I assume that it's the same in Octave. Once you're certain that a 'script' is working, you should be converting it to a full-fledged function.

Subject: Scripts with functions?

From: dpb

Date: 2 Aug, 2011 18:17:37

Message: 21 of 40

On 8/2/2011 10:32 AM, Matt J wrote:
...

> ...Scripts are slow and sub-optimal in execution....

??? Why is that? What's any different in a script vis a vis a function
other than the workspace context and no arguments/returns?

--

Subject: Scripts with functions?

From: dpb

Date: 2 Aug, 2011 18:20:11

Message: 22 of 40

On 8/2/2011 10:06 AM, Steven_Lord wrote:
...

> But no, there is no way to create a script file that contains a function

...

But is there any reason that script files could _not_ include functions
just as function files contain subfunctions other than nobody thought to
implement it?

--

Subject: Scripts with functions?

From: Steven_Lord

Date: 3 Aug, 2011 14:31:39

Message: 23 of 40



"dpb" <none@non.net> wrote in message news:j19f4l$f0n$3@speranza.aioe.org...
> On 8/2/2011 10:06 AM, Steven_Lord wrote:
> ...
>
>> But no, there is no way to create a script file that contains a function
>
> ...
>
> But is there any reason that script files could _not_ include functions
> just as function files contain subfunctions other than nobody thought to
> implement it?

Off the top of my head? I can't think of a compelling reason. But I can
think of a number of scenarios that would warrant further investigation and
consideration to determine what, if anything, this change would affect and
whether those effects are positive, neutral, or negative. It's not as simple
as "change the ALLOW_FUNCTIONS_IN_SCRIPTS variable to 1 instead of 0 and
recompile" or anything like that.

If you really, really want this feature you should ask Technical Support for
it, with a description of how you'd use the functionality if it existed or
what pain you're experiencing due to it not existing. The latter piece is
important: "We want feature X" is less compelling IMO than "We want feature
X because it will allow us to do cool thing Y."

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

Subject: Scripts with functions?

From: Matt J

Date: 3 Aug, 2011 14:50:24

Message: 24 of 40

dpb <none@non.net> wrote in message <j19evs$f0n$2@speranza.aioe.org>...
> On 8/2/2011 10:32 AM, Matt J wrote:
> ...
>
> > ...Scripts are slow and sub-optimal in execution....
>
> ??? Why is that? What's any different in a script vis a vis a function
> other than the workspace context and no arguments/returns?
===============

The best explanation probably involves more computer science than my qualifications cover.

However, my understanding is that, because you can't know apriori everything that's in the workspace of a script, you can't JIT compile it. Basically, you have to execute the commands in a script as naively as if you used EVAL to execute each line one at a time.

Subject: Scripts with functions?

From: dpb

Date: 3 Aug, 2011 15:04:22

Message: 25 of 40

On 8/3/2011 9:31 AM, Steven_Lord wrote:
> "dpb" <none@non.net> wrote in message
> news:j19f4l$f0n$3@speranza.aioe.org...
...
>> But is there any reason that script files could _not_ include
>> functions just as function files contain subfunctions other than
>> nobody thought to implement it?
>
> Off the top of my head? I can't think of a compelling reason. But I can
> think of a number of scenarios that would warrant further investigation
> and consideration to determine what, if anything, this change would
> affect and whether those effects are positive, neutral, or negative.
> It's not as simple as "change the ALLOW_FUNCTIONS_IN_SCRIPTS variable to
> 1 instead of 0 and recompile" or anything like that.
>
> If you really, really want this feature you should ask Technical Support
> for it, with a description of how you'd use the functionality if it
> existed or what pain you're experiencing due to it not existing. The
> latter piece is important: "We want feature X" is less compelling IMO
> than "We want feature X because it will allow us to do cool thing Y."

That's where my minimal thinking left me as well, Steve, and I had
already recommended to the OP who was the "wanter" for the feature since
was the one who instigated the thread that he submit an enhancement
request with the supporting reason(s) for desiring the particular
enhancement.

I had/have no delusions that there is anything such as a flag already
implemented that hasn't been set; only that at the aforementioned
superficial level it doesn't seem fundamentally that much different than
subfunctions as far as the parsing, scope within the containing m-file,
etc., are concerned. The devil is always in the details as you say,
however, and I expressly noted previously I don't have the background or
knowledge to even attempt such a detailed evaluation.

--

Subject: Scripts with functions?

From: Kelly Kearney

Date: 3 Aug, 2011 15:07:27

Message: 26 of 40

"Matt J" wrote in message <j1959p$gib$1@newscl01ah.mathworks.com>...
> "Mark" wrote in message <j14t47$q4u$1@newscl02ah.mathworks.com>...
> >
> > >
> > > That's very easy to deal with. Insert the KEYBOARD command at the bottom of the function and it will stop in the workspace of the function after you execute.
> > >
> > > You can also use the command DBSTOP IF ERROR to make it so that an error will trigger the same thing.
> >
> > Thanks for the tips, I honestly appreciate your input. I'm sure those commands are useful many times, but inserting them everywhere is burdensome and tiresome. Of course, I can always put the code inside a try catch block, but it's yet another thing to do.
> =============
>
> I'm not sure what you meant here by "inserting them everywhere". My suggestion was to insert KEYBOARD at the bottom of the function only (and remove it once you get everything working).
>


I think this suggestion reveals a difference in coding to do a specific task, versus coding as a means of experimentation. I've been an adamant supporter of functions-in-scripts for years, and it doesn't imply that I'm a bad/inefficient coder, or that I don't understand the importance of functions. To me, functions and scripts serve very different purposes.

I often use scripts when I'm playing around with data, model output, etc., without an extremely specific result in mind. Do some analysis from the command line, run scripts (often cell mode scripts where breakpoints aren't an option) to do more complicated analysis/plotting/reformatting of data, etc. The important thing in this workflow is not the end result, but rather the intermediates, so I want to be able to look more closely at lots of different variables, often not knowing in advance which ones will be most interesting. Scripts are perfect for this.

For me, allowing functions in scripts would be a time-saver, not because it's any quicker or easier to write that way (versus external functions in their own files), but because it allows for much cleaner file organization. I've become pretty adept at utilizing anonymous functions, but there's a limit to how much you can cram into a one-liner. So instead, I find my work folder littered with little one-off functions that are too specialized to be moved to my main library of functions (often specialized plots for data analysis, or utilities to reformat data in a very specific way), but a pain to wade through when I go back in search of a certain script I had written a few weeks ago. (I compromise on easy-to-type function names versus overly descriptive function names).


> If you meant that you have many such files, you shouldn't be seeking to work with lots of scripts. Scripts are slow and sub-optimal in execution.

I don't care. :-) Not in the circumstances listed above, at least.

Subject: Scripts with functions?

From: Matt J

Date: 3 Aug, 2011 15:18:13

Message: 27 of 40

"Kelly Kearney" wrote in message <j1bo7f$a98$1@newscl01ah.mathworks.com>...
>
>
> I often use scripts when I'm playing around with data, model output, etc., without an extremely specific result in mind. Do some analysis from the command line, run scripts (often cell mode scripts where breakpoints aren't an option) to do more complicated analysis/plotting/reformatting of data, etc. The important thing in this workflow is not the end result, but rather the intermediates, so I want to be able to look more closely at lots of different variables, often not knowing in advance which ones will be most interesting. Scripts are perfect for this.
===============

That's all fine, but again, there's little difference between a script and a function with KEYBOARD as its last line. It's always been a fairly painless workaround for me.

Subject: Scripts with functions?

From: dpb

Date: 3 Aug, 2011 15:38:03

Message: 28 of 40

On 8/3/2011 9:50 AM, Matt J wrote:
> dpb <none@non.net> wrote in message <j19evs$f0n$2@speranza.aioe.org>...
>> On 8/2/2011 10:32 AM, Matt J wrote:
>> ...
>>
>> > ...Scripts are slow and sub-optimal in execution....
>>
>> ??? Why is that? What's any different in a script vis a vis a function
>> other than the workspace context and no arguments/returns?
> ===============
>
> The best explanation probably involves more computer science than my
> qualifications cover.
> However, my understanding is that, because you can't know apriori
> everything that's in the workspace of a script, you can't JIT compile
> it. Basically, you have to execute the commands in a script as naively
> as if you used EVAL to execute each line one at a time.

Hmmmm....there's "whos" in the workspace to tell that context if that
were required; I'm not seeing it (not saying it isn't so, just perhaps
I'm also unqualified to see the problem)...

Now just maybe TMW didn't implement JIT on scripts something like they
didn't implement functions thinking they are the redhaired stepchild;
that's possible, too (altho again, I've no actual clue). I'd consider
doing some testing but my release is so out of date it would have no
bearing on reality today to be worthy of the effort.

--

Subject: Scripts with functions?

From: dpb

Date: 3 Aug, 2011 15:41:53

Message: 29 of 40

On 8/3/2011 10:07 AM, Kelly Kearney wrote:
...
> I think this suggestion reveals a difference in coding to do a specific
> task, versus coding as a means of experimentation. I've been an adamant
> supporter of functions-in-scripts for years, and it doesn't imply that
> I'm a bad/inefficient coder, or that I don't understand the importance
> of functions. To me, functions and scripts serve very different purposes.
>
> I often use scripts when I'm playing around with data, model output,
> etc., without an extremely specific result in mind. Do some analysis
> from the command line, run scripts (often cell mode scripts where
> breakpoints aren't an option) to do more complicated
> analysis/plotting/reformatting of data, etc. The important thing in this
> workflow is not the end result, but rather the intermediates, so I want
> to be able to look more closely at lots of different variables, often
> not knowing in advance which ones will be most interesting. Scripts are
> perfect for this.
>
> For me, allowing functions in scripts would be a time-saver, not because
> it's any quicker or easier to write that way (versus external functions
> in their own files), but because it allows for much cleaner file
> organization. I've become pretty adept at utilizing anonymous functions,
> but there's a limit to how much you can cram into a one-liner. So
> instead, I find my work folder littered with little one-off functions
> that are too specialized to be moved to my main library of functions
> (often specialized plots for data analysis, or utilities to reformat
> data in a very specific way), but a pain to wade through when I go back
> in search of a certain script I had written a few weeks ago. (I
> compromise on easy-to-type function names versus overly descriptive
> function names).
...

I'd suggest another enhancement request would be the ticket... :)

I certainly see no fundamental reason why the _concept_ isn't ok and
useful; the implementation details are something else as in the sidebar
discussion.

--

Subject: Scripts with functions?

From: Matt J

Date: 3 Aug, 2011 15:51:26

Message: 30 of 40

dpb <none@non.net> wrote in message <j1bq0m$9ok$1@speranza.aioe.org>...
>
>
> Hmmmm....there's "whos" in the workspace to tell that context if that
> were required; I'm not seeing it (not saying it isn't so, just perhaps
> I'm also unqualified to see the problem)...

Again, this is conjecture on my part, but you would have to perform the "whos" equivalent each time the script was executed (because the base workspace can change) and that extra overhead for compilation is what hurts you.

That might be related to the "first run effect" in which we see functions execute slowly the first time, then faster after that. The first execution is slower because the function is being JIT compiled...

Subject: Scripts with functions?

From: dpb

Date: 3 Aug, 2011 15:56:15

Message: 31 of 40

On 8/3/2011 10:18 AM, Matt J wrote:
...

> That's all fine, but again, there's little difference between a script
> and a function with KEYBOARD as its last line. It's always been a fairly
> painless workaround for me.

But why should there necessarily be a WORKAROUND???

--

Subject: Scripts with functions?

From: dpb

Date: 3 Aug, 2011 16:09:21

Message: 32 of 40

On 8/3/2011 10:51 AM, Matt J wrote:
> dpb <none@non.net> wrote in message <j1bq0m$9ok$1@speranza.aioe.org>...
>>
>>
>> Hmmmm....there's "whos" in the workspace to tell that context if that
>> were required; I'm not seeing it (not saying it isn't so, just perhaps
>> I'm also unqualified to see the problem)...
>
> Again, this is conjecture on my part, but you would have to perform the
> "whos" equivalent each time the script was executed (because the base
> workspace can change) and that extra overhead for compilation is what
> hurts you.
>
> That might be related to the "first run effect" in which we see
> functions execute slowly the first time, then faster after that. The
> first execution is slower because the function is being JIT compiled...

OK, that I can see as being not as much gain possibly...one could
envision there being a "dirty" flag on the workspace variables to aid in
the process.

TMW may have well have decided it's not worth the effort, I don't know.
Again, my release is so old the state of the JIT compiler is totally
different.

--

Subject: Scripts with functions?

From: Matt J

Date: 3 Aug, 2011 17:13:11

Message: 33 of 40

dpb <none@non.net> wrote in message <j1br2p$c5g$3@speranza.aioe.org>...
> On 8/3/2011 10:18 AM, Matt J wrote:
> ...
>
> > That's all fine, but again, there's little difference between a script
> > and a function with KEYBOARD as its last line. It's always been a fairly
> > painless workaround for me.
>
> But why should there necessarily be a WORKAROUND???
=================

Ah well, workarounds are necessary because direct methods are unavailable. I'm not saying that should be the case, only that I don't see it constituting a major inconvenience. That could, of course, be by virtue of the kind of work I do. It's rare that I would write a script without eventually wanting to turn it into a function.

Subject: Scripts with functions?

From: dpb

Date: 3 Aug, 2011 17:27:24

Message: 34 of 40

On 8/3/2011 12:13 PM, Matt J wrote:
...
> virtue of the kind of work I do. It's rare that I would write a script
> without eventually wanting to turn it into a function.

OTOH, I _may_ eventually make something into a high level function, but
like Mark most of my time w/ Matlab was spent in the interactive "play"
mode he describes of trying lots of different ideas where the global
nature of the workspace was infinitely handy. I lived w/ the functions
being throwaways and having to live in their own files as well simply
because that was how it was/is but I'd have certainly thrown stuff into
subscript functions (to coin a phrase) if were available.

When (or if) those 'playings" were refined to an actual something
useful, then there were others to make use of that and generally those
went into embedded products that didn't have any relationship to Matlab
at all.

As you say, a wholly different working paradigm as far as Matlab was
concerned.

--

Subject: Scripts with functions?

From: Matt J

Date: 3 Aug, 2011 17:51:28

Message: 35 of 40

dpb <none@non.net> wrote in message <j1c0dn$rqt$1@speranza.aioe.org>...
> On 8/3/2011 12:13 PM, Matt J wrote:
> ...
> > virtue of the kind of work I do. It's rare that I would write a script
> > without eventually wanting to turn it into a function.
>
> OTOH, I _may_ eventually make something into a high level function, but
> like Mark most of my time w/ Matlab was spent in the interactive "play"
> mode he describes of trying lots of different ideas where the global
> nature of the workspace was infinitely handy.
==============

OTOOH, it's often beneficial to work in interactive play mode within the workspace of a function, rather than the base workspace, in which case the KEYBOARD approach is what you'd inevitably have to use.

The main awkwardness that I see with working in the base workspace is that you need to make sure that certain variables (but maybe not all of them) are cleared between runs. I find it easier to do this by passing the variables you intend to reuse as arguments to the function and letting all other variables go outof scope.

OK, you could counter-argue that one could always use CLEARVARS -EXCEPT ....

Subject: Scripts with functions?

From: Mark

Date: 3 Aug, 2011 21:36:26

Message: 36 of 40

> I'm not sure what you meant here by "inserting them everywhere". My suggestion was to insert KEYBOARD at the bottom of the function only (and remove it once you get everything working).

By "everywhere" I meant on every single function. Now, you are answering to a comment I made regarding DBSTOP IF ERROR, not about KEYBOARD. You just said that KEYBOARD requires to be inserted on every function, which is what I mean by "everywhere"


> If you meant that you have many such files, you shouldn't be seeking to work with lots of scripts. Scripts are slow and sub-optimal in execution. I assume that it's the same in Octave. Once you're certain that a 'script' is working, you should be converting it to a full-fledged function.


That's not very relevant for my particular case. The script will execute a few times per day, it does not matter if they are slower than functions. I prefer speed of development in this case than of execution.

I guess that for the moment I will need to use DBSTOP IF ERROR as suggested before. I don't like the idea to be inserting "KEYBOARD" statements in my functions, but I appreciate your suggestion.

Subject: Scripts with functions?

From: Mark

Date: 3 Aug, 2011 21:44:25

Message: 37 of 40

> I think this suggestion reveals a difference in coding to do a specific task, versus coding as a means of experimentation. I've been an adamant supporter of functions-in-scripts for years, and it doesn't imply that I'm a bad/inefficient coder, or that I don't understand the importance of functions. To me, functions and scripts serve very different purposes.
>
> I often use scripts when I'm playing around with data, model output, etc., without an extremely specific result in mind. Do some analysis from the command line, run scripts (often cell mode scripts where breakpoints aren't an option) to do more complicated analysis/plotting/reformatting of data, etc. The important thing in this workflow is not the end result, but rather the intermediates, so I want to be able to look more closely at lots of different variables, often not knowing in advance which ones will be most interesting. Scripts are perfect for this.
>
> For me, allowing functions in scripts would be a time-saver, not because it's any quicker or easier to write that way (versus external functions in their own files), but because it allows for much cleaner file organization. I've become pretty adept at utilizing anonymous functions, but there's a limit to how much you can cram into a one-liner. So instead, I find my work folder littered with little one-off functions that are too specialized to be moved to my main library of functions (often specialized plots for data analysis, or utilities to reformat data in a very specific way), but a pain to wade through when I go back in search of a certain script I had written a few weeks ago. (I compromise on easy-to-type function names versus overly descriptive function names).


Thanks a lot Matt. Our dev cycles has many things in common

Subject: Scripts with functions?

From: Mark

Date: 3 Aug, 2011 21:59:14

Message: 38 of 40

> Thanks a lot Matt. Our dev cycles has many things in common

I meant, thanks a lot Kelly Kearney :-)

Subject: Scripts with functions?

From: Bruno Luong

Date: 3 Aug, 2011 22:20:29

Message: 39 of 40

Something I never understand is that Mathworks seem to spend a lot effort just to differentiate significantly scripts to functions: no JIT accelerator, no possibility of nested/subfunction declaration.

They must have their reason that somehow escapes me.

Bruno

Subject: Scripts with functions?

From: Matt J

Date: 3 Aug, 2011 22:30:33

Message: 40 of 40

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <j1chjc$6oc$1@newscl01ah.mathworks.com>...
> Something I never understand is that Mathworks seem to spend a lot effort just to differentiate significantly scripts to functions: no JIT accelerator, no possibility of nested/subfunction declaration.
>
> They must have their reason that somehow escapes me.
====================

But then why in Unix is there a distinction between scripts and compiled functions? Isn't it the same issue? See also Message #28 for conjectures exchanged between me and dbp.

Tags for this Thread

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us