importing GIS data can result in NaN values about gis-extension HOT 4 OPEN

Hmmm... I'm not sure how NetLogo ought to handle this.

When not using the GIS extension, NaN as a value is outlawed in NetLogo. Any operation producing NaN immediately causes an error. It's a case that (as Tina has discovered) the is-number? primitive doesn't even bother to check for, since it isn't supposed to arise in the first place.

GIS data, though, may contain NaN values that the GIS extension lets through. So how should NetLogo treat them?

It may seem rather bizarre that is-number? is true of NaN, I mean, how much more clear could "Not a Number" be that it isn't a number? But, if it isn't a number, what is it? It may not be a number per se, there's a very strong sense in which it is nonetheless numeric. It isn't some other kind of value, and it only arises in contexts where a number is normally expected.

NetLogo isn't the only language in which the equivalent of is-number? returns true on NaN. For example in JavaScript we have:

> typeof(NaN)
'number'

and in order to distinguish NaN from actual numbers, a separate isNaN function is provided. Java is similar; NaN is a distinct value, but not a distinct type. new java.lang.Double(1.0).getClass and new java.lang.Double(Double.NAN).getClass both return an identical result.

Perhaps the GIS extension shouldn't be letting the NaN values through in the first place, and should be replacing them with some valid but non-numeric NetLogo value, such as false. That solution isn't available in statically typed languages, but in a dynamically typed language, it would work.

from gis-extension.

It's been a while, but I think the reason I went with NaN instead of some other non-numeric value was that I couldn't think of a good non-numeric value that wouldn't cause problems in at least one use case. I can think of at least two good improvements to the current situation:

1. Provide a gis:is-nan? primitive in the GIS extension to explicitly test for NaN values, and explain in its documentation why is-number? NaN reports true
2. Allow the user to configure the representation of missing values. By default, the extension would use the current behavior so as not to break existing code. But users could also say gis:set-nan-representation false if they wanted to.

from gis-extension.

This issue still persists. The workaround shown in the docs using a check of ifelse (value <= 0) or (value >= 0) where value could be NaN reports an error in NetLogo6.2.2 of "can't use <= to compare between a number and not a number". The most reliable way I have found is to define a set of values you know you are looking for, and then use a member? test. This will allow one to filter null values without throwing any errors.

from gis-extension.

i think this may work
let resol 1e-4
ifelse (abs value > resol)...

from gis-extension.