ImageTools needs the Array to have datatype=float[8]  in order to accept it as representing an image.

But `map` does not preserve the datatype. One way to apply `round` to image `b`, and get that same datatype for the returned Array is to use `map[evalhf]` instead. That will also be faster than using just `map` and then casting it afterwards. It works because `round` is evalhf'able.

Note that kernel builtin `trunc` will also be faster that Library level `round`, even without using evalhf.

st:=time():
d1:=Array(map(round,b),datatype=float[8]):
time()-st;
                             1.922

st:=time():
d2:=Array(map(trunc,b),datatype=float[8]):
time()-st;
                             0.141

st:=time():
d3:=map[evalhf](round,b):
time()-st;
                             0.031

st:=time():
d4:=map[evalhf](trunc,b):
time()-st;
                             0.031

LinearAlgebra:-Norm(Matrix(d1-d2));
                               0.

LinearAlgebra:-Norm(Matrix(d1-d3));
                               0.

LinearAlgebra:-Norm(Matrix(d1-d4));
                               0.

All of d1,d2, d3, and d4 above now work with ImageTools:Preview, for example.

acer

What's the status of finding a fix for this? (Last round of multi-thread spam posts was this morning 27/04/2011.)

[edited, as maybe this site no longer runs drupal?]

The spam is irritating, and it makes people want to participate here less often.

If a good, functional "banning" solution (which circumvents bugs, cookie- or persistent login-related or not) will take more than a week to code then write a quick one-off script for the interim. Note that spam's been a problem quite longer than that, by now. Have the script/daemon scan every 20 mins for submissions by blacklist authors, and delete them automatically. Then keep working on a proper solution, because the integrity of the timeline on the "Recent" page is one of the more useful parts of this site. Just an idea.

acer

A quick graphical comparison of computation times is interesting (to me, at least, because I'm fascinated by Maple's performance quirks, and especially mysteries like unexplained near-linear vs quadratic timing growth). Suchs issues matter, when one wants to scale high. Profiling, or examing bytesused may indicate garbage collection as one issue. I haven't looked further.

Here below we see the simpler code growing much faster in its execution time. (I did not measure the growth rates quantitaively, but the plot gives the picture.)

restart:

N:=2011:
inc:=64:

for m from 2 to N by inc do
  st:=time();
  add(j*round(m!/2^(j+1)),j=1..round(log[2](m!)));
  H[m]:=time()-st;
end do:

PP:=proc(n) n! - Q(n!/2); end proc:
Q:=proc(n) local w, m, i;
   w := 0; m := n;
   while m > 0 do
     i := m mod 2;
     w := w+i;
     m := (m-i)/2;
   end do;
   w;
 end:

for m from 2 to N by inc do
  st:=time();
  PP(m);
  A[m]:=time()-st;
end do:

plots:-display(
  plots:-pointplot([seq([i,H[i]],i=2..N,inc)],color=red),
  plots:-pointplot([seq([i,A[i]],i=2..N,inc)],color=blue)
               );

add(j*round(2011!/2^(j+1)),j=1..round(log[2](2011!))) - PP(2011);

                               0

acer

A quick graphical comparison of computation times is interesting (to me, at least, because I'm fascinated by Maple's performance quirks, and especially mysteries like unexplained near-linear vs quadratic timing growth). Suchs issues matter, when one wants to scale high. Profiling, or examing bytesused may indicate garbage collection as one issue. I haven't looked further.

Here below we see the simpler code growing much faster in its execution time. (I did not measure the growth rates quantitaively, but the plot gives the picture.)

restart:

N:=2011:
inc:=64:

for m from 2 to N by inc do
  st:=time();
  add(j*round(m!/2^(j+1)),j=1..round(log[2](m!)));
  H[m]:=time()-st;
end do:

PP:=proc(n) n! - Q(n!/2); end proc:
Q:=proc(n) local w, m, i;
   w := 0; m := n;
   while m > 0 do
     i := m mod 2;
     w := w+i;
     m := (m-i)/2;
   end do;
   w;
 end:

for m from 2 to N by inc do
  st:=time();
  PP(m);
  A[m]:=time()-st;
end do:

plots:-display(
  plots:-pointplot([seq([i,H[i]],i=2..N,inc)],color=red),
  plots:-pointplot([seq([i,A[i]],i=2..N,inc)],color=blue)
               );

add(j*round(2011!/2^(j+1)),j=1..round(log[2](2011!))) - PP(2011);

                               0

acer

If you want to talk to a web server over a socket connection, then you can study the Hypertext Transfer Protocol (HTTP). ... here is one sort of header summary.

