## 7722 Reputation

14 years, 139 days

## On _nparams...

@acer The special symbol _nparams is rarely used in Maple code.  A quick search of the Maple archive maple.mla indicates it isn't used at all, for any practical application.  It is used in some conversions to/from inert procedures, but that is only to handle it's (non)occurrence in code being transformed.  Curiously, since you mentioned it is not specific to the debugger, the one place where I have used it, and found it invaluable, is in code that is used in the Emacs/Maple debugger to better display the arguments of a given procedure. In that application it is necessary to know how many of the arguments were declared, etc.

## Permuting...

@bmartin Note that you can directly apply this permutation to the list to verify it:

```(**) L := [8,1,7,12]:
(**) P := sort(L, `>`, output=permutation);
P := [4, 1, 3, 2]

(**) L[P];
[12, 8, 7, 1]
```

## Observation...

@vv Thanks.  That's a better approach; I've incorporated it into the worksheet.  Note that the peak of that curve is where the target rating matches your rating (but not your strength).

## not sure...

@vv Am not sure.  I suspect there are multiple solutions and fsolve is picking the wrong one, at times.  Restricting the range to r1 .. 1700 should help, but the call to fsolve is returning unevaluted for r1 > 1673.

Followup: Here's a fix that better limits the solution space

```Ept := Glicko:-ExpectedDelta(1700, r1, r2):
dEpt := diff(Ept,r2):
r2vsr1 := r -> fsolve(eval(dEpt,r1=r), r2, r/2..1700):
plot(r2vsr1, 1000..1700, 'numpoints' = 30);
```

I updated the worksheet to use this code, but otherwise left the post alone

## has...

@Kitonum Be careful with has.  It works fine here, but could be problematic for a more general problem where L1's sets contained other than integers. Suppose

```L1 := [{2,3},{2,f(3)}, ... ]:
```

## separation...

@Mac Dude A user should be able to globally configure a package, say by making a suitable addition to the Maple initialization file, without loading the package, otherwise the package would always be loaded whenever Maple was used, regardless whether the package was being used. This precludes making the configuration mechanism local to the package, because accessing it would load the package.  Thus the use of globals.  The issues you dealt with are precisely the ones I'm dealing with.

The Configure object I proposed does solve the problem, but it seems overkill and I don't like the access mechanism; using a member operator (foo:-default) is nicer than an index (foo['default']). A record that strictly enforced its types would be close to ideal.  Some packages might have options that cannot be completely validated via a type, so a more general mechanism could be occasionally useful.

## embedded components...

One way to implement that in a Maple worksheet is to add a few embedded components, say a text area to accept the user input, a button to process it, and a math container to display the output.  Is that what you have in mind?  Or something different?

## Make it easy on us...

@vanzzy Please don't post an image of the equations; nobody want's to retype them.

## post worksheet...

For the quickest and must useful response, it is generally best to upload the worksheet to this site.  Use the green up-arrow on the toolbar (here).

## Equations...

What equations do you want for HW5DC, the motor/pendulum?  The closed loop equations for the entire system, including the step source?

## assignment...

@Carl Love Really clever technique (though the Matrix operations are considerably slower).  The use of the assignment operator as a first order expresssion, for example, y := (x :=1), is new for Maple 2018 (I believe) and the documentation for it a bit sparse, see the penultimate bullet in the Description of the help page for assignment.

Further How long did it take for the loop that assigns T to complete? That needs to be rethought.

Later Am thinking much of the time is wasted allocated memory for the internal array used to compute the product.  The row vector can be eliminated by using add:

```   in P do
T[(v := add(pm.t))] := T[v] + 1;
od:
```

That helps, but there is still the memory allocation for pm.t. Ideally one could avoid that by doing something like

```   V := Vector(3):
in P do
T[(v := add((V := pm.t)))] := T[v] + 1;
od:
```

Not too surprisingly, there is no change because the Matrix-Vector product always allocates memory for the result. That could be avoided with a suitable call to a routine, but that is less nice.  For example,

```VMT := proc(V,M,T)
local i,j;
for i to 3 do
end do:
V;
end proc;
V := Vector(3):
in P do
T[(v := add(VMT(V,pm,t)))] := T[v] + 1;
od:
```

Despite handling the matrix-vector product manually, that is considerably faster because no additional memory is allocated.  There should be a nicer (prebuilt) way to do this, but I'm not aware of it.

## don't know...

@brian bovril I don't understand that part; it seems to contradict the whole point of the exercise.

## Example...

Show an example of what you have done.