The only ImageTools routine that was of use to me in this was Read. I'm simply implementing some formulae for such distortion and applying them to the (layers of the ) image Array.

I'm using option autocompile on the procedures, with evalhf as a fallback. The polynomial formula for forward distortion is evaluated using Horner's rule. I was only looking at the kinds of distortion due to focal length (ie. wide-angle barrel distortion, pincushion, etc) and not due to mismatch focal planes. I'm using an order 3 polynomial.

The very fast prototype version just truncates the Array index value, when accessing from the source Array. A less lossy version would interpolate. (I haven't figured out whether I'll use Curvefitting:-ArrayInterpolation or a hard-coded formula for that yet.)  I haven't yet split out the action so as to treat the three color layers separately (though I understand that this may be desirable as there is a rare lens issue with focal length distortion that affects some colors more than others, so that correcting them separately may be desirable.)

I probably won't have time to make it presentable until next week at earliest.

acer

The only ImageTools routine that was of use to me in this was Read. I'm simply implementing some formulae for such distortion and applying them to the (layers of the ) image Array.

I'm using option autocompile on the procedures, with evalhf as a fallback. The polynomial formula for forward distortion is evaluated using Horner's rule. I was only looking at the kinds of distortion due to focal length (ie. wide-angle barrel distortion, pincushion, etc) and not due to mismatch focal planes. I'm using an order 3 polynomial.

The very fast prototype version just truncates the Array index value, when accessing from the source Array. A less lossy version would interpolate. (I haven't figured out whether I'll use Curvefitting:-ArrayInterpolation or a hard-coded formula for that yet.)  I haven't yet split out the action so as to treat the three color layers separately (though I understand that this may be desirable as there is a rare lens issue with focal length distortion that affects some colors more than others, so that correcting them separately may be desirable.)

I probably won't have time to make it presentable until next week at earliest.

acer

> restart:

> with(Statistics):
> G:=Sample(RandomVariable(Normal(0,1)),10):

> Mean(G);
                                -0.04797088930

> StandardDeviation(G);
                                 0.7424204031

> tmean := 0.0:
> for kk from 1 to 10 do
>   tmean := tmean + G[kk];
> end do:
> tmean := tmean/10;
                            tmean := -0.04797088937

> tSD := 0.0:
> for kk from 1 to 10 do
>   tSD := tSD + (G[kk]-tmean)^2;
> end do:
> sqrt(tSD/(10));
                                 0.7043218365

> sqrt(tSD/(10-1));
                                 0.7424204031

acer

> restart:

> with(Statistics):
> G:=Sample(RandomVariable(Normal(0,1)),10):

> Mean(G);
                                -0.04797088930

> StandardDeviation(G);
                                 0.7424204031

> tmean := 0.0:
> for kk from 1 to 10 do
>   tmean := tmean + G[kk];
> end do:
> tmean := tmean/10;
                            tmean := -0.04797088937

> tSD := 0.0:
> for kk from 1 to 10 do
>   tSD := tSD + (G[kk]-tmean)^2;
> end do:
> sqrt(tSD/(10));
                                 0.7043218365

> sqrt(tSD/(10-1));
                                 0.7424204031

acer

Since Maple's Compiler is generally available (bundled Watcom on 32bit Windows, free MS compiler on 64bit Windows, free gcc on Linux&OSX&Solaris) it seems ok to use it for this task.

#Number theory
#Calculation of 10000000 fibonacci numbers

> t,tr:=time(),time[real]():
> N:=10^7:
> A := LinearAlgebra:-RandomVector(N,generator=100..1000,
>                 outputoptions=[datatype=integer[4]]):

> f := proc(a::Vector(datatype=integer[4]),b::Vector,n)
>         option autocompile; local phi,s5,i;
>         s5:=sqrt(5.); phi:=0.5*s5+0.5;
>         for i from 1 to n do
>           b[i]:=(phi^a[i]-(-phi)^(-a[i]))/s5;
>         end do;
>         NULL;
>      end proc:

> B:=Vector(N,datatype=float[8]):
> f(A,B,N): # results are in B
> min(time()-t,time[real]()-tr);
                                     5.340

(32bit Linux, Maple 13.01, Intel(R) Pentium(R) 4 CPU 3.20GHz)

acer

The question "how do I assign the results of a `solve` call to the individual variable names?" is a frequently asked question.

But often it is the "wrong" question, for the given task, where the "right" question is often more like, "how to I use the results of a `solve` call?".

Doug's reply above, showing the distinction between `assign` versus 2-parameter `eval`, is what ought to go in the FAQ page for this topic.

(A FAQ item for this topic might simply use equations and not Matrix M, to make it appear more general.)

acer

The question "how do I assign the results of a `solve` call to the individual variable names?" is a frequently asked question.

But often it is the "wrong" question, for the given task, where the "right" question is often more like, "how to I use the results of a `solve` call?".

Doug's reply above, showing the distinction between `assign` versus 2-parameter `eval`, is what ought to go in the FAQ page for this topic.

(A FAQ item for this topic might simply use equations and not Matrix M, to make it appear more general.)

acer

I can search for the word nebuchadnezzar and get to this thread. So some of my posts have been processed so as to allow searching.

