* Singular Value Decomposition (SVD) Ada Algorithm @ 2004-10-29 17:18 skidmarks 2004-10-29 19:14 ` Jeffrey Carter ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: skidmarks @ 2004-10-29 17:18 UTC (permalink / raw) Anyone have an SVD in Ada? I have the C/C++ versions from Numerical Recipes in C++ (I have the CD-ROM) and would rather not rewrite it into Ada unless I have to. art ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Singular Value Decomposition (SVD) Ada Algorithm 2004-10-29 17:18 Singular Value Decomposition (SVD) Ada Algorithm skidmarks @ 2004-10-29 19:14 ` Jeffrey Carter 2004-10-30 16:54 ` John Woodruff 2004-10-30 19:08 ` Gautier Write-only 2 siblings, 0 replies; 10+ messages in thread From: Jeffrey Carter @ 2004-10-29 19:14 UTC (permalink / raw) skidmarks wrote: > Anyone have an SVD in Ada? I have the C/C++ versions from Numerical > Recipes in C++ (I have the CD-ROM) and would rather not rewrite it > into Ada unless I have to. I'm sure these exist; check adapower.com and adaworld.com. The PragmAda Reusable Components do not offer SVD, but do provide QR factorization, if that is of interest: http://home.earthlink.net/~jrcarter010/pragmarc.htm -- Jeff Carter "Every sperm is sacred." Monty Python's the Meaning of Life 55 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Singular Value Decomposition (SVD) Ada Algorithm 2004-10-29 17:18 Singular Value Decomposition (SVD) Ada Algorithm skidmarks 2004-10-29 19:14 ` Jeffrey Carter @ 2004-10-30 16:54 ` John Woodruff 2004-10-31 6:59 ` skidmarks 2004-10-30 19:08 ` Gautier Write-only 2 siblings, 1 reply; 10+ messages in thread From: John Woodruff @ 2004-10-30 16:54 UTC (permalink / raw) aschwarz@acm.org (skidmarks) wrote in message news:<35f054ea.0410290918.5f7f7d0@posting.google.com>... > Anyone have an SVD in Ada? I have the C/C++ versions from Numerical > Recipes in C++ (I have the CD-ROM) and would rather not rewrite it > into Ada unless I have to. > > art I have a considerable collection of publicly available Ada libraries, and I find that there is one that defines an SVD: You can acquire the Drexel U Matrix Math items from http://dflwww.ece.drexel.edu/research/ada/ They are marked: -- Copyright (c) Drexel University, 1996 -- -- Data Fusion Laboratory -- -- Electrical and Computer Engineering Department -- -- $AUTHORS: Chris Papademetrious, Xiaoxun Zhu, Moshe Kam Their package Generic_Real_Arrays.Operations defines a subprogram "Singular_Value_Decomposition". This might be what you want! John ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Singular Value Decomposition (SVD) Ada Algorithm 2004-10-30 16:54 ` John Woodruff @ 2004-10-31 6:59 ` skidmarks 2004-10-31 18:01 ` John Woodruff 0 siblings, 1 reply; 10+ messages in thread From: skidmarks @ 2004-10-31 6:59 UTC (permalink / raw) > > I have a considerable collection of publicly available Ada libraries, > and I find that there is one that defines an SVD: > > You can acquire the Drexel U Matrix Math items from > http://dflwww.ece.drexel.edu/research/ada/ > They are marked: > -- Copyright (c) Drexel University, 1996 -- > -- Data Fusion Laboratory -- > -- Electrical and Computer Engineering Department -- > -- $AUTHORS: Chris Papademetrious, Xiaoxun Zhu, Moshe Kam > > Their package Generic_Real_Arrays.Operations defines a subprogram > "Singular_Value_Decomposition". > > This might be what you want! Thank you. I haven't looked closely but have looked enough (to say) it seems to be what I need. By-the-by, any reason that you made it a generic package? More a loaded question than you'd expect. What I tend to do, and to encourage others to do, is to separate what needs to be 'generic' from what needs not be 'generic' but is required for the generic package to execute. In my own (very recent experience) I developed a doubly-linked list. List management is a normal package body. The generic package provides space, in the generic body, and interfaces to the non-generic list manager. The effect is to have a no-cost generic package interfacing with a shared non-generic package. (And so I'm on a mission - sigh). Anyway. Thanks. art ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Singular Value Decomposition (SVD) Ada Algorithm 2004-10-31 6:59 ` skidmarks @ 2004-10-31 18:01 ` John Woodruff 2004-11-01 16:17 ` skidmarks 0 siblings, 1 reply; 10+ messages in thread From: John Woodruff @ 2004-10-31 18:01 UTC (permalink / raw) aschwarz@acm.org (skidmarks) wrote in message news:<35f054ea.0410302259.7510a56e@posting.google.com>... > > > > You can acquire the Drexel U Matrix Math items from > > http://dflwww.ece.drexel.edu/research/ada/ > > They are marked: > > -- Copyright (c) Drexel University, 1996 > > Their package Generic_Real_Arrays.Operations defines a subprogram > > "Singular_Value_Decomposition". > > > > This might be what you want! > > Thank you. I haven't looked closely but have looked enough (to say) it > seems to be what I need. > > By-the-by, any reason that you made it a generic package? Well, it wasn't I who did the making. But I'll offer the "conventional" explanation: application writers are wise to select specific types to represent the numeric quantities, and the generic formal in such packages as "generic_real_arrays" is instantiated to reflect those application-specific types. <...> I developed a > doubly-linked list. List management is a normal package body. The > generic package provides space, in the generic body, and interfaces to > the non-generic list manager. The effect is to have a no-cost generic > package interfacing with a shared non-generic package. I'm not sure I followed that claim; you might consider posting an example (folks here are pretty constructive, so you won't get pilloried :) However when I read "generic package provides space", I interpret that to mean maybe you're coercing lots of different "components" of some list, using 'address' to manage memory (?). If that's your suggestion, I don't think I'll agree. In any event, I don't think there is a "cost" argument in favor of avoiding generics -- but I'm interested in the discussion. John ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Singular Value Decomposition (SVD) Ada Algorithm 2004-10-31 18:01 ` John Woodruff @ 2004-11-01 16:17 ` skidmarks 2004-11-06 5:23 ` John Woodruff 0 siblings, 1 reply; 10+ messages in thread From: skidmarks @ 2004-11-01 16:17 UTC (permalink / raw) > <...> I developed a > > doubly-linked list. List management is a normal package body. The > > generic package provides space, in the generic body, and interfaces to > > the non-generic list manager. The effect is to have a no-cost generic > > package interfacing with a shared non-generic package. > > I'm not sure I followed that claim; you might consider posting an > example (folks here are pretty constructive, so you won't get > pilloried :) Sorry. To be brief: 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. 2. The List Manager handles all list operations, insertion, deletion, data changes, and is invariant to any application. 3. The generics: a. Handles transmission of data to/from cell datum fields. b. Creates a free list (an array of cells) in the generic body. c. At instantiation, populate the free list. d. Provide an interface to the List Manager and some application niceties not supported by the List Manager. At the end, the generic functions are all pragma inline and reference the List Manager. Data specific issues are addressed in the generic package which converts data from the user type to the List Manager type via an Unchecked_Conversion, which I assume requires the generation of no code for data which have the same size. The application then does (something like): (Ada like not like Ada): package List is new Generic (data_type); begin Cell := List.Push(local data); Cell := List.Delete(Cell); List.etc end <>; A List Manager equivalent function is: function Push( List, Cell ) return Cell_Adr_Ptr; and the Generic functions which make this happen is: function Push( Data ) return Cell_Adr_Ptr is begin return List_Manager.Push( List, Set_Data( Unchecked_Conversion(Data), NUCELL)); end Push; pragma inline ( Push ); where: NUCELL creates a new cell from the available space list Set_Data puts a datum into a cell List is known only to the generic (the list is created in the generic body. And sorry, this is way too long winded. 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. The generic acts as a no-cost intermediate level (no code or very little code) to the general purpose list manager functions. There is always room for comment and architectural changes. A dialog will always be appreciated. art ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Singular Value Decomposition (SVD) Ada Algorithm 2004-11-01 16:17 ` skidmarks @ 2004-11-06 5:23 ` John Woodruff 2004-11-06 19:28 ` Jeffrey Carter 2004-11-09 17:16 ` skidmarks 0 siblings, 2 replies; 10+ messages in thread From: John Woodruff @ 2004-11-06 5:23 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Singular Value Decomposition (SVD) Ada Algorithm 2004-11-06 5:23 ` John Woodruff @ 2004-11-06 19:28 ` Jeffrey Carter 2004-11-09 17:16 ` skidmarks 1 sibling, 0 replies; 10+ messages in thread From: Jeffrey Carter @ 2004-11-06 19:28 UTC (permalink / raw) John Woodruff wrote: > 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. As I learned it, more like 25 years ago: 1. Don't do it 2. If you must do it, don't do it yet. 3. If you still must do it, see 1. -- Jeff Carter "It's symbolic of his struggle against reality." Monty Python's Life of Brian 78 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Singular Value Decomposition (SVD) Ada Algorithm 2004-11-06 5:23 ` John Woodruff 2004-11-06 19:28 ` Jeffrey Carter @ 2004-11-09 17:16 ` skidmarks 1 sibling, 0 replies; 10+ messages in thread From: skidmarks @ 2004-11-09 17:16 UTC (permalink / raw) jpwoodruff@irisinternet.net (John Woodruff) wrote in message news:<34defe4d.0411052123.49702f47@posting.google.com>... > aschwarz@acm.org (skidmarks) wrote in message news:<35f054ea.0411010817.52bbf8fc@posting.google.com>... > > > > <...> I developed a doubly-linked list. > <...> > > > 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 > I enjoy the occasional dialog! And so I do. Well, you've (and others) given several point of thought. Quickly, let me address some: I learned: 1. There are no absolutes in software. 2. Look at the issues before you solve the problem. In this light there are some notes. Issue: The CPU is of limited capability in an embedded, critical real-time environment. It is very important to conserve space and save speed. The tendered solution seems to solve the issue without compromising system integrity. Programmer optimization is often not required, and more often should not be done (because the compiler does it better and good code is preserved). It is a mistake to say 'never'. It is better to address whether this is an appropriate time to consider optimization by the programmer rather than it is always a mistake for the programmer to 'hand' optimize. I did consider the optimization issues, and did mention them. My opinion is that this a case when the compiler will do more damage than good. Let's consider an example. Hopefully there are counter-examples available which solve the same problems which you are aware of and I am not. Suppose that our data size is a Boolean, and suppose further that we conserve space by using 'pragma packed'. A baseline requirement is that pointers be used, and not just indices, and I am left with something like: (Please correct and glaring Ada errors, but understand that this is just for explication of a viewpoint not for delivery of a product). type Cell_Ptr_Type; type Cell_Type is record Previous: Cell_Ptr_Type; Next : Cell_Ptr_Type; Data : Boolean; end record; type Cell_Ptr_Type is access all Cell_Type; type List_Type(Size: Natural) is record Active: Cell_Type; -- Active List Pointer Free : Cell_Type; -- Available Space List Space : array(1..Size) of aliased Cell_Type; end record; List : List_Type; pragma packed( List ); (Hopefully the Ada isn't too wrong). Now one thing that my approach allows is the complete recovery of all list management functions (inserting, deleting, etc.). This translates into not using a generic for list management and not needing to replicate the list management code for each instance of use with a new type. Another advantage(?) is that non-homogenous lists are supported, provided that the datum size fits into the specified size. Another advantage(?) is that processing overhead is minimized because (in my case) advantage is taken of computer data access characteristics, in this case alignment of cells are on _proper_ boundaries. A disadvantage is that more space is consumed. Given my previous example and looking at the above, 31-bits are wasted for each cell. My point is that the advantages exceed the disadvantages. In particular, the 31-bits lost per cell may be gained when the cost of data plus instruction size (to manipulate the lists) plus instruction size (to access data) plus instruction size (for generic copies of the list management functions) are all included. In general terms, the largest list management routine is (about) 10 SLOC and the remainder vary between 1 - 4 SLOC. Unless the maintainers come from a non-software degree, I wouldn't expect much thought in this case, and I have mentioned that issues should be considered before solutions. And is there a suitable counter-example? thanks PS: I only mention this because age seems to be a prominent characteristic in some of the responses. When I went to college it was relayed to me that statistically unless you made your mark in Physics, Mathematics, or Philosophy before age 25 you never would. Mozart composed a number of good compositions prior to his 20th birthday. And I would rather be young than wise. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Singular Value Decomposition (SVD) Ada Algorithm 2004-10-29 17:18 Singular Value Decomposition (SVD) Ada Algorithm skidmarks 2004-10-29 19:14 ` Jeffrey Carter 2004-10-30 16:54 ` John Woodruff @ 2004-10-30 19:08 ` Gautier Write-only 2 siblings, 0 replies; 10+ messages in thread From: Gautier Write-only @ 2004-10-30 19:08 UTC (permalink / raw) skidmarks: > Anyone have an SVD in Ada? I have the C/C++ versions from Numerical > Recipes in C++ (I have the CD-ROM) and would rather not rewrite it > into Ada unless I have to. For SVD you have an answer; for other algorithms from the N.R. you can translate the Pascal version (freely available) via P2Ada. See http://homepage.sunrise.ch/mysunrise/gdm/gsoft.htm#p2ada HTH ________________________________________________________ Gautier -- http://www.mysunrise.ch/users/gdm/gsoft.htm NB: For a direct answer, e-mail address on the Web site! ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2004-11-09 17:16 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-10-29 17:18 Singular Value Decomposition (SVD) Ada Algorithm skidmarks 2004-10-29 19:14 ` Jeffrey Carter 2004-10-30 16:54 ` John Woodruff 2004-10-31 6:59 ` skidmarks 2004-10-31 18:01 ` John Woodruff 2004-11-01 16:17 ` skidmarks 2004-11-06 5:23 ` John Woodruff 2004-11-06 19:28 ` Jeffrey Carter 2004-11-09 17:16 ` skidmarks 2004-10-30 19:08 ` Gautier Write-only
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox