I enclose 3 Referee reports on your paper. We would be pleased to accept it and could you please send me a new version before November 5 99 Please send a memo describing any suggestions of the referees that you did not address Ignore any aggressive remarks you don't think appropriate but please tell me. I trust you! Please help me help you by improving paper! Thank you for your help in writing and refereeing papers! Referee 1 ********************************************* Subject: C438 JGSI Review Title: JCArray - the jCrunch Java Array Classes Author: David S. Dixon a)Overall Recommendation ------------------------ REJECT b)Words suitable for authors ---------------------------- The paper describes JCArrays that store Java array data in Fortran fashion. Hence, these arrays can easily be passed to native routines written in Fortran. The paper has several significant problems: 1.) The paper claims to discuss a robust framework for high-performance methods. However, there are no performance measurements in the paper at all. Performance measurements and benchmarks are necessary. 2.) The paper does not discuss how the array data is stored internally. There is only one hint that there is some one-dimensional data[] array that seems to store all the elements. In a technical journal paper there should be some technical information, not just a discussion of an API. 3.) Since JCArrays are targeted towards use in native methods, the author should discuss JNI issues. How expensive is a JNI call that passes a JCArray? Is it possible to make a Fortran array available to a Java program as a JCArray? Since the author discusses the NOCOPY-routines within Java he should be aware of the fact that the JVM might try to copy array data into C-arrays. What is done to solve this problem? Can the programmer influence the copying-behavior of the JVM in the JNI-interface? How does JCArray solve the cooperation with the garbage collector? Is it a problem to pin huge arrays (or copies thereof) for the duration of a native method? 4.) The paper does not discuss how a Java programmer would access individual array elements. Are there any set- and get- routines? Only constructor methods are presented. Their presentation however requires in depth knowledge of gOffset, indexOffset and gStep. Unfortunately, most Java programmers are probably unfamiliar with these terms. 5.) Section 3 discusses "Special Matrix Forms". It is probably premature to talk about these because the reader is informed in the end of the section that nothing has been implemented by now. Section 4 discusses the future as well. 6.) The discussion of the related work is weak. It is hard to find out what the specific contribution of JCArrays is. It is my impression that these problems are too severe to be fixed in a short period of time. I therefore suggest to REJECT the paper. The author should fix the problems and re-submit it as a full paper to a conference. Some minor bugs: - the abstract mentions "persistence" although this issue is missing in the rest of the paper. - please explain why shape is of type int[] when it first appears in JCxVector. - Why did you chose to have indexOffset=1 and gStep=1 in the JCDVector example? What does that mean? - Java offers an elaborate mechanism to format numbers for output (see class NumberFormat for example). Why do you provide a low-level print method instead? - In the JCFMatrix example the first argument of the constructor should be an f instead of an m. - There are two almost identical paragraphs on the copy/nocopy issue. Please avoid cut&paste. - At the very end of section 5: "...but not for enough ..." Referee 2 ***************************************************************** Subject: C438 JGSI Review Paper no.: C438 Title: JCArray - the jCrunch Java Araay Classes Reviewer: Mark Bull Overall Recommendation: Publish with substantial revisions. Comments for authors: The paper is interesting and sound, but needs some additional material to make it suitable as a journal paper instead of a poster. An introduction section should be added, elaborating on the contribution of the work described, and setting out the structure of the paper. Some motivational material would be useful: i.e. why are such classes necessary? section 1, list item 2: there is some confusion here betwen the functionality of LAPACK and that of the BLAS. section 2, para 1: explain the meaning of shape and rank without using Java syntax. section 2, last para: it is not at all clear what some of these utility methods do. section 2: perhaps a more comprehensive listing of the API might be appropriate. section 3: It is not clear whether the JCxMatrix class supports exactly the same forms and storage formats as LAPACK. Some more details could be added here. sections 5 and 6 should be merged into a single "Relationship to other work" section. section 5, para 2, line 1: bet JAMA -> but JAMA section 5, last para, line 2: not for enough -> not far enough A "Conclusions and further work" section should be added. The bibliography should be expanded, particluarly with references to the BLAS and to other O-O matrix packages. Comments for editor: Needs quite a lot of work to convert it from a poster to a journal paper! Referee 3 *************************************************************** Subject: C438 JGSI Review JCArray - the jCrunch(TM) Java Array Classes David S. Dixon a)Overall Recommendation Overview of Least Squares' jCrunch classes, and comparision with related packages. Probably needs a more formal introductory section, with some background. Section 2 could do with more explanatory text, fewer bullets. b)Words suitable for authors Section 2 The notations used in: "shape = (int [1]) {length} datatype = x(x:float for JCFVector, double for JCDVector)." etc, are strange to me. One is slightly incorrect Java, the other isn't. In the "Verbose examples", explanation of at least `gOffset', `indexOffset', `gStep' would be beneficial. Section 5, para 2: "[...] similar to JCArray, bet JAMA doesn't [...]" ^^^ Typo. Same section, para 3: "For example computating a Complex [...]" ^^^ Typo. c)Words for me if necessary None.