@Teep I would agree with Tom that it's more straightforward to specify the grid size in terms of the number of blocks horizontally and vertically (rather than as a refinement ratio).

Here is a more general example (uglier end-points, without just an integer range).

It uses seq in a similar manner than I had above, but adjusted for this way of specifying the numbers of blocks.

The procedure C can compute the position of an inner block.
 

Download Grid_Example_ac2.mw

@MapleUser2017 The name of the module is MyMat.

So you'd load it using the  with(MyMat)  call.

You keep trying to utilize the name MyLib to refer to the module which you had assigned to MyMat, but that's wrong. The name MyLib is just a name that you introduced for referring to the .mla filename or its location.

This has been mentioned about 4 or 5 times now. It seems that the problem lies not in your Maple installation.

Upload an attachment that contain a definition for f(x,y).

It need not recreate f by previous computations (integrations or what have you). You may be able to lprint the call f(x,y).

But being able to reproduce the issue is important.

Long explanations alone are less useful, for a performance issue.

Could you upload an attachment which can be used to recreate the precise issue?

It only need contain the definition of f(x,y), not all the lead-up computations (integrations, say) to it.

You might be able to just lprint the result of the call f(x,y).

@Adam Ledger My point was not about the fact that `^` is a kernel builtin. My point was that there's no reason to think that the implementation would be the most naive full iterated multiplication.

For big integers it might call a GMP function, so perhaps see here. But why wouldn't all integers be handled as well as that.

I don't understand what you mean by "which factorization". The exponent is stored in binary.

@ThU The OP asked how to combine all the exp terms. But your collect suggestion does not combine all the products of exp terms. I feel that I may be missing your point, sorry. Could you please clarify?

@Adam Ledger You are equating the Maple call x^n with "multiplying x n times".

And that's what I was trying to clarify -- the nature of that belief by you.

I wrote nothing about your code's quality. I am wondering why you think that the Maple kernel implements (large) integer powering with full iterated multiplication. Why do you not imagine that it too might be doing something better?

What is your justification for your expectation that you would be able to write Library-level code that implements binary powering that is faster than the Maple kernel?

You write, "...exponentiation by squares should be faster." Well, to what precisely do you think you are comparing that?

@lima_daniel The line which initially assigns to x has strange output in your original attachment. Does the call to sqrt in that line really produce just a float? Is Asch unassigned? Do you have any initialization file?

Is you Maple otherwise behaving normally? (If you had issues similar to this I'd have expected it to be noticed by you before now...)

@Kitonum  I forgot about this issue (with the NAG LP function in hardware floats). I know it happened for some (but definitely not all!) people's machines, and seems relevant to Windows 64bit rather than Linux.

@Kitonum If the goal is to fit a linear model then the code as written (to call Statistics:-Fit with model a+b*x supplied literally as first argument) may work unexpectedly if a or b are assigned, say, numeric values at the higher level at which LinModel is called. One easy way to deal with that is to declare a and b as local.

Or LinModel could call CurveFitting:-LeastSquares and omit the model argument.

@Earl The reason that Kitonum's original didn't pretty-print as nicely in your Maple 2016 is that you have its default of standard for interface(typesetting), while in Maple 2019 the default is extended.

If you execute interface(typesetting=extended): in Maple 2016.2 then it too will show as Kitonum's original.

One way to force it -- regardless of typesetting level -- is to make the following adjustment to the code. The inert=false option has the additional effect of making all the (+) plus signs render in usual output blue/black rather than gray.

LongSum:=proc(f,n0,n)
 InertForm:-Display(`%+`(seq(f(k),k=1..n0)),
                    ':-inert'=false)+`...`+f(n);
end proc:

LongSum(n->x[n], 2, n);
LongSum(n->n/(n+1), 3, k);
LongSum(n->n/(n+1), 3, 100);

@ActiveUser I am not going to give you a full introductory tutorial to the subject of signal processing.

You can find plenty of that on the internet. You might even look on Mapleprimes and the App Center.

But you could start by searching for FFT (Fast Fourier Transform).

Even a linear fade-in/out for each note (rather than a merging glissando) reduces the clicks I had previously. Now I hear just a minor click between re-runs, when looping it.

The fade could be constructed more automatically, based on the sample rate and duration.

restart;
with(AudioTools):

MK := proc(f::numeric)
        AudioTools:-Create(duration=0.5,rate=44100,
             x->evalhf(sin(x*2*Pi*f/44100))):
      end proc:

S1:=Array(1..22050,x->evalhf(piecewise(x<0.6*22050,5/3*x/22050,
                                       x<0.8*22050.0,1.0,
                                       5*(1.0*22050-x)/22050.0)),
           datatype=float[8]):
S2:=Array(1..22050,x->evalhf(piecewise(x<0.2*22050,5*x/22050,
                                       x<0.8*22050.0,1.0,
                                       5*(1.0*22050-x)/22050.0)),
           datatype=float[8]):
S3:=Array(1..22050,x->evalhf(piecewise(x<0.2*22050,5*x/22050,
                                       x<0.4*22050.0,1.0,
                                       5/3*(1.0*22050-x)/22050.0)),
           datatype=float[8]):

Cmaj:=Create(Vector([S1.MK(261.62),
                     map(u->S2.MK(u),
                         [293.67,329.63,349.23,
                          392.00,440.00,493.88])[],
                     S3.MK(523.25)])):

Write(cat(kernelopts(homedir),"/mapleprimes/Cmaj.wav"),Cmaj):

But I have yet to adjust for even loudness (for the average teenage listener, say).

@ActiveUser My computer computes the Array and exports it to a 4.0sec duration .wav file very quickly, doing it all in a fraction of a second in real time. These pure tones Arrays could be constructed quickly in a routine that runs wholly under evalhf, even in Maple 12. So I suspect that it could be built faster, using AudioTools only for its Write command.

But I won't have time to look at that before Sunday night at the earliest. And I wouldn't know for sure until next week whether it's all just slower in Maple 12 (or whether you might just have a slow machine).

And of course I have no idea what you mean when you say you've used a for-loop, because you haven't been polite enough to show your code.

@ActiveUser 

Here's a C major scale, from C[4] (Middle C) to C[5] (Tenor C), with A[4]=440.00Hz and equal temperament.

restart;
with(AudioTools):

MK := proc(f::numeric)
        AudioTools:-Create(duration=0.5,rate=44100,
             x->evalhf(sin(x*2*Pi*f/44100))):
      end proc:

Cmajor:=Create(Vector(map(MK,[261.62,293.67,329.63,349.23,
                              392.00,440.00,493.88,523.25]))):

Write(cat(kernelopts(homedir),"/mapleprimes/Cmajor.wav"),
      Cmajor):

When I play the exported .wav file I hear a click between the pure tones. It might be possible to remove it by having a windowing effect to have the power taper at the ends of the notes, ie. a fade-in/out, or a glissando. (I won't use any windowing functionality from the SignalProcessing package because the OP has Maple 12.)

I have not used any equal loudness contour so as to make all these pure tones have the same loudness (in phons).