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

**1**

# Endless nan errors in calculator program (+ WarpDrive Integration)

Started by Dauntless4 Programs, May 18 2019 02:24 AM

3 replies to this topic

### #1

Posted 18 May 2019 - 02:24 AM

### #2

Posted 18 May 2019 - 06:39 AM

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.

### #3

Posted 18 May 2019 - 03:58 PM

SquidDev, on 18 May 2019 - 06: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.

**Edited by Luca_S, 18 May 2019 - 05:03 PM.**

### #4

Posted 22 May 2019 - 07:58 AM

SquidDev, on 18 May 2019 - 06: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.

#### 1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users