Carl Love

Carl Love

27343 Reputation

25 Badges

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

MaplePrimes Activity


These are answers submitted by Carl Love

Wolfram|Alpha is not exactly the same thing as Mathematica. The former is the online "knowledge base" that uses the latter as an engine. It's one thing to update a website, and another to distribute updates for a multitude of different users' systems. I'm glad that I don't have to install a Maple update every week.

The answers you got from fsolve are correct. The deviations accumulate because of round-off in the evaluation of xp, X, yp, and Y. That's just the nature of floating-point computations. The following example "tower" of computations at successively higher values of Digits shows that each answer returned by fsolve is correct to the requested number of digits, yet the "check" evaluation of the original equations is usually not accurate to that same number of digits.

p1,p2,p3,p4:= seq(randpoly([x,y]), k= 1..4):
for k from 3 to 15 by 2 do
   Digits:= k:
   soln:= fsolve({p1=p2, p3=p4}, {x,y});
   eval([p1,p2,p3,p4], soln)
od;

Digits := 3
soln := {x = .448, y = -.492}
[-1.1, -1.1, -.99, -.999]
Digits := 5
soln := {x = .44765, y = -.49237}
[-1.138, -1.138, -1.0135, -1.0134]
Digits := 7
soln := {x = .4476498, y = -.4923714}
[-1.13839, -1.13838, -1.013304, -1.013301]
Digits := 9
soln := {x = .447649842, y = -.492371448}
[-1.1383856, -1.1383856, -1.01330066, -1.01330067]
Digits := 11
soln := {x = .44764984210, y = -.49237144750}
[-1.138385629, -1.138385629, -1.0133006602, -1.0133006606]
Digits := 13
soln := {x = .4476498420985, y = -.4923714475019}
[-1.13838562902, -1.13838562902, -1.013300660590, -1.013300660592]
Digits := 15
soln := {x = .447649842098485, y = -.492371447501895}
[-1.1383856290149, -1.1383856290149, -1.01330066059060, -1.01330066059061]

@amrramadaneg Enter the following command to Maple, and tell me what Maple says:

kernelopts(datalimit);

This is part of the answer of 13 Jan 2013 to which I was referring. I am not referring to your question about the 1200x800 system.



 

The following command should give you a number which is very close to proportional to the amount of memory used by the object stored in variable V, except for cases where V is a trivially small object.

length(sprintf("%m", eval(V)));

I haven't done tests to find the constant of proportionality. Hopefully someone else can do that, as I don't have time today. What the %m code to sprintf does is take the internal representation of the object in memory and converts it to a string of characters. It may restrict that to printable characters. So the constant of proportionality may be close to

256 / (number of printable characters in the character set),

where 256 is the number of possible byte values.

The constant may be different for different types of objects. Sorry, I haven't tested this. Hopefully someone else can take up that task.

I let expr represent your large expression. Then do

fd:= FileTools:-Text:-Open("C:/Users/Carl/desktop/archive.txt"):
seq(fprintf(fd, "%a\n\n", term), term in expr):
fclose(fd);

You need to use add instead of sum, because sum evaluates its arguments before adding them, and even before assigning values to the index variable. If you evaluate f(n), with n being just an unassigned variable, then you have an infinite recursion: the sequence f(n-2), f(n-4), ... never gets to a base value of f(0) or f(1) because every term has that unassigned n. You will get the same error if you simply try to evaluate f(a) by itself. Maple's three sequential operators---seq, add, and mul (but not $)---have special evaluation rules that allow for values to be assigned to the index variable before the expression using that index variable is evaluated. But the vast majority of other commands have their arguments evaluated before they are passed to the command.

Use add when the numeric limits of summation are known and you literally want to add the terms. Use sum for symbolic summation. If the items to be summed already exist in memory and can be accessed without a sequencing operation, then consider using prefix `+`. for example, if the items are already in a list L, then `+`(L[]) is often much faster than add(x, x= L). But, the `+` method also generates significantly more "garbage" (i.e. temporary memory usage).

Use display, or display3d--- it doesn't matter which. No capital D though. I needed to put a colon at the end of your first line and correct the spelling of "implicit" in your last line.

with(plots):
f:=(x,y,z)-> z=x^2+y^2;
implicitplot3d(f(x,y,z),x=-5..5,y=-5..5,z=-5..5);

If you're happy with the plot, save it to a variable:

p1:= %:

f:=(x,y,z)->z=2-x^2-y^2;
implicitplot3d(f(x,y,z),x=-5..5,y=-5..5,z=-5..5);

Again, save it to a variable:

p2:= %:

display([p1,p2]);


All that being said, an implicit plot is not a great choice for this problem, seeing as how your equations are already solved for z. You could just do this:

plot3d([x^2+y^2, 2-x^2-y^2], x= -5..5, y= -5..5);



 

Your computed answers are correct. It would just be nice to put them togther in a clear way. Indeed, we can do that in such a way that the solution reads almost directly as the statement of the problem.

