Re: Multiple Window Feature Request
- To: mathgroup at smc.vnet.net
- Subject: [mg108994] Re: Multiple Window Feature Request
- From: "E. Martin-Serrano" <eMartinSerrano at telefonica.net>
- Date: Fri, 9 Apr 2010 03:33:56 -0400 (EDT)
Hi, Do the function calls have that much overhead as to be advantageous the substitution of the calls for the actual code in the final loop? As far as I remember the overhead of the function calls, if any, is almost insignificant (leaving apart the eventual parameter checking, and according to my personal experience). And the code resulting from that grouping would be easier to review and maintain. On the other side, some balanced parameter checking would add certain sort of control to the computation if used as pre-conditions and post-conditions for critical intermediate results, as the one you mention about the computation of elements "n" and "n+1". So the general idea of reducing the length of the code inside the loop by grouping natural parts as functions sounds pretty attractive. Of course, some parts of the code so implemented should received special attention to avoid eventual performance issues. E. Martin-Serrano -----Original Message----- From: Murray Eisenberg [mailto:murray at math.umass.edu] Sent: Thursday, April 08, 2010 2:00 PM To: mathgroup at smc.vnet.net Subject: [mg108994] [mg108950] Re: Multiple Window Feature Request Presumably it's during development and debugging that the problem arises where you need to look back at the top of the many-line For loop. But once your function with that loop is defined, you shouldn't have to look back there. A good method of development and debugging, then, would be this: (1) Instead of one monolithic For loop of many, many, many lines, split the steps into natural groups, each group expressing a single idea of the processing, and implement each of those groups as a function. Then you can write a loop with only a few lines where you call those functions. (2) Test that version of your loop with a *small* test-data set, where you don't have to worry about the efficiency issue. (3) Once you have all that working properly, then, and only then, create your big loop by replacing each of the called functions with the actual code for what that function does. This is a sensible, viable development method. Trying to write a single loop with many, many, many lines is a bad development method that is fraught with the possibility of errors and resultant wasted time for you. On 4/7/2010 3:19 AM, Nate Dudenhoeffer wrote: > I use Mathematica for data processing on some large data sets. Often this > involves using a "For" loop, which may have many steps. I know it > preferable to use "map" type functions, but this is not always practical. > For example processing time-dependent data where the result of element n > determines how element n+1 will be processed. I often look back at early > in the loop to see how I have defined variables. > > Thanks for the suggestions on technique. I should probably also make a > practice of defining more sub-routines, which can be called with a single > command and that would make it easier to navigate. I don't think having > multiple windows is a major issue, but I would find it convenient. > > Nate > > On Sat, Mar 27, 2010 at 4:12 AM, Murray Eisenberg<murray at math.umass.edu>wrote: > >> In my reply of a few minutes ago I forgot another solution to your >> problem. You are organizing your notebook into sections, subsections, >> etc., right? (If not, you should be!) >> >> Then just collapse the entire sections, etc., groups between the >> beginning of the notebook and where you're working at the end. >> >> On 3/26/2010 6:34 AM, Nate Dudenhoeffer wrote: >>> I would really like to be able to have multiple windows of the same >> notebook >>> open. Often I will have a very long notebook. This feature would be >>> especially handy in debugging, as often the way something is declared at >> the >>> beginning of the notebook will create problems later. Anybody else out >>> there think this would be useful? >>> >>> Nate >>> >>> >> >> -- >> Murray Eisenberg murray at math.umass.edu >> Mathematics& Statistics Dept. >> Lederle Graduate Research Tower phone 413 549-1020 (H) >> University of Massachusetts 413 545-2859 (W) >> 710 North Pleasant Street fax 413 545-1801 >> Amherst, MA 01003-9305 >> >> > -- Murray Eisenberg murray at math.umass.edu Mathematics & Statistics Dept. Lederle Graduate Research Tower phone 413 549-1020 (H) University of Massachusetts 413 545-2859 (W) 710 North Pleasant Street fax 413 545-1801 Amherst, MA 01003-9305