@tomleslie It wasn't clear (to me, at least) whether the answer is supposed to be in terms of units A^2 or A^2*s. Perhaps the target answer was supposed to be obvious?!

@mmcdara The padding value is in pixels, afaik. (Well, pixels in the usual sense, ie. at 100% zoom. Let's not get into dot-pitch.)

The example mostly works for me in my Maple 2020 GUI. Some things work imperfectly when rendered by this site's considerably older backend engine.

@zphaze You showed two attempts.

The first doesn't make sense to me.

The primary problem with the second is the integrand itself, which as written is already problematic in the Units:-Standard framework, even outside of the int call. The Units:-Simple subpackage was designed with one of its principal themes being to allow that kind of tacit dimension for an unassigned name such as the t in your second example's integrand.

If you don't want the strictures of the Units:-Standard package then don't load it.

You can call it whatever you want.

After normalizing to 0..1 (and prior to scaling), you could subtract from 1.
 

>  restart; >  P1:=plots:-fieldplot([1, y^2 + x], x = -10 .. 10, y = -6 .. 6,                  fieldstrength = fixed,                  color = COLOR(HSV, 0.5*sqrt(((y^2+x)^2+1)/((6^2+10)^2+1)),                                     1.0, 1.0)): >  P2:=plots:-fieldplot([1, y^2 + x], x = -10 .. 10, y = -6 .. 6,                  fieldstrength = fixed,                  color = COLOR(HSV, 0.5*(1-sqrt(((y^2+x)^2+1)/((6^2+10)^2+1))),                                     1.0, 1.0)): >  plots:-display(Array([P2,P1]),size=[400,400]);

Download color_formula_rev.mw

@mmcdara I like your Answer (and Tom's, too). I especially like the rowspan use.

For fun, here I get black 2D Input, with numeric formatting of the last column, and alternating background color varying with the k sequence index.

(I don't know why this one doesn't render as nicely as yours on Mapleprimes. It does look much better in the Maple GUI. Was yours a screenshot?)

Layout_1_ac.mw

@mmcdara If you are using Maple 2015, or if the OP is using Maple 17, then it is significantly faster to do it like so:

Download Try_This_2_ac.mw 

In older versions there is (unnecessary, unwanted) wiping of cached information that occurs even when the parameters are set to their same, extant values. This causes considerable inefficiency, that can be avoid by the simple check that I show here. I believe that inefficiency is fixed in recent versions.

@ahmeng From my Maple 2017.2 for 64bit Linux,

Download isect.mw

When solve detects the explicit float coefficiant that I introduced into the example it tries to resolve the ensuing approximate RootOfs (via evalf, etc). So it's similar to evalf after allvalues. For me it is not fast on first attempt (and being fast upon repeats means nothing here -- it just remembers some results internally).

The maxsols for fsolve (univariate non-polynomial) usage can be traced through to a iterated use of Rootfinding:-Nextzero, which is yet another approach that one could do up manually.
   showstat(fsolve::scalarmultiple)
It is true that the maxsols option is not documented for the univariate nonpolynomial case. But it is documented for the univariate polynomial case. Your screenshot doesn't show even that, though, since it seems you are citing ?fsolve and not ?fsolve,details .

In your example, L is a table and not a list.

I changed this comment from another thread into its own Question. The subject matter is quite different.

Your Question lacks detail and clarity.

Your Matrix B has 22 rows and 4 columns.

What do you hope to get, when you write terms such as  B[1..1,[17, 18]] ? Do you understand that refers to the (nonexistent) 17th and 18th column entries of the first row?

What parts of B are you trying to plot?

How should we "correct" your code when you didn't tell us anything about what you wanted it to do?!

@dharr I adjusted your Answer slightly, and inlined images (right-click exporting the plots) so that it would be certain that Mapleprime's own rendering wasn't interfering.  I hope that's OK.

@nm You have G as  x*sin(Pi*x)  instead of  x*sin(Pi*y) .

But even if your second result were to attain, it has x restricted to integers and hence not free.

@dondomingo But you won't know home many solutions there are and how many names to use, in general. I don't think that is a good methodology.

I agree, nobody wants to have to re-type or copy&paste from output. It's not good programming to have to do so.

Just assign the full list of solutions to a single name, let's call it Sol, say.

Then you can get at the first solution by indexing, as Sol[1]. And then you evaluate any formula involving x and y using 2-argument eval (as showed in my Answer above). You could even access just the simplest formula x, or y.

Eg,
   eval( x, Sol[1] );
   eval( y, Sol[1] );
   nops(Sol);    # how many solutions there are
   eval(  x^2+sin(y-x),  Sol[3] );
etc.

@alijp I don't understand why you didn't show that when you initially asked the Question.

Now you've introduced the `i` parameter when you already had two (r and phi). So you don't need `i`, now.

Is your problem with the differentiation at symbolic order n?

(I have marked your Question as being for Maple 17.)

I could point out that a function might by undefined on an interval between discontinuities (including a pair returned by discont). And iscont could return true for the test on that open interval. This might matter to you.