Dave L

Dave Linder

472 Reputation

16 Badges

16 years, 52 days
Maplesoft
Software Architect
Waterloo, Ontario, Canada

 

Dave Linder
Mathematical Software, Maplesoft

MaplePrimes Activity


These are replies submitted by Dave L

As far as the central issue discussed here goes, I'll do that now. I've already discussed it in person with the people who should know about it. It's better to have a duplicate SCR than to miss it altogether.

I'm talking about the loss of functionality between Maple 11 and 12, for updating a  embedded component TextArea using either FileTools:-Text:-Write's default handle or printf and friends. That is a regression.

Sure, one could use `print` or `lprint` or even userinfo and get staggered intermediate output from a running procedure as described in this thread. But those all insert a line break.

It could be nice if the worksheet itself (not an embedded component or Maplet) could also gain this functionality.

I'll enter these two separately.

Dave Linder
Mathematical Software, Maplesoft

As far as the central issue discussed here goes, I'll do that now. I've already discussed it in person with the people who should know about it. It's better to have a duplicate SCR than to miss it altogether.

I'm talking about the loss of functionality between Maple 11 and 12, for updating a  embedded component TextArea using either FileTools:-Text:-Write's default handle or printf and friends. That is a regression.

Sure, one could use `print` or `lprint` or even userinfo and get staggered intermediate output from a running procedure as described in this thread. But those all insert a line break.

It could be nice if the worksheet itself (not an embedded component or Maplet) could also gain this functionality.

I'll enter these two separately.

Dave Linder
Mathematical Software, Maplesoft

I like to think that there is some path to an evalat function which is not "really, really" slow and which is also significantly stronger than at present.

Dave Linder
Mathematical Software, Maplesoft

I said that I would give my opinion on this. So, what follows is that: just my own personal opinion.

Let's call the functionality evalat, just to distinguish it from 1-argument eval.

I think that the behaviour in the posted example shows something that could (and should) be improved.

One scenario that concerns me here is that in which the calling of evalat is made deep inside some routine in the shipped Maple Library. That's quite different from cases where the user calls it interactively (directly) at the top-level. I'm thinking of cases where there is no chance for the user to intercede and choose to do some different analysis of the expression at or near the point.

And, as I only found out only a few days ago, this very example was such a case. The user received an answer for a complicated computation that turned out to be wrong. This (longstanding, expert) user was fortunately able to recognize that the result was wrong, and was able to trace the problem back to this particular evaluation at a point, which was being done within some Library routine. So there was no clean and simple workaround -- no immediate way to make the Library routine take some other approach.

As a Maple user, I would be prepared to take a small performance penalty if evalat could be improved here. If one wanted to use a super fast but mathematically unsafe evaluator then one could make do with subs, which is more intended for substitution into a data structure. But eval is supposed to be the smarter, mathematical safer evaluator.

And the improvement should be centralized. I don't buy a line of argument which says that individual Library routines all ought to be more careful in their use of evalat. The evalat functionality is used very widely within the Maple Library. If Maple's going to be improved to be stronger in its zero detection when evaluating expressions at points, for mathematical computation, then that should be done centrally.

Maple is not finished. No computer algebra system will ever be perfect. But the competition will improve, and thus so must Maple. I think that we ought to be able to seriously revisit this kind of functionality at least once every few years. It's in the class of issues for which -- while perfection is unattainable -- incremental, practical improvements are good.

This problem should not be impossible to cover adequately. Perhaps radicals could be dealt with at object simplification/uniquification time. Eg. 27^(1/2) -> 3*3^(1/2) automatically. Having evalat revert to substituting `^` by root and sqrt (as shown here) would be prohibitively expensive.

An extensible, user-customizable solution might be cheapest, if the default behaviour were not changed. That's because the system would only have to check something simple like a flag. And the user could choose how hard the system ought to work at zero testing. But then, how helpful would it be, if the default behaviour were left as it is?

Dave Linder
Mathematical Software, Maplesoft

While the behaviour of the expression around a=1/3 may be interesting in its own right, the bit that we discussed was the behaviour of eval() at just that given point.

More specifically, is it a "bug"? And if so then how serious is it? Should the burden be on the user to recognize the issue and work around it? Is documentation of the potential problem "good enough"? Is speed more important than correctness here? And what might be done about resolving the class of such problems directly?

