## 12497 Reputation

12 years, 231 days

## Still no problem...

I exported the plot the same way as Rouben except on a Win7 system. The exported plot looks pretty nice in AcrobatPro, although it is painfully slow to load/render compared with jpg.

Since the export seems to work and is viewable on both Win7 and Linux - what system/viewers are giving you a problem??

PS I note with interest that in Maple2015, eps is not listed as valid output format for ImageTools[Export], exactly how are you exporting the plot?

## No luck so far...

Had no luck trying to come with symbolic solutions. Numeric may be your only choice. To help further would need to know the initial value of x (maybe 0?) together with u(x_init), U(x_init), v(x_init) and V(x_init). Derivatives of these four functios evaluated at x_init might also be useful. Are any of these known???

To avoid the possibility of cut/paste error it would be better if the addditional info could be incorporated in a worksheet together with the original equations  to be uploaded here

## Not impressed...

All that the zero equivalence problem (and its relations) really states is that it cen be very, very difficult to determine equality between two expressions. In other words a CAS might be expected to return one of true, false or undecided.

The fact is that in the fifteen cases I listed above, the answer is always true. If Maple had thrown errors and returned 15 undecideds, I could live with it. Just means I have to work harder, reformulate the problem, whatever. However Maple did not admit the existence of the "zero equivalence problem", with associated difficulty of solution, because it always managed to return either true or false and was therefore wrong on 9 out of 15 instances.

I accept that the zero equivalence problem exists - Maple apparently doesn't: it prefers to produce the wrong answer. You may not see that as an issue, but I do.

## Harder(?) quiz...

Imagine the scenario - I've just done some lengthy computations and produced ~8 expressions.

Suppose that (like the OP), these expressions are too large/complicated to be meaningfully comprehended by human eyeball, so to mimic this, I'm not going to tell you what the 8 expressions are.

However I do want to test the equality of these expressions in certain combinations.

A few clues

1. In all cases, pencil/paper return true
2. In the first group, Maple returns 2/5 true - which 2
3. In the second group, Maple returns 3/5 true - which 3
4. In the third group, Maple returns 1/5 true - which 1

Group1: Maple returns 2/5 as true

if   t1=t3/t2

if   simplify(t1=t3/t2)

if   expand(t1=t3/t2)

if   simplify(expand(t=t3/t2))

if   expand(simplify(t1=t3/t2))

Group2: Maple returns 3/5 as true

if   t4=t2/t3

if   simplify(t4=t2/t3)

if   expand(t4=t2/t3)

if   simplify(expand(t4=t2/t3))

if   expand(simplify(t4=t2/t3))

Group3: Maple returns 1/5 as true

if   t6*t5=t7

if   simplify(t6*t5=t7)

if   expand(t6*t5=t7)

if   simplify(expand(t6*t5=t7))

if   expand(simplify(t6*t5=t7))

If (as I suspect), one of these combinations *always* works, then why doesn't Maple utilise it by default in such Boolean comparisons?

And if you want to know what the expressions t1..t8 actually are, check out

Quiz2.mw

## Still have a problem...

I fixed the typos and still got "inconsistent" results. I gave up on the OP's matrices,because they are just too big/ugly to deal with, so I constructed a simple example. I deliberately haven't loaded it as a worksheet because I'd like you to come up with the answers (true/false) to each of the following cases, before you cut/paste to Maple.

NB the test matrix is always symmetric.

restart;
M1:= < <0, x*(1+x)> | <0, 0> >:
M2:= < <0, 0> | <x+x**2, 0> >:
M1+M2; # whatever Maple says, this matrix is symmetric!
IsMatrixShape( M1+M2, symmetric);
IsMatrixShape( simplify(M1+M2), symmetric);
IsMatrixShape( simplify(M1)+simplify(M2), symmetric);
IsMatrixShape( simplify~(M1)+simplify~(M2), symmetric);
IsMatrixShape( simplify~(M1+M2), symmetric);
IsMatrixShape( expand(M1+M2), symmetric);
IsMatrixShape( expand(M1)+expand(M2), symmetric);
IsMatrixShape( expand~(M1)+expand~(M2), symmetric);
IsMatrixShape( expand~(M1+M2), symmetric)

How many did you get right??? - and can you explain why in each case??

rgds

Tom

## Upload a worksheet...

No-one likes retyping or using cut/paste to figure out what you are trying to do. Please use the big green up-arrow (right-hand end of the second row in the toolbar) to upload the best worksheet you have so far

## Not sure it is that simple...

I got bogged down trying to fix this (cos I'm crap with 2D input). I ended up more or less converting/rewriting the OP worksheet in 1-D format, converting some indexed names to inert subscripts etc etc, and even then the final symmetric check would not run.

It does however provide the result false when using simplify, rather than map/expand??!!

See the last two execution groups on the attached

symm2.mw

## Used I__b...

I used I__b in my worksheet, and have just changed my local version to M__b - I still can't get IsMatrixShape to admit that the matrix is symmetric unless I expand the entries

Check the simple example at the bottom of  the revised worksheet

symm.mw

My previous workheet uses matrices with symbolic entries, becuase I wanted to check the general case (and I still don't think that it should have been necessary to expand the entries within the product!)

However if your matrices contain floats (and these are a bit ugly), then I suppose that it is possible for round-off error in generating the entries of the product to result in a non-symmetric result.

## Hmm - I think you are right to be confus...

See the attached worksheet.

It would seem that in order for IsMatrixShape(symmetric) to return true for an obviously symmetric matrix one first has to "expand" the entries in that matrix

I don't think this should be necessary - so I think you are right to be confused

symm.mw

## Agree...

Agree with everything Edgardo says:

1. remove the curly braces from the equation definitions
2. fix the unbalanced parenthesis in eqd3.
3. supply the equations to the dsolve command as a list or set

I stuck a (more-or-less random) closing parenthesis in the definition of eqd3 in the attached worksheet, and fixed item (3) above, but Maple was then unable to find a solution for the four equations. I don't plan to try any harder until you supply synctactically correct equation definitions

PDsolve.mw

## Use built-in command...

Check the help entry for LinearAlgebra[GaussianElimination], which as the first sentence in its description says,

"The GaussianElimination(A) command performs Gaussian elimination on the Matrix A and returns the upper triangular factor U with the same dimensions as A."

Do you want ro reinvent the wheel for teaching/learning purposes?

## OP may have a point...

Whilst agreeing Carl's post provides the correct answer, I thik the OP is correct to be curious. OP was using the defualt environment and I can't see why this doesn't work.

The third example in the attached sheet (which should be using the "default environment", gives a different answer from the first two examples - the "natural environment" or the "standard environment" and I can't figure out why.

It si particulary annoying becuase the first discrepancy occurs in the evaluation of M and things gets a bit pear-shaped from then on. However the eyeball evaluation of M in the third example suggests that it it is identical to that in the first two examples, just not simplified in the same way.

Something subtle going on???

units.mw

## The _z thing...

At the risk of getting lunched by the serious mathematicians on here (and teaching you stuff you already know)- I think the following way:

If one has a second order inhomogeneous differential equation of the form

diff((y(x),x,x)+f(x))*diff(y(x),x)+g(x)=h(x)

then the first textbook method to come up with a solution is to solve the corresponding homogeneous equation

diff((y(x),x,x)+f(x))*diff(y(x),x)+g(x)=0

then come  up with a "particular integral" - more or less any random function which is also a solution of the original equation. The complete solution is then the sum of the solution to the homogeneous equation and the "particular integral".

The second textbook method is to investigate the possibility of power series solutions, using something like Frobenius method. This gives rise to Bessel functions, Laguerre functions etc etc. Don't propose to discuss this here

With the first textbook method ie homogenous solution + particular integral approach, most textbooks will suggest techniques by which such a "particular integral" can be obtained. In textbook examples the form of the differential equation is usually such that the "particular integral" can be easily guessed, and the required integration easily performed - otherwise why put it in a textbook???. However the approach can be valid, even when the particular integral is "difficult",m and one gets a closed-form, ie non-power series solution

For this restricted set of second-order inhomogeous differential equations, solving the corresponding homogeneous equation is usually simpler than guessing the particular integral. Maple does  a pretty good job of coming with these solutions, inculding examples of particular integrals which I would never find. You just have to accept the following

1. Most second order inhomogenous differential equations have no analytic solution known to man, Maple or anyone else (but can often be solved numerically)
2. A (very) few second order inhomogenous differential equations have an analytic solution comprising the sum of the solution to the homogeneous equation and a particular integral
3. Of these, even fewer have solutions where the particular integral can be obtained by average humans. Maple probably does a a fair job of getting the particular integral where most humans can't. (It is possible that Maple will fail to provide a particular integral when a seriously good mathematician could get one)
4. A few more (but a long way from all)  second order inhomogenous differential equations which cannot be handled by the homogenous solution+particular integral approach, can be solved using Frobenius method to provide power series solutions
5. Textbooks on second-order differential equations tend to leave the very misleading impression that second order inhomogeneous differential equations can *usually* be solved, because all the examples they give can be solved. Just remember that most can't be solved (analytically) by either method

The message to take away from this is don't get to hung up on the rather ugly integral term with an arbitrary variable like _Z in it. It looks unpleasant, but really it is not surprising and not anything to worry about. Think of it as a particular integral and be grateful that you got one.

## An apology...

I should apologise unreservedly for my original comments on this problem. By some unfortunate quirk of my browser your original post managed to fill the screen in such a way that

1. the RHS was clipped (and my L/R scroll bar was off the bottom of the screen), so it didn't immediately occur to me to look for it - I just stupidly assumed that this was a posting problem
2. to make things worse, the link to your worksheet happened to be off the bottom of the screen I was looking at, so I made the assumption that it didn't exist. How stupid that does make me?

I accept that getting the above wrong makes me a bit of an idiot.

The second issue about the clarity of your problem is, I think slightly (only slightly) more understandable. From your original problem statement, it wasn't obvious to me whether you were interested in

diff(rho(r),r)=piecewise( rho(r)<rho_crit, f(rho(r), m(r), K1, P1), f(rho(r), m(r), K2,P2))

diff(m(r),r)=piecewise( rho(r)<rho_crit, g(rho(r), m(r), K1, P1), g(rho(r), m(r), K2,P2))

or

diff(rho(r),r)= f(rho(r), m(r), K2,P2))

diff(m(r),r)=piecewise( rho(r)<rho_crit, g(rho(r), m(r), K1, P1), g(rho(r), m(r), K2,P2))

As far as I am concerned, either of these *could* have been a valid interpretation of the  problem you wanted to solve.

Before posting my response I gave the first of these a quick, dirty check and managed to get somethng which looked like a plausible solution. I then pondered why someone would be overlooking what seemed to be the obvious approach (piecewise) and be considering something really clever (like events, whihc I have never used), and concluded that maybe *I didn't really understand the issue* - hence my comment abot clarifying the problem. Although I was wrong on this as well. I think it is a forgiveable error - which my first criticism definitely wasn't

BTW I wouldn't generally recommend using piecewise definitions in functions which you supply to dsolve. The more-or-less inevitable dicontinuties in function slopes/values tends to make life very difficult for the solvers - but hey this time it worked!

PS Don't let my original rudeness put you off posting problems here. Most of the time, most of the people (including me) here are only too happy to help

﻿