Custom Query (454 matches)

Even after fixing the problems described in #390 and #391 I was still seeing odd behavior on background seismicity sources. It turns out the UCERF2 isn't thread safe after all - the background seismicity sources reuse a ProbEqkRupture? object, just overriding the magnitude, surface, etc... That means that if 2 threads are working on the same source at the same time, the surface or magnitude could change mid-computation. We need to address this - I can think of a couple different ways but each has tradeoffs.

the javadoc for XY_DataSet.hasPoint(x, y) describes the functionality as:

Determine wheither a point exists in the list, as determined by it's x-value within tolerance.

Most implementations only check that there is a value at the specified x value (which is how I interpret the javadoc). One exception, however, is EvenlyDiscretizedFunc? which checks that not only does a point exist at the given x value (within tolerance) but that the y value matches as well.

This is a point of potential confusion. Maybe we should have two different methods:

hasPoint(x) hasPoint(x, y)

The first would only check x values, the second would check both x and y values. We would have to decide what to return for hasPoint(Point2D), however. Thoughts?

This class has a several useful, but poorly documented and untested methods. It also has methods that are implemented in Guava Doubles and should be removed. Per Eric Martinez, methods in the ArrayUtils? class that are used by NSHMPRiskMapCalc were decompiled from USGSutil.jar for inclusion in the repository. During variable renaming, one or two errors were introduced.

DataUtil? and DataUtils? need consolidation or method relocation.