acer

29859 Reputation

29 Badges

18 years, 199 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by acer

@C_R In your previous Question (also about indexed procedure calls) my Answer made use of op(1,procname) .

I considered mentioning that you might also add various guards, defensive programming, further manipulation of procname, etc, to that.

When you call  f[a,b,c](...)  then inside f a reference to procname will evaluate to all of the indexed name f[a,b,c].

And you can poke at that just like any other indexed name. Using op you can get its operands. Using op(0,procname) you can get the base name f. And the usual type checks for names can be utilized, as Preben's shown above.

f := proc()
  lprint( procname );
  lprint( op(procname) );
  lprint( op(0,procname) );
  NULL;
end proc:

f[a,b,c]();

f[a,b,c]
a, b, c
f

Download procname_ex.mw

[Sorry, I had to do a chore, and split my response.]

The Help page ?simplify,details has a table of links, in its Options section.

The text labels of those links are names of some options that the simplify command admits.

The links go to Help pages whose Topics are available in the Help system in the form simplify/name, where name is one of those labelled options. There are actually procedures assigned to most of those, eg,
   showstat(`simplify/sqrt`);
   showstat(`simplify/piecewise`);

That Help page ?simplify,details describes them as "simplification procedures" because 1) most are such, and 2) internally simplify's implementation of its approaches is organized by procedures.

So, the internal mechanisms corresponding to the various options of simplify are mostly organized by procedures with a naming convention similar to the option names. I suspect that this is the key thing that you hadn't realized.

Note 0: I don't know how you came up with the syntax simplify[sqrt] or combine[trig].

Note 1: One reason for the that (old) internal naming convention involving "/" is kind of historical. A long time ago it was also quite usual for the some names of ancillary (internal) procedures and of the Topic of some Help pages to be split by "/". That was partly due to the way that source code was stored in directories by Maplesoft, in Unix.

Note 2: Several kernel builtin commands allow for an extension mechanism that also relies on the form,  `foo/name` . So, there's some more historical convention...  But Library commands don't automatically allow for such; The simplify command's Library code is written to call those mentioned `simplify/name` procedures when it sees fit. Moreover,

restart;
`simplify/f` := proc() K(args); end proc:
simplify( f(A+b, C+G) );

      K(f(A + b, C + G))

See showstat(`simplify/do`,74..89) where parts of that mechanism is coded for simplify.  My point here is just that its extension mechanism implementation -- using `simplify/name` -- also happens to be consistent with its naming convention for its "simplification procedures" that match option names.

I shall be submitting a bug report that dsolve,numeric does not directly recognize an appliable object (such as Interpolation returns) for use with its known option.

@dglevitt I described it as an option of the dsolve command.

Since dsolve,numeric is the command/topic that was with which you were having issues, its Help page is a decent place to start looking. (One wouldn't search for "known" if one didn't yet know anything about it or of its existence.)

You can find a description and examples (eg. for the known option at the end, for dsol8, dsol8b) on the Help page for the dsolve,numeric command.

@C_R Your syntax,

E := t -> Mt(t);
diffeq := D(C)(t) = E;

is muddled. Utilizing the ensuing "solution" from dsolve in odeplot will not actually make any calls to E. You'd get similar invalid results with, say,

Q := z->0:
diffeq2 := D(C)(t) = Q;

