Prev: imwrite image in an array
Next: CONVERT
From: Cygnine on 9 Feb 2010 11:08
"Steven Lord" <slord(a)mathworks.com> wrote in message <hkrtc0$3l2$1(a)fred.mathworks.com>...
> Okay, I'll bite -- what's your use case? What should your function do
> differently if called from the command line than if it's called from a
> function?

Well, isn't that a doozy of a question. At the end of this message, just remember: you asked :)

I'm in the process of hacking Matlab's builtin function representation (actually, I'm pretty much done). I'm a fan of the way Python handles things myself. Right now I've tweaked things with the packages I've written that I can do things like:

>> from finite_difference.matrices import central_second_order_matrix as d2

And this creates a function handle d2 in whichever workspace from which it's called. Unfortunately, I write lots of functions and frequently forget information about it (# of inputs, order of inputs, what the original function d2 was called, etc.).

To solve this, I've created a class FunctionNode, and each instance of FunctionNode corresponds to an m-file in a package. Now I've overloaded subsref for this object so that using function calling syntax, i.e. f(blah1, blah2), works exactly the same way as a function handle. However, going through Matlab's internal processing structure of overloading subsref appears to take a considerable amount of time (and my codes call lots of FunctionNodes multiple times). This is why the "from" statement only imports the function handle and not the entire FunctionNode instance -- for speed.

However, when I'm at the command line, I'd like to access my helpstring for a function imported using "from". I don't think I can do this using Matlab's implementation of a function handle. Sooooo, if I type a from statement at the command prompt or a script, I probably don't care about the extra time necessary to pass through subsref, but I DO care about helpstrings, function locations, etc. So at the command line I want to import the FunctionNode instance.

But inside a function, unless I'm debugging, then I have absolutely no need for helpstrings, etc., so I just want to import the function handle.

And all of this is just a way for me to create nice Python-like importing structures in Matlab so that I don't have to pollute namespaces with all of the bazillions of functions that I use (plus I create different functions with the same name...Matlab doesn't like that). I'm not aware of a clean way to do this in Matlab. (I don't like messing around with the PATH variable, and I am aware of Matlab's builtin import statement...I don't like it.).

Oh, and Matt J:

Thanks for the more in-depth implementation. I won't be needing this functionality in debug mode, so that's ok.
From: Matt J on 9 Feb 2010 11:38
"Cygnine " <cygnine(a)remove.this.gmail.com> wrote in message <hks195$fpc$1(a)fred.mathworks.com>...

> And all of this is just a way for me to create nice Python-like importing structures in Matlab so that I don't have to pollute namespaces with all of the bazillions of functions that I use (plus I create different functions with the same name...Matlab doesn't like that). I'm not aware of a clean way to do this in Matlab. (I don't like messing around with the PATH variable, and I am aware of Matlab's builtin import statement...I don't like it.).
============================

Well, you said you don't like to mess with the path, but I'll just point you regardless to my FEX submission which does precisely that.

http://www.mathworks.com/matlabcentral/fileexchange/26221-namespace-scoping-operator

If you read the fine print, you'll see that there are some hazards, but the hazard is mainly if one of the functions you're trying to import is itself a path-manipulating function, which you say is already something you try to avoid.
From: Cygnine on 9 Feb 2010 11:54
"Matt J " <mattjacREMOVE(a)THISieee.spam> wrote in message
> http://www.mathworks.com/matlabcentral/fileexchange/26221-namespace-scoping-operator
>
> If you read the fine print, you'll see that there are some hazards, but the hazard is mainly if one of the functions you're trying to import is itself a path-manipulating function, which you say is already something you try to avoid.

Huh, that seems pretty snazzy. Obviously I don't understand the implementation yet, but it seems that it should be robust for most purposes. However, for me a big issue is speed (I run codes that collect many files from many different packages together). You do mention that path switching might be a little slow, and add this to whatever overhead is incurred by nesting things inside a class, and it might be too much for me.

Nevertheless, I'll probably download this and take a look-see. Thanks!
From: Matt J on 9 Feb 2010 13:46

> Huh, that seems pretty snazzy. Obviously I don't understand the implementation yet, but it seems that it should be robust for most purposes. However, for me a big issue is speed (I run codes that collect many files from many different packages together). You do mention that path switching might be a little slow, and add this to whatever overhead is incurred by nesting things inside a class, and it might be too much for me.
=========================

Well, keep in mind the alternative syntax shown in Example 2

newspace(Obj); %switches to temporary path

%do stuff

oldspace(Obj); %switches back to original path


The code in the "do stuff" section will execute under the temporary path with whatever speed it normally would in MATLAB. So, as long as these computations in that block are numerous enough or intensive enough that the CPU time is much longer than the time it takes to switch paths, the overhead due to path-switching will be 2nd order.

I don't know if that secnario applies to you...
From: Cygnine on 9 Feb 2010 15:00
"Matt J " <mattjacREMOVE(a)THISieee.spam> wrote in message
> Well, keep in mind the alternative syntax shown in Example 2
>
> newspace(Obj); %switches to temporary path
>
> %do stuff
>
> oldspace(Obj); %switches back to original path
>
>
> The code in the "do stuff" section will execute under the temporary path with whatever speed it normally would in MATLAB. So, as long as these computations in that block are numerous enough or intensive enough that the CPU time is much longer than the time it takes to switch paths, the overhead due to path-switching will be 2nd order.

Well, it turns out that such a scenario probably will apply to me. I certainly know that CPU time is significantly wasted if I overload subsref. I'll have to test it out to see if it applies when I change the path on the fly as well.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: imwrite image in an array
Next: CONVERT