Talk:Subset sum problem: Difference between revisions

→‎how many solutions?: added comment about worthwhile optimization (or not). -- ~~~~
(→‎how many solutions?: added comment about worthwhile optimization (or not). -- ~~~~)
 
(3 intermediate revisions by the same user not shown)
Line 30:
::::::: ''It takes as long as the original set of weights (to complete)''
::::::: Does it? Rexx works in mysterious ways. Anyhow, I can't verify that myself, as regina-rexx complains about something like <code>sh: 1: COMBN: not found</code> when trying to run your code. One thing though, I wouldn't call subset sum problem "something this trivial", but to each his own. --[[User:Ledrug|Ledrug]] 07:34, 8 May 2012 (UTC)
 
:::::::: The lack of a "combN" subroutine (PROCEDURE statement) is my mistake, I "lost" it when doing multiple cut & pastes. It's been re-inserted. Normally, I cut & paste the whole program when updating it, but I was taking shortcuts and only cut & pasted the updated subroutine, but I missed the first statement of the PROCEDURE. Because of the header comment, it looked normal at first glance. I'm sorry about the mishap -- too much late, late night programing, or rather, early morning programming. I hope I didn't offend your sensabilities about what I consider a trival program. The REXX solution (originally) took only a matter of minutes to write, and coupled with the shortness of it, it was a trivial program. I didn't mean to imply that the importance of the task was trivial. -- [[User:Gerard Schildberger|Gerard Schildberger]] 16:50, 8 May 2012 (UTC)
 
:::::::: Come to think of it, did the interpreter just call the shell when it couldn't resolve "combN"? That's seriously naughty. --[[User:Ledrug|Ledrug]] 07:42, 8 May 2012 (UTC)
 
::::::::: Yes, that's the way REXX works. Any function/subroutine not in the program, REXX just looks elsewhere. Normally, it would be another REXX program in a common repository (such as a folder) for such things. There's nothing in the language to distinguish a subroutine that could be written in REXX, assembler, Java, etc. This is due to the environment that REXX was developed in, where any program can invoke another program, no matter what language it was written in (where program invocation had a common linkage). This is a mechanism to force REXX to look outside the program for subroutine execution by inclosing the subroutine name in quotes or apostrophes. As an aside, someone has written an interface for REXX to call (use) any Java subroutines (I'm not sure what Java calls such stuff). It's the writing of the linkage (interface) that's tricky. REXX has the same difficulity as PL/I does, it's variable types are, for a lack of a better word, so non-traditional that PL/I had to resort to something called ''dope vectors'' to describe the variable types. I think the closest thing I could call REXX variables would be ''non-null terminated character strings''. -- [[User:Gerard Schildberger|Gerard Schildberger]] 16:50, 8 May 2012 (UTC)
 
:: After saying I wasn't going to optimize the REXX program (two versions are now on RC), I kept thinking about the program and eventually made it over a magnitude times faster. -- [[User:Gerard Schildberger|Gerard Schildberger]] 23:59, 20 May 2012 (UTC)
 
:: After upgrading the 2nd version of the REXX program that sorted the names by their weights (and realizing the order of magnitude improvement), it seemed rediculus to keep the much slower version around, so it was deleted and the 2nd version was enhanced to sort the output which presents the names in alphabetical order, thus preserving the original order of the names. Much more optimization could be made, but I'm not sure the effort would be worthwhile. I may come back to this program after my other computer is freed up from its heavy usage. -- [[User:Gerard Schildberger|Gerard Schildberger]] 05:44, 29 May 2012 (UTC)