Joe Riel

8548 Reputation

22 Badges

16 years, 184 days

MaplePrimes Activity

These are replies submitted by Joe Riel

@nm A version of the debugger is on my GitHub site,, however, I haven't updated that lately so please don't install it. There are a few screenshots there and a description of its capabilities.  While I don't use Windows much, it does work there, at least the last time I tried it. If you (or anyone) are interested, please contact me directly and I'll get you set up with the latest version.  If you are familar with Emacs, life will be easier.  Regardless, expect to invest some time getting it operational.  While I'm clearly biased, I will say that it makes debugging Maple code much nicer.

@wswain Why not try enclosing the code in a procedure, instrumenting that, then debugging it?  I write all my maple code in procedures precisely for that reason.  Doing so will cause some of the variables to be declared as locals.  If that isn't suitable, you can manually add a global statement to declare them as globals.

@wswain You can step through the Property procedure, just instrument it and execute code that calls it.  For example

stopat(Property):  # launch debugger when the Property export is called.
Property(density, temperature=300, pressure=1*Unit(atm), Water);

The call to Property will launch the debugger.  You can then step through the procedure and into the subprocedures that it calls.  An alternative approach is just trace the procedure.  For example

(**) restart;
(**) with(ThermophysicalData[CoolProp]):
(**) trace(Property):
(**) Property(density, temperature=300, pressure=1*Unit(atm), Water);
{--> enter "Property |lib/ThermophysicalData/CoolProp/src/|", args = density, temperature = 300, 
pressure = Units:-Unit(atm), Water
                                                    has_units := FAIL

                                                    fluid := "Water"

                                                   output := "density"

                                     inputs := [temperature = 300, pressure = [atm]]

                                           result := ["T", 300., "P", 101325.]

<-- exit "Property |lib/ThermophysicalData/CoolProp/src/|" (now at top level) = 996.5569353*Units:-Unit(
                                                               [ kg ]
                                                   996.5569353 [----]
                                                               [  3 ]
                                                               [ m  ]

I rarely use trace, preferring the interactivity of debugging. Full disclosure, I also rarely use the builtin debugger, instead relying on an Emacs-based version with a better interface. 

@filiporlo There is a straightforward transformation from a transfer function to that form.  Given a transfer function in the form N(z)/D(z), with N and D polynomials in z, you can do it manually by cross-multiplying that with Y(z)/U(z) to get D(z)*Y(z) = N(z)*U(z), then factoring out the leading term, rearranging and converting z^(-k)*Y(z) to y(q-k), similarly for the terms with U(z), that is, computing the symbolic inverse z-transform, term by term.  This can be easily coded into Maple.  Here's a quick and dirty attempt.

TFtoDE := proc(tf :: algebraic)
global q, z, u, y;
local a, den, k, nd, nn, num;

    num := numer(tf);
    den := denom(tf);

    if not num :: polynom(anything, z)
    or not den :: polynom(anything, z) then
        error "transfer function can not be handled";
    end if;

    a := lcoeff(den);

    num := num/a;
    den := den/a;

    num := PolynomialTools:-CoefficientList(num, z);
    den := PolynomialTools:-CoefficientList(den, z);

    nn := numelems(num);
    nd := numelems(den);

    if nd < nn then
        WARNING("improper transfer function");
    end if;

    y(q) = ( add(num[k]*u(q+k-nd), k = 1..nn)
             - add(den[k]*y(q+k-nd), k = 1..nd-1) );
end proc:

Now applying it to a typical example

                 y(q) = 3 u(q - 1) - y(q - 2) - y(q - 1)


@Carl Love Hmm.  I suppose it's a personal preference.  I generally interact with maple via tty maple and don't want to see any superfluous output when launching it, which would be the case if the initialization file produced output.

@Thomas Dean The problem there was that I had used the MELPA identifier for the button-lock package, which is based on the date, rather than a version.  Not sure the best way to fix that.  Do you know where you got button-lock from?

@nm Yes, I can reproduce the lockup issue in Standard.  I'll submit as a bug.

@Anthrazit I haven't followed this thread closely enough, so may be misintrepreting your interpretation of Acer's comment. Accessing an entry to a Vector does not necessarily evaluate it, so be careful with that first bullet. Consider the following demo

V := Vector(2):
V[1] := a:
a := 23:
lprint(V[1] = eval(V[1])):


local V, a;
    V := Vector(2);
    V[1] := a;
    a := 23;
    lprint(V[1] <> eval(V[1]));
end proc():


local V;
global a;
    V := Vector(2);
    V[1] := a;
    a := 23;
    lprint(V[1] <> eval(V[1]));
end proc():


local a;
global V;
    V := Vector(2);
    V[1] := a;
    a := 23;
    lprint(V[1] = eval(V[1]));
end proc():

The generated output is

23 = 23
a <> 23
a <> 23
23 = 23

To make the tractable, can you upload the msim model (use the Green Arrow in the toolbar here when responding), with the attached worksheet that calls GetEquation.

@Davidsenjaya I don't understand your question.

Possibly this was addressed in one of the other responses, but I didn't see it.  Your function makes little physical sense in that the units are not consistent, that is, the output has dimensions of length or 1/length, depending on the continuous input.

@dharr Also, note that the assignment to VLAlibpath has a rooted directory (/VLA, which is a rather strange top-level directory), while the shown output (possibly a typo) doesn't show the initial forward slash.

Without access to the procedure ElloidInTet it's hard to say.  Did you try using the debugger to step through ElliodInTet to see what statement raises the error?

Later Hadn't realized the procedures were in there.  Kind of strange that they are assigned at the end (after they are called).  The problem is this sentence, which is supposed to be a comment, but is not:

   ElloidNorm evaluated at its tangent point in Tet's ABC face

Writing complicated procedures in 2D math is asking for trouble.  You found it.


@acer Shorter is

k := 5:


How is s^ to be interpreted?  It would be helpful if you wrote the expressions using Maple syntax.

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