Carl Love

Carl Love

28045 Reputation

25 Badges

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

MaplePrimes Activity


These are replies submitted by Carl Love

I came up with a much simpler explanation of how to derive the equation. It's essentially the same as the above with the steps to compute removed because it's easy to see that the sum of the distances to the foci is exactly the major-axis length. I also made explicit the steps needed to get rid of the square roots to get the standard polynomial form.

restart:
Dist:= (P,Q)-> sqrt(add((P-Q)^~2)):  #Euclidean distance between points P and Q

P:= <x,y>:                       #An arbitrary symbolic point on the ellipse
F:= [<0,-5>, <5, 0>]:  MA:= 12:  #Givens: Foci and major-axis length

(* An ellipse's defining property: The sum of the distances from any of its
points to its foci is constant. I'll call that constant C for the moment. 

The major axis is the line segment that the ellipse cuts from the line 
through the foci. If we measure the distances from either of the points where
that line meets the ellipse (those points are called vertices) to the foci, then
you can see that C is the length of the major axis. *)

add(map(Dist, F, P)) = MA;
             sqrt(x^2 + (-5 - y)^2) + sqrt((5 - x)^2 + y^2) = 12

expand(%^2);  #Squaring gets both sqrts into a single term
                    2*x^2 + 2*y^2 + 10*y + 50 + 
      2*sqrt(x^2 + y^2 + 10*y + 25)*sqrt(x^2 + y^2 - 10*x + 25) - 10*x = 
                                144

#Separate terms with and without sqrt:
selectremove(hastype, (lhs-rhs)(%), anything^(1/2));
             2*sqrt(x^2 + y^2 + 10*y + 25)*sqrt(x^2 + y^2 - 10*x + 25),
                         2*x^2 + 2*y^2 - 10*x + 10*y - 94

`-`(expand([%]^~2)[]);  #Square both groups, then subtract
                476*x^2 - 200*x*y + 476*y^2 - 2880*x + 2880*y - 6336

(primpart/sign)(%);  #Cancel common integer factors of the coefficients
                  119*x^2 - 50*x*y + 119*y^2 - 720*x + 720*y - 1584


 

@mmcdara Because of the special evaluation rule of piecewisedecisions is seen as 1 argument rather than 2, just like it is with `if`. So piecewise acts as if it has 2 arguments. When piecewise has an even number of arguments, then a default value is used in case all the conditions are false. Usually, the default value is 0, but it's possible for the user to change it.

@hojat You can skip the derivatives entirely; NLPSolve will compute them in the background if needed. Doing simply

NLPSolve(I1, assume= nonnegative),

I get

[1.53301315530314795*10^(-13), [gh1 = 0.154462739528209, gh2 = 0.371529041174829, gi1 = 1.37108385850808, gi2 = 0.860957036085277, gl1 = 12.9569226548585, gl2 = 9.39082402975947, gs1 = 1.04561251174819, gs2 = 0.586651783990275, p_i0 = 8.48431621548923*10^(-7), p_i1 = 0., p_i2 = 0., ph0 = 2.39549267065501, ph1 = 1.88487638439243*10^(-8), ph2 = -8.56043422781661*10^(-10), pl0 = 0., pl1 = 4.86320524745181*10^(-7), pl2 = 0., ps0 = 0.599755159534200, ps1 = 0., ps2 = 0.]]

I don't know whether nonnegative is a valid solution for you. It's just an example.

@hojat Why "estimate" or approximate the derivatives when you can compute them exactly, as you already have?

@digerdiga I agree with your formula for D(f^k), except that Maple syntax would require ln(f) to be ln@f

There seems to be some deeper problem with applied to any `^` expression whose exponent (2nd operand) is not of type complexcons (explicit complex constant).

@rlopez The effects of bad typography are often subconscious: longer time to read, agitation, irritation, tiredness, eyestrain, reduced comprehension. The reader may not be aware of the cause of these symptoms.

