Strangely small output when returning tuple

General Usage
1

I’ve been using QuantumOptics.jl in Jupyter to run some physics simulations, and I’ve encountered an odd behaviour with one of my functions. My function is defined as follows

function lprϕ(Δ, tf, ψ0, tspan1, Δ_11)
    tspan2 = [0, tf].*10^-6
    tout1, ψ1 = timeevolution.schroedinger(tspan1, ψ0, H_2314(Δ, Δ_11))
    tout2, ϕs = timeevolution.schroedinger(tspan2, ψ1[end], H_12; fout = get_phase)
    return ϕs
end

ϕs is an array of tuples, one for each element of tout2, which means there are 2 of them in this case. Returning this way works fine, and I call this function successfully:

lprϕ(40000, 168, ψ0, [0,136].*10^-6, 23000)

returns

2-element Vector{Any}:
 (0.7652719548899038, -0.28774709756921724)
 (0.2373470060104735, -1.3494626427587488)

However, I only actually want the last tuple in the array. So I can just add [end] to the line above and it also works fine:

lprϕ(40000, 168, ψ0, [0,136].*10^-6, 23000)[end]

returns

(0.2373470060104735, -1.3494626427587488)

Here’s the weird part: if I instead have the function return only the last tuple, as follows:

function lprϕ(Δ, tf, ψ0, tspan1, Δ_11)
    tspan2 = [0, tf].*10^-6
    tout1, ψ1 = timeevolution.schroedinger(tspan1, ψ0, H_2314(Δ, Δ_11))
    tout2, ϕs = timeevolution.schroedinger(tspan2, ψ1[end], H_12; fout = get_phase)
    return ϕs
end

then it instead returns nonsense

image
image974×147 51 KB

Incidentally, these values are just the output of calling angle() on a complex number.
Anyone know what might be going on here? I’m having a hard time understanding how changing where the [end] is called can be that important intentionally, hence putting it here as a supposed bug. I suppose it’s also possible that this has something to do with Jupyter. I’d be happy to include more of the code if it would be relevant.

2

I don’t actually see what you’re doing different when you say “return only the last tuple” as the function you present appears identical to the version above.

But those values you’re getting as outputs are subnormal numbers (below the “normal” range for Float64). Since you don’t expect a result like that, I suspect they are coming from uninitialized values in some array somewhere. Perhaps some change you make actually makes the problem ill-posed and it quietly does nothing, returning uninitialized values?

If you run it multiple times, do you get different results (when they should be the same?)? That would support uninitialized values as the source.

1 Like
3

Yes sorry, that’s my mistake; the second function definition should read

function lprϕ(Δ, tf, ψ0, tspan1, Δ_11)
    tspan2 = [0, tf].*10^-6
    tout1, ψ1 = timeevolution.schroedinger(tspan1, ψ0, H_2314(Δ, Δ_11))
    tout2, ϕs = timeevolution.schroedinger(tspan2, ψ1[end], H_12; fout = get_phase)
    return ϕs[end]
end

And yes, when I run it multiple times I get the same result. The only difference in the code between the two behaviours is where I put the characters “[end]”.

4

Whether you return ϕs[end] or return ϕs then index [end] from the call should not make a difference and I’ve never seen any bug resembling this. I strongly suspect that is not the actual issue.

I would start by making two functions (e.g., call the second one lprϕ2) with the different [end] index sites, and calling them each (one right after the other, preferably, or maybe even alternating calls to them a few times) rather than editing and re-running one single function. Then add @show ϕs immediately before the return of each function to verify that the full ϕs are in fact the same before the return or [end] access. If the outputs differ, print the inputs also and verify whether they match. One possibility is that some inputs are being unintentionally mutated within the call, so that the latter call is not actually using the same inputs.

I suspect the above sort of debugging will allow you to quickly locate the issue.

If that sort of exploration doesn’t lead you to the problem, you’re quickly approaching the point where you’ll need to include a MWE (preferably without adding a lot more code than you’ve already done) so others can reproduce the issue and try to help.