## 20133 Reputation

14 years, 359 days

## Maple 13...

For a very old version like Maple 13, and for a 3D plot, you may need to use an approach like Kitonum has done here.

## if vs piecewise...

@mmcdara Actually it's even less useful to utilize `if`, since that applies evalb itself.

Above, I had it in my head that you were trying piecewise rather than `if`.

For the Mean example it is possible to grind it out with magic amounts of delayed evaluation. But it gets ugly. And that kind of unevaluation quote usage it prone to breakage since every intermediate evaluation strips off a pair. Not recommended.

 > restart;
 > with(Statistics):
 > Dice1 := RandomVariable(DiscreteUniform(1, 6)): Dice2 := RandomVariable(DiscreteUniform(1, 6)):
 > K := (a,b) -> piecewise(Or(a=1,b=1), -4, abs(b-a));

 > K(Dice1,Dice2);

 > Mean(K(Dice1,Dice2));

 > W1 := (a,b) -> piecewise(a=1 or b=1, -4, abs(b-a));

 > W1(Dice1,Dice2);

 > Mean(W1(Dice1,Dice2));

 > W2 := (a,b) -> piecewise('a=1 or b=1', -4, abs(b-a));

 > W2(Dice1,Dice2);

 > Mean(W2(Dice1,Dice2));

 > W3 := (a,b) -> `if`(a=1 or b=1, -4, abs(b-a));

 > W3(Dice1,Dice2);

 > Mean(W3(Dice1,Dice2));

 > W4 := (a,b) -> '''`if`'''('a=1 or b=1', -4, abs(b-a));

 > W4(Dice1,Dice2);

 > Mean(W4(Dice1,Dice2));

 >

## Question 1...

@mmcdara I have to dash out the door right now, but regarding Question 1,

The lowercase `or` and `and` commands do an immediate evalb of a strict equality or strict "non-equality".

```a = b or u = 5;
false

a = b or u < 5;
u < 5

b <> 4 or 5 = 7;
true

a = b and b <> 4;
false
```

It can sometimes work if you use a pair of non-strict inequalities (which logically imply the strict equality). Eg,

```a<=b and a>=b and u<5;
a <= b and b <= a and u < 5
```

Hence my use of the capitalized `Or` command.

Here's what you were, in effect, passing to the Mean command,

```with(Statistics):
Dice1 := RandomVariable(DiscreteUniform(1, 6)):
Dice2 := RandomVariable(DiscreteUniform(1, 6)):

K := (a,b) -> `if`(a=1 or b=1, -4, abs(b-a) ):

K(Dice1, Dice2);
|-_R16 + _R15|

Mean(K(Dice1, Dice2));
35
--
18

Mean(abs(Dice2-Dice1));
35
--
18
```

## return value...

@emendes From the second bullet point of the Description in the Help page,

"The return value of the command is the identity of the inserted parent Table, as a string. The display of the returned value can be suppressed by terminating the statement with a full colon."

You could read the other bullet points in that Description, as there are ramifications as to what you can and cannot do with Tabulate.

The return value, being the identity of the parent Table, could allow one you to utilize the repliceid option of the DocumentTools:-InsertContent command to redisplay entirely new content to the originally inserted Task region (even from another Execution Group). That's a very esoteric use, and I don't recall ever seeign anyone else use it.

It's easier to do running replacement from within the very same Execution Group, simply by calling Tabulate more than once. This can produce a nice effect if you want in-place overwriting of the displayed content at key points of a long computation.

But it's important to realize that, unlike plots:-display, the return value of Tabulate is not any kind of "plot" structure understood by commands from the plots package.

By the way, you can resize the GUI Table that is inserted by plots:-display. You can even right click in the Table and adjust the Table properties, to change the exterior and interior borders, width-mode, etc. But such changes are not stored in any usual programmatic structure, and are transient in the sense that repeating the plots:-display call will wipe out such manual changes.

