Prev: DatabaseLink Remote Kernel Bug/Feature Request
Next: Mathematica needs better support for automatic
From: Murray Eisenberg on 8 Apr 2010 07:59
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(a)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(a)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(a)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

From: E. Martin-Serrano on 9 Apr 2010 03:34
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(a)math.umass.edu]
Sent: Thursday, April 08, 2010 2:00 PM
Subject: 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(a)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(a)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(a)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


First  |  Prev  | 
Pages: 1 2
Prev: DatabaseLink Remote Kernel Bug/Feature Request
Next: Mathematica needs better support for automatic