undocumented expectations and behavior of fimplicit

I think we should establish here some basic information about fimplicit, since it seems to be very poorly documented.

Maybe the biggest omission is the explicit relationship between x,y,z in fimplicit's parameter f. The documentation says that f should accept matrices x and y and that z should be the same size, but this is insufficient knowledge to extend a function from scalar I/O to matrix I/O. It seems that fimplicit expects corresponding entries of x and y to be paired, i.e. for all i and all j, z(i,j)=f(x(i,j),y(i,j)). I'm not sure why this isn't openly stated in fimplicit's documentation. Perhaps the author was afraid that readers would infer from this that f should be implemented using loops, but the above relationship does not imply any such thing.

Another issue with fimplicit is that it seems to be secretly multithreaded. To plot the curve defined by f(x,y)=0, fimplicit evaluates f many times. According to my experience, code following the call to fimplicit executes in parallel (and non-deterministically) with the evaluations of f. This is extremely undesirable in some situations. Is there a way to disable this?

Thanks!

[Adam Danz]

I'm having trouble understanding the problem with the documentation or your expectation of the fimplicit function. Perhaps you could provide an example of what you're describing.

> It seems that fimplicit expects corresponding entries of x and y to be paired... I'm not sure why this isn't openly stated in fimplicit's documentation

What specific statement are you looking for? I think it's obvious that x and y should be paired in order to plot the results along the x and y axes. The documentation indirectly suggests this, fimplicit(f) plots the implicit function defined by f(x,y) = 0, where x and y are a function of f(). If x and y were not paired then the (x,y) inputs wouldn't work. But maybe you've come across an example that would clarify the problem.

Also, the tips section and the input argument section clearly instructs users to use element-wise array operators rather than matrix operators.

Regarding efficiency, the most efficienty way to plot the function is to compute the values and use plot() rather than letting fimplicit do the work.

[Herbert Triceratops]

@Adam Danz

• As the first sentence of my post indicates, things are missing from the documentation and I am merely trying to get something in print that fills those gaps, partly to help other users in the future. You say that the documentation "indirectly suggests" this, and that's exactly my point. Isn't it better, and equally easy, to just state directly how matrices x and y should be interpreted. There's nothing controversial here.
• The documentation's suggestion to use element-wise operators is sort of silly, and it certainly isn't a substitute for the x,y,z business. Not every function can be correctly vectorized by blindly inserting '.' before every operation. Whether or not a function can be written in a loop-less way, and how to do it, depends on the particular function.
• I'm not sure why you mention efficiency, since I never said anything about that. I'm asking why this function is non-blocking, or whatever, and if there is any way to avoid it. This is very unusual and there is no hint of this behavior in the documentation. Unexpected asynchronous execution of code is undesirable, period. Are you sure that you understand the behavior I'm talking about? This is not some broad, generic question.

[Adam Danz]

An explicit example of the scalar/matrix ambiguity you're facing using fimplicit would help to support your points.

"Things are missing" and "get something in print" is not clear. Perhaps you could suggest the exact sentence you think is missing in the feedback section at the bottom of the fimplicit page (first rate the page using the stars, then the feedback window will appear).

Multithreading for several numerical functions have been on by default in Matlab since 2008 [1]. I'm not a frequent user of fimplicit so your foobar example below was helpful to illustrate the problem. You may want to try to use the singleCompThread option [2]. But as I said in my previous comment, I avoid this by plotting the functions directly rather than using fimplicit.

[1] https://www.mathworks.com/discovery/matlab-multicore.html

[2] https://www.mathworks.com/help/matlab/ref/maxnumcompthreads.html

[Herbert Triceratops]

It's not a scalar/matrix ambiguity, it's simply a case of omitted information. What does x represent, what does y represent, and how are they to be combined, in the language of the original scalar-valued function?

There's already an example of what might be documented in my original post:

"for all i and all j, z(i,j)=f(x(i,j),y(i,j))"

This is very different from what is currently written "The function must accept two matrix input arguments and return a matrix output argument of the same size". You may think it's obvious, but most documentation would be deleted if the standard was "do people who already know how it works think it's obvious".

Regarding the maxNumCompThreads, that looks very promising. I will play around with it tomorrow. I actually tried it just now, changing from 2 to 1, but it didn't seem to solve the problem, maybe I'm tired or something. Regardless, thanks for that info, will be valuable somewhere, even if not for this.

[Steven Lord]

Which fimplicit documentation page do you feel needs more information? The one included in MATLAB that accepts function handles as the first input? Or the one in Symbolic Math Toolbox that accepts symbolic inputs?

[Herbert Triceratops]