I see from your "(9 C 3)" that you like to put C, the choose-combinations function, between its arguments. We can do that, but the Maple syntax requires that we make it &C if the function name goes between its arguments. The "choose" function in Maple is called binomial, which we'll rename &C. (Don't confuse this with the binomial probability distribution that was used for your heads-and-tails problem, which is essentially a "with replacement" problem. This problem uses what is technically called the hypergeometric distribution. They both use make use of the "choose" function.)

(Lines in bold are the input you give to Maple. Lines in italics are Maple's respones. (Usually, I suppress the response by ending a Maple input line with a colon.) Lines in normal typeface are my comments.)

restart;
`&C`:= binomial:

The backquotes (``) are required when a name with special characters is being assigned to, or when it is otherwise being used as a name.

Input the problem data:

wht, tn, pnk, pur, yel, orn, gr:= 19, 10, 7, 3, 5, 2, 6:

Check the total to make sure:

total:= `+`(%);

total := 52

(Note the backquotes around the +.) The percent sign % is used to represent the output of the last command.

Now here's your problem A. Read the command aloud to yourself like this: "From the whites, choose 3; from the nonwhites, choose the rest of the 9. In all, we've chosen 9 from the total."

(wht &C 3) * ((total-wht) &C (9-3)) / (total &C 9);

102486/351325

Get a decimal answer with the evalf command.

evalf(%);

.291712801537038

Which agrees with the answer that you got. (Notice that % again.)

Now for your problem B: In the command below, the lengthy factor with all the used colors being subtracted from the total is just 1. I only include it for didactic completeness.

(wht &C 3) * (tn &C 2) * (pnk &C 1) * (yel &C 1) * (gr &C 2)
* ((total-(wht+tn+pnk+yel+grn)) &C (9-(3+2+1+1+2))) / (total &C 9);

7695/1236664

evalf(%);

0.622238538519760e-2

which agrees with the answer that you got. Note that the number is presented in "scientific notation".

It's a second-order recurrence, so we need a second boundary condition. The problem's solution posted in your attached HTML file does not contain a clear statement of the original problem; it is just the solution. However, I infer from that solution that we can use a(30) = 1 as a boundary condition and that the ultimate goal is to find a(20).

restart;
BCs:= a(0)=0, a(30)=1:
eqn:= a(n) = 9/19*a(n+1) + 10/19*a(n-1):
A:= rsolve({eqn, BCs}, a(n), makeproc):
A(20);

47025509469056928801/147025509469056928801

evalf(%);

.319845920880512

...which agrees with the answer in your attached solution.

We can also easily get a closed-form solution.

I took a look at your polynomial (actually a rational expression) C2. Unfortunately, your worksheet was output only, so I couldn't take apart and analyze the expression. I'd be willing to look at your .m file. My advice:

  1. Use unapply to make each polynomial into a procedure.
  2. Use codegen:-optimize with the tryhard option to compress each procedure. This command is amazing in its ability to compress and simplify very lengthy expressions. I wouldn't be at all surprised if it compressed one of these expressions down to 100 lines of code.
  3. Use fsolve with the list-of-procedures input option.

(< < C|D >, < E|F > >^6 . < 0,1 >)[1];

Be careful with your use of `^`. I can tell that by A^j you mean A_j (i.e. A-subscript-j), because if you really meant exponentiation (the usual meaning of `^`), then your question is nonsensical.

Your code refers to a function fp, the derivative of f, but you never defined fp. Under the line where you define f, you can put a line

fp:= D(f);

Your assume(Rmin < Rmax) needs to be replaced with additionally(Rmin < Rmax). Multiple assume commands on the same variable are not cumulative. I tested this on your code snippet, and with the additionally it integrates fine. So, no need to upload tomorrow.

But, In the future, please cut-and-paste at least a snippet of code into your original posts, or upload a worksheet. Even a poorly written question with a code example is easier to answer than a well-written question with no code example.

How are you making the assumptions, with assume or assuming? And does the variable upon which the assumptions are made come from a function call, but other than as a parameter to that function? If you're using assuming, then that's the problem.  For example, the following works:

restart;
assume(k<0);
f:= x-> exp(k*x): # k in function, but is not a parameter
int(f(x), x= 0..infinity);

-1/k

But in the following, the assumption is ignored:

restart;
f:= x-> exp(k*x): # k in function, but is not a parameter
int(f(x), x= 0..infinity) assuming k < 0;

limit((exp(k*x)-1)/k, x = infinity)

The assumptions made with assuming  are only applied to variables which appear in the expression before it is evaluated.

To expand on what Preben said, what plot said is only a warning, not an error, and it turns out to be unrelated to why you didn't get a plot. If you apply argument or abs after taking the derivative, it plots fine:

f:= HeunG(3,-9/2+3/4*I*k-3/4*k^2,-1+1/2*I*k,-1/2+1/2*I*k,1/2,1+I*k,1/2):
f1:=diff(f,k):
plot([argument,abs](f1), k= 0..2);

Edit: I realize that this plot is not the same as the function you want. I'm just illustrating that the failure to plot is unrelated to the warning message.

First 382 383 384 385 386 387 388 Page 384 of 390