Two issues in installing ITensor c++ on Windows

[YuhanLiuSYSU]

I am using windows 10 with Cygwin for installation and here are two issues I encounter, along with my (might not be the most elegant) solutions:

Issue 1

The Makefile in itensor folder does not write on this_dir.mk. To resolve it, I replace @echo "THIS_DIR=$(PWD)" by

@echo "THIS_DIR=$(shell pwd)"

Issue 2

When compling algs.cc , I got the error:

In file included from /usr/lib/gcc/x86_64-pc-cygwin/10/include/c++/cctype:42,
                 from /usr/lib/gcc/x86_64-pc-cygwin/10/include/c++/bits/localefwd.h:42,
                 from /usr/lib/gcc/x86_64-pc-cygwin/10/include/c++/string:43,
                 from /usr/lib/gcc/x86_64-pc-cygwin/10/include/c++/stdexcept:39,
                 from tensor/algs.cc:17:
tensor/algs.cc: In function 'int itensor::detail::hermitianDiag(int, itensor::Real*, itensor::Real*)':
tensor/algs.cc:37:20: error: expected unqualified-id before numeric constant
   37 |         LAPACK_INT _N = N;
      |                    ^~

My solution is simply replacing _N and _Rrows by names that don't contain underscore. I don't fully understand the reason behind and I still wonder what cause this problem.

I am a very beginner to makefile so these might be really trivial. But maybe it can help other beginners :)

[lgds]

Hi. I ran into the same issue as YuhanLiuSYSU when I updated ITensor on Cygwin. I did a quick Google search and got here.
I checked that the previous version of algs.cc did not have underscores in front of "N" or "M" and "Rrows" etc. so I just commented out lines like
//LAPACK_INT _M = M, _N = N, _Rrows = Rrows;
and replaced "_N" with "N", "_M" with "M" etc. everywhere. It compiles ok now.
I hope I did not break anything!...

[mtfishman]

Could one of you make a pull request with the minimal changes needed to get it working on Cygwin? If the tests pass we can merge it.

[lgds]

Would it help if I placed the file here?
algs_compilesCygwin.cc.txt

[mtfishman]

Please try making a pull request with the desired changes. If you don't know how, there are many resources online to learn how to do it.

Have you considered using the Julia version (https://github.com/ITensor/ITensors.jl)? We highly recommend that version over the C++ version (for many reasons, one of which is that the installation is much easier).

[lgds]

Hello Matthew, thanks for the tip.
I've never done a pull request but it would be a nice opportunity to learn.
I'm looking at the instructions here:
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request
Looks like I have to create a fork first... and then I guess I will go to
https://github.com/ITensor/ITensor/pulls
... and choose "New pull request" -> "Compare across forks".
I will try.
Thanks also for the Julia tip. I heard of it but there was always the inertia of learning Julia, etc. but I will give it a try, Specially since I'm getting some compilation errors in some of my old C++ ITensor codes in the newer versions...
Best,
Luis

[haggaila]

Hi, I struggled with this cygwin problem as well for a bit (and found this issue here exactly after I managed to solve it :)
The C++ standard reserves identifiers starting with an underscore and a capital letter (or two underscores) to the compiler implementation, and apparently on cygwin the macros "_N" and "_R" are indeed defined by the compiler, such that they get replaced and the preprocessed file is garbage.. This just does not happen on Linux and MacOS apparently.
@lgds if you are not available to make a PR to fix this, I can do it.
Thanks.

[lgds]

@haggaila , please go ahead, by all means!

I'm actually sold on the idea of migrating to the Julia version and I'm giving it a try... ;)

Thanks!

[haggaila]

@mtfishman could you please advise on the preferred naming convention for the local variables _N, _M, _Rrows that I will rename in the PR? Should I just add an initial L (standing for LAPACK), e.g.:
LAPACK_INT L_M = M, L_N = N, L_Rrows = Rrows;?

[mtfishman]

That seems fine. Or what about N_ instead of _N? Or does that also cause problems with the compiler?

[haggaila]

N_ should be ok - I'll test locally and will PR if it's good. Thanks.