In summary, Tabulate gives only an immediate and purely printing effect, but allows you to programmatically control more aspects of the encapsulating GUI Table than does plots:-display.

## trig...

@Rim So, clearly you need at least some amount of trig simplification, because your examples might include the need to make, say, sin(t)^2+cos(t)^2 -> 1.

If you're building up bigger and bigger expressions within a loop, it's might be best to keep the intermediate expressions "simplified" at each iteration. But you may wish to avoid everything except basic factoring/grouping and that trig simplification. That is, you may be better off with some degree of control about expression swell and trig simplification at each iteration, but without `simplify` trying its hardest to get the very "simplest" representation at each iteration.

I'm mostly just guessing, because I don't have the full package or the complete examples.

So I'll make a few suggestions for replacement to the costly (according to your analysis) call to just `simplify`. You could try them out separately and re-profile. Perhaps one of them might be faster for your full examples.

The idea is to replace the call  simplfy(ee)  which you've identified as a bottleneck, where ee is just the single expression argument.

simplify(ee, trig)
simplify(normal(ee, trig))
`simplify/nosize`(ee, trig)
`simplify/nosize`(normal(ee),trig)

There are other actions that might be thrown into this mix (combine, factor, frontend, etc).

What might be even more fruitful is if you could produce some enormous, "wrong" final result that has not been simplified as you need. If you can produce such, you could upload a worksheet here as an attachment (big green up-arrow).

What version are you using, BTW?

some_trig_simp.mw

## suggestion...

@Rim Suppose that the code just calls simplify at some internal part of the code.

One possibility is that the code does this inefficiently, eg. calling it unnecessarily and repetitively inside a loop. Presumably you are already checking out for that.

Another possibility is that simplify is too costly a tool for the simplification task at hand. We might be able to help there, but it would likely require several large examples of both input expression and desired output expression. There may be a combination of lighter weight commands that produce the same simplifications.

If you repost the procedure's source code here the please provide either a URL where you got it or the name of the author(s).

## published where?...

Free-dealing/Free-use exceptions to copyright for some purposes can include the need for proper attribution.

But also (and if applicable here then supercedent) copyright free-use pertains to published work. If the code itself has not been published by its rightful owner then the question of copying/reproducing it is moot. Publishing someone else unpublished work is not copying and is not ok on the fair-dealing/fair-use grounds governing copyrights.

For example, this thesis says, in its Appendix A, that some of the "files can be received from the Chair for Automation and Control of the Department for Measurement and Automation of the University of the German Armed Forces in Munich". That need not mean that the code available only in said files is published.

## someone else's work...

@Carl Love He previously posted the full code of the procedure skewSimplifier. I deleted it as an unattributed procedure from someone's else's package and thesis, posted without the author's explicit permission.

If he can show the permission of the author of that full procedure to re-post it here, or at the very least add proper attribution, then I'll let it stand.

Even fair use (or fair-dealing) exceptions to copyright generally requires proper attribution of authorship.

## why Maplets?...

I'm interested to know why you want to program this using Maplets rather than Embedded Components. (Each has its merits, and drawbacks.)

## Matrix...

These both work for me as I might expect,

```ExportMatrix("EM.txt", Matrix(Vector[column](5,i->i)), target = csv);

ExportMatrix("EM.txt", Matrix(Vector[row](5,i->i)), target = csv);
```

So perhaps you could try wrapping your result (from Statistics:-Sample) in a call to Matrix. (A column Vector or a row Vector produces the nx1 or 1xn Matrix, accordingly.) This seems to work reasonably with ExportMatrix.

## the code...

Where is the code itself?

## clues...

@tomleslie The preamble in the OP's code, looked to me as if it were being used in the construction of the eqs[i], but unfortunately not in a fully programmatic way (or, at least, not a way revealed to us). The preamble code made me suspicious that the equations might be underdetermined and possibly admit infinitely many solutions. Impossible to tell for sure without getting rid of the floats and discovering just how the eqs[i] are built. But I'd already noticed several familiar floats.