Also, could you please show how your remarks about derivatives of a linear interpolant come into play with this particular result from LinearInterpolation? (We know that we could simply get by with 3*t instead, but that's quite another issue.) How does your claim explicitly come into play with this returned Interpolation object? Or perhaps you were writing more generally, say of piecewise linear examples where the derivative might agree in limit on only one side of each data point?

@Rouben Rostamian  That would get get it down to 3 times. His code also called his procedure three times unnecessarily.

It seems to me that the OP is trying to learn how to code better in Maple.

@Rouben Rostamian  If only those changes are made to the original code then it will (unnecessarily) call operator fun nine times with the same arguments.

Those multiple occurrences of `>` within a single execution group have little to no effect.

They are mostly just artfefacts of how multiple execution groups might have been joined (with the F4 key, say).

The name t in your passed equations DV1,DV2 is not the same as the local t declared and used in your procedure.

ps. I changed both this and your previous query from a Post to a Question. Could you please submit future queries as Questions rather than Posts?

If you're going to submit further queries on this same topic then could you please either 1) use the Branch to split them off the earlier one (which automatically inserts cross-reference links, or 2) just add the close followup as Comment/Reply in the earlier thread?

@C_R 

The first part of this explains why your earlier approach did not work. Ie. why the running value of loop index i doesn't get put into the bodies of the operators constructed by,
    x -> `^`(x,i)

When you utilize unapply within a loop then the running value of i gets picked up because of what the first argument (to unapply) evaluates to.

restart;

 

i := 5;

5

 

Note that the body of the following operator f is just a
reference to the name i.

 

When f gets called then it will pick up the value of i using scoping
rules.  (Here, that means the running value of i at the higher level.)

 

f := x -> x^i;

proc (x) options operator, arrow; x^i end proc

f(3);

243

i := 'i';

i

f(3);

3^i

i := 7;

7

f(3);

2187

 

restart;

 

i := 5;

5

x^i;

x^5


Observe that the following operator has 5, not name i, in
its body.

f := unapply(x^i, x);

proc (x) options operator, arrow; x^5 end proc

f(3);

243

i := 'i';

i

f(3);

243

 

A few additional (more syntax, but more flexible) ways to
construct a procedure by substitution.

 

restart;

 

ftemp := x -> _dummyexpr;

proc (x) options operator, arrow; _dummyexpr end proc

f := subs(_dummyexpr=x^5, eval(ftemp));

proc (x) options operator, arrow; x^5 end proc

f(3);

243

restart;


We already know that you could use a generic solution.

But, only for clarity, this shows that you can make multiple
constructions from a template operator.

Naturally, it is unnecessarily inefficient to construct many
of these.

ftemp := x -> x^i;

proc (x) options operator, arrow; x^i end proc

f[A] := subs(i=5, eval(ftemp));

proc (x) options operator, arrow; x^5 end proc

f[A](3);

243

f[B] := subs(i=7, eval(ftemp));

proc (x) options operator, arrow; x^7 end proc

f[B](3);

2187

 

Download proc_notes_1.mw

 

Pardon me if I also try to explain it slightly differently, using a loop:

restart;

for i from 3 to 5 do
  x^i;
  f := unapply(x^i, x);
  f(2);
end do;

x^3

proc (x) options operator, arrow; x^3 end proc

8

x^4

proc (x) options operator, arrow; x^4 end proc

16

x^5

proc (x) options operator, arrow; x^5 end proc

32

i := 13;
f(2);

13

32

eval(f);

proc (x) options operator, arrow; x^5 end proc

for i from 3 to 5 do
  x^i;
  Here the `i` inside `f` is not the current value of  `i`.
    Rather, it is still just the name (a reference).
  f := x -> x^i;
  f(2);
end do;

x^3

proc (x) options operator, arrow; x^i end proc

8

x^4

proc (x) options operator, arrow; x^i end proc

16

x^5

proc (x) options operator, arrow; x^i end proc

32

i := 13;
f(2);

13

8192

eval(f);

proc (x) options operator, arrow; x^i end proc

 

 

Download proc_notes_2.mw

@mmcdara

First, please note that the first sentence of my Answer is specifically about the fact that this simpler approach is possible. As it stands, of course, the extra locals and assignments are wholly unnecessary.

Second, I supposed that he has some further purpose, as yet unstated by him. I supposed that perhaps his actual intention is to have his procedure manipulate its parameters (arguments) DVA,RV1A,RV2A and then assign the modified ones to locals DV,RV1,RV2 and utilize those in the plotting.

Third, his code already had lines that appeared to be possibly for such assignment.

So I went along with that aspect of what he already had.

[edit] At first I wondered whether he could instead use DEplot. I didn't notice that the symbolic solution makes the left end-point easier to deal with. I think I see better now why he'd made the custom procedure. (I don't know whether he'll also want to handle odes without an explicit symbolic solution...)

I've changed your Post into a Question.

Please put any followup queries on this here, instead of spawning wholly separate new Question threads on it.

Duplicate Question threads get flagged as such and may be deleted.

It seems that this dies when attempting to convert to parfrac.

@sand15

It seems that OuterProductMatrix may be measurably faster than KroneckerProduct in the case of symbolic entries. For float[8] Vectors it's much closer.

nb. Switching the other of the arguments seems better than transposing either result.

The `.` variant ends up calling OuterProductMatrix, with a tiny extra bit of overhead to get there (and less flexibility w.r.t. transposing).

1 2 3 4 5 6 7 Last Page 2 of 546