acer

32632 Reputation

29 Badges

20 years, 46 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by acer

Do you really need an explicit formula (eg, a piecewise polynomial)? I mean, what are the subsequent tasks which you wish to accomplish with an "interpolator"?

Would it be satisfactory to have just a (black box) procedure which you could evaluate at any new 2d x-y points? Yet another scenario might be where you need only to plot an interpolated surface.

Sometimes (but not always) it appears that an explicit formua is needed, while turning out in practice that an implicit formulation is adequate to meet the tasks.

acer

@Christopher2222 If you intend this to ever be repeatedly run many times, or to scale to large images, then you should strive for efficiency.

ImageTools:-Create(map(round,b)) is another inefficient solution, similar to Array(map(round,b),datatype=float[8]). See above.

Automatic type/datatype coercion is often [in the context of hardware float computation] a really bad idea, in that it fosters highly inefficient coding. The advantage of efficiency is not coolness, or bragging rights, etc. It's that it can allow larger probems to be tractable.

If there's only one (or very few) efficient way(s) to accomplish a task, then its documentation will be naturally easier to make good, and people will learn how to do it well. If there are many ways, and most of them are easy and inefficient, then people will have great difficulty in learning how to do it well.

Suppose that the rest of ImageTools were changed to accept numeric Arrays which didn't have float[8] datatype, by virtue of some new mechanism to automatically convert the input data. Then before you could say Rumplestiltskin many people would write a lot of code that involved huge amounts of new. unseen, and automatic data structure conversion done behind the scenes. Goodbye competitive performance.

@Christopher2222 If you intend this to ever be repeatedly run many times, or to scale to large images, then you should strive for efficiency.

ImageTools:-Create(map(round,b)) is another inefficient solution, similar to Array(map(round,b),datatype=float[8]). See above.

Automatic type/datatype coercion is often [in the context of hardware float computation] a really bad idea, in that it fosters highly inefficient coding. The advantage of efficiency is not coolness, or bragging rights, etc. It's that it can allow larger probems to be tractable.

If there's only one (or very few) efficient way(s) to accomplish a task, then its documentation will be naturally easier to make good, and people will learn how to do it well. If there are many ways, and most of them are easy and inefficient, then people will have great difficulty in learning how to do it well.

Suppose that the rest of ImageTools were changed to accept numeric Arrays which didn't have float[8] datatype, by virtue of some new mechanism to automatically convert the input data. Then before you could say Rumplestiltskin many people would write a lot of code that involved huge amounts of new. unseen, and automatic data structure conversion done behind the scenes. Goodbye competitive performance.

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

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

First 442 443 444 445 446 447 448 Last Page 444 of 597