Re: Efficiency of code generated by Ada compilers

["Elias Salomão Helou Neto" <eshneto@gmail.com>]

On Aug 13, 12:37 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Fri, 13 Aug 2010 08:08:42 -0700 (PDT), Elias Salomão Helou Neto wrote:
>
> > 1) You can, in more than one way, tell the compiler to suppress most
> > (any?) checks, but people do not advise to do so. Even if I say that I
> > do need that :(
>
> You think you need that, but you cannot know it, because you didn't used
> Ada and have no experience to realistically estimate the amount of checks
> an Ada compiler would introduce in your, not yet developed program.

This is a good point indeed! But it should be a really smart compiler
to realize that my ray-tracing algorithm is mathematically designed to
not to go out of bounds and so suppress automatically those checks.
Anyway, it wouldn't be wise not to try it out.

>
> > P.S: Multidimensional _arrays_ are not multidimensional _matrices_
>
> I don't see any difference, unless specialized non-dense matrices are
> considered.
>
> > neither are them MD _images_.
>
> Same here. Multi-channel images, sequences of images, scenes can be seen
> and implemented as  arrays. Again, unless some special hardware is in play.

Well, in such a case C could do the job, right? Encapsulating the low-
level array implementation within well designed classes, possibly
templated ones, would be a much better idea, would not?

What I meant from the beginning was to possibly write code such as
(sorry for the C++ syntax):

Matrix< 3, double > volumeImage( 100, 100, 100 );
Matrix< 2, char > asciiArt( 50, 75 );

asciiArt( 10, 10 ) = a;
volumeImage( 1, 2, 3 ) = 5.7;

Where those two or three dimensional members/constructors were
automatically generated by the compiler by using "template
metaprogramming". It will be possible with C++0x. It is already
possible by using the experimental implementation of the new standard
in GCC.

>
> > The two latter are far more specific
> > classes and the last case even needs to be templated in, say, pixel
> > type, etc.
>
> I don't see a great need in that. Usually the type of pixel (grayscale,
> tricky color models, separate channels etc) influences image operations so
> heavily that the common denominator might become too thin to be useful, at
> least in the case of image processing.

Humm, I guess you're not quite into the medical image reconstruction
field, right? Granted, you may, very likely, be a much better and
experienced programmer than I am (I am a mathematician, not a computer
scientist), but you should realize that non-overlapping pixels are not
the only beast in this world. There are useful spherically symmetric
pixels that may be parametrized in more than one way and for which you
won't find hardware implementation - recall it is image
reconstruction, not processing.

As for matrices, you've got it right when mentioned sparsity. But it
is not a truly fundamental issue for me, so let us move right along.

Again, you're right when you say that the common denominator may be
too thin. I am right now struggling to find a good compromise and for
that matter in C++ there are template specializations, which are great
in this sense - but far from ideal, of course.

> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

Thanks,
Elias Salomão Helou Neto.