From: Paul K. <pki...@ja...> - 2002-09-11 15:57:48
|
On Wed, Sep 11, 2002 at 08:40:55AM +0100, Etienne Grossmann wrote: > Hello > > On Tue, Sep 10, 2002 at 06:34:19PM -0400, Paul Kienzle wrote: > # Etienne, > # > # I would model this on fplot, which does this for functions of one variable. E.g., > # > # fmesh('fn') - plots the bivariate function or expression. It is a function > # if it is a single identifier otherwise it is an expression. > > I prefer having the building of data and plotting separate. Reasons: > there are many plotting methods (gnuplot ...); it is easy to call the > data-building function from within a plotting function. Of course, > fmesh() can be called from any other plotting function, but still I'd > rather keep code for plotting separate. > > Otoh, since you propose many calling methods (below), the code for > determing the boundaries, the size of the grid etc would have to be > repeated in the plotting and in the data-building function (and > repetition of code isn't fun). So one function could be better in that > respect. The idea is to get a simple view of a 2D expression with the minimum of hassle. The single plotting function called [mesh(x,y,z)] will hopefully be called the same no matter whether you are using gnuplot, plplot, or (when I get off my duff and start writing it) BLT. If users want fancy surfaces, or more control over the look and feel of the plot, they can easily grab the return values and call their own function just like they would have to do if no simple plotting were provided. > > # fmesh(x,y,'fn') - use the given x and y grid spacing > # > # fmesh(...,[xmin xmax ymin ymax]) - use the given axis limits > # > # fmesh(...,n) - use the given number of steps in each dimension x, y > # > # z = fmesh(...) - return the mesh rather than plotting > # > # [x,y,z] = fmesh(...) - return the mesh and the mesh spacing > # > # fmesh(...,'loop') - don't vectorize the expression, but instead evaluate > # it once for each point in x cross y. > > Other question: 'loop' by default, or not? Looping will be excruciatingly slow. The vectorized variety should be easier to invoke since it will be the most frequently used. > Also, the user may want to provide an already vectorized expression. Which is why I need to strip the ".." after vectorizing. The alternative is to write vectorize so that it doesn't vectorize an expression which is already vectorized: function expr = vectorize(expr) if isempty(regexp("[.][*/^]",expr)) expr = strrep(expr,'*','.*'); expr = strrep(expr,'/','./'); # I forgot this one before. expr = strrep(expr,'^','.^'); endif endfunction > I did not provide an auto-vectorize feature, but let the user put the '.'. I'm not very happy with the idea of auto-vectorize either, but it mostly does the right thing. It's unfortunate for loops are so slow that we have to go to great lengths to avoid them. > I thought there may be some cases where there are some matrix products that > shouldn't be .-prefixed. Hard to imagine: you are evaluating on an indeterminate grid without any access to local variables. Does it really make sense to say something like: fmesh("y + (x*x')") or fmesh("exp(x+y)/norm(x'*y)") Maybe. At least with auto-vectorize it will fail with something like: error: product: nonconformant arguments (op1 is 1x3, op2 is 3x1) so the user will know that something has gone wrong. This is after all a function to make common things more simple, not a replacement for meshgrid. > > [snip] > # To distinguish between expression and function use: > # > # if all(isalnum(expr)), z=feval(expr,x,y); else eval(["z=",expr,";"]); end > > Should check for "x" and "y" too. Yeah, that would be easy enough. > > # To vectorize we will need a function which converts bare ^ and * to .^ and .*. > # This would be something like: > # > # expr = strrep(expr,'*','.*'); > # expr = strrep(expr,'^','.^'); > # expr = strrep(expr,'..','.'); > > Beware of trailing "..." This is moot if we only vectorize expressions that don't have any .*, ./ or .^ operators. > > [snip] > # I would put it in main/plot. > # > # What do you think? > > Don't know, there's no rush so I'll let the question rest. > > Cheers, > > Etienne > > -- > Etienne Grossmann ------ http://www.isr.ist.utl.pt/~etienne > > > ------------------------------------------------------- > In remembrance > www.osdn.com/911/ > _______________________________________________ > Octave-dev mailing list > Oct...@li... > https://lists.sourceforge.net/lists/listinfo/octave-dev |