The idea is this: if you want to talk to an HTTP server, then you'll likely need to know its communication protocol. It's not a Socket thing per se, since sockets could be used to talk to all sorts of other things too. For some other socket communication task you might then need to converse according to some other networking protocol.

I don't think that the Sockets help-page has space to teach a course in sockets communication. But you can check out its references section (available directly in your Maple 12 Help as well).

acer

If you want to talk to a web server over a socket connection, then you can study the Hypertext Transfer Protocol (HTTP). ... here is one sort of header summary.

The idea is this: if you want to talk to an HTTP server, then you'll likely need to know its communication protocol. It's not a Socket thing per se, since sockets could be used to talk to all sorts of other things too. For some other socket communication task you might then need to converse according to some other networking protocol.

I don't think that the Sockets help-page has space to teach a course in sockets communication. But you can check out its references section (available directly in your Maple 12 Help as well).

acer

It seems that a very long line (eg, long string) does not always get shown by this site, as it may bleed off the edge of what is visible in one's browser.

The code above could also look like this (just cut 'n paste as 1D Maple Notation source code),

s:=Sockets:-Open("Tomorrowsgaspricetoday.com",80):
Sockets:-Write(s,"GET /rssfeed.php?city=16 HTTP/1.1\nContent-Type: text/plain
                  User-Agent: Maple\nHost: tomorrowsgaspricetoday.com:80\n\n"):
R:="": count:=0:
while count<100 do
  r:=Sockets:-ReadLine(s,30);
  if r=false then break;
  else R:=cat(R,"\n",r);
       count:=count+1;
  end if;
end do:
R;

acer

It seems that a very long line (eg, long string) does not always get shown by this site, as it may bleed off the edge of what is visible in one's browser.

The code above could also look like this (just cut 'n paste as 1D Maple Notation source code),

s:=Sockets:-Open("Tomorrowsgaspricetoday.com",80):
Sockets:-Write(s,"GET /rssfeed.php?city=16 HTTP/1.1\nContent-Type: text/plain
                  User-Agent: Maple\nHost: tomorrowsgaspricetoday.com:80\n\n"):
R:="": count:=0:
while count<100 do
  r:=Sockets:-ReadLine(s,30);
  if r=false then break;
  else R:=cat(R,"\n",r);
       count:=count+1;
  end if;
end do:
R;

acer

The Programming Guide for Maple 15 is (at present) available from the Documentation Center.

acer

The Programming Guide for Maple 15 is (at present) available from the Documentation Center.

acer

A Plot Component can be resized programatically.

plotcomponent.mw 

acer

A Plot Component can be resized programatically.

plotcomponent.mw 

acer

@hirnyk That's exactly my point! You won't know whether it is just taking a long time, or not converging at all, when it seems to run forever! The same is true for the original code (though that is much slower, on top of having this problem).

So, that was my point. How to control the Digits (in two places, perhaps differently) so that it is 1) not slower than it has to be, and 2) convergent, and 3) convergent at the correct minimal value of n-1?

I don't think that those are easy questions, without knowing some analysis of the behaviour of the famous approximation.

(note. when I wrote that Digits might have to depend on q, inside `euclid`, that introduces a technical issue. We want `euclid` to remember results. But we don't want it to remember inaccurate float results. So `euclid` would have to accept an additional argument q, if internally it used Digits as a function of q.)

acer

@hirnyk That's exactly my point! You won't know whether it is just taking a long time, or not converging at all, when it seems to run forever! The same is true for the original code (though that is much slower, on top of having this problem).

So, that was my point. How to control the Digits (in two places, perhaps differently) so that it is 1) not slower than it has to be, and 2) convergent, and 3) convergent at the correct minimal value of n-1?

I don't think that those are easy questions, without knowing some analysis of the behaviour of the famous approximation.

(note. when I wrote that Digits might have to depend on q, inside `euclid`, that introduces a technical issue. We want `euclid` to remember results. But we don't want it to remember inaccurate float results. So `euclid` would have to accept an additional argument q, if internally it used Digits as a function of q.)

acer

Call your a+b*I as the more commonly used name z. You z^n is a special instance of (z-c)^n, where c=0.

You've implied (by your "begin with") that the general term has something more that just the (a+b*i)^n to it. Let's express the general term as a(n)*(z-c)^n, where a(n) is the part you omitted to mention explictly.

Now read here, on Laurent series. You wrote that you suspect convergence for all z such that abs(Re(z))<1 and abs(Im(z))<1. That's not right, in general. But you can read there about convergence for z in an annulus.

This is part of the basics of complex analysis, which is well studied.

acer