@hojat I think that after changing Gamma to GAMMA, you are not re-executing the code from the restart command. If I execute your modified code, I get 

Error, (in Optimization:-NLPSolve) no improved point could be found

This new error is much different from the prior. It is not due to a simple syntax issue. It is due to a more-fundamental mathematical issue with solving the problem.

Here's a synopsis: Your objective function I1 is a function of 20 variables. Your call to NLPSolve is essentially equivalent to

"minimize I1 subject to gradient of I1 = <0, ..., 0> (vector of 20 zeros)"

with no other constraints. I suspect that type of thing is slightly outside the designed scope of NLPSolve. The more-usual solution technique is

  1. Find via numeric solution techniques the values of the 20 variables that make the gradient 0. This step looks only at the gradient, not the objective.
  2. Evaluate the objective at the hopefully finite number of points found in 1.
  3. Find the minimum of the evaluations from 2.

I'm not saying that this is computationally feasible (given the large number of variables)! My first choice for attempting it would be the freely downloadable 3rd-party package DirectSearch.

@sursumCorda You misunderstand the purpose of RealDomain:-solve. Its purpose is NOT to return all complex solutions that are also real. RealDomain is correct to return only one solution for this problem. 

Good catch. I confirm that these examples also don't work in Maple 2023, even though the help page ?D clearly says that ... assuming x::constant or ... assuming k::constant should work.

@hojat You need to post the new code for which you claim to have changed Gamma to GAMMA. I see 32 Gammas in the code above.

@ecterrab The MathML operator mn does it correctly, printing an unary negation symbol at about half the width of the binary:

`#mn("-1");`;

So, since the functionality to print the correct symbol already exists in Maple, I'd think that this would be fairly easy to fix.

Your worksheet works for me without any changes. Use the !!! on the toolbar to execute the worksheet in order, from the beginning, starting with restart. I get this plot:

The determinant is large, but Maple can easily handle it.

@ecterrab Here it is. While I do think the unary minus sign is too long, I would not say that this is "absurdly" long. That may have been corrected, and it may have been only a problem of the MaplePrimes rendering rather than the Maple GUI.
 

restart;

[interface, kernelopts](version);

[`Standard Worksheet Interface, Maple 2023.0, Windows 10, March 6 2023 Build ID 1689885`, `Maple 2023.0, X86 64 WINDOWS, Mar 06 2023, Build ID 1689885`]

interface(typesetting);

extended

Illustration of the length and spacing of prettyprinted unary and binary negation symbols:

x-1, -1, 1-x, -8, x-8, 8-x, y-x, y+x;

x-1, -1, 1-x, -8, x-8, 8-x, y-x, y+x

1. We see that exactly the same glyph is used for unary and binary negation. In my opinion, the unary should be not as wide (referring to its horizontal extent).

 

2. In my MaplePrimes Reply, I said that the unary should be moved to the right to be closer to its operand. I withdraw that comment; as can be seen above, the unary is differentiated from the binary and is indeed closer to its operand.

 

3. An issue that I hadn't noticed before is that the spacing for the binary case differs depending on whether the left operand is a numeral. In that case, the sign is not centered between its operands. This also affects `+`:

<1-x, x-1, 1+x>;

Vector(3, {(1) = 1-x, (2) = x-1, (3) = 1+x})

 

Download UnaryNegation.mw

@acer Doesn't there exist some somewhat user-friendly menu- / Maplet-based tools for fine-tuning the typesettings? Perhaps they are limited to functions though, just like the older `print/...mechanism.

@Greenwaldian If you also want the axes themselves to be thicker, then include the option 

'axis'= ['thickness'= 2]  #Note: 'axIs', not 'axEs'

in the setoptions3d or directly in the plotting command. The 2 can be adjusted larger or smaller, as needed, and isn't limited to integer values.

First 47 48 49 50 51 52 53 Last Page 49 of 709