[Org-ad-workshop] ICCS 2006 - Revised paper

-- ********************************************************************* Attention: My email address "kowarz@math.tu-dresden.de" is subject to removal within the next few month. Please use my new address "Andreas.Kowarz@tu-dresden.de" in order to contact me per mail. Please update your address book. Thanks. ********************************************************************* major comments: A: related to pg 5 first paragraph etc: The condition for retaping is stated only to be a change of control flow. ... Since a lot of this paper is about the nested taping it think it should undertake the effort to precisely characterize when a tape representative for a time step is valid, which invalidating scenarios are automatically caught and which extra steps are required. Comment: Now, we explain that the function evaluation is retaped automatically when the control flow changes due to a change of an adouble value. Furthermore, now we provide a flag such that if this flag is set to 1 the function evaluation is retaped for each reverse differentiation to be on the save side. A corresponding explanation is contained in the revised version of the paper. B: related to the numerical example in Sect 3. I would find it much more compelling if the paper gave more detail on the practical example ... The paper would gain significantly if this effect could be shown in a practically relevant application. Comment: We skipped the trajectory example and present now only the robotor example in detail. minor comments: pg 2, first paragraph: The statement of "enormous memory reduction" should be qualified. I.e. it should be stated that - presumably - it is compared to the tape (I guess more precisely execution trace and value tape) arising from purely split mode. Comment: done pg 2, insert: "The size of the much smaller randomly accessed ...." ^^^^^^^^^^^ Comment: done pg 2 last paragraph first sentence: The memory grows with run-time, regardless if this is a time-stepping procedure or not and what is acceptable depends on the user. I suggest to refer directly to the new nested tape facility in ADOL-C and point out that time-stepping procedures usually imply repetitions of identical operation sequences on the tape which the nested taping eliminates as explained on the bottom of page 3. Comment: We reformulated this sentence pg 4 end of first paragraph insert: "... presented at the AD 2004 conference." ^^^^^^^^^^ Comment: done pg 5 Interface section: The time_step_function signature requires the user to pack and unpack the state data that might be distributed over various arrays into u. I am not sure that everybody agrees this is "minimal user effort". Instead it might be fairer to say that the objective is a "lean and concise interface" which I believe has been achieved. Comment: reformulated correspondingly The following is more of a general comment. As ADOL-C wants to attract not only C but also C++ codes it should consider providing actual C++ interfaces along with the old C style ones. Serious C++ users of ADOL-C will likely cringe at the sight of the CpInfos* to be populated and a bunch of C functions when all of this perfectly lends itself to a well organized class. Comment: We added a C++ interface and changed the description correspondingly. p. 3 Fig 1, Fig 2: The light grey rectangle used in the new tape generation should be explained. What is the difference w.r.t the original ones ? Comment: A description of this light grey rectangle is contained in the text. What is the semantic of the arrows ? If you manage to show graphically the different tapes it would enforce the paper. Comment: The figures were rearranged and are hopefully easier to understand now. p. 4: You talk about the "external diff. function", but give no explanation nor a pointer to the paper at AD2004. Comment: This was presented in the poster session. We plan to have a documentation of this "external diff. function" facility in the ADOL-C manual within the near future. p. 5: You should give a code or a function example to clarify the user intervention. Explain the difference with a manual use of resolve from the user point of view. Comment: From out point of view, there is no space for such an explanation when the page limit is set to 8. Once more, we plan to have a corresponding documentation in the ADOL-C manual within the near future. Typos: p. 1 section 1: you use e.g sometimes in an unapropriate way. Comment: Well, we tried to fix as many as possible p. 7: "despite the fact of the" should be changed. Comment: done Experiments are made on a very small academic example. The results are quite convincing. I'm looking forward to results on real-life codes. Comment: We switched from the academic example to the roboter example Table 1 is puzzling. It actually looks like a simple affine function: tape-size = 492 + l*252. From which I deduce that it shows the memory consumption without any checkpointing? If there was some sort of optimal checkpointing, size should grow like log(l), right? Then why not show a table that shows that, which would better illustrate the benefits of checkpointing? Comment: In the old version, the Table shows the tape-size without any checkpointing. The tape size itself is constant if the checkpointing is use within ADOL-C. Only the amout of memory needed to store the checkpoints grows. The table now shows the tape size needed without and with checkpointing. Minor stuff: --The "applied checkpointing procedure" sounds bizarre cause it makes me wonder what is "applied checkpointing". Comment: Reformulated. --I was told that "allowing the usage..." is incorrect, should be "allowing us to use...", or "permits the usage..." Comment: Reformulated.