@wzelik 

Alter the code to push the evaluated expression to a MathContainer component.

answer3.mw

@wzelik Ok, so put this line of code in the "Action When Value Changes" property of the Slider.

q := DocumentTools:-GetProperty('Slider0','value');

Does it matter to you, whether you assign to to `a` before you move the slider the first time? (It matters to Maple, depending on how you write it.) I'm supposing that you assign a:=q^2 first. If not, try it like a:='q'^2 using uneval quotes.

answer2.mw

@wzelik Ok, so put this line of code in the "Action When Value Changes" property of the Slider.

q := DocumentTools:-GetProperty('Slider0','value');

Does it matter to you, whether you assign to to `a` before you move the slider the first time? (It matters to Maple, depending on how you write it.) I'm supposing that you assign a:=q^2 first. If not, try it like a:='q'^2 using uneval quotes.

answer2.mw

Of the ways mentioned, doing either of the the following on a typical Matrix is not a good approach.

> a:=Matrix(4,7,rand(1..25)):

> op(a)[1], op(a)[2];

                                   4, 7

> op(a)[1..2];
                                   4, 7

The reason that is not good is that it unnecessarily forms all of op(a) which includes amongst other things a set of all the indexed entries. This is just production of collectible garbage for no purpose, and incurs an unnecessary memory management cost.

If you want to use op on the Matrix, better would be

> op([1,1],a), op([1,2],a);        
                                     4, 7

> op(1,a);                        
                                     4, 7

Here is a larger example

> restart:                                                                    
> a:=Matrix(400,700,rand(1..25)):                                             
> memalloc:=kernelopts(bytesalloc):                                           
> op(a)[1..2];                                                                
                                   400, 700

> kernelopts(bytesalloc)-memalloc; # increase in allocation, to get dimensions
                                   32499904

> restart:                                                                    
> a:=Matrix(400,700,rand(1..25)):                                             
> memalloc:=kernelopts(bytesalloc):                                           
> op(1,a);                                                                    
                                   400, 700

> kernelopts(bytesalloc)-memalloc; # increase in allocation, to get dimensions
                                       0

Of the ways mentioned, doing either of the the following on a typical Matrix is not a good approach.

> a:=Matrix(4,7,rand(1..25)):

> op(a)[1], op(a)[2];

                                   4, 7

> op(a)[1..2];
                                   4, 7

The reason that is not good is that it unnecessarily forms all of op(a) which includes amongst other things a set of all the indexed entries. This is just production of collectible garbage for no purpose, and incurs an unnecessary memory management cost.

If you want to use op on the Matrix, better would be

> op([1,1],a), op([1,2],a);        
                                     4, 7

> op(1,a);                        
                                     4, 7

Here is a larger example

> restart:                                                                    
> a:=Matrix(400,700,rand(1..25)):                                             
> memalloc:=kernelopts(bytesalloc):                                           
> op(a)[1..2];                                                                
                                   400, 700

> kernelopts(bytesalloc)-memalloc; # increase in allocation, to get dimensions
                                   32499904

> restart:                                                                    
> a:=Matrix(400,700,rand(1..25)):                                             
> memalloc:=kernelopts(bytesalloc):                                           
> op(1,a);                                                                    
                                   400, 700

> kernelopts(bytesalloc)-memalloc; # increase in allocation, to get dimensions
                                       0

@herclau I'm not sure what you're expecting, for a view of TM, since I don't have that book.

But have you tried either of these?

plots:-matrixplot(TM, orientation = [0, 0], heights = histogram, style = patchnogrid,
                  shading = zgrayscale, scaling = constrained, transparency = 0.0);

plottools:-rotate(plots:-listdensityplot(TM, axes = none), -(1/2)*Pi);

The commands plots:-matrixplot and ImageTools:-Preview both produce a 3D plot (and handily give you the "right" orientation for it). But these are larger structures, and can tax the Standard GUI when manipulating them with the mouse. The plots:-listdensityplot command produces a smaller structure which is a 2D plot and doesn't seem to hit the GUI as hard (although the black boundaries between the polygons might be undesirable for a final image).

@herclau I'm not sure what you're expecting, for a view of TM, since I don't have that book.

But have you tried either of these?

plots:-matrixplot(TM, orientation = [0, 0], heights = histogram, style = patchnogrid,
                  shading = zgrayscale, scaling = constrained, transparency = 0.0);

plottools:-rotate(plots:-listdensityplot(TM, axes = none), -(1/2)*Pi);

The commands plots:-matrixplot and ImageTools:-Preview both produce a 3D plot (and handily give you the "right" orientation for it). But these are larger structures, and can tax the Standard GUI when manipulating them with the mouse. The plots:-listdensityplot command produces a smaller structure which is a 2D plot and doesn't seem to hit the GUI as hard (although the black boundaries between the polygons might be undesirable for a final image).

Thank you very much!

Thank you very much!

Most of the search results are mere shadows of a single previous instance.

Most of the search results are mere shadows of a single previous instance.

It's an interesting way of thinking about it.

 (**) eq := f(x+y) = f(x) + f(y) + 80*x*y:

 (**) dsolve({subs(x+y=x,diff(eq,x,y)),f(1/4)=2,f(0)=0});

                                         2
                              f(x) = 40 x  - 2 x

It's an interesting way of thinking about it.

 (**) eq := f(x+y) = f(x) + f(y) + 80*x*y:

 (**) dsolve({subs(x+y=x,diff(eq,x,y)),f(1/4)=2,f(0)=0});

                                         2
                              f(x) = 40 x  - 2 x

Only slightly simpler is:

 (**) eq := f(x+y) = f(x) + f(y) + 80*x*y:
   
 (**) fx = rsolve( {eval(eq,y=x),f(1)=f1}, f(x) );

                                           2
                           fx = f1 x + 40 x  - 40 x

 (**) solve({%,eval(%,[x=1/4,fx=2])}, {f1,fx});

                                                   2
                         {f1 = 38, fx = -2 x + 40 x }

A slight variation is to first find f(1)=38 in two doubling steps (using x=1/4,y=1/4, etc). After which rsolve({eval(eq,y=x),f(1)=38},f(x)) attains the result.

Only slightly simpler is:

 (**) eq := f(x+y) = f(x) + f(y) + 80*x*y:
   
 (**) fx = rsolve( {eval(eq,y=x),f(1)=f1}, f(x) );

                                           2
                           fx = f1 x + 40 x  - 40 x

 (**) solve({%,eval(%,[x=1/4,fx=2])}, {f1,fx});

                                                   2
                         {f1 = 38, fx = -2 x + 40 x }

A slight variation is to first find f(1)=38 in two doubling steps (using x=1/4,y=1/4, etc). After which rsolve({eval(eq,y=x),f(1)=38},f(x)) attains the result.