John Fredsted

2238 Reputation

15 Badges

20 years, 170 days

MaplePrimes Activity


These are replies submitted by John Fredsted

Thanks for that precise analysis. I wonder, though, how these (special) mathematical functions should be handled by the procedure: simply adding a line like

elif type(x,function) then true

is of course quite nonsensical as that would also make f([x]), say, deeply algebraic - in fact, for functions it would make isDeeplyAlgebraic behave surface algebraically. Is there a compact way of doing such a thing, or does one have to treat each case individually?

Thanks for that precise analysis. I wonder, though, how these (special) mathematical functions should be handled by the procedure: simply adding a line like

elif type(x,function) then true

is of course quite nonsensical as that would also make f([x]), say, deeply algebraic - in fact, for functions it would make isDeeplyAlgebraic behave surface algebraically. Is there a compact way of doing such a thing, or does one have to treat each case individually?

I am pleased to read that you also think that any commutative-associative operator should be implemented as an n-ary operator.

And that brings us back to the use of the good old <code>-tag (available in the old editor at a click at a button) which could be used for inline mathematics, whereas the <pre>-tag, being launched when choosing Formatted in the pull down menu of the new editor, is appropiate for code sections only because it affects the whole paragraph. For the moment, the only way (that I am aware of) to format inline mathematics is to switch back and forth between WYSIWYG view and source view.

Prior to this thread I was actually not aware of the fact that switching to Formatted, using the pull down menu of the editor, inserted the <pre>-tag. Thanks for making me aware of that which is an improvement over the old editor in which this tag had to be entered by hand. But now, of course, it is the <pre>-tag which must be entered by hand, and that is harder because it appears more often than the <code>-tag, I think. So, if choosing Formatted in the pull down menu could instead imply the <code>-tag, and (as requested by Joe) it could be moved up in the menu, so that no scrolling would be needed, then I would be satisfied.

So, is the third (and last) part what primarily distinguishes the codes for CriticalPoints in Maple 9.5 and Maple 11?

So, is the third (and last) part what primarily distinguishes the codes for CriticalPoints in Maple 9.5 and Maple 11?

Although I have seen it used before in this forum, it did not dawn on me to use foldl in this connection. Thanks for that tip.

Yes, it surprised me to learn that `and` and `or` could only accept two arguments, unlike `+`, `*`, `.`, etc. I was curious to figure out why. Even though

dismantle(x + y + z);
dismantle(x * y * z);

and

dismantle(x and y and z);
dismantle(x or y or z);

clearly have different structures, I would nonetheless say that the and and or inline operators are associative in the sense that

(x and y) and z = x and (y and z)
(x or y) or z = x or (y or z)

for any booleans x, y, and z.

Am I correct in thinking that the following procedure will verify whether or not an expression is "deeply algebraic"?

isDeeplyAlgebraic := proc(x)
	if not type(x,algebraic) then false
	elif type(x,atomic) then type(x,algebraic)
	else andmap(isDeeplyAlgebraic,x)
	end if
end proc:

Am I correct in thinking that the following procedure will verify whether or not an expression is "deeply algebraic"?

isDeeplyAlgebraic := proc(x)
	if not type(x,algebraic) then false
	elif type(x,atomic) then type(x,algebraic)
	else andmap(isDeeplyAlgebraic,x)
	end if
end proc:

Thanks for putting me out of my misery: I was trying something along similar lines, using select, but could not figure out how, because (that is obvious now) I was missing the match part.

Thanks for putting me out of my misery: I was trying something along similar lines, using select, but could not figure out how, because (that is obvious now) I was missing the match part.

It seems that

CriticalPoints(2*x^5-5*x^4+3*x^3-3*x^2+x+2,x);

evaluates nicely in Maple 9.5, but not in Maple 11. Why?

It seems that

CriticalPoints(2*x^5-5*x^4+3*x^3-3*x^2+x+2,x);

evaluates nicely in Maple 9.5, but not in Maple 11. Why?

Thanks, Jacques, for making clear this point concerning surface contra deep types, which exactly hit the nail on the head concerning how I felt about the issue yesterday.

Actually, for a short while yesterday, I tried to formulate something along these lines, but gave up trying because I could not figure out how to put it. With your post you have now provided me with the vocabulary for doing so.

First 39 40 41 42 43 44 45 Last Page 41 of 68