REPL arithmetic gives wrong result on first run

REPL gives 2 different results for simple arithmetic calculation

Gives came after running a bunch of complex, quantitative code
I have not replicated it, nor tried due to lack of time

So this is just to put out there that something is not 100%

Not even sure whether its julia or Atom or Juno or what

There’s really not much we can do with this. Without any clue as to what you were doing before or how to reproduce, this could be a bug in just about anything, or even something like some subtle type piracy in a library you’re using.

Can you give any detail? Or find any reproduction? Otherwise I might as well just assume your RAM was hit by a stray cosmic ray.

Also, please post code as text, not as a screenshot.

1 Like

Yes, I realise its pretty useless without a reproduction
I thought I would still submit in case anyone else ever runs into something like this and perhaps gives another clue
If I get it again, I will add info

I will certainly keep an eye out myself :slightly_smiling_face:

I’m seem to recall some Juno/Atom bug along these lines being reported previously.

I’ve seen some similar strangeness (expressions that should be deterministic returning different results when run back-to-back), but also have never been able to come up with a repro. It’s only been when running from with Atom, but I also usually run within Atom, so I can’t say it wouldn’t happen at a bare REPL.

I thought I filed an issue with atom-julia-client at some point, but maybe not. Here are a couple issues I filed with FixedPointNumbers, which was the package I was hacking on when this was happening to me before:

https://github.com/JuliaMath/FixedPointNumbers.jl/issues/103
https://github.com/JuliaMath/FixedPointNumbers.jl/issues/104

There was also a discussion on Slack a while ago where it happened to someone else.

1 Like

https://github.com/JunoLab/Juno.jl/issues/119

If you update to a somewhat recent version of Atom.jl (current is 0.6.14) that should not happen any more.

1 Like