@Steven Lord

The original question is about the former, MATLAB's native function that takes a function handle. I never used the symbolic version, but it seems like some but not all of what I said also applies there. For example, I suspect that there is no need to explain the relationship between x,y,z because the user provides an expression and MATLAB itself handles every aspect of the vectorization. Contrast this with the non-symbolic version, where the handle may be to a purely numerical function that does not have a symbolic form, or it is impractical to provide a symbolic form. On the other hand, it may be worth mentioning the asynchronous nature of the function in both.

Regarding the documentation on x,y,z, let me clarify that I fully understand that the missing information can be deduced. Certainly, there are not that many reasonable things one can do with x and y, and if one looks at particular examples of x and y, one will immediately recognize that pairing corresponding entries produces all possible combinations of a list of x-coordinates with a list of y-coordinates, i.e. a grid. None of it is genius-level stuff, I agree. I just feel that one extra line would let everyone skip this step.

[Walter Roberson]

The documentation says that f should accept matrices x and y and that z should be the same size, but this is insufficient knowledge to extend a function from scalar I/O to matrix I/O.

It might help if you were to give us an example function that can take in matrices x and y that are the same arbitrary size, and give back z the same size, but which is not vectorized so that z(i,j) is not a function of only x(i,j) and y(i,j) ?

The functions that come to mind for me that are not vectorized for output, rely upon particular aspect ratios (such as x and y both being square) or rely upon particular sizes that x and y will always be [e.g.] 7 x 3 so that a matrix-multiply works.

I have certainly seen people have trouble because the very first invocation of a function such as fplot() can be with scalar inputs, as fplot() probes to see whether vectorization works... but I am having trouble thinking of a function that works for arbitrary size arrays but whose output is not corresponding (well, except for functions that use random numbers.)

Answer 1

[Matt J]

According to my experience, code following the call to fimplicit executes in parallel (and non-deterministically) with the evaluations of f.

You can use drawnow() to force the plot to display at a particular point in the code, e.g.,

fimplict(___)

drawnow

More code

This is not specific to fimplicit, however. All graphics display commands in Matlab work this way.

[Herbert Triceratops]

That's a promising suggestion, but the execution is still fishy...

For concreteness, here's some example code:

   function z = f( x, y )
        disp( "foo" );
        z = x + y;
    end %function
    
    fimplicit( @f );
    
    % TBD
    
    disp( "bar" );

Surprisingly, the output is:

    foo
    foo
    foo
    foo
    bar
    foo
    foo
    foo

Replacing the "TBD" with a pause, of course, makes everything come out as expected, but this isn't a real solution.

I tried what you suggested, replacing "TBD" with drawnow, but it only works sometimes. Sometimes, there is still one extra "foo" after the "bar"...

[Matt J]

but this isn't a real solution.

Why not?

Sometimes, there is still one extra "foo" after the "bar"...

It would be good to see an example. I can't reproduce it.

[Adam Danz]

Neither can I reproduce the trailing "foo" with your solution but I only ran it about 30 times.

clc
fimplicit( @f );

foo
foo
foo
foo

drawnow

foo
foo

disp( "bar" );

bar

function z = f( x, y )
    disp( "foo" );
    z = x + y;
end %function

[Herbert Triceratops]

I appreciate the attempt, but I'm really looking for somebody from MathWorks to confirm some behavior. All this other stuff is moving farther and farther from the point. It should be clear that one cannot insert interactive pauses, or even timed pauses, into arbitrary code. I could investigate fimplicit.m myself, but that defeats the purpose of this website. I could write my own fimplicit, but that defeats the purpose of MATLAB. I just want somebody to say "yes, this is known behavior, due to X".

[Matt J]

I just want somebody to say "yes, this is known behavior, due to X".

Well, it's definitely known and intentional behavior, as the very existence of the drawnow command indicates. The stated purpose of that command is to sync graphics commands with the rest of the flow of Matlab. The fact that graphics commands can run asynchronously with the rest of Matlab is no secret at all.

You can also see the same behavior with apps. They will also run asynchronously with things that are happening in the command window.

It should be clear that one cannot insert interactive pauses, or even timed pauses, into arbitrary code.

Not to me. When you have asynchronous processes, commands that insert sync points seem like a very natural thing to have.

Answer 2

[Walter Roberson]

Yes, this is known behaviour, due to X.

fimplicit and fplot set up calculations internally, create the axes to draw into, create an internal calculation and drawing thread, and then return control. They refine the search mesh in the background, and fill in details as they go.

In this way, they can be reactive to zoom and pan and resize without the user having to know to call a specific "update fimplicit plot if it needs it" function.