From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,2a34b7ad6c6a0774 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!postnews.google.com!d8g2000yqf.googlegroups.com!not-for-mail From: =?ISO-8859-1?Q?Elias_Salom=E3o_Helou_Neto?= Newsgroups: comp.lang.ada Subject: Re: Efficiency of code generated by Ada compilers Date: Mon, 16 Aug 2010 06:29:42 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <1jn1a4o.1dfllwo1uin3imN%csampson@inetworld.net> <1jn36d6.se2f0g1edjjnyN%csampson@inetworld.net> <61f149b9-00ff-40cd-9698-01e69fdc5c0f@v15g2000yqe.googlegroups.com> <1fwir3k681b8x.unwo52g4gt32.dlg@40tude.net> NNTP-Posting-Host: 143.107.183.162 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1281965382 17262 127.0.0.1 (16 Aug 2010 13:29:42 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 16 Aug 2010 13:29:42 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: d8g2000yqf.googlegroups.com; posting-host=143.107.183.162; posting-account=8auP9QoAAACkSx2qxJhP83KA6-tg78E8 User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.99 Safari/533.4,gzip(gfe) Xref: g2news1.google.com comp.lang.ada:13408 Date: 2010-08-16T06:29:42-07:00 List-Id: On Aug 13, 12:37=A0pm, "Dmitry A. Kazakov" wrote: > On Fri, 13 Aug 2010 08:08:42 -0700 (PDT), Elias Salom=E3o Helou Neto wrot= e: > > > 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 =A0arrays. Again, unless some special hardware is in p= lay. 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 ) =3D a; volumeImage( 1, 2, 3 ) =3D 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 s= o > heavily that the common denominator might become too thin to be useful, a= t > 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=E3o Helou Neto.