That's interesting. I wonder if the server log contains IP information.

Dave L

Has a winner been picked yet?

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