mmcdara

7891 Reputation

22 Badges

9 years, 55 days

MaplePrimes Activity


These are replies submitted by mmcdara

@Anthrazit 

I've just edited my previous answer.
I agree: if you use only Maplets you don't have any problems.
The only difficulty is that the onchange option of the TextField  component requires that "something else" exists in the maplet in order you can click on.
So it's simpler here to use a Button element in conjunction with TextField:

restart
f := proc()
  local maplet:
  uses Maplets, Maplets:-Elements, Maplets:-Examples:
  maplet := Maplet(
    [
      [
        TextField['TF'](),
        Button("OK", onclick=Evaluate(function='Alert', Argument('TF', quotedtext)))
      ]
    ]
  ):
  Display(maplet)
end proc:
f()

The "three times knocking" is likely a consequence of an undesired interaction between DocumentTools and Maplets packages

Would adding a Button Component suit you?
KnockOneTimes.mw

@KIRAN SAJJAN 

I repeat as I think that maybe I wasn't clear enough:
Did the file I sent you execute correctly?

If it is so, that is already a first good point.
Now you claim it doen's execute correctly with your NEW bcs. What are they, could you please provide them, and only them, without all the unnecessary stuff.

What do you mean by writting "same problem i m using with different boundary conditios"?
That you don't get any solution?
Which is wrong: with your BCs1 as boundary conditions the solution is returned without any problem:

data :=  [
   S1=  0.5,   S2= 0.5, A=  1,
   Pr= 21, delta=0.01,g=0.1, 
   Ec= 0.5, Ra=0.5,Q=1,Gr=0.5,Br=0.5, 
   betu= 1.1,  bett= 1.1, S=  0.1,
   alp= 0.1,   
   bet= 2, 
   M1= 1, 
   Rd= 1
]: 
dsolve(eval({ODEs1[], BCs1[]}, data), numeric)
      proc(x_bvp)  ...  end;

Similarly

dsolve(eval({ODEs[], BCs[]}, data), numeric);
     proc(x_bvp) ... end;   #well posed problem

# a wrong posed problem: what are these auxiliary conditions NBVs?
dsolve(eval({ODEs[], BCs[], NBVs[]}, data), numeric);
Error, (in dsolve/numeric/process_input) invalid specification of initial conditions, got {-1.13493842976305*(D(Theta1))(1) = `Nu1*`, 1.14603660000000*(D(W1))(1) = `C*__f1`}

Is it necessary to write all these modules?

@KIRAN SAJJAN 

# What does this is aimed to do?
subs(
      _Sys= {:-ODEs[], :-BCs[], :-NBVs[]}
      Sol:= dsolve(_Sys, _rest, numeric);
      AccumData(Sol, {_options});
      Sol
   )
Error, `:=` unexpected   ### Of course!!!

Write correctly ModuleApply

@KIRAN SAJJAN 

Didn't my file Worksheet_1D.mw work?
Had you some difficulties to load it?  If it it so try again Worksheet_1D.mw

But I see that your reply contains command that were not in your original file Ode_Error.mw.

So you are talking about ANOTHER problem, dont'you?

In any case, load your own file and be more explicit. How the hell do you think anyone can do anything with the mix of inputs and outputs in your answer?

@acer 

Hi, I totally agree with your point about the end-goal to solving these systems symbollically.
I have already said that a long time ago to @MaPal93 but it keeps getting into this idea that it's better to solve symbolically despite all the problems this way presents.

It expects to find "simple" expressions for some quantities... "simple" in the sense, I guess, that the could be written on a single line of a report, or that a being with reasonable brain capacities could "understand" these expressions by simply looking at them.
But it's a kure in the present case.

@Carl Love @tomleslie (with copy to @The function )

What you both did is consistent with the copy of the book provided by the OP.
But this doesn't give the deviation of the target quantity.

On the first example you both got 0.42333... as the value of the relative deviation.
But package Tolerances gives 0.41084..., a simple by hand calculus gives the same value, and a Taylor expansion with up to an order large enough to account fully of the deviations of each independent quantitties also gives 0.41084...

Two reasons:

  • You limit yourself to a first order approximation
  • Mainly: you suppose that the central value Q of Q=R*I^2*t is equal to R*I^2*t, which is wrong.
    For instance you consider that  Q = 93.750 as it is Q = 96.788125 (which is also the value Tolerances finds)


If you want to express the deviation of Q under the form Q +- delta, then Q is necessarily the half of the bounds of Q? If Q=f(R, I, t) then  Q  = f(RIt) iif f is linear, which is not the case here.
If you take  Q  = f(RIt) as the "reference value", then the deviation is no longer +- delta, but a range a..b with a < 0, b > 0 and a <> b.
In engineering it's common to handle tolerances of the form 

So, I repeat myself: what you did is consitent with the image of the text book but the values of Q and of the deviation you get are not correct. Simply because this book gives unfortunately a wrong idea of what tolerances or deviations are.
Form this point of view the packages Tolerances or ScientificErrorAnalysis provide a far more rigorous way to assess them. 

@Teep 

You can easily load the file RecursivePartitioningAlgorithm.tar.gz from http://lobato.it/packing/ and execute it in a terminal window (I work with MAC OS X platform).