It could be that the reply containg shake and evalr wasn't so processed because the terms were in URLs, or were highlighted, or because some mechanism doesn't work as it once did. Or, possibly, because it seemed negative (but isn't that a slightly paranoid supposition?).

acer

Why are all those procs being created inside the counter loop? That means that Maple has to recreate the actual procedure bodies with each interation throught the loop, which inefficient.

Also, when there are that many global variables in all the procs, that is another sign that something is amiss.

acer

Why are all those procs being created inside the counter loop? That means that Maple has to recreate the actual procedure bodies with each interation throught the loop, which inefficient.

Also, when there are that many global variables in all the procs, that is another sign that something is amiss.

acer

Why would you want the routine to be more simple, for its own sake? For these kinds of routines, it can pay off to take the time and make it super efficient and super fast, even if that does't make it simple.

I suspect that the following internal routines, which ImageTools:-Rotate uses to do the actual work, could be made more efficient. I'm looking at these "helper" routines used by Rotate.

kernelopts(opaquemodules=false):
eval(ImageTools:-rotate:-rotate_90);
eval(ImageTools:-flip:-flipHorz);
eval(ImageTools:-flip:-flipVertInplace);

They generally have double (nested, one to the number of layers and one to the widht) loops with calls to ArrayTools:-Copy at the inside. External calls are expensive enough that this is not best. It would likely be more efficient to put all that in C instead (where function calls are much less expensive) . Alternatively, it could all be rewritten as procs with option autocompile and/or option hfloat or be made evalhf'able. I guess that they can't easily be passed to the Compiler with ArrayTools calls which are call_external. What I'm trying to say is this: ArrayTools:-Copy is a compiled routine, sure, and that is fast. But simply calling ArrayTools:-Copy many times (for each column, for each layer) is in itself a cost that accumulates and which could be avoided by instead having the entire routine be compiled.

In other words, if you want best performance then make it all run (somehow) as compiled code. Avoid Maple function calls.

The ImageTools:-rotate:-rotate_180 works by doing both a flip and a flop. That cost might be cut in half, by doing the rewrite directly. But perhaps that could only use fast vendor BLAS if the dcopy admits a negative increment argument, and so a single straight piece of O(n^2) C code might be slower than twice the work done using cache-tuned BLAS. You'd have to benchmark it.

To it's credit, the ImageTools:-Rotate routine does allow inplace operation on an optional output argument (as I described above) and thus allows for no unnecessary garbage production. That is a very good thing, because garbage generation and collection (...like Maple function calls)  is another big potential efficiency hit.

acer

Why would you want the routine to be more simple, for its own sake? For these kinds of routines, it can pay off to take the time and make it super efficient and super fast, even if that does't make it simple.

I suspect that the following internal routines, which ImageTools:-Rotate uses to do the actual work, could be made more efficient. I'm looking at these "helper" routines used by Rotate.

kernelopts(opaquemodules=false):
eval(ImageTools:-rotate:-rotate_90);
eval(ImageTools:-flip:-flipHorz);
eval(ImageTools:-flip:-flipVertInplace);

They generally have double (nested, one to the number of layers and one to the widht) loops with calls to ArrayTools:-Copy at the inside. External calls are expensive enough that this is not best. It would likely be more efficient to put all that in C instead (where function calls are much less expensive) . Alternatively, it could all be rewritten as procs with option autocompile and/or option hfloat or be made evalhf'able. I guess that they can't easily be passed to the Compiler with ArrayTools calls which are call_external. What I'm trying to say is this: ArrayTools:-Copy is a compiled routine, sure, and that is fast. But simply calling ArrayTools:-Copy many times (for each column, for each layer) is in itself a cost that accumulates and which could be avoided by instead having the entire routine be compiled.

In other words, if you want best performance then make it all run (somehow) as compiled code. Avoid Maple function calls.

The ImageTools:-rotate:-rotate_180 works by doing both a flip and a flop. That cost might be cut in half, by doing the rewrite directly. But perhaps that could only use fast vendor BLAS if the dcopy admits a negative increment argument, and so a single straight piece of O(n^2) C code might be slower than twice the work done using cache-tuned BLAS. You'd have to benchmark it.

To it's credit, the ImageTools:-Rotate routine does allow inplace operation on an optional output argument (as I described above) and thus allows for no unnecessary garbage production. That is a very good thing, because garbage generation and collection (...like Maple function calls)  is another big potential efficiency hit.

acer

I do not know the exact answer, offhand.

But consider that Maple does things in base 10, and for arithemetic and trig (and some other common special functions) it gets accuracy (in base 10 ulps) also in terms of base 10 digits. So a floating-point library which acts at arbitrary precision base 2 is going to behave differently.

For Maple to get the same radix 10 accuracy as at present, but somehow utilizing mpfr, it would have to work out the corresponding/equivalent precision/accuracy/guards in radix 2 as it needed for radix 10, or vice versa, for each atomic computation. Maybe I don't know what I'm talking about.

The latest timing comparison at that site that I see is for mpfr v2.4.0 (though the latest seems to be v2.4.2). And that is run compared against Maple 12. Older timings are also there (eg. here against Maple 9.01). So one can see something about how its performance has changed, relative to the competition.

It's diffcult to see immediately exactly how Maple might have improved versus itself since the timings are reported as run on different machines. Of course, if you wanted to see how Maple had progressed, you could run the Maple source of their timing comparison on your same machine, against various releases.

acer

He asked twice. And you answered in the other thread. See here.

The answer is yes, it can be done in Maple.

acer

Sorry, I typed that wrongly. It's a thread in the group sci.math.symbolic, not comp.soft-sys.math.maple.

But the links should still work correctly.

acer