Carl Love

Carl Love

26488 Reputation

25 Badges

12 years, 263 days
Himself
Wayland, Massachusetts, United States
My name was formerly Carl Devore.

MaplePrimes Activity


These are replies submitted by Carl Love

@acer Thanks. I hadn't tried NextZero because I assumed that it couldn't work on something that can't be symbolically differentiated. But it's the winner among the methods shown.

All three methods get a 3X time boost by using option remember in BC2.

Although it didn't seem to give any trouble in this case, one might need to be wary of the singularity at a = -1 in some other situations.

@Gabriel Barcellos What was your result from eval(A1, exp= cos)? I get 5, which is correct because the cos terms sum to 0, as you said.

I can't display the worksheet inline, so I'll copy in the plots:



@acer Okay, I can get all 4 values of a from fsolve without any plot-based seed values, thus making the implitcitplot irrelevant. My procedure SubDivide searches all real intervals (starting with -infinity..infinity), splitting each interval when it contains a root, and discarding an interval when fsolve comes back with nothing. This extra fsolveing (especially the ones that return empty) adds nearly 2 seconds. That can be  reduced to about 1.5 seconds by using option remember on procedure BC2.

SubDivide:= proc(P, {maxsols::posint:= 99})
local Q:= DEQueue(-infinity..infinity), sols:= 0, intv, r;
    {while sols < maxsols do
        intv:= pop_back(Q);
        r:= fsolve(P, intv, 'avoid'= ({op}(intv) minus {infinity, -infinity}));
        if r::numeric then sols++; Q,= lhs(intv)..r, r..rhs(intv); r fi
    until empty(Q)}
end proc
:
Digits:= 10: #precision for fsolve
a_sols:= SubDivide(BC2);
    a_sols := {-3.535939019, -2.002235920, -0.7734241018, 0.1155584192}

Those are the same values as before. Thus, the plotting procedes exactly as before.

The Maple 2023 help ?fsolve,details mentions a method= subdivide option. I tried to use it, but it seemed to be completely ignored! So, I implemented my own SubDivide.

@Carl Love MaplePrimes incorrectly formatted the GUI output (including plots) from my worksheet above. I have no idea why. You'll need to download it and view it directly in Maple.

@C_R The OP means GUI "equation/table" labels such as what one can get with Ctrl-L or, from the menus, Insert => Label.

Your Question has been received! Please don't repost it to new threads. If you want to add additional information (you're welcome to do so), put it in this thread.

@Suryakanth The code in your Reply seems extremely familiar to me. I'm certain that this exact same Question or one extremely close to it has been asked, and Answered, here on MaplePrimes within the last year or so. Perhaps both you and the other person who asked it obtained that worksheet from the same source. Anyway, perhaps someone who is better at searching MaplePrimes than I am can find that other thread.

@imparter seems to be an index variable, especially since the code refers to m+1. Thus, the m:= 7.44, 7.88 from your 1st line doesn't make sense.

@imparter Your code assigns values in the 3D arrays (or tables) eq1, ..., eq4. But nothing sets any values in the 3D arrays (or tables) U, V, T, or C; not even any initial values.

@sursumCorda Here is your lexical-vs-dynamic example, which I've indented to improve readability:

:-CompSeq:= -1:
proc($) local CompSeq; 
    convert(
        [x = a + b, i = a*b, j = x + i, y = a + sin(x)], 
        'procedure', 
        'locals' = [i, j], 'globals' = [x, y], 'params' = [a, b]
     ) 
end proc();
Error, (in convert/list) too many levels of recursion

You've used CompSeq as a variable here in two different ways, as a global and as a local. There's nothing at all wrong with doing that; I just need to point out for the following discussion that Maple considers these as two completely separate variables that only coincidentally have names that are spelled the same. I think that most other languages would consider it the same way, regardless of whether they're purported to be lexically or dynamically scoped (since I'm only guessing about other languages, it'd be worth checking whether this is true).

I do not have a thorough knowledge of the precise formal definitions of lexically scoped language and dynamically scoped language. Do you agree with the definitions given by Ming-Ho Yee in the blog post that I linked earlier? (Read the whole post, because Yee expresses some skepticism about his definitions.) If no, what definitions are you using? According to Yee, both concepts are about how a single variable is viewed at various places in a program---in which places is it evaluated and in which is it viewed as a "free" variable. Since, your example has two separate variables named CompSeq, it can't be used to discriminate between the two types of scoping under the given definitions.

Now, to be fair, your "local CompSeq" has no affect at all on the outcome. So, we might as well remove it and reconsider the scoping question. The same error occurs. This time I can't raise the two-variable objection from the previous paragraph. Could the result be considered evidence of lexical scoping, dynamic scoping, or neither? I'm not sure. The keyword CompSeq is used in three different ways in `convert/procedure` and `convert/CompSeq`. In `convert/procedure`, it's used as a type name on line 1 and as a kind of conversion for the convert command on line 26. In `convert/CompSeq`, it's used as a function name on line 45. In this last usage, it's used without unevaluation quotes. I think that this is the source of the error, and, regardless, it should be considered a bug.

Consider the following variation of your code, which runs without error. I use local CompSeq, but this could be replaced by any symbol.

:-CompSeq:= -1:
proc($) local CompSeq:= :-CompSeq, P;
    :-CompSeq:= ':-CompSeq'; 
    P:= convert(
        [x = a + b, i = a*b, j = x + i, y = a + sin(x)], 
        'procedure', 
        'locals' = [i, j], 'globals' = [x, y], 'params' = [a, b]
    );
    :-CompSeq:= CompSeq;
    eval(P) 
end proc();
 proc (a, b) local i, j; global x, y; x := a+b; i := b*a; j := 
    x+i; y := a+sin(x) end proc

Is this now evidence of one of the scoping methods? I don't have an opinion on that yet.

@C_R You wrote

  • The fact that the rendering is as expected after a restart (of Maple or the whole system?) indicates that the system starts Maple in a correct way with all involved software and hardware components configured correctly. 

The required "restart" in this case is of the Maple GUI (user interface), which necessitates the closure of all open worksheets. Thus, a system "reboot" (restart of the operating system) works also but is more than is necessary.

To avoid confusion. readers should note that the usage of the word "restart" in this discussion has nothing to do with Maple's restart command.

@Ronan For any procedure keyword option X, passing alone is equivalent to passing X= true, even if true isn't a valid value for X.

@Jesús Guillera You're welcome. There are many notations commonly used for pochhammer and related functions. Maple's Typesetting package allows the display (only) of many MathML formulae that are beyond the usual Maple displays. Let me know if you'd like something different. 

@mmcdara Thank you. I didn't expect my technique to be the fastest possible, just brief and reasonably fast and intuitive.

I realize that your Maple version may not have the command convert(M, list, dimension= 1). If is a matrix, this makes a list of the rows, but the rows themselves are still rtables. I haven't tested, but I suspect that that is more efficient than convert(M, listlist) or its modern replacement convert(M, list, nested); and I suspect it'd be even more efficient if has order= C_order.

If you care to rerun your test, I think that my code using ArrayTools:-Alias in the Reply immediately above will work in Maple 2015.

First 13 14 15 16 17 18 19 Last Page 15 of 688