Hierarchal tensor svd

Help
1

Does anyone know of an f90 tensor svd?

2

@Lenore do you mean a modern Fortran equivalent of multidimensional array svd, like svd in NumPy (numpy.linalg.svd — NumPy v1.24 Manual) ?

3

Yes.
I looked at NumPy and they call gemsvd and that is written in f77.
I’d like to see an f90 version of the code.

1 Like
4

Isn’t this in Lapack? So you are looking for a modernized Lapack?

I think the Lapack authors decided to use C++ for the modernized version: Why abandon Fortran for Linear Algebra?. That’s a common path: F77 codes go directly to C++, skipping all modern Fortran from F90 and later.

So I would recommend to just use Lapack.

5

Yes
I want modernized Fortran NOT C++.
Thank you. I’ll look at Lapack.
Lenore

6

We don’t have a modernized version of Lapack yet, only the F77 style version available at GitHub - Reference-LAPACK/lapack: LAPACK development repository.

@jacobwilliams is very interested in providing these modernized versions of older libraries, maybe he would consider doing Lapack also. :slight_smile:

7

Thanks, I’ll check them out.

I’ll also contact Jacob Williams. Thank you for that contact.
I really don’t know why the CS community does not care about Fortran.
Backus was such a revolutionary and the movement to whole array operations, inspired by Iverson, was
way before C++ templates etc. I care about Fortran being all he envisioned.
So much research in Fortran scientific codes, such a foundation.
Lenore

2 Likes
8

There are long threads about exactly this question on this forum. :slight_smile:

We are working hard to change that.

9

Count me in to help.

4 Likes
10

@jacobwilliams do you know about any modern Fortran versions of svd?

Given your experience with modernizing old Fortran code (minpack, fftpack, etc.), what is your opinion on modernizing Lapack.

11

I think one could modernize a given snapshot of LAPACK, but the problem is that LAPACK is under constant development and is continually changing. Maintaining an up to date modern fortran version would require cooperation of the LAPACK developers. Given that they have not done that in over 30 years already, what would encourage them to do so now at this late date? I’m assuming some kind of meta programming for multi language support would be involved in this process.

1 Like
12

We could start with the tensor SVD. We formulate in MoA and modern fortran as a start.
Sound like fun?

1 Like
13

I think when we can get better performance , prove correctness, scalability and portability they may listen. :blush:

1 Like
14

Just an FYI re MoA. It is really all about the psi function and shapes. The operations in my dissertation represent most of Iverson’s algebra devoid of anamolies. As long I can define an operation using shapes and psi it can be psi reduced, e.g.NumPy. See attached paper for an example.

(Attachment MDPI_November_2022_Proofread.pdf is missing)

1 Like
15

The paper attachment did not get included.
Here is the paper.

16

Which is good news in itself :slight_smile:

I don’t think that “modernizing LAPACK” is the only way to go. Instead, one could have either explicit interfaces (enabling argument checking etc…), or wrappers with all the usual benefits (optional arguments, assumed shapes,…). Without having to deal with LAPACK itself.

18

This is what LAPACK95 is, no?

19

Here is one such example using LAPACK95 (see this LAPACK95) and netlib-LAPACK95:

! from the same link as above: 
use la_precision, only: wp => dp
use f95_lapack, only: la_gesv

real(wp) :: A(3,3), b(3)

call random_number(A)
b(:) = 3*A(:,1) + 2*A(:,2) - A(:,3)

! Solve Ax=b, overwrite b with solution
call la_gesv(A,b)

print *, b
end program

! Output (exact: 3 2 -1):
! 2.9999999999999978        2.0000000000000018       -1.0000000000000004
20

I’d like to do a tensor SVD

21

@Lenore just to clarify, when you say tensor in this context, you mean a multidimensional array (such as a Fortran array), correct?

So by “tensor SVD”, you mean SVD on arrays with higher dimension than 2, correct?