@Christopher2222 For your code example I see the very same output in the 32bit Windows versions of Maple 14.01 as well as in Maple 12.02, 13.00, and 15. I just don't see the difference in output that you've ascribed to Maple 14.

I mean in the Standard GUI, when running in a Worksheet. With either 1D or 2D input. And the same, for either "Extended" or "Maple Standard" Typesetting level.

An example. The second result below is correct to both places after the decimal point, after rounding. The first result is inaccurate.

> restart:

> evalf[2]( (1-sqrt(5))/2 );

                             -0.60
> restart:

> evalf( (1-sqrt(5))/2 ):

> evalf[2]( % );

                             -0.62

acer

An example. The second result below is correct to both places after the decimal point, after rounding. The first result is inaccurate.

> restart:

> evalf[2]( (1-sqrt(5))/2 );

                             -0.60
> restart:

> evalf( (1-sqrt(5))/2 ):

> evalf[2]( % );

                             -0.62

acer

@Joe Riel I was feeling ambivalent about showing the 1-level eval alternative, for the top-level computation, because this post contains just one of several reasons why I think that procedures are very useful and important. Ease of workflow, debugging, profiling... the list goes on. But it's good that you mention it, so that readers will be more informed about their choices for programming. Thanks.

For me, the Maple's programming language is the gem that lies at the heart of the product. Fancy GUI, nice plots, slick formula output, that's all well and good. But the jewel -- the thing that lets you accomplish so much -- is the powerful programming language. It is the best and most important part of the product, not just for advanced users but for all users.

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