@Rouben Rostamian  A number of previously valid .mw files would still run with errors in Maple 2015, if the only amendment made to to Maple 2015.0 were to change the behaviour of the F4 action. The issue would still be for backwards compatibility of users' worksheets.

To retain much better compatibility with valid and functioning worksheets produced in M18 and earlier, while still obtaining new convenience (as indicated in the very last example here) it seems to me that the new behaviour could just be amended to:

     A explicit statement terminator such as a colon or semicolon is no longer
     required in 1D Maple Notation input for the last line of an Execution Group.

One way that this popup can occur is if you try and open an empty file (0 bytes) in the Standard GUI, even if it has ".mw" as the file extension.

(And one unfortunate way that zero-length .mw files can be generated is by downloading unzipped .mw attachments from email, using some webmail tools such as client to a misconfigured Outlook server. This because the mail server can misidentify the attachment, since .mw Maple files contain XML.)

So check whether the file is not empty. If it's an .mw file and it's not empty then you might upload it here so that we could try and see what's wrong with it.

acer

Which version of Maple are you using, and which platform (32bit or 64bit?).

acer

@Alejandro Jakubi I think that my narrative here doesn't even come close to WRI's position as described in the link you gave. I'm very much against that view being applied to Maple. And indeed I am one of the relatively few people who has posted fixes to Library code on this site. And many of my Posts here comprise new techniques to make use of Maple's full functionality (whether documented or not). Maple's openness is one of its great strengths.

I merely mentioned waiting for a point-release as something I might do in this particular case. But I also described two approaches, and qualified one of them as being difficult or involved (ie, "tricky"). I haven't advocated that anyone else not try. Everyone is free to decide for themselves how such efforts' cost measure against the benefits.

I see no merit or truth in your Comment. Please snipe in your own Answer, or contribute concretely.

@itsme Well, you might try cycling through all the exports and locals (and similarly for any submodules you discover such as Explore:-Runtime). Fortunately Explore doesn't have a ModuleLoad which redefines any part of itself, so that's one kind of trickiness avoided.

It might be simpler to just try the combination: unprotect, unset kernelopts(opaquemodules) ?, redefine the ModuleApply, reset kernelopts(opaquemodules), and reprotect in an initialization file. And forego resaving to your own .mla archive.

@itsme It is tricky. You need to ensure that the full module, and all its locals, have been read in from system archive. This is not accomplished by just calling eval on the module, and may not be guaranteed just by calling it on a particular example.

Personally, I'd wait for a point-release fix...

@itsme I see. Thanks. I think that it is a bug, and I will submit a bug report.

I agree, the plot array should be aligned (in its sub-table) toward the controls and not away from them. I'd have to dig and debug before figuring out whether a Library-side code change would help -- plot arrays have some funny alignment behavior which is sometimes purely GUI related, and without debugging I'm not sure offhand whether this is a Library or GUI problem.

OTOH, the sub-table that contains the PlotComponent just seems unnecessarily wide. That too might be a fixable bug, possibly by just adjusting some width-related  fudge factor in the code. I'll let you know if I figure something out.

There is also suboptimal behavior in the subtable on the left (where the controller stuff is). The current value (of 1) is in a subtable that is wide enough to contain an "animating" checkbox. But this is not an animated exploration, so the subsubtable that contains the "1" is just unnecessarily wide. I'll submit this too.

Ok, I (sort of) see part of the problem now. The two principal subtables have column weights of 300 and 1210 for the example you gave. That is see by using infolevel[Explore]:=4 I think, It might be possible to fiddle with the weights, but I suppose that changing the alignment of the PlotComponent's subtable might also be ok. It would have to careful, changing the alignment to `left` only when there were no controllers placed on the right (or vice-versa). Perhaps the ideal solution would consist of both kinds of change, relative weights as well as alignment.

BTW, Your example looked "better" in Maple 18.02, but only in the sense that the width of the PlotComponent was being overridden by the outermost Table's behaviour -- fit to GUI 100% of window. This is something related for which I've already logged a Software Change Request -- Explore could get a new width-mode option to control whether the outermost Table was a fixed percentage of GUI window, or a pixel count at default zoom. (The new Tabulate command in Male 2015 has such an option.)

