Thanks Berend, Yes, I know about these warnings, they are mostly a consequence of the automated translation from the ancient Bell Labs dialect of fortran called ratfor. It is easy to add type declarations for “in” and the others, but it seems unlikely that this is going to fix anything. The extra labels are all attributable to the ratfor translation. I agree that the code is ugly — the ratfor is somewhat better, but not much. I fact the algorithm is rather simple, but I’m reluctant to write it again from scratch, since there are few fiddly details and I would worry somewhat about reproducibility.
Roger Roger Koenker r.koen...@ucl.ac.uk<mailto:r.koen...@ucl.ac.uk> Department of Economics, UCL London WC1H 0AX. On Aug 4, 2019, at 3:26 PM, Berend Hasselman <b...@xs4all.nl<mailto:b...@xs4all.nl>> wrote: Roger, I have run gfortran -c -fsyntax-only -fimplicit-none -Wall -pedantic rqbr.f in the src folder of quantreg. There are many warnings about defined but not used labels. Also two errors such as "Symbol ‘in’ at (1) has no IMPLICIT type". And warnings such as: Warning: "Possible change of value in conversion from REAL(8) to INTEGER(4) at ..." No offense intended but this fortran code is awful. I wouldn't want to debug this before an extensive cleanup by getting rid of as many numerical labels as possible, indenting and doing something about the warnings "Possible change of value ...". This is going to be very difficult. Berend Hasselman On 4 Aug 2019, at 08:48, Koenker, Roger W <rkoen...@illinois.edu<mailto:rkoen...@illinois.edu>> wrote: I’d like to solicit some advice on a debugging problem I have in the quantreg package. Kurt and Brian have reported to me that on Debian machines with gfortran 9 library(quantreg) f = summary(rq(foodexp ~ income, data = engel, tau = 1:4/5)) plot(f) fails because summary() produces bogus estimates of the coefficient bounds. This example has been around in my R package from the earliest days of R, and before that in various incarnations of S. The culprit is apparently rqbr.f which is even more ancient, but must have something that gfortran 9 doesn’t approve of. I note that in R-devel there have been some other issues with gfortran 9, but these seem unrelated to my problem. Not having access to a machine with an R/gfortran9 configuration, I can’t apply my rudimentary debugging methods. I’ve considered trying to build gfortran on my mac air and then building R from source, but before going down this road, I wondered whether others had other suggestions, or advice about my proposed route. As far as I can see there are not yet binaries for gfortran 9 for osx. Thanks, Roger Roger Koenker r.koen...@ucl.ac.uk<mailto:r.koen...@ucl.ac.uk><mailto:r.koen...@ucl.ac.uk> Department of Economics, UCL London WC1H 0AX. [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org<mailto:R-devel@r-project.org> mailing list https://stat.ethz.ch/mailman/listinfo/r-devel [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
