Endless nan errors in calculator program (+ WarpDrive Integration)

Hi. I was working on a jump calculator to use alongside LemADEC's WarpDrive Mod, to calculate the best ways of travelling to a set of coordinates, using the boundaries implemented by the mod. I attempted a simplified version, as I haven't quite yet figured out how to integrate data from WarpDrive yet. However, when I ran the code, I ended up with a spool of nan values until the in-game computer crashed. The code can be found at pastebin.com/fZe1eJ19. I am aware that it could be some rookie mistake, as simple as a missed variable, but I've looked through and can't figure it out… Any help in stopping the endless flow of nan errors and also any help in trying to integrate data from a WarpDrive ship core would be greatly appreciated. Do note that this is not the final purpose of the code. I was hoping to store the necessary details of the jumps into a table, either to be used to program jumps, or as a list of needed jumps able to be followed through in a person's own time on the computer. The form as it currently is allowed me to diagnose the nan problem.

Once again, the code can be found at: pastebin.com/fZe1eJ19
Details of WarpDrive can be found here: https://github.com/LemADEC/WarpDrive

Any help would be gladly appreciated

Just a couple of things which stand out:

• Tables are compared by reference, which means that tables with the same entries aren't always equal. As a result, your while disp ~= {0, 0, 0} do loop is equivalent to while true do.
• nan comes from trying to divide by 0 - so most likely one (or more) of the disp[t]s are 0. One work around would be to do: fctr = disp[t] == 0 and 0 or math.abs(disp[t])/disp[t]. So when the displacement is 0, the fctr is 0. Otherwise take the sign as you were before.

SquidDev, on 18 May 2019 - 07:39 AM said:

• nan comes from trying to divide by 0 - so most likely one (or more) of the disp[t]s are 0. One work around would be to do: fctr = disp[t] == 0 and 0 or math.abs(disp[t])/disp[t]. So when the displacement is 0, the fctr is 0. Otherwise take the sign as you were before.

Doing fctr = math.abs(disp[t])/disp[t] seems like a strange thing to do anyway, I would suggest using fctr = disp[t] > 0 and 1 or -1 instead. Assuming that all entries in the maxjump table are positive the special case disp[t] = 0 doesn't matter anyway, because the factor will be multiplied by zero.

SquidDev, on 18 May 2019 - 07:39 AM said:

Tables are compared by reference, which means that tables with the same entries aren't always equal.

To clarify, the values you're comparing are your table pointers, as opposed to what's in your tables (their contents). Unless you compare a table pointer to itself you won't ever find an "equal match" that way; whether your tables contain the "same entries" isn't at all relevant.

A primitive but simple example of a check that looks at table contents might look like this:

local function compareTables(table1, table2)
  for i = 1, #table1 do
    if table1[i] ~= table2[i] then return false end
  end

  return true
end

if compareTables(disp, {0, 0, 0}) then ...

It'd be helpful to know what values you're actually expecting to get out of your script. Providing example input alongside the "correct" output would make it a lot easier to figure out which alterations need to be made.