I think it would be interesting to run this C++ code from Maple while using system/ssystem commands, but I failed to do it. I advice you to post a question on this specific topic.

Good luck

@acer  @Carl Love

I like your solutions based on subsindets+suffixed (I couldn't remember the name suffixed).
I vote up for both of you.

@MaPal93 

You wrote Something like: "if denominator parameters of t__1 increase, t__1 decreases and since t__2 = something - t__1, then t__2 increases"
That's wrong, it depends on the values of these 7 indeterminates

[`&sigma;__&epsilon;1`, `&sigma;__&epsilon;2`, nu__0[1], nu__0[2], rho__v[1, 2], sigma__v[1], sigma__v[2]]

you consider.
For instance, if rho__v[1, 2] and if no sigma is null (which should be the case as they are standard deviation), then the common denominator "D" of t__1, t__2 and t__3 is < 0.
But as rho__v[1, 2]=0 one gets t__1=0 whatever the value of D: so for rho__v[1, 2]=0 t__1 doesn't increase nor decrease as D changes.

More generally you have no chance at all to achieve what you want to do unless you give numerical values to the 7 indeterminates.

Here are a few examples of what you could do.
But I can assure you that there is no ready-made solution to your problem and that it is up to you to imagine how you want to display your formulas and turn them in all directions to get the information you want.
What you are asking for is not help about Maple, but assistance about the methodology of data processing or visualization.
If I had to give you a single advice it would be this one:

You have pushed the formal computations as far as you could (and likely too far from any practical point of view, this is my own opinion), so accept that keeping the things formal will be of no help.
You have 3 quantities that depend on 5 or 7 variables (basically a function from R^7 to R^3)  and there is no simple way to figure out how these variable intervene on the evolutions of these quantities.
You talked of derivatives, but derivatives of rational fractions are generally more complex than these same fractions which means that if you are not capable to "understand" how these fractions behave, you won't be capable to understant how their partial derivatives do.
At the opposite plotting curves or surfaces, or using specific sensitivity analysis strategies are of great help... but they  works with numeric data, not symbols.

rearrangingterms.mw

 

If I remember correctly the expressions ot t__1, t__2 and t__3 are those of conditional variances among several random variables nu__0, nu__1, ???, epsilon__2.
Am I right?

If it is so the most compact form is "Var(X | Y)"(= conditional Variance of X given Y) for some ad hoc choice of X and Y.
Let's suppose that t__1 = Var(nu__1, nu__2 | epsilon__1, epsilon__2)and t__2 = Var(nu__1, nu__2 | epsilon__1)then the most compact symbolic expressions of t__1 and t__2 are the rhs of these two relations.
As soon as you evaluate these rhs you get something more complex and it become impossible to recover the initial simple  expressions Var(nu__1, nu__2 | epsilon__1, epsilon__2)and Var(nu__1, nu__2 | epsilon__1).`

In the notional example (which may or may not correspond to your actual problem), I could be interested in in expressing Var(nu__1, nu__2 | epsilon__1, epsilon__2)in terms of  Var(nu__1, nu__2 | epsilon__1)or, more likely, Var(nu__1, nu__2 | epsilon__1)in terms of Var(nu__1, nu__2 | epsilon__1, epsilon__2).
Then Var(nu__1, nu__2 | epsilon__1)is the marginal expectation of Var(nu__1, nu__2 | epsilon__1, epsilon__2) wrtepsilon__2, 
that is Var(nu__1, nu__2 | epsilon__1) = int(Var(nu__1, nu__2 | epsilon__1, epsilon__2)*pdf(epsilon__2)).
This is , in my opinion, the simplest relation you can write

It seems to me that you did the job towards one direction (from theoritical expression of conditional variances to their detailed expressions) and that you want then to do it backwards by expressing one of these detailed expressions in terms of one another.
This is, still in my opinion, a useless waste of time.

@ijuptilk 

The expression you give in this last reply is of the form expr := A*dudy^2 + B*dvdx^2  (not **dvdx^2).
It is then already collected wrt dvdx^2 and there are no coefficients of dvdx^2 but a single one you can get with 

coeff(expr, dvdx^2)

This reply doesn't enlighten me.

Going back to you initial problem, do one of these suit you more?
coeff_2.mw
coeff_3.mw

@delvin 

What is the "correct solution" which you are talking about?

@ijuptilk 

Sorry but I don't understand what you say.
As the coefficient of dudy^2 doesn't contain dvdx^2, and reciprocaly, I don't see why collecting  them separately or not would change anything.
If you REALLY want to collect the coefficients in one go, do this

coeff~(aa, [dudy^2, dvdx^2])

@delvin 

You have an overdertermined linear system of 9 equations and only 3 unknowns, so be happy it has a solution!
If the solution Sol = {a[0] = 0, a[1] = 0, b[1] = 0} you get doesn't suit you this is likely because your problem is not correctly formulated.

By the way, the solution found is correct:

eval(eq1, Sol);
                               0

pseudo_degrees2.mw


Thank you for this extremely interesting post.
I have had some difficulties with Maple Learn (a strange"too big a page to be loaded" message) but it's not that important.
I also appreciate the many links you provided (I can also suggest you this video https://www.youtube.com/watch?v=p6j2nZKwf20).

Thanks again for this excllent initiative.

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