You do not seem to be trying the relevant function arguments to test if the eps argument is defined as euclidean distances. That said, it may help to look at the help for the
fpc::dbscan implementation as the help is a bit more informative and the model specification/parameters almost identical. The dbscan package implementation is just an optimized version of the fpc version. However, keep in mind that the two model parameters "eps" and "minPts" interact in a way that may not result in an "exact" search distance.
The require input for
dbscan::dbscan specifically states a matrix that can be a distance object. In other terms, a matrix of coordinate pairs or actual distance matrix. You can have an underlying assumption that a matrix of projected coordinate pairs will be calculated using euclidean distances.
x - a data matrix or a dist object.
search - nearest neighbor search strategy (one of "kdtree" or "linear", "dist").
data - matrix, data.frame, dissimilarity matrix or dist-object.
Specify method="dist" if the data should be interpreted as
dissimilarity matrix or object. Otherwise Euclidean distances will be
method (same as search) - "dist" treats data as distance matrix
(relatively fast but memory expensive), "raw" treats data as raw data
and avoids calculating a distance matrix (saves memory but may be
slow), "hybrid" expects also raw data, but calculates partial distance
matrices (very fast with moderate memory requirements).
The search/method argument then should probably be "dist" to ensure that euclidean distances are used. However, you should also perform some exploratory analysis to ensure that this is a supported value for eps. Take a look at
In reference to @gene, you should be aware that the dbscan::dbscan function supersedes the implementation in the fpc package.
Note: use dbscan::dbscan to call this implementation when you also use