This kind of CPU load, just to get a reminder, is a terrible idea.

acer

@Christopher2222

Problem 1) Reducing the working precision of a computation just to manage the output display is a bad idea. It's much better to compute with default (or higher, if required) precision and then manage the display separately. Whether one printf's, of evalf's final floats, or uses the displayprecision mechanisms of GUI or `interface` is more a matter of taste or practical consideration -- what matters more is that these are postprocessing approaches, instead of affecting the actual floating-point computations.

Problem 2) Using the multiple-argument syntax of the evalf command to control its precision is not best, in general. The evalf and evalf,details help-pages describe the indexed calling sequence instead.

Sure, the OP might just want to handle only 10.0/50.0 or things just as simple. But maybe more complicated expressions are to be handled, and this was just an illustrative example.

Also, and this is more important, all kinds of other people read the solutions posted in this forum. We should strive for better general solutions, since people will re-use the posted methodolgy and all too often latch on to bad programming habits.

Good coding practice doesn't get the attention is deserves. That's why too many people get into unfortunate habits with respect to `cat` vs `||`, `assign` vs 2-argument `eval`, expressions vs procedures, and a lot of other things that they don't really understand well.

@Christopher2222

Problem 1) Reducing the working precision of a computation just to manage the output display is a bad idea. It's much better to compute with default (or higher, if required) precision and then manage the display separately. Whether one printf's, of evalf's final floats, or uses the displayprecision mechanisms of GUI or `interface` is more a matter of taste or practical consideration -- what matters more is that these are postprocessing approaches, instead of affecting the actual floating-point computations.

Problem 2) Using the multiple-argument syntax of the evalf command to control its precision is not best, in general. The evalf and evalf,details help-pages describe the indexed calling sequence instead.

Sure, the OP might just want to handle only 10.0/50.0 or things just as simple. But maybe more complicated expressions are to be handled, and this was just an illustrative example.

Also, and this is more important, all kinds of other people read the solutions posted in this forum. We should strive for better general solutions, since people will re-use the posted methodolgy and all too often latch on to bad programming habits.

Good coding practice doesn't get the attention is deserves. That's why too many people get into unfortunate habits with respect to `cat` vs `||`, `assign` vs 2-argument `eval`, expressions vs procedures, and a lot of other things that they don't really understand well.

> nops(daytoday(25,12,1899,15,3,1900));
                               82

> nops(daytoday(25,12,2099,15,3,2100));
                               82

acer

@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.

@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