Use Vec() instead of complex number for non-complex SIEs.

[dlfivefifty]

ApproxFun now supports (for the most part) 1D domains embedded in R^2. This should be used here, partly to draw a distinction between dz and ds, which are still confusing.

In this case, whether it's dz or ds would be inferred from the domain:

    d_2d=Interval((0,1),(1,1))   
    d_C=Interval(im,1+im)
     SingularIntegral(d_2d,1) # would be in R^2, so use ds as dz makes no sense
     SingularIntegral(d_C,1) # use dz

This requires a bit of work in ApproxFun before it can be used. For example, I'd want the following to work:

s=Fun(d_2d)  # this is a Fun whose values are Vecs, and plays the role of z
s_0=Vec(1,2)   # plays the role of z_0=1+2im

log(norm(s-s_0))   # plays the role of log(abs(z-z_0))

[MikaelSlevinsky]

I think this will be an improvement. Currently, we are using complex numbers to represent (i) the real & imaginary parts of a GreensFun, (ii) the geometry, and (iii) use in vector-valued line integrals for the Neumann problem.

Complex numbers in Julia are Julian types, so I don't expect this will significantly alter performance. Instead, it will bring clarity to the situations above. It will also generalize to 3D.

We should be able to distinguish between a line integral over a scalar field (∫ f ds) and a vector field (∫ F ⋅ dr).

[MikaelSlevinsky]

Perhaps the last part is a question...

[dlfivefifty]

Complex{Float64} is not (just) a Julia type, it's stored as bits. This is why BLAS is fast for Complex numbers. But so is Vec{2,Float64}, with the exact same number of bits. Therefore anywhere complex numbers are faster, we can convert between the two:

c=rand(Complex128,20)
v=unsafe_wrap(Array,reinterpret(Ptr{Vec{2,Float64}},pointer(c)),20)
v[1]=Vec(1,2)
c[1]  # returns 1.0+2.0im

[dlfivefifty]

(Note that reinterpret(UInt128,1.0+2.0im) does not work since Complex128 is not a bitstype, even though isbits(1.0+2.0im) is true. )

[MikaelSlevinsky]

Gotcha.

[daanhb]

Slightly off-topic, sorry, but does Vec refer to FixedSizeArrays? I've recently switched to using StaticArrays (following this discussion) for small vectors in 2D-3D. It is often convenient in code that the vectors in StaticArrays inherit from AbstractArray, whereas those in FixedSizeArrays don't. The constructors are also more friendly. (On the other hand, tracing dependencies in ApproxFun it seems FixedSizeArrays are imported via Plots, so switching may not be an option.)

[dlfivefifty]

Yep, I was referring to FixedSizeArrays. It looks from that link that even @SimonDanisch agrees that StaticArrays is the way forward, and after spending a day adding special cases for Vec to ApproxFun, I also agree.

Though it's 0.5 only so let's postpone this change til 0.4 support is dropped (which should wait til the type inference big is fixed)

Sent from my iPhone

On 27 Oct. 2016, at 18:38, Daan Huybrechs [email protected] wrote:

Slightly off-topic, sorry, but does Vec refer to FixedSizeArrays? I've recently switched to using StaticArrays (following this discussion) for small vectors in 2D-3D. It is often convenient in code that the vectors in StaticArrays inherit from AbstractArray, whereas those in FixedSizeArrays don't. The constructors are also more friendly. (On the other hand, tracing dependencies in ApproxFun it seems FixedSizeArrays are imported via Plots, so switching may not be an option.)

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[daanhb]

I see, I did not realize the 0.5 restriction of StaticArrays.