Complex Arguments!

[JoeyT1994]

This PR adds the ability to use complex arguments within the library.

Specifically the IndexMap has been updated to have a dictionary keeping track of whether an Index counts as Real or Imaginary. Whether or not the Index is Real or Imaginary effects how it translates to a scalar.

The default for the library is not to use complex arguments and in order to switch them on one should pass the kwarg, is_complex = true to the continuous_siteinds constructor. By default there will then be two siteinds on a given vertex, one real and one imaginary.

All elementary functions now can be constructed as complex versions and this will be automatic based on whether s::IndsNetworkMap contains imaginary indices or not. Extensive testing is added and example/construct_multidimensional_function.jl has been modified to do complex version of the functions.

Operators (such as differentiation, boundary operators etc) are not tested within this framework and so should not currently be used with the is_complex=true flag. Perhaps we should add a check for that.

[emstoudenmire]

Nice – I could see this being immediately useful in quantum physics applications.

[JoeyT1994]

Overall this looks good first step! I just have some small comments left throughout.

I think there are two major questions we should decide though. The first is that there is question of how we support R->R, R->C, C->R, and C->C. I imagine there is lots to do for each of them.

The second is that we currently essentially "hardcode" that we can have multiple indices per tensor. But we dont have to stop at 2, we could do quaternions or some other basis like quadrature. I can see an argument for only hardcoding complex since its the most common, but we could rewrite things with an assumption of arbitrary site inds (with the user caring how things works), and is_complex being a wrapper for a special case of that. It's almost like this already, but a bit specialized toward the case of 1 or 2 siteinds/tensor. What do you think?

I agree that we don't have to stop at 2 and the PR here actually lets there be an arbitrary number of inds per tensor. All the elementary function constructors should work in this case.

The code is only tested for 1/2 and the real vs complex case so there is an argument for demonstrating a test where we do say 4 indices per tensor. Let me add something like that for completeness. I think if the user wants to do something like quaternions they would need to define their own index_map as we shouldn't support that natively.

It does raise a good question if we do something more abstract like define an AbstractIndexMap with the functionality we want and then introduce

1. RealIndexMap
2. ComplexIndexMap

as two concrete instances. Perhaps not in this PR but it could be a good way to generalize the code.

[JoeyT1994]

Closing in favor of #40