It's a real shame that so many posters here only reveal a portion of their goal. It is a very common phenomenon that a Questioner here will only ask about the problematic methodology that they've chosen for just one small step in a (possibly dubious) overall approach to a wider problem.

## why floats?...

Why do you use floating-point numbers in the first place?!

I mean, are you trying to use these values, or something similar?

```phi[1][0], phi[2][0], phi[1][1], phi[2][1], phi[1][2], phi[2][2]
:= sqrt(2), sqrt(2), (4*t-1)*sqrt(6), (4*t-3)*sqrt(6),
(1/2)*sqrt(10)*(3*(4*t-1)^2-1), (1/2)*sqrt(10)*(3*(4*t-3)^3-1)```

If so then why not use exact rationals for alpha, lambda[3], etc. And why not subsequently construct the eqs[i] from the X.Y,H[1],etc and their derivatives?

Maybe you'd be able to get an exact root, which you could approximate quickly and with less accumulated roundoff error.

Maybe you'd even be able to get an exact symbolic formula for a generic form of the root for general k and M. (I can't tell, because you've already done the dubious step of cut and pasting just to get the formulas used used to construct eq[i]. And the formulation has been obscured...).

## A symmetric, B symmetric positive defini...

 > restart;
 > kernelopts(version);

 > with(LinearAlgebra):
 > Dimensions( M );

 > interface(rtablesize=70):
 > Digits:=150:
 > infolevel[LinearAlgebra]:=1:
 > A:=Matrix(eval(M,P=0),shape=symmetric):
 > B:=Matrix(-diff(M,P), shape=symmetric):
 > E:=CodeTools:-Usage( Eigenvalues(A,B) ):

Eigenvalues: calling external function

Eigenvalues: CLAPACK sw_dggevx_

memory used=4.10GiB, alloc change=38.00MiB, cpu time=15.01s, real time=12.95s, gc time=4.82s

 > Bpd:=Matrix(B,shape=symmetric,attributes=[positive_definite]):
 > Epd := CodeTools:-Usage( Eigenvalues(A,Bpd) ):

Eigenvalues: calling external function

Eigenvalues: CLAPACK sw_dsygvd_

memory used=498.11MiB, alloc change=-4.00MiB, cpu time=1.65s, real time=1.39s, gc time=567.68ms

 > evalf[10](Epd[1..5]), evalf[10](sort(Re(E))[1..5]);;

 > infolevel[LinearAlgebra]:=0:
 > Norm( Epd - sort(Re(E)) );

 > for d from 48 to 58 do   Digits:=d:   Epd2 := Eigenvalues(A,Bpd):   nrm := Norm(Epd - Epd2):   print(d, evalf[2](nrm)); end do:

 >

## mechanism is weak...

@rquirt Yes, thanks for the upload. (You don't need to insert all the content of the upload, every time. Inserting the link suffices.) But thanks.

The mechanism the fsolve uses to determine what are the units (of both the input and the output) is not strong. It seems to require the literal presence of the output units in (some addend of) the expression to be solved. But that is quite fragile and breaks for some choices of fsolve calling sequence. It is inadequate for both operator form as well as the unevaluated function call. I will submit some bug reports.

Here are two workaround that succeed for your procedure test.

The first adds an insignificantly small amount of Unit(W), which is adequate to let fsolve figure out the output unit and not balk later. I note that in your examples with just the single function call you already had a constant term in Unit(W). It was the absence of such which "broke" the test example.

The second, which was also in my answer, essentially strips out input and output units and proceeds with raw numbers.

```fsolve(test(x)+0.1e-99*Unit(W), x = 20*Unit(degC) .. 30*Unit(degC));

23.94824265 Unit(°C)

fsolve(x -> test(x*Unit(degC))/Unit(W), 20 .. 30)*Unit(degC);

23.94824265 Unit(°C)
```
 First 68 69 70 71 72 73 74 Last Page 70 of 435
﻿