Auto null detection

[kinverarity1]

Repeated values at the top or bottom or both ends of a curve are probably null values. e.g.

-999.25
-999.25
231.64
231.64
231.64
231.64
231.64
101.1
147.2
132.4
...
151.5
150.3
231.64

In the above case -999.25 might be defined as the NULL value but lasio -- given a particular keyword argument -- should autodetect and replace 231.64 by the desired null value (nan by default) in addition to -999.25 (NULL).

This is a particular problem with one piece of software that writes LAS files.

[VelizarVESSELINOV]

From my experience 231.64 can be:

1. first/last reading (that also need to removed but there a lot of algorithms to do that)
2. casing reading of the tool (which can be interesting value to keep when you look to detect where is the end of the casing and the beginning of open hole).
3. wireline cable stuck that is important to keep if you are doing speed corrections

During parsing I keep these data at let other measurement correction algorithms to remove them if needed.

From my experience NULL that I would like to be removed by lasio will be more:

• different variations of 999 user defined missing values like: (9_)999.(25)(0_)
• Not a number floating spelling variations: 1.#IND, 1.#INF, -1.#IO, #N/A, etc. https://en.wikipedia.org/wiki/NaN#Display give a good list of different possible spellings
• Not a number that some people try to use with short/long types (specially when you will start playing with sonic array in LAS 3.0), often min or max of integer range are used as missing values https://en.wikipedia.org/wiki/Integer_(computer_science)#Common_integral_data_types: 2147483647 (max long: https://en.wikipedia.org/wiki/2147483647), −2147483648 (min long) or −32768 (min short), 32767 (max short)

[kinverarity1]

OK. I think we need an option to control the behaviour (I frequently deal with software that incorrectly places e.g. 231.64 instead of NULL -- it's a real pain). How about a keyword argument null_policy which can be set to either None, "NULL", "common", or "aggressive":

1. None - no replacements are made, even of the value defined by the NULL line in the ~W section. This behaviour would not conform to the specification but I can see it as potentially useful.
2. "NULL" - the only replacement made is the value defined by the NULL line in the ~W section. This would conform to the specification I think.
3. "common" - replacements would include NULL, (-)(9)999.(25)(0), 1.#IND, 1.#INF, -1.#IO, #N/A, etc., (+|-)2147483647, (+|-)32767, etc.
4. "aggressive" - replacements would include all those defined by "common", plus algorithms like that I suggest in the original post.

The default would be either "NULL" or "common" -- I would prefer the latter.

How does that sound?

[VelizarVESSELINOV]

Sounds very good 👍 I like it :)

[kinverarity1]

I now have this code written elsewhere - reminder to myself to incorporate it into lasio.

[kinverarity1]

Implemented by PR #185