@AHSAN 

Right, I updated my answer, please check it again

@jalal 

Read carefuly the ImageTools:-Read help page
First syntax:

Read( file, img, opts )

A few lines below it's written

file    -   string; the pathname of the image file to read

Ask yourself the question: is  this:///Images/Maple.jpg a string?
Obviously not, so Read will fail (for the moment your "Read" is cornered by the special symbol ":" , see the its help page).

Now, is "this:///Images/Maple.jpg" a valid path?
I assume you use Windows and that this: is a the name of some disk? Unfortunately Maple doesn't accept this ,otation: you must enter the full path of Maple.jpg, not a shortcut.
A full path is something like "//../../../Images/Maple.jpg", to get it:

• go to the directiory Images,
• copy paste the name full path which should appear in the address bar,
• paste it in your worksheet,
• add  /Maple.jpg,
• enclose all this by double quotes,
• change all the backslashes by slashes (maybe it's no longer necessary in recent Maple versions?).

Now you have a correct full path.

@jalal 

I thought you would have understood that my image had full path 

cat(currentdir(), "/Desktop/Maple.jpg"):

I f you have some image whose full path is My_Image_is_here, just do 

img := Read(My_Image_is_here):

I updated my previous answer and attached the mw file.

@shashi598 

UPDATED

You will find in this new file another point of view to solve numerically the Emden and Lane-Emden equations.
This is simpler than what was done before but (is it a drawback for you?) the numerical solution of the Lane-Emden equation can be computed ONLY in the range 0..Pi

ANALYSIS
Looking to the exact solution (n=1) of the Lane-Emden equation shows it contains the integration constant _C2 when initial conditions 

gamma(0) = 0, D(gamma)(0) = 0

are used.
Said otherwise these IC do not determine completely the solution, so the idea to write instead (epsilon is a priori a small strictly positive value):

gamma(epsilon) = 0, D(gamma)(epsilon) = 0

Unfortunately this leads to a  solution which doesn't verify 

gamma(Pi) + Pi * D(gamma)(Pi) = 0

Thus the quite complex procedure I used to identify two extra parameters eta and tau in this new Initial Value Problem:

ic := gamma(epsilon) = eta, D(gamma)(epsilon) = tau;
sol := dsolve({ode2(1), ic}), ....):

# find eta and ray such that 
sol(Pi) + Pi * D(sol)(Pi) = 0

CONSEQUENCE
The other approach presented here starts from the observation that 

gamma(0) = 0, D(gamma)(0) = 0

does not define a unique solution of the Lane-Emden equation.
So the idea is now to replace these initial conditions by these boundary conditions (see the attached file)

bc := D(gamma)(0) = 0, gamma(Pi) + Pi * D(gamma)(Pi) = 0

The correctness of this approach can be verified by doing this

rhs(dsolve({ode2E(1), bc}));
      (cos(xi alpha) xi alpha - sin(xi alpha)) Pi
      -------------------------------------------
            /     2    \                    2    
         xi \alpha  - 1/ sin(Pi alpha) alpha     

           /     /      2    \   2\                       
           \-2 + \-alpha  + 1/ xi / sin(xi) + 2 xi cos(xi)
         + -----------------------------------------------
                                  2            2          
                    xi (alpha - 1)  (alpha + 1)           

and by checking that this expression is equal to the one we get from the original approach (identification of _C2).

Once this understood, getting the numerical solution of the Lane-Emden equation (with a numerical solution of the Emden equation) becomes obvious (note that this require using the option method=bvp[midrich] in dsolve/numeric).
The whole procedure is much simpler than the one previously used but forbids computing the numerical solution of the Lane-Emden equation beyond xi=Pi.

Here is the file

Download LaneEmdenNumeric_Another_POV.mw

@shashi598 


UPDATED
 

(I answer you from my personal account, not my professional one @sand15).

By the same procedure as before here is the file corresponding to the case alpha=1.4.
You will find also the explanation of the different values you get at xi=Pi (essentially a numerical precision issue, see the lines after the text  Check the value of f(xi)+xi*diff(f(xi), xi) at point xi=Pi) and a way to find the initial conditions at xi=epsilon such that the solution verifies

gamma(xi)+xi*diff(gamma(xi), xi)=0

at point  xi =Pi (see after the text Attempt to circumvent using the exact solution to define the initial conditions at xi=epsilon.).
The main idea is

• to relax the initial conditions by writting gamma(epsilon)=eta and D(gamma)(epsilon)=tau (the numerical solution of the Lane-Emden equation then is a function of xi parameterized by eta and tau)
  I used 

  epsilon = 10-8

   

• and then to minimize some functional of eta and tau in order that

   gamma(xi ; eta, tau)+xi*diff(gamma(xi ; eta, tau), xi)=0  for xi=Pi

  The optimal solution  gamma(xi ; eta_opt, tau_opt) is equal to the exact solution up to an error of the order of 10^-6 (a value that could be improved if necessary).
  I got the optimal values

  eta = -2.410160197*10-17
  tau = -3.174864904*10-11

  You may observe their are extremely close to the original initial condition eta=tau=0 we would write for the limiting case  epsilon=0;  but these small variationse have significant consequences:

  eta = tau = 0:
  gamma(Pi) + Pi*D(gamma)(Pi) = -1.01987         (instead of 0)
  gamma(Z) + Z*D(gamma)(Z)    = 0  if Z = 3.2267 (instead of Pi)
  
  eta = -2.410160197*10-17 and tau = -3.174864904*10-11
  gamma(Pi) + Pi*D(gamma)(Pi) = 3.223690001*10-14  

   

Here is the file (link to DropBox)  LaneEmden_1dot4.txt

LaneEmdenNumeric_1dot4.mw

@Carl Love 


Thanks for your reply.

You wrote "I didn't expect my technique to be the fastest possible", yes I understood that. 
My opinion is that your technique has the strong advantage to manage a list of columns of any longer, as my procedure would be quite complex to generalize to a list of length larger than 2 (a recursive formulation could be useful).

You are also right, your technique is "reasonably fast and intuitive", (It needs to compare the lebgth of our respective codes).

Here are the performances I got with your last reply.

Download ColumnSorting_4.mw

@Carl Love 

What follows in no way diminishes the interest of your solution (see the reply I sent you earlier).
I improved  my procedure MultipleSC to avoid building submatrices and and managing only indices.
Here are compared performances for MultipleSC and your proposal.

Download ColumnSorting_2.mw

It is likely that one can reach even better performances with a more subtle coding.

@Carl Love 

I've just seen your reply, it is definitely excellent !!!
You deserve a gold star.

@sursumCorda 

Here is a way to sort a matrix wrt to the order induced by the elements of some column c₁, and next (if required) wrt to the order induced by the elements of an other column c₂.
This is very partial work for

• the procedure MultipleSC is restricted to sort wrt 1 or 2 columns (a recursive formulation seems necessary for a larger number of sorting columns;
• the column arguments could be gathered into a list;
• there is no checking of the input types nor of the values of the colums;
• the sorting acts only on columns, not on rows;
• I didn't assess the efficienvy of this procedire;
• ...

On the partial hospital[1..5, 1..3] test case displayed here  sortrows/sortcols, MultipleSC seems to return the expected result.

Download ColumnSorting.mw

REMARK: I always found this lack of column/row sorting was painful (with R, which I use to use, it is really easy to do this, likely as with Matlab). 
I suggest that you submit a specific question on this subject.

@sursumCorda 

I realized as I woke up this morning "Time taken to sort 1000000 elements 300 times" and I was about to connect on Mapleprimes in order to remove my last claim as I read your reply.

About sortrows/sortcols
There is no such things for matrices.
Nevertheless, as I use Maple 2015 right now, I advice you to give a look to DataFrames if tou use a more recent version: if something like sortrows/sortcols do exist it should be there.

For the record, to sort a matrix wrt to the order induced by some row or column I use to do this (but I guess you were capable to find this by yourself :-)

restart
# sort all the columns wrt the order induced by column 1
SC := (M, j) -> M[sort(M[.., j], output=permutation), ..];

# sort all the lines wrt the order induced by line 1
SR := (M,i) -> M[.., sort(M[i, ..], output=permutation)];

T := LinearAlgebra:-RandomMatrix(5, 3, generator=0..4):
SC(T, 1);
SR(T, 2);

@sursumCorda 

X is a vector of 10⁵ floating points, Y is the same vector converted into a list.
PartialSorting_perf.mw

Main results:

• sort@Trim and Trim both are almost identical (memory used/allocated, cpi/real/gc times.
• Operating on a vector is six times faster then operating on a list and uses three times less memory.
• The performances are almost independent on the number (K) of elements in the partial vectors/lists.
• The cpu times are extremely small compared to those obtained with Matlab 

@sursumCorda 

Yeah, I noticed that.
What is strange is that if you execute 

CodeTools:-Usage( sort(Trim(X, 0, 100*k/N)) )

before 

CodeTools:-Usage( Trim(X, 0, 100*k/N) ):

you get reversed times and Trim is now logicallly faster than sort@Trim.
See Look_at_this.mw
 

@Axel Vogt 

Yes, our answers intersected.
It is only after I submitted mine that I saw yours, I hope you don't mind?

@Sky-Bj 

Integrating without numerical bounds mean means integrate formally and I doubt that a closed form expression does exist.
So you have to integrate numerically, which means there must be numerical bounds.

Look here: How_to_integrate_formal.mw
 

Please upload your mw file while clicking on  the green up-arrow in the menu bar if you want someone to help you