Could you give a (toy, or simple) example where the alignment problem is manifested?

Also, which version of Maple are you using?

acer

@Carl Love Thanks for those timing results. I'd hazard a guess that this (rather high level) parallelism has its performance benefit constrained by shared use of the cache by multiple cores. 

There may be some additional gains possible by some reuse of the column sums in (what we were previously calling `subimage`). If kerneld has horizontal symmetry then the weighted column sums each contribute to a pair of newaa entries, I think. And if the columns of kerneld are scalar multiples of each other then each column sum (scalar) can be reused even more -- it just needs to be adjusted by a scalar weight corresponding to the particular column as it contributes to several newaa[I,j].

OTOH I'm not sure that ImageTools:-Convolution is using the function for that in the Intel IPP library that Maple now uses for SignalProcessing. So may it too could be faster.

Fun stuff.

In Maple 2015.0 the Task multithreaded compiled code I gave immediately above runs about twice as fast as in Maple 18.02 on my 64bit Windows 7, for that 600x800 example.

@Carl Love You should check your results for correctness, when using `Compile` on a procedure containing calls to `add` over float values. It's a "known bug" that it often get confused about the types in play, in such a mix. As you originally have it the code intended to be compiled will not produce correct results, I suspect. The workaround of replacing `add` calls with explicit loops may slow down under evalhf. So one may need distinct versions for running compiled versus running under evalhf.

The following uses explicit loops instead of `add`, for the Compile version. The temporary accumulator for the sum is a scalar variable, since using `newaa[i,j]` instead as accumulator can (MS-Windows, LLVM compiler) incur a big performance hit due to unnecessary referencing into array memory.

Also, as mentioned before, I also obtain another performance gain by computing i-k-1+m outside of the n-loop (stored in `mindex`).

And lastly, by having the procedure `Convolve_C` accept the lower and upper index values for the i-loop as arguments, the Threads:-Task model can be applied to parallelize the computation.

Download convolve_compiled3.mw

@Carl Love Yes, that top-level code isn't the same as calling `Convolve` without evalhf. Rather, it is an elementwise (vectorized) use of kernel builtin `*` on float[8] rtables which it knows how to treat well. So, yes, it's already parallelized in another way, and is fast despite the fact that it repeatedly creates `subimage` as a collectible garbage rtable.

Attached is a sheet with a few ideas on speedup. This does not include what I'd expect to be best: Compiled and multithreaded with the Task mode.

The top level code can be optimized at its second stage, by rolling the two nested `add` calls into just one call.

Yes, I believe that using order=C_order on `subimage` and `kerneld` can make it a bit faster -- as long as loops or the nested `add` calls walk along rows at their innermost layer (so as to walk adjacent entries in memory).

More saving can be had by constucting part of the `subimage` indicies, for re-use, at the start of each nested i and j loop. (See `ipart`, `jpart`, and `mindex`.)

And then one can notice that `subimage` is not really needed in such a proc.

Download convolve_evalhf.mw

@rollermonkey Your claims about my suggestions appear to be entirely false, and appear to depend on your continued mistyping of key syntax, or misspelling (you now appear to have done with(Plots) not with(plots) as I suggested), or perhaps in part due to a faulty installation. Carl's Answer covers it in detail, I see.

@Carl Love Did you intend,

  subimage[m,n]:= aa[i-k+m-1, j-k+n-1] * kerneld[m,n]

instead of that,

  subimage[m,n]:= aa[i-k+m, j-k+m] * kerneld[m,n]

within that innermost loop of `Convolve`?

You have several basic syntax mistakes which are not version specific.

To assign a plot to name F you need to use the syntax,

F := ...

and not,

F = ...

The plots package is loaded by issuing the command,

with(plots)

and not by (what you have),

withPlots

If you want to call display without loading the package then it would be done like either,

plots[display]( ... )

or,

plots:-display( ... )

and not (as you have it) as,

plots[display][ ... ]

acer