Flow chart using {diagram} in R 3.0.0 for Windows

Question

I am trying to re-make a flow chart in R using the diagram package (v 1.6). I was able to make a chart using this exact script (which I modified from the example in the diagram documentation), but once I updated R to 3.0.0, the coordinates function gives me an error. Here is an example:

library(graphics)
library(diagram)

par(mar = c(1, 1, 1, 1))
openplotmat()
elpos<-coordinates(c(1,1,2,4))

Error in (function (classes, fdef, mtable)  : unable to find an inherited method for function ‘coordinates’ for signature ‘"numeric"’

I am still new to R and code, etc., so when I run traceback(), I really don't understand what it is telling me:

3: stop(gettextf("unable to find an inherited method for function %s for signature %s", 
   sQuote(fdef@generic), sQuote(cnames)), domain = NA)
2: (function (classes, fdef, mtable) 
  {
   methods <- .findInheritedMethods(classes, fdef, mtable)
   if (length(methods) == 1L) 
       return(methods[[1L]])
   else if (length(methods) == 0L) {
       cnames <- paste0("\"", sapply(classes, as.character), 
           "\"", collapse = ", ")
       stop(gettextf("unable to find an inherited method for function %s for signature %s", 
           sQuote(fdef@generic), sQuote(cnames)), domain = NA)
   }
   else stop("Internal error in finding inherited methods; didn't return a unique method", 
       domain = NA)
  })(list("numeric"), function (obj, ...) 
  standardGeneric("coordinates"), <environment>)
1: coordinates(c(1, 1, 2, 4))

Mostly I don't know why coordinates() won't work post-update. Any insight with that, as well as possibly a translation of the traceback would be a huge help. Thank you!

Answer 1

I can't answer the question so much as the problem. Initially, I could not reproduce your error:

library(diagram)
openplotmat()
(elpos1 <- diagram::coordinates(c(1,1,2,4)))
#       [,1]  [,2]
# [1,] 0.500 0.875
# [2,] 0.500 0.625
# ...

Finding Same-Named Functions

However, looking for other instances of a coordinates function revealed something:

help.search('coordinates', fields='name')
# Help files with name matching 'coordinates' using fuzzy matching:
# 
# diagram::coordinates                  coordinates of elements on a plot
# sp::coordinates-methods               retrieve (or set) spatial coordinates
# sp::coordinates                       sets spatial coordinates to create spatial data, or retrieves spatial
#                                       coordinates
# sp::coordnames                        retrieve or assign coordinate names for classes in sp

This output searches all installed (not necessarily loaded) packages. From this, it appears that sp also has one. Using its version in your use-case produces the error.

Package Loading Order (or, Masked Functions)

The order that packages are loaded is important, as functions from later-loaded functions mask functions of the same name from previous-loaded packages. Specifically:

# ensure we have neither package loaded
detach(package:diagram, unload=TRUE) # ignore errors if not loaded
detach(package:sp, unload=TRUE)      # ignore errors if not loaded
library(diagram)
library(sp)
# Attaching package: 'sp'
# 
# The following object is masked from 'package:diagram':
# 
#     coordinates

This message is telling you that a simple call to coordinates() will be using the version from sp and not from diagram. (For each code block below, I use detach() as above to ensure neither package nor its nameSpace is still around.)

Using the sp version produces the same error that you got, after having loaded the libraries in the order: diagram, sp:

library(diagram)
library(sp)
# Attaching package: 'sp'
# 
# The following object is masked from 'package:diagram':
# 
#     coordinates
(elpos <- coordinates(c(1,1,2,4)))
# Error in (function (classes, fdef, mtable)  : 
# unable to find an inherited method for function 'coordinates' for signature '"numeric"'

The traceback() is identical to what you provided.

Reversing the loading order works:

library(sp)
library(diagram)
# Attaching package: 'diagram'
# 
# The following object is masked from 'package:sp':
# 
#     coordinates
(elpos <- coordinates(c(1,1,2,4)))
#       [,1]  [,2]
# [1,] 0.500 0.875
# [2,] 0.500 0.625
# ...

Note that the warning now tells you that sp::coordinates() is now masked.

When In Doubt, Be Unambiguous

If there's any doubt as to which version is being called, we can always force which we intend to use:

(elpos <- diagram::coordinates(c(1,1,2,4)))
#       [,1]  [,2]
# [1,] 0.500 0.875
# [2,] 0.500 0.625
# ...

I feel a little off posting this as an answer, since I'm addressing your problem and not necessarily the stated question. Please keep prompting for answers if you still need to hunt down the results of traceback(). In that effort, though, I could not find .findInheritedMethods(), but it makes sense when diagram::coordinates is expecting a vector specifying the number of elements in each row, or 2-columned matrix with element position, or 'NULL', while sp::coordinates is expecting object deriving from class "Spatial" (which is most definitely not a simple vector).