@CakePie No, it would not make sense to substitute lign5 into Matrix T.

lign5 is an equation involving symbolic names.

T is a Matrix built with coefficients of such symbolic equations. But lign1 does not appear explicitly anywhere inside T.

GenerateMatrix takes one or more equations and turns that into one or more Matrix rows.

So you can replace a row of Matrix T with a new row produced by GenerateMatrix. (That's what my answer did.)

But it doesn't make sense to want to substitute equation lign1 by a new equation lign5 in T, since T doesn't contain such symbolic equations.

I hope that helps some.

By the way, how does lign5 arise? Is it the result of some command or other computation? Or are you typing it in fresh? If it is computed, then what does it mean? (Is is supposed to be the result of taking some linear combination of the other rows?)

What database do you mean?

acer

@Markiyan Hirnyk Having already created Matrix T it is shorter to do,

T[1,..] := GenerateMatrix([lign5], [x,y,z], augmented):

But of course it's not necessary to use GenerateMatrix again, if one is simply typing in the defn of lign5. In such a case it would be simpler still to just enter,

T[1,..]:=<1|1|1|6>:

@H-R I was working on it... but am not satisfied.

@acer In Maple 15 there is no ColorTools:-RGB24ToHex, hence the rgb2hex procedure.

I suppose that for a list `L` of three nonnegints between 0 and 255 one could also do,

sprintf("#%06X",L[1]*65536+L[2]*256+L[3])

Only when n is very small (ie, n=1,2,3 say) are more than a few iterates needed to get an accuracy change that is visible in a plot. And even then it is only detectable for certain ranges of x_l and C_a, it seems.

The Explore call in the end of the attached worksheet (which requires Maple 18) is set up so that moving just the `max_iter` slider (with all other parameters taking the specified initial values) illustrates the need for more iterates at very small n.

itsme1.mw

This computes all n from 1 to 10^5 in about 3 ms (milliseconds) on my machine with the Compiler working, and about 50 ms if it has to falll back to evalhf instead. As mentioned before, it might also be multithreaded by splitting the action across Array A with Threads:-Task (since it does not use the previous n's solution as the initial value). But maybe it's fast enough now?

@itsme  Sorry, I had the sequence inside the Array hard-coded to size 1000. Replace,

n=1..1000

with,

n=1..max_n

inside the `seq` call inside the `Array` constructor call. 

I'll likely try a few things... after the holiday weekend.

Quick question, though: how accurate do you want the results?

acer

@jonlg The display command that you are trying to use is part of the plots package.

Your usage problem is covered in the 4th bullet point of the Notes section of that display help page.

Either call it like, say,

plots:-display(...);

or load the package before you use it the first time in a session.

with(plots):
display(...);

But I can let you know that it will only show the result for your `plot1`. Your `plot2` is incorrectly constructed as a mismatch of expression form (where you substitute N for n in expression RR) and supposed procedure form (where you build the sequence using RR(k) as if RR were a procedure).

@kneehowguys The with() effect lasts until you restart, or into you issue a matching unwith() call.

Your problem with `rref` is that there is no such command exported by the LinearAlgebra package. There is a much older and now deprecated package called `linalg` which has a member named `rref`.

I suggest instead you try,

LUDecomposition( M, output=R );

to get the reduced row-echelon form of Matrix M. That uses LUDecomposition which is a command in the LinearAlgebra package.

You might also want to look at the Student:-LinearAlgebra package, or read the manual.

@jonlg Your followup worksheet MapleSimulation_test2.mw has a few errors.

There are errant spaces between the `sqrt` and the open-braces that follow it, in the 2D Math input where you define lambda1 and lambda2. That extra space makes those get interpreted as implicit multiplications like sqrt * (....) rather than the desired function call sqrt(...).

In that same worksheet, where you have RR as an expression in unknown N the plot can be done as follows. The view is optional.

plot([seq([N, RR], N = 2 .. 10)], style = point, view = 0 .. 5);

You might possibly be interested in the plot of both the real and imaginary parts of RR, where the imaginary part equals zero when N is an integer. (I realize that your described your problem as concerning a "discrete function". It's just FYI.)

plot([Re(RR), Im(RR)], N = 2 .. 10);

@Alejandro Jakubi OK, though that often is not the case. Do such examples (if you have some) also affect the method of export-to-.mpl or copy & paste as plaintext?

BTW, one might also be able to copy and paste to Code Edit region or TextArea Component.

@Vesnog I don't know that the black arrow displayed by doing a context-menu action within a Document Block can be converted afterwards to an explicit command (as if it had instead been done in just an Execution Group).

@Jazen1 Why are you asking me, as if I hid your palettes? Note that I did not suggest using palettes at all.

contourplot3d has similar problems, though not always to apparent at default `view`. If the view is forcibly restricted to something similar to what contourplot produces automatically then countourplot3d can produce similar aberrations as contourplot does for the same contour values.

plots:-contourplot3d(1/(x^2+y^2), x=-1..1, y=-1..1,
                     view=[-0.25..0.25,-0.25..0.25,0..100],
                     grid=[50,50], orientation=[90,0,0]);

plots:-contourplot3d(1/(x^2+y^2), x=-1..1, y=-1..1
                     , view=[-0.25..0.25,-0.25..0.25,0..500]
                     , contours=[seq(1..301,5)]
                     #, grid=[100,100]
                     , orientation=[90,0,0]
                     );

plots:-contourplot3d(1/(x^2+y^2), x=-1..1, y=-1..1
                     , view=[-0.15..0.15,-0.15..0.15,0..700]
                     , contours=[seq(1..701,25)]
                     , orientation=[90,0,0]);

The central problem is that these methods are not adaptive, as Alejandro pointed out, and for problematic examples one may have to refine the whole mesh.

One advantage of `contourplot` over repeated calls to `implicitplot` is that the latter involves recomputing values on the initial grid for each requested contour value. Another is the filled regions. It would be nice to get an improved 2D contour plotting routine that was adaptive, re-used grid values where possible/relevant, and offered filled regions.