Hi everyone,

I am seeing certain practice that is confusing for me in some Fortran77 code. This code is about the so-called interpolative decompositions of matrices (you might also know them as CUR decompositions in other circles).

As a part of rewrite in SciPy, rather unwillingly I must confess, I’m trying to be faithful to the original codebase from Tygert et al. The source code is still available in author’s website Software (third entry)

We have been already warned by @certik in the old PR where this code has been added to SciPy; see Interpolative decomposition by inducer · Pull Request #2616 · scipy/scipy · GitHub

But I would like to understand the consequences or motivation, if you can tell, by the following code. I’ll remove the docstring for brevity here but the code is taken from here scipy/scipy/linalg/src/id_dist/src/id_rtrans.f at 86c3a5bf8d7bc965a7873b744127ee076a8c3fa1 · scipy/scipy · GitHub ;

```
subroutine idd_random_transf_init(nsteps,n,w,keep)
implicit real *8 (a-h,o-z)
save
dimension w(*)
ninire=2
ialbetas=10
lalbetas=2*n*nsteps+10
iixs=ialbetas+lalbetas
lixs=n*nsteps/ninire+10
iww=iixs+lixs
lww=2*n+n/4+20
keep=iww+lww
w(1)=ialbetas+0.1
w(2)=iixs+0.1
w(3)=nsteps+0.1
w(4)=iww+0.1
w(5)=n+0.1
call idd_random_transf_init0(nsteps,n,w(ialbetas),w(iixs))
return
end
```

But if we look at the definition of the subroutine called it is an implicitly typed 2D integer array. Does this mean every `real *8`

entry is considered to be two `integer *4`

s?

```
subroutine idd_random_transf_init0(nsteps,n,albetas,ixs)
implicit real *8 (a-h,o-z)
save
dimension albetas(2,n,*),ixs(n,*)
c
c routine idd_random_transf_init serves as a memory wrapper
c for the present routine; please see routine
c idd_random_transf_init for documentation.
c
do 2000 ijk=1,nsteps
c
call idd_random_transf_init00(n,albetas(1,1,ijk),ixs(1,ijk) )
2000 continue
return
end
```

`fortls`

already catches this with “*Type mismatch in argument ‘ixs’ at (1); passed REAL(8) to INTEGER(4)*” (Nice!)

However, what could be the motivation to do so ? I don’t think there is bit arithmetic playing here but not sure. Is this going to truncate the floating result to integer as in type casting `(int)num`

in C-lang? I was hoping that the compilers would error out in type-checking phase but apparently not the common practice.

Appreciate the help.