Dave Linder
Mathematical Software, Maplesoft

Hi Alec,

I'm not personally in a position to grant you a copy. But I can pass along the request.

If you don't already know of it, you might be interested in Maplesoft's Beta site.

Dave Linder
Mathematical Software, Maplesoft

I'll do it.

Dave Linder
Mathematical Software, Maplesoft

I have recorded this problem, so that it gets attention. Thank you for posting it, Axel.

Dave Linder
Mathematical Software, Maplesoft

Curiously, another member of our mathematical software development group mentioned this routine to me today. The developer -- who mentioned looking at this a while ago -- said that the routine behaves something like K*m*n , and might not seq(`if`(..)..) be faster? I asked if this stemmed from the mapleprimes thread, but apparently it was independent.

I used to be more surprised by such coincidences, when things being considered in-house matched some external query or request. It's hard to always keep in mind that coincidences get noticed while the many more instances of no coincidence pass by quietly.

And then I found out that John and yet another math developer had been discussing mixed strategies. For example, starting off with one method and then possibly switching methods if the number of matches reached a key value and if there was yet some other key value of entries still left to search. (Such key values might depend on each other, and on what proportion had been searched so far.)

So, I'm pretty sure that we'll figure out a good heuristic for this. I've been reminded that ListTools is important as a lower level utility in the Math Library (eg. in `solve`, etc).

Dave Linder
Mathematical Software, Maplesoft

Use of OMP_NUM_THREADS is an MKL thing rather than a Maple thing per se. I can conjecture as to the rationale of its use in MKL. It gives one some separate control of the CPU usage allotment which might not be possible were only a Windows variable used instead. Its use might also be seen as an effort to adhere to OpenMP.

Dave Linder
Mathematical Software, Maplesoft

Currently, the best ways to submit a bug report are either to send it as email to support@maplesoft.com or to submit it here using the Software Change Request (SCR) form.

Posting it here without submitting it on the SCR form runs the risk that it'll get overlooked, since it adds another layer of dependence on human actions between the submitter and the developer who ultimately gives it attention. The SCR form is a way for you to be able to submit it with greater confidence that it will get into the system.

But I don't see any objection to your posting it and submitting it. Problems in Maple that get posted here often lead to some very interesting discussions and innovative suggestions which I am sure benefit the wider mapleprimes community.

Dave Linder
Mathematical Software, Maplesoft

Hi Toby,

I think that it's a bug, and I will log it as such.

I wrote "nice" because I was suprised by the nature of the quirk. Sorry if that made it unclear.

Dave Linder
Mathematical Software, Maplesoft

> restart:

> f[g]:=evalf:

> f[g][3](2.2222); # OK
                                     2.22

> f[g](2.2222);
Error, invalid input: expected evalf[] index to be
of type posint but received g

Dave Linder
Mathematical Software, Maplesoft

Hi Jacques,

You wrote that it had changed "recently", which initially had me slightly confused. The Math Library section of context-sensitive menus was all rewritten between Maple 9 and 9.5. That's when this change to the order came about, I believe. That development was done in late 2003, so about 4.5 years ago.

The rewrite work was done by a former student of yours, if I recall. Not that you had anything to do with it, of course. But you could ask the author, if you need more details about either the decision to change the item order or about other changes in it.

We know that it also slowed down, both with the rewrite and with the advent of Java in the GUI. Some performance improvements have been made in Maple 12, especially with regard to the speed of generating the context-menus for large Matrices, but also in some other ways. Naturally, we would like to find the resources for making it faster still.

I'm writing here about the performance of the Library-side code that generates the menus on the fly for a given object. The speed of Java for doing its part (especially for the very first menu's initialization) is a whole other GUI aspect from my perspective.

If you see context-menu items that you think are wrong, please do submit them. Thanks.

Dave Linder
Mathematical Software, Maplesoft

Hi Jacques,

Yes, there is a group of Maplesoft developers who read almost every post here.

I will ask; maybe we might be allowed to dump some of our expository "beta" forum posts, or some of the What's New help page content, into a Collaborative Books section here.

Dave Linder
Mathematical Software, Maplesoft

3 4 5 6 7 8 9 Page 5 of 11