#43 f2cl fails on TOMS-717 translation

closed-fixed
Raymond Toy
f2cl (3)
5
2006-10-10
2006-01-03
drb
No

I tried to translate the three main files of the ACM
TOMS Algorithm 717 (dmdc.f, dglfgb.f, and dgletc.f).
The packaged version of f2cl succeeds on the first two
files, but fails to translate dgletc.f in both CLISP
and CMUCL. I tried the CVS version, and it fails on
both dgletc.f and dmdc.f.

A packaged version of the complete code can be
downloaded from

http://cll.stanford.edu/~ljupco/alg-717/TOMS-717.tar.gz

and a formal description can be found at the ACM website.

http://portal.acm.org/citation.cfm?id=151271.151279

Discussion

  • Raymond Toy
    Raymond Toy
    2006-01-03

    Logged In: YES
    user_id=28849

    Ok. The first problem is a parsing bug. There's a line like:

    ZERO. AND. V(PREDUC)

    This should be written ZERO .AND. V(PREDUC)

    The other errors I've found are because of the use of
    Hollerith strings in FORMAT statements. f2cl does not know
    how to parse Hollerith strings You need to convert them
    from Hollerith strings to strings (with single quotes).

     
  • Raymond Toy
    Raymond Toy
    2006-01-03

    Logged In: YES
    user_id=28849

    dmdc.f won't work in f2cl because it tries to equivalence a
    double precision variable with an integer.

    You'll have to rewrite dmdc.f in lisp. Doesn't look too
    hard because it looks rather like d1mach, which f2cl provides.

     
  • drb
    drb
    2006-01-03

    Logged In: YES
    user_id=1418467

    Thanks for the information. After removing the Hollerith
    strings and fixing the formatting error both dglfgb.f and
    dgletc.f translate without any apparent problems. I'll work
    on translating dmdc.f by hand.

    As a side note, the version of f2cl in the current CLOCC
    tarball (non-CVS) processes dmdc.f without identifying any
    problems.

     
  • Raymond Toy
    Raymond Toy
    2006-01-03

    Logged In: YES
    user_id=28849

    Non-cvs versions of f2cl doesn't do anything with
    equivelences except produce an output lisp file that says
    equivalences aren't handled. Check the contents of dmdc.lisp.

    The CVS version can handle some equivalences as long as the
    types are the same. And produces an error message saying it
    can't handle them if the types are different.

     
  • drb
    drb
    2006-01-04

    Hollerith free dgletc.f

     
    Attachments
  • drb
    drb
    2006-01-04

    Logged In: YES
    user_id=1418467

    I have attached the version of dgletc.f with converted
    Hollerith strings. Translating this file with CLISP and
    loading it yields the following error.
    *** - EVAL: " " is not a function name

    The relevant lisp code looks like:
    (replace model1 (" ")) (replace model2 (" G "))

    which I assume to be created from the fortran
    DATA MODEL1/' ',' ',' ',' ',' G ',' S '/,
    1 MODEL2/' G ',' S ','G-S ','S-G ','-S-G','-G-S'/

     
  • Raymond Toy
    Raymond Toy
    2006-01-04

    Logged In: YES
    user_id=28849

    Thanks for the file. Yes, that appears to be a bug in f2cl.
    I'll look into it.

     
  • Raymond Toy
    Raymond Toy
    2006-01-04

    Logged In: YES
    user_id=28849

    I think I've fixed the parsing issue and the issue with
    initializing an array of character strings.

    I'd appreciate it if you could test out the latest CVS
    version of f2cl with your code.

     
  • drb
    drb
    2006-01-06

    Logged In: YES
    user_id=1418467

    I'm now getting an array-based error in dgletc.f with both
    CMUCL and CLISP. A two-dimensional array is being accessed
    with only one index. CMUCL outputs the following extended
    information.

    (LISP::%ARRAY-ROW-MAJOR-INDEX
    #2A(("" "" "" "" "" ...)
    ("" "" "" "" "" ...))
    (0)
    T)

     
  • drb
    drb
    2006-01-06

    Logged In: YES
    user_id=1418467

    I should add that the previous error occurs when dgletc.lisp
    is loaded back into the lisp environment.

     
  • Raymond Toy
    Raymond Toy
    2006-01-09

    Logged In: YES
    user_id=28849

    The array error in dgletc is fixed. But there are other
    problems.

    Since TOMS 717 appears to be valid code that f2cl should be
    able to handle but doesn't, I'm adding it as one of the
    packages for f2cl.

    I was also mistaken about Hollerith strings. They ARE
    supported in format statements, but the parser was not
    correctly recognizing indented format statements. However a
    double-quote character in strings confuses f2cl, so removing
    double-quotes helps the parser.

     
  • Raymond Toy
    Raymond Toy
    2006-01-11

    Logged In: YES
    user_id=28849

    f2cl will convert enough of toms 717 to run the two test
    programs madsen and madsenb correctly. The other 3 test
    programs can't be converted by f2cl currently.

    Please see if enough of toms 717 can be converted for your
    needs.

     
  • Raymond Toy
    Raymond Toy
    2006-05-03

    Logged In: YES
    user_id=28849

    Current cvs should be able to compile some of TOMS 717 now.
    In particular, dmdc, dglfgb, and dgletc work.

    See also the package/toms/717 directory with includes TOMS 717.

    The madsen and madsenb tests appear to pass. The dpmain
    test will not because f2cl does not support equivalences of
    arrays, implied-do loops in read statements.

     
  • drb
    drb
    2006-10-05

    Logged In: YES
    user_id=1418467

    From what I can tell the f2cl translation supports all the
    behavior that I require from TOMS-717. I did have to change
    generated code to avoid a type-checking error. In dl7svx,
    f2cl generates the following code in two locations

    (|COMMON-LISP|::|SETF| |FORTRAN-TO-LISP|::|IX|
    (|COMMON-LISP|::|MOD|
    (|F2CL-LIB|::|INT-MUL| 3432. |FORTRAN-TO-LISP|::|IX|)
    9973.))

    INT-MUL checks the type of the value returned by
    multiplication against INTEGER4. I often ran across the
    problem that (* 3432 IX) was too large although the result
    of the modulus certainly wouldn't be. I replaced the
    INT-MUL operator with the standard multiplication operator
    and everything seems to work fine. The value of IX at the
    time of the error is 6864, which is legal given the code.
    As a result, I'm not sure that INTEGER4 is the correct type
    for IX (or for any of the other integers in the program).

     
  • Raymond Toy
    Raymond Toy
    2006-10-05

    Logged In: YES
    user_id=28849

    This doesn't make sense. Are you sure ix is 6864 when the
    error occurs? 6864 * 3432 fits in a 32-bit int. And if
    there were an overflow in the Fortran code, the results are
    unspecified, I think.

     
  • drb
    drb
    2006-10-05

    Logged In: YES
    user_id=1418467

    The specific error is

    THE: (* 3432 FORTRAN-TO-LISP::IX) evaluated to the values
    (23557248), not of type F2CL-LIB:INTEGER4

    Break 1 [3]> fortran-to-lisp::ix
    6864

    The code (THE F2CL-LIB:INTEGER4 23557248) gives me the same
    error when run on GNU CLISP 2.38 (2006-01-24).
    Interestingly, this error does *not* appear when I tell
    CLISP to compile the code while it's loading.

     
  • Raymond Toy
    Raymond Toy
    2006-10-06

    Logged In: YES
    user_id=28849

    Oh, ok. That makes sense because clisp says
    most-positive-fixnum is 16777215, which is smaller than the
    number you have, but still fits in a 32-bit integer.

    Perhaps the integer4 type should be changed from fixnum to
    (signed-byte 32)? Not really sure.

    Unless there are other issues, I'm ready to declare this bug
    closed.

     
  • drb
    drb
    2006-10-06

    Logged In: YES
    user_id=1418467

    close it. all seems fine other than general speed and tuning issues. thanks for
    your work on this.

     
  • Raymond Toy
    Raymond Toy
    2006-10-10

    • status: open --> closed-fixed
     
  • Raymond Toy
    Raymond Toy
    2006-10-10

    Logged In: YES
    user_id=28849

    Closing bug as fixed.