Very fun. (...but what's up with Navajo White?!)

The mention of color metrics is tantalizing.

Suppose I had two colors denoted by a pair of RGB values, and that I wanted to evenly transition between them. Will a plain linear transition in the RGB space look good? Or should I first map the values to some other color space?

What if I wished to avoid going anywhere near gray, during the transition? Is that easier to map in another color space? Do I need to compute how "opposite" the two initial colors are, to calculate whether they would otherwise transition through something like gray?

acer

A very nice post. In under 24 hours it appeared to get something like ten times as many (distinct IP, and twenty times as many total) views as any prior post had ever accumulated.

Is the voxel-ization code in the attached worksheet generally reusable? Could it be pulled out for easy use?

I note the use of the zlib library for i/o. Was that at all inspired by Alec's very nice post here? Or was it needed for minecraft formatting?

Note to admins: Is there a reason that "Corporate" blog posts don't earn their submitters badges like Good Post and Popular Post? (And it's been mentioned before, wouldn't it be more useful if those badge pages linked to the actual posts rather than to the members who submitted them?)

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