Advanced Search

Rouben Rostamian

8003 Reputation

23 Badges

18 years, 164 days
Contact Rouben Rostamian

MaplePrimes Activity


These are questions asked by Rouben Rostamian

Applying fsolve to unknowns of type x(0)...

Rouben Rostamian 8003 Maple 2020
solve fsolve
September 17 2020
4 0
 
> 

restart;
> 

kernelopts(version);

`Maple 2020.1, X86 64 LINUX, Jul 30 2020, Build ID 1482634`

This one works as expected:

> 

solve({x + y = 5, x - y = 3});

{x = 4, y = 1}

This one fails:

> 

solve({x(0) + y(0) = 5, x(0) - y(0) = 3});

That shouldn't fail.  According to ?solve,details, under the Description

heading, it says that the unknown may be a name or a function.  Note that

> 

type(x(0), function);

true

so there seems to be a contradiction.  Nevertheless, there is a workaround:

> 

solve({x(0) + y(0) = 5, x(0) - y(0) = 3}, {x(0), y(0)});

{x(0) = 4, y(0) = 1}

> 

 

Now try with fsolve().  This one works as expected:

> 

fsolve({x + y = 5, x - y = 3});

{x = 4., y = 1.}

This one fails:

> 

fsolve({x(0) + y(0) = 5, x(0) - y(0) = 3});

But the previous workaround does not help:

> 

fsolve({x(0) + y(0) = 5, x(0) - y(0) = 3}, {x(0), y(0)});

I can temporarily rename the variables to plain symbols, or perhaps

freeze/thaw them.  But is there a simpler workaround?

 

 

Download fsolve-problem.mw

 

A gamma puzzle awaiting an explanation...

Rouben Rostamian 8003 Maple 2020
evalf local gamma
September 17 2020
1 2

Maple's gamma constant appears to misbehave.

> 

restart;
> 

kernelopts(version);

`Maple 2020.1, X86 64 LINUX, Jul 30 2020, Build ID 1482634`

> 

evalf(gamma);     # this one is expected

.5772156649

> 

evalf(gamma(0));  # this one may be explained

.5772156649

> 

evalf(gamma(1));  # how to explain this one?

-0.7281584548e-1

Things get more puzzling.  Let's declare gamma as local:

> 

local gamma:

Warning, A new binding for the name `gamma` has been created. The global instance of this name is still accessible using the :- prefix, :-`gamma`.  See ?protect for details.

> 

evalf(gamma);     # this is good

gamma

> 

evalf(gamma(0));  # expected an unevaluated gamma(0) here!

.5772156649

> 

evalf(gamma(1));  # expected an unevaluated gamma(1) here!

-0.7281584548e-1

 

Download gamma-puzzle.mw

 

Teaching Maple a new rule...

Rouben Rostamian 8003 Maple 2020
applyrule
July 19 2020
2 7

Consider the family of functions "{`f__n` : -infinity< n<infinity}," where the index n is
integer, and f__n; proc (R) options operator, arrow; R end proc.   It is known that diff(f__n(x), x) = `f__n-1`(x) for all n.

 

I want to convey that information to Maple.  For instance, given the input
diff(f[3](x),x), Maple should return f__2(x).  Similarly:
diff(f[3](x), x$2)                   should return   f__1(x)
f[4](x)*diff(f[3](x),x)^5   should return   f__4(x)*f__2(x)^5

What is a good way of doing that?

 

Unexpected leakage from seq...

Rouben Rostamian 8003 Maple 2020
seq
June 15 2020
1 5

Consider

restart;
L := [1,2,3,4];
x[j];
seq(%, x[j] in L);
x[j];

What would you expect the output of the last line to be?

Answer:   Maple says 4.   Why?

 

A puzzle on type-specification in a proc...

Rouben Rostamian 8003 Maple
May 30 2020
3 8

I want to write a proc, say f, that takes an single argument Z, as in
f := proc(Z::?) ...
where the only acceptable Z values are pairs [x,y], where x and y are selected from the set {a,b,c,d}. The entries a,b,c,d of that set are prescribed symbolic constants. 

Thus, the following are legal calls to f:
f([a,a]), f([a,b]), f([d,c])
but these are illegal:
f([a]), f([a,b,c]), f([a,x])

I don't know what to put for the "::?" in the proc's definition in order to enforce those constraints.  Any ideas?

Extra: In fact, I would prefer to ban the f([a,a]) option as well (no repeated symbols) but that's of secondary importance since it is easy to inspect and handle that within the proc's body.

4 5 6 7 8 9 10 Last Page 6 of 16