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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,4246083efae0e43b X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!not-for-mail From: jpwoodruff@irisinternet.net (John Woodruff) Newsgroups: comp.lang.ada Subject: Re: Singular Value Decomposition (SVD) Ada Algorithm Date: 5 Nov 2004 21:23:17 -0800 Organization: http://groups.google.com Message-ID: <34defe4d.0411052123.49702f47@posting.google.com> References: <35f054ea.0410290918.5f7f7d0@posting.google.com> <34defe4d.0410300854.5c038648@posting.google.com> <35f054ea.0410302259.7510a56e@posting.google.com> <34defe4d.0410311001.36e3680@posting.google.com> <35f054ea.0411010817.52bbf8fc@posting.google.com> NNTP-Posting-Host: 66.81.116.152 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1099718598 30313 127.0.0.1 (6 Nov 2004 05:23:18 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 6 Nov 2004 05:23:18 +0000 (UTC) Xref: g2news1.google.com comp.lang.ada:6015 Date: 2004-11-05T21:23:17-08:00 List-Id: aschwarz@acm.org (skidmarks) wrote in message news:<35f054ea.0411010817.52bbf8fc@posting.google.com>... > > <...> I developed a doubly-linked list. <...> I guess since I might have induced you to show us your thinking, it's proper I offer my remarks. > 1. Optimization of data via generics was avoided. All data is 32-bits. > The rationale is: > a. If size optimized and packed, more instructions are required > during operation for (un)packing operations, which increases > total size, and with more instructions there is decreased > performance. > (The size is relative and depends on use. Performance is bad.) > b. If size optimized and unpacked, then depending on the CPU, slack > bytes are added which increases the size. > c. By making all sizes the same, the issue becomes movement into > and out of the fixed size datum field. Let me say that I have no idea what requirements you're working to. If you're working in a context with a few tens of kilobytes of memory, or with a 100 Khz processor, or the like, I can sympathize with your effort to crowd every last particle of performance. However in my own life, I have stuck with an aphorism on the topic of optimization that I picked up 30 or so years ago: There are two guidelines for micro-optimization: -- Don't do it -- Don't do it yet. <...> > The final result is that there > is a division of responsibility which (I believe) provides an adequate > level of encapsulation and information hiding while giving some > application level conveniences. My thought is that you have not encapsulated quite as much as you might have done. At the outset, you said "All data is 32-bits". But I can think of *a lot* of data that don't comply. And your list handler doesn't cover those. So someday you might need to repeat the effort you expended in order to build a new one. Or, even worse, you or your successor will forget the restrictions and reuse your list manager with a non-32bit-compliant component, and the result might not be pretty. My committment to software engineering was (before I retired) to try to leave lasting artifacts that will function for *decades* in evolving service. The tactics that Ada promotes helped me do that, I think. Other folks have other goals, I guess > There is always room for comment and architectural changes. A dialog > will always be appreciated. > I enjoy the occasional dialog! John