Carl Love

Carl Love

26513 Reputation

25 Badges

11 years, 190 days
Himself
Wayland, Massachusetts, United States
My name was formerly Carl Devore.

MaplePrimes Activity


These are replies submitted by Carl Love

This comment is not meant to answer your question, but perhaps some trouble is coming from this. I notice that n is a free variable in your genfun1. Was that what you intended? Also, genfun1 contains no mu, so how could it equal genfun2?

@PatrickT Thank you for the kind words.

@PatrickT Thank you for the kind words.

@GrecoRoman Yes, you can make it nops(data) instead of 25. Try it.

@GrecoRoman Yes, you can make it nops(data) instead of 25. Try it.

Preben's example of frontend uses the default value of the third parameter, [{`+`,`*`}, {}], so one could just use the user-friendlier-looking frontend(collect, [ex,s]).

I often forget about this powerful command simply because the name is so vague. IgnoreIndets would be a better name, as it seems closely related to subsindets and evalindets.

Preben's example of frontend uses the default value of the third parameter, [{`+`,`*`}, {}], so one could just use the user-friendlier-looking frontend(collect, [ex,s]).

I often forget about this powerful command simply because the name is so vague. IgnoreIndets would be a better name, as it seems closely related to subsindets and evalindets.

Can you make a smaller example? Your sums go from 0 to 42. Could you substantially reduce the 42 and still have the same questions? Get the bugs worked out with fewer terms, then move on to 42.

The example above showed that two Records which seem identical but are stored at different addresses will be stored as separate entries in the table---which may slow down the recursion, but won't cause a real error. The following example---of the converse situation: different Records, same address---is more insidious.

restart;
A:= Record(a=1):
T[eval(A)]:= 1:
A:-a:= 2:
eval(T);

     table([Record(a = 2) = 1])

So even though the record has changed, the value associated with it in the table has not. This situation would cause a procedure that used a remember table on Record arguments to give wrong results.

There is a way that cache tables might help, though it wouldn't usually be worth it: If the situation in the example immediately above was relatively rare, then you could clear the cache every time you changed the contents of a record.

The example above showed that two Records which seem identical but are stored at different addresses will be stored as separate entries in the table---which may slow down the recursion, but won't cause a real error. The following example---of the converse situation: different Records, same address---is more insidious.

restart;
A:= Record(a=1):
T[eval(A)]:= 1:
A:-a:= 2:
eval(T);

     table([Record(a = 2) = 1])

So even though the record has changed, the value associated with it in the table has not. This situation would cause a procedure that used a remember table on Record arguments to give wrong results.

There is a way that cache tables might help, though it wouldn't usually be worth it: If the situation in the example immediately above was relatively rare, then you could clear the cache every time you changed the contents of a record.

@acer I agree totally that I manually extracted the arguments from the sqrts. I thought that you were referring to manual extraction of the reduced constraints as returned by solve. I was trying to approach the problem as if it were presented as originally posed to a freshman student, who knows to solve for nonnegativity of arguments to sqrt, as you said.

@acer I agree totally that I manually extracted the arguments from the sqrts. I thought that you were referring to manual extraction of the reduced constraints as returned by solve. I was trying to approach the problem as if it were presented as originally posed to a freshman student, who knows to solve for nonnegativity of arguments to sqrt, as you said.

@acer I was very careful to remove any need for manual extraction of the reduced constraints (returned by solve) from my solution. I just decided the display the results at that point so the reader could "catch a breather"---kinda like a dramatic pause. The remaining code works regardless of what those reduced constraints are or how many there are. All that matters is each constraint set eliminates one variable and gives numeric bounds for the other.

Also, I did use Im or any other complex-number commands.

@acer I was very careful to remove any need for manual extraction of the reduced constraints (returned by solve) from my solution. I just decided the display the results at that point so the reader could "catch a breather"---kinda like a dramatic pause. The remaining code works regardless of what those reduced constraints are or how many there are. All that matters is each constraint set eliminates one variable and gives numeric bounds for the other.

Also, I did use Im or any other complex-number commands.

I want to point out that my solution above gets the exact answer with purely symbolic techniques. It does not require plots. It does not require any initial guess. It uses only basic Maple commands, no packages. It does not use any complex-number commands such as evalc, Re, Im. It does not use any assumptions or RealDomain or Student. Each command runs quickly. In short, it is accessible to the average student. The apparent complexity with indets, etc., was only because I wanted to ensure that it would run the same regardless of the order that solutions are returned by solve. That would not be a concern to a student running Maple as a "desk calculator". 

First 679 680 681 682 683 684 685 Last Page 681 of 689