-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
importing GIS data can result in NaN values #5
Comments
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 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 NetLogo isn't the only language in which the equivalent of
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. 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 |
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:
|
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. |
i think this may work |
Tina Balke reports:
The text was updated successfully, but these errors were encountered: