DJKeenan

422 Reputation

9 Badges

12 years, 73 days

MaplePrimes Activity


These are replies submitted by DJKeenan

Thanks much acer!

I had assumed that the Intel hardware supported quadruple precision.  I see now that was untrue.

Thanks much acer!

I had assumed that the Intel hardware supported quadruple precision.  I see now that was untrue.

@acer

I think that the palette items, and command completion of `plusmn` or `pm`, should all produce `&+-`(A,B) alone.

I agree--when I first wrote the code, I expected that plusmn would produce that, and it was confusing for me to discover otherwise.

@Alejandro Jakubi 

I confirm that!  I was able to reproduce the problem (on my re-installed Maple 16.01) by turning off inline plots at the beginning of the the session.

I am running Maple 16.01, under Windows XP (SP3).  I encountered the error consistently, on many trials, and I included systems restarts in the trialing.  After reading the comment from Christopher2222, I uninstalled Maple, and then reinstalled.  Now everything seems to work.

The comment from Alejandro Jakubi rightly explains that the problem lies in the handling of 2-D input.  I believe that 2-D input is nicer for people who are not Maple experts.  I have always used inline plot mode, though; so I do not think that is the root cause.  Moreover, just now I tried non-inline plot mode, and the document executed correctly.

This all seems odd.  Very much thanks to Christopher2222 and Alejandro Jakubi for assisting!

Your explanation is greatly appreciated.  I had not been aware of all the subtleties.  The bottom line, though, is that the current implementation of Optimization is so slow, it is often not usable.  That is a shame: the Optimization package ought to be one of the jewels in Maple's crown, at least for applied work.

A fix might include having Optimization call fdiff with the global value of Digits; making this change would be easy.  I do not know what to suggest for fdiff, but surely something could be done.

Your explanation is greatly appreciated.  I had not been aware of all the subtleties.  The bottom line, though, is that the current implementation of Optimization is so slow, it is often not usable.  That is a shame: the Optimization package ought to be one of the jewels in Maple's crown, at least for applied work.

A fix might include having Optimization call fdiff with the global value of Digits; making this change would be easy.  I do not know what to suggest for fdiff, but surely something could be done.

acer, kind thanks!  Yes, I had confirmed that lfGn was being called with Digits=26 by using something like a print statement in lfGn.  And I had tried a partial workaround of replacing the definition of f, in max2lfGn, by

f:= (m, s, H) -> evalf[digits+1](lfGn(X, m, s*s, H))

where digits is a variable containing the global value of Digits; as your comment indicated, though, this sometimes causes failure.

What I do not understand is why fdiff calls the function to be evaluated with Digits=26, even on the first call, when Digits=10 and optimalitytolerance=0.01.  To me, this looks like far-from-optimal behaviour, if not a bug.

 



acer, kind thanks!  Yes, I had confirmed that lfGn was being called with Digits=26 by using something like a print statement in lfGn.  And I had tried a partial workaround of replacing the definition of f, in max2lfGn, by

f:= (m, s, H) -> evalf[digits+1](lfGn(X, m, s*s, H))

where digits is a variable containing the global value of Digits; as your comment indicated, though, this sometimes causes failure.

What I do not understand is why fdiff calls the function to be evaluated with Digits=26, even on the first call, when Digits=10 and optimalitytolerance=0.01.  To me, this looks like far-from-optimal behaviour, if not a bug.

 



A search for Kronecker finds a single result.  Using Help in Maple 13, a search for Kronecker finds five Help pages, and three dictionary pages.

I would definitely like support for <code>, for the same reasons that others have given.

 

It might be argued that posting SCRs should take extra effort, to avoid cluttering things and taking up developers time.  My view is that potential SCRs should usually first be posted as Product Suggestions; the SCR can be posted afterward. 

As an example, I posted a product suggestion for speeding up convert(_,binary).  The suggested code was based on Knuth, and written carefully.  Yet afterwards, acer found a substantial improvement.  So any SCR posted by me would have been wasting Maplesoft's time.

Should this have been posted in the thread on decimal expansion of pi?
I run Maple under WinXP on a Thinkpad. For n<5000, the routine in my worksheet is faster than Q. But absolute times are so small (e.g. 0.05 seconds) that the speed increase is unlikely to be worth worrying about. As n grows larger than 40000, the speed increase from using Q can be both a substantial ratio and minutes of real time. (The much better performance for larger Digits is presumably due in part to using GMP.) Hence I think that acer's approach should be adopted in all cases.
Thanks for the pointer to Temme's presentation. Googling turned up three more-recent works that might be of interest. Gil A., Segura J., Temme N.M. (2007), “Numerically satisfactory solutions of hypergeometric recursions”, Mathematics of Computation, 76: 1449–1468. Gil A., Segura J., Temme N.M. (2007), Numerical Methods for Special Functions, SIAM. [Book, also available via amazon.] Temme N.M. (2008), “Numerical aspects of special functions”, Acta Numerica, 17: 1–101. The last explicitly discusses Maple, albeit briefly.
1 2 3 4 5 6 7 Last Page 1 of 13