[AniMov] some questions on R

calenge at biomserv.univ-lyon1.fr calenge at biomserv.univ-lyon1.fr
Wed Jul 4 12:24:18 CEST 2007


Dear Anna,

> 1- which kind of bug was affecting mcp.area?

This was a major bug related to the management of numeric values and character
strings with R. The old version of the function mcp.area defined a factor ID
from the vector of ID after conversion to character strings. The problem is
that the order is not the same for the character string and the numeric values
when the IDs are numbers. For example, consider the following vector:

id <- c(1,2,5,11,13,22)

Now sort this vector

> sort(id)
[1]  1  2  5 11 13 22
> sort(as.character(id))
[1] "1"  "11" "13" "2"  "22" "5"

The order is not the same for the two: "11" is considered as "lower" than "1",
whereas eleven is larger. When converting id into factor, this changes the
order of the levels of the factor:

> factor(id)
[1] 1  2  5  11 13 22
Levels: 1 2 5 11 13 22
> factor(as.character(id))
[1] 1  2  5  11 13 22
Levels: 1 11 13 2 22 5

There was a confusion resulting from this behaviour, and this resulted into
interchanged levels of the ID in the results. Although this bug has now been
corrected, I think that it is still a safe behaviour to work with pure
character strings as id. For example, use:

id <- paste("animal", id, sep=".")
id


> 2- horne & garton 2006 in JWM (vol 70-3, pp. 641-648) suggested an appealing
alternative to LSCVh: CVh (likelihood cross-validation). Is anyone working to
implement CVh in kernelUD ?

I do not have planned to work on this implementation, though I agree this would
be an interesting improvement (but it should be programmed in C and interfaced
with R to speed up the calculation, which is a huge work). I stay open, and
would accept any improvements of this function in adehabitat.


> 3- sometimes (but not for any level !!!) kver.to.shapefile returns the
following error message:
> Errore in convert.to.shapefile(a[[i]], b[[i]], "Id", 5) :
>         Id set in shpTable not the same as Id set in attTable
>
> ...could somebody tell me his opinion about it?
>

See the answer of Ferdinando.

> 4- if two different functions in R, belonging to two different packages, have
the same name, is it possible some confusion inside the software? (e.g.
write.dbf, belonging to shapefiles and foreign)

Yes, this may occur. A already met this problem, though I do not have any
example in mind. In fact, to avoid this problem, the package where is the
function to be used should be in the top of the search list. The packages
attached the most recently are in the top of this list:

> search()
 [1] ".GlobalEnv"         "package:stats"      "package:graphics"
 [4] "package:grDevices"  "package:utils"      "package:datasets"
 [7] "package:RSvgDevice" "package:gpclib"     "package:adehabitat"
[10] "package:ade4"       "package:lattice"    "package:methods"
[13] "Autoloads"          "package:base"
> detach("package:adehabitat")
> search()
 [1] ".GlobalEnv"         "package:stats"      "package:graphics"
 [4] "package:grDevices"  "package:utils"      "package:datasets"
 [7] "package:RSvgDevice" "package:gpclib"     "package:ade4"
[10] "package:lattice"    "package:methods"    "Autoloads"
[13] "package:base"
> library(adehabitat)
This package requires ade4 to be installed

Type:
demo(rastermaps) for demonstration of raster map analysis
demo(homerange) for demonstration of home-range estimation
demo(managltraj) for demonstration of animals traject management
demo(analysisltraj) for demonstration of animals traject analysis
demo(nichehs) for demonstration of niche/habitat selection analysis

> search()
 [1] ".GlobalEnv"         "package:adehabitat" "package:stats"
 [4] "package:graphics"   "package:grDevices"  "package:utils"
 [7] "package:datasets"   "package:RSvgDevice" "package:gpclib"
[10] "package:ade4"       "package:lattice"    "package:methods"
[13] "Autoloads"          "package:base"

Hope this helps,


Clément Calenge

-- 
Clément CALENGE
LBBE - UMR CNRS 5558 - Université Claude Bernard Lyon 1 - FRANCE
tel. (+33) 04.72.43.27.57
fax. (+33) 04.72.43.13.88




--------------------------------------------------------------------------
Ce message a été envoyé depuis le webmail IMP (Internet Messaging Program)



More information about the AniMov mailing list