Re: Iterative summation using sum(), fails with ezmesh

[Erik Leunissen]

On 04/10/2014 03:23 PM, Jordi Gutiérrez Hermoso wrote:
> On Wed, 2014-04-09 at 18:09 +0200, Erik Leunissen wrote:
> > On 04/09/2014 03:17 AM, Jordi Gutiérrez Hermoso wrote:
> > > On Tue, 2014-04-08 at 20:53 +0200, Erik Leunissen wrote:
> > >
> > >> Could somebody please explain why this is going wrong? Some directions
> > >> towards a remedy would be awesome.
> > >
> > > Error messages are meaningful.  Read them!
> > >
> >
> > That's the response of someone who presumes that I did not read them.
> >
> > What if I did read them, and failed to apply them to my case because of
> > misunderstanding?
>
> I have no evidence that you attempted to understand it. Did you? What
> were you able to figure out?
>
> > >> error: _sumh: operator +: nonconformant arguments (op1 is 60x60, op2 is 1x9)
> > >> error: evaluating argument list element number 1
> > >> error: called from:
> > >> error:   _sumh at line 30, column 5
> > >
> > > The first part tells you where the error is. You are attempting to add
> > > matrices of incompatible sizes.
> > >
> > > Go edit that file at that line and column and figure out what's wrong.
> > > Or insert a `keyboard` statement in there to go into debug mode and
> > > understand what's wrong (`whos` to see what variables you have, `doc
> > > dbstack` to learn more about how to use debug mode).
> > >
> >
> > You took the trouble to respond, and from a purely
> > technical/informational point of view, there is mixed value for me
> > in it.
>
> How far did you get with debug mode? I forgot to mention another
> useful way to get into debug mode: debug_on_error(1). When you're in
> debug mode, it's like an ordinary Octave session at the current
> location of where the debugger stopped you. All normal Octave commands
> work, in additional to the debugging commands. They all start with
> "db", type "db" and hit tab to see which ones you have, type "help
> dbanything" to see what the dbanything command does.
>
> > However, the tone and included presumptions (regarding my reading,
> > and my level of understanding octave) verge on presumptuousness.
>
> Let's focus on the problem at hand instead of your perceptions of me.

OK.

In the meantime I figured out that I grossly misunderstood the workings 
of element-wise operations; a misunderstanding at a very very 
fundamental, conceptual level. What put me on the track of seeing that, 
is your remark:

  "You are attempting to add matrices of incompatible sizes."
                             ^^^^^^^^

For easy reference, here's the script again:

--
function rv = C(x,t)
        rv = 2.*x.*sum(_sumh(x,t, -4:4));
endfunction

function rv = _sumh(x,t, it)
        rv = exp(-(x.+(it.-1./2)).^2./t);
endfunction

domain = [-5, 10, 1, 10];
graphics_toolkit gnuplot
setenv GNUTERM wxt
fh = @(x,t) C(x,t);
ezmesh (fh, domain);
--

Somehow the idea took a firm place in my brain, that a function that 
does just element-wise operations (my function C), passes matrix 
*elements* to its sub-functions, sum(_sumh) in my case. Therefore, it 
was just beyond my consideration that this could be otherwise, and 
that's why the phrase "non-conformant arguments" in the error message, 
just didn't make any sense to me.

Now, after your hint, I recognized my misunderstanding, and it was easy 
to confirm it. No special debugging mode needed. A simple disp(x) inside 
_sumh() sufficed.

If you agree with my above description, then this is a case of newbie's 
ignorance/confusion about how and where element-wise operations are 
carried out.

As for a resolution, i.e. how to perform an iterative summation of a 
term, for each of the points on a mesh, I'm not there yet.

Since the attempt in my script was conceptually wrong, I now realize 
that you may also not understand at all what I'm trying to achieve. In 
*scalar* form, I want to evaluate the following function on the mesh 
points of a grid (to produce a 3D-plot):

                  4
                 __
   C(x,t) = 2*x* \  - exp(x+(i-0.5))^2
                 /   -----------------
                 --        t
                i=-4

Of course I'd prefer a vectorized way, but right now I don't see which 
road would lead to that, but I'm not yet done exploring that. If you see 
right away that there is no such way, then please let me know, otherwise 
I'm prepared to explore further to find it on my own.

Thanks,

Erik Leunissen


> What happens if you do C([-5,10],[1,10])? What do you think should
> happen?

That's not needed anymore now. I understand my misconception.

> - Jordi G. H.