dharr

Dr. David Harrington

6611 Reputation

21 Badges

20 years, 72 days
University of Victoria
Professor or university staff
Victoria, British Columbia, Canada

Social Networks and Content at Maplesoft.com

Maple Application Center
I am a retired professor of chemistry at the University of Victoria, BC, Canada. My research areas are electrochemistry and surface science. I have been a user of Maple since about 1990.

MaplePrimes Activity


These are replies submitted by dharr

@Magma A final suggestion might be to look into the literature on totally positive matrices (all minors nonnegative) or strictly totally positive matrices (all minors positive), where there are improvements on how many determinants you need to check - for example you only need check n^2 minors for totally positive matrices, not all of them. These originate in relationships between various determinants, which might help for the MDS case though it seems the MDS case will likely be more difficult. On the other hand, all strictly totally positive matrices are MDS, so if you just want to find some MDS matrices, this might be helpful.

A good starting point is J. Pen~a, SeMA Journal, 62 (2013) 61. 

http://dx.doi.org/10.1007/s40324-013-0008-z
 

@Magma My point was mainly that doing the inverse is slower than the adjoint, and you can keep everything in integer arithmetic. And you're right that mul is probably not the best way to check all zeroes. But thinking about it, adjoint has to do the same determinants anyway, so I think the inverse idea really is not any better. I tried to do it recursively (often efficient in Maple), but it took forever.

But note that Determinant has the possibility of using many different algorithms, so you could optimize the routine to some extent. And see ?LinearAlgebra,Generic,Determinant for working in different fields. 

@Magma If Determinant(A) is 0, then it's not MDS and you are done, but otherwise just calculate the Adjoint rather than the inverse. Then for an integer matrix the Adjoint is another integer matrix. Multiplying all the entries and checking if the answer is zero is also integer-only operations. So for 16x16 this is certainly feasible. Surprisingly, mul(Adjoint(A)) is much faster than working out the Adjoint and then using mul in a seperate step [edit: no, the display just slows things down], and takes about 0.02 s on my laptop. 

 Then you can work down to the smaller matrices.

Adjoint.mw

@Thomas Richard that's embarrasing; its years since I made that mistake in my own worksheets. Perhaps pi should be prettyprinted in grey and Pi in blue, since it is a common error.

@vv taylor can do this, but I agree it shouldn't. I guess it just passes it to asympt.


 

restart;kernelopts(version);

`Maple 2017.3, X86 64 WINDOWS, Sep 27 2017, Build ID 1265877`

taylor( (2 * pi * n) ^ (1/(2*n)), n = infinity, 2);

1+((1/2)*ln(2)+(1/2)*ln(pi)+(1/2)*ln(n))/n+O(1/n^2)

asympt( (2 * pi * n) ^ (1/(2*n)), n, 2);

1+((1/2)*ln(2)+(1/2)*ln(pi)+(1/2)*ln(n))/n+O(1/n^2)

 


 

Download asympt.mw

@eslamelidy plot can be done as on the attached (adjust imax to suit).

final4.mw

@eslamelidy If you use a variable b[2], then this is part of a table called b, so you cannot then use b as a variable name. I fixed this and showed how to get the table outputs you want. I'm assuming you want all these quantities at z=500.

However, you have not properly converted the integrals. The integrand of M__2 had only the integration variable t (and not z) so I used eval to substitute t for z to make the differential equation (this was just to avoid making editing errors and save me time, you could just enter the z's by hand). I then had a differential equation for M__2. But then this gets multiplied by z in creating M, which is a combination of M__2 etc. But there should be no differential equation for M. You have somehow combined into a single differential equation for M, but this has z and t together, and when you substitute t for z you just get zero, which you can see in the output of dsol3: M(z) and Mc(z) are always zero.

So you only convert M__2 etc that were integrals to differential equations, not M or Mc or N or Nc.

 final3.mw 

@eslamelidy Yes, in my method the integrals (M[1] etc) are calculated at the same time as the (other) differential equations, which makes it efficient. (You can compare these with the integrals you had after if you like.)

@eslamelidy I've started to change the worksheet, and think that if you do the rest it should work, Just to repeat, you don't need the integrals if you have the corresponding ODEs, for example f(z) = Int(sin(t),t=0..z) is the solution to diff(f(z),z)=sin(z) with initial condition f(0)=0.

final2.mw

 

@eslamelidy You have done a lot of cutting and pasting to get the "known" functions H(z) etc, which presumably are related simply to M[1] etc, but this is not clear in the worksheet you have given, so it is not obvious to me how to implement the details of the idea I am suggesting. You need to clearly specify how H(z) etc were constructed from the simpler functions.

I don't understand your remark.

@Carl Love I'm not seeing that in 2017.3. Executing the first time doesn't give any indication, but the second time I select and "!" (or ctrl-E) the highlighted line moves to the line with the error but no underline appears. Perhaps I'm missing a reqruired setting. I can live with the highlighted line.

CodeEdit.mw

@Carl Love Thanks - I missed the tooltip, but as you say, syntax errors aren't too hard to find. Not sure why the same mechanism wouldn't work in a regular code edit region.

@ebrahimina LinearSolve will be faster and more accurate than finding the inverse then multiplying. Since you have a generalized eigenvalue problem, you could just use the Eigenvectors command directly Eigenvectors(FF1,FF2). (But for non-square matrices not sure what inverse you want,...)

Finding the inverse could be part of the problem if it is ill-conditioned. So if you can use Eigenvectors, you may not need Digits=30. You really, really need to decide what part of your calculation is requiring this accuracy and improve/avoid it.

 

@awass I agree it is a bug.

I take @tomleslie's point that floating point arithmetic may make things that are linearly dependent seem linearly independent and too many vectors are returned, and his and @vv's solutions to get rid of extra one(s) are certainly useful for the case where n-component vectors give <=n solutions.

But for 3-component vectors, the routine should never attempt to give more than 3 vectors, so I consider that a bug, and not just possibly a bug.

@Mac Dude I suppose if I were looking for density of various substances, I'd look in a table listing properties of various substances, not just elements. Maple has the ThermophysicalData package, which seems more appropriate (and does have densities), but the database only has fluids. Perhaps there are plans for expansion of that for other materials....

First 57 58 59 60 61 62 63 Last Page 59 of 68