Adding IsDecreasing and IsIncreasing

[zeroviscosity]

No description provided.

[btracey]

sort.Float64sAreSorted?

[jonlawlor]

This would allow testing for strict monotonicity, for what it's worth. This approach would also be faster than sort.IsSorted. This kind of thing doesn't really come up for me though so I don't know how useful it would be.

[zeroviscosity]

The need to check for strictly increasing data came up for me this morning when working with some time series stuff. I'd added a basic version in the project I was working on and then thought I'd toss a more generic one into this repo in case it would be useful.

[btracey]

I've never needed a test for strict monotonicity, though of course that doesn't mean it's not useful. I'm not just not sure we want to be duplicating standard library functionality. It would be a bit slower, but would it be more useful to add a Unique([]float64) float64 function?

if !sort.Float64sAreSorted(s) || !floats.Unique(s) {
   // whatever
}

At the very least, we need to be careful with the English in the description because of NaN (or add more text).

[jonlawlor]

I would expect it to be floats.IsUnique(...) and that floats.Unique would return the unique members. Speaking of which we could use a unique function like matlab's that also tells you the indexes of unique values both in the original slice and as a method of recreating the original slice from the unique slice.

[zeroviscosity]

Good points about duplicating functionality and the NaN issue. I originally had IsStrictlyIncreasing and IsStrictlyDecreasing before making the strictness optional. In any event, that functionality may not be needed often enough by others to justify its inclusion.

[kortschak]

floats.AreUnique?

What is the decision here?

[zeroviscosity]

The floats README states that the functions avoid allocations, so that rules out most efficient uniqueness checks, I think. Without allocations, the only option would be the brute force approach of comparing every element with every other element, would it not? If it comes down to an O(n²) approach without allocations or a faster approach that requires overhead, is it worth including in this package?

[btracey]

floats.AreUnique seems like a useful function, and it treats the slice as an entire unit. The map allocation is fine.

[btracey]

I'm still not sold on IsIncreasing, etc. though

[zeroviscosity]

I'm happy to scrap IsIncreasing and IsDecreasing. If you're OK with a map allocation for AreUnique, would you rather I rework/rename this PR or close it and start a new one?

[btracey]

I think a new PR would be better, although we're in the process of trying to merge all the repos together, so if it's not super time critical, maybe it can be one of the first PRs in the new combined repo?

[zeroviscosity]

Makes sense. I'll close this one out then.