joeroe / era Goto Github PK
View Code? Open in Web Editor NEWR package for year-based time scales
Home Page: https://era.joeroe.io
License: Other
R package for year-based time scales
Home Page: https://era.joeroe.io
License: Other
Currently:
library("era")
a <- yr(1:10, "BP")
b <- yr(1:10, "BP")
c <- yr(1:10, "BC")
a == b
#> [1] TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE
a == c
#> Error: Can't combine `..1` <yr (BP)> and `..2` <yr (BC)>.
#> Reconcile eras with yr_transform() first.
The first result is correct. The second result maybe too strict and should return FALSE
instead of an error.
Including #21.
We should have a function for converting between era_yr and date/datetime classes. There should probably be plenty of warnings about the fact that it isn't precise.
Arithmetic with yrs with functionally equivalent, but differently named, eras throws a warning as expected:
library("era")
yr(1, "BP") + yr(1, "cal BP")
#> Warning: `era(x)` and `era(y)` have different label or name parameters.
#> # BP years <yr[1]>:
#> [1] 2
#> # Era: Before Present (BP): calendar years, counted backwards from 1950
But combining the same vectors doesn't:
c(yr(1, "BP"), yr(1, "cal BP"))
#> # BP years <yr[2]>:
#> [1] 1 1
#> # Era: Before Present (BP): calendar years, counted backwards from 1950
Created on 2020-12-08 by the reprex package (v0.3.0)
The check currently in vec_arith.era_yr.era_yr()
should be moved lower, to catch all instances of combination.
When converting between CE-based and BP-based eras, yr_transform() does not account for the absence of a year zero.
library("era")
yr_transform(yr(10000, "BP"), era("BCE"))
#> # BCE years <yr[1]>:
#> [1] 8051
#> # Era: Before Common Era (BCE): calendar years, counted backwards from 1
OxCal is good at this kind of thing.
CE-based eras come in pairs, i.e. negative values of CE are BCE; negative values of BCE are CE. There is currently no concept of this in era. I can think of two ways to add it:
inverse
attribute that contains another era.The underlying question is whether it makes sense to support paired eras in analytical use (in which case we'd need 1) or just for printing and plotting (then 2 would be enough).
They wouldn't do much, just change the default order of the sequence based on the era's direction
attribute, and add abbreviated labels somewhere.
It would also be nice to support paired eras when plotting (#17).
Resources:
Currently era() assumes the epoch parameter is a year in the Common Era, but we could make this itself a yr object (defaulting to CE).
Adding non-Gregorian calendars complicates the definition and conversion of eras. We need to account for:
I haven't fully worked out how to do this. But some general principles:
Because using vec_assert has a puzzling result:
vctrs::vec_assert(era::era("BP"), era:::new_era())
#> Error: `era::era("BP")` must be a vector with type <era>.
#> Instead, it has type <era>.
i.e. rlang::abort(), warn() and inform() over base::stop(), warning() and message(). See: https://rlang.r-lib.org/reference/abort.html
yr_transform() is precise with epoch transformations, which is appropriate for more recent years but unnecessarily messy for distant ones:
library("era")
yr(100000000, "BCE") %>%
yr_transform(era("mya"))
#> # mya years <yr[1]>:
#> [1] 100.0019
#> # Era: million years ago (mya): calendar (×1e+06) years, counted backwards from 1950
Created on 2020-11-12 by the reprex package (v0.3.0)
It would be nice to add an option to round the output to a desired level of precision in yr_transform().
Currently:
library("era")
yr(1, "BP")
#> # BP years <yr[1]>:
#> [1] 1
#> # Era: Before Present (BP): calendar years, counted backwards from 1950
But:
yr_set_era(1, era("BP"))
#> # BP years <yr[1]>:
#> [1] 1
#> # Era: Before Present (BP): calendar years, counted backwards from 1950
Created on 2020-11-12 by the reprex package (v0.3.0)
This as annoying. Every function that has an era
argument should also accept a character label to look up in eras().
eras are complicated enough that a validate_era()
function is needed. This should be called in the era() constructor, but not new_era(), to maintain the ability to create (invalid) empty eras internally.
Prepare for release:
devtools::build_readme()
usethis::use_cran_comments()
devtools::check(remote = TRUE, manual = TRUE)
devtools::check_win_devel()
rhub::check_for_cran()
*cran-comments.md
Submit to CRAN:
usethis::use_version('minor')
devtools::submit_cran()
Wait for CRAN...
usethis::use_github_release()
usethis::use_dev_version()
Currently the standard eras known to the package are defined internally in era_dictionary(). These should at least be documented somewhere for the user. I can see two options:
eras()
?) which, in addition to returning a specified era, could:
First release:
usethis::use_cran_comments()
Title:
and Description:
@return
and @examples
Authors@R:
includes a copyright holder (role 'cph')Prepare for release:
git pull
devtools::build_readme()
urlchecker::url_check()
devtools::check(remote = TRUE, manual = TRUE)
devtools::check_win_devel()
rhub::check_for_cran()
git push
Submit to CRAN:
usethis::use_version('patch')
devtools::submit_cran()
Wait for CRAN...
git push
usethis::use_github_release()
usethis::use_dev_version()
git push
As a result of 86a6015, passing NA to era() constructs every available standard era:
library("era")
era(NA)
#> <era[24]>
#> [1] Before Present (BP): calendar years, counted backwards from 1950
#> [2] Before Present (cal BP): calendar years, counted backwards from 1950
#> [3] Before Christ (BC): calendar years, counted backwards from 0
#> [4] Before Common Era (BCE): calendar years, counted backwards from 0
#> [5] Anno Domini (AD): calendar years, counted forwards from 0
#> [6] Common Era (CE): calendar years, counted forwards from 0
#> [7] kiloannum (ka): calendar (×1000) years, counted backwards from 1950
#> [8] megaannum (Ma): calendar (×1e+06) years, counted backwards from 1950
#> [9] gigaannum (Ga): calendar (×1e+09) years, counted backwards from 1950
#> [10] thousand years ago (kya): calendar (×1000) years, counted backwards from 1950
#> [11] million years ago (mya): calendar (×1e+06) years, counted backwards from 1950
#> [12] billion years ago (bya): calendar (×1e+09) years, counted backwards from 1950
#> [13] years before 2000 (b2k): calendar years, counted backwards from 2000
#> [14] uncalibrated Before Present (uncal BP): radiocarbon years, counted backwards from 1950
#> [15] Radiocarbon Years Before Present (RCYBP): radiocarbon years, counted backwards from 1950
#> [16] Before Present (uncalibrated) (bp): radiocarbon years, counted backwards from 1950
#> [17] Before Christ (uncalibrated) (bc): radiocarbon years, counted backwards from 1950
#> [18] Before Common Era (uncalibrated) (bce): radiocarbon years, counted backwards from 1950
#> [19] Anno Domini (uncalibrated) (ad): radiocarbon years, counted forwards from 1950
#> [20] Common Era (uncalibrated) (ce): radiocarbon years, counted forwards from 1950
#> [21] Holocene Era (HE): calendar years, counted forwards from -10000
#> [22] Before Holocene Era (BHE): calendar years, counted backwards from -10000
#> [23] Anno Lucis (AL): calendar years, counted forwards from -4000
#> [24] After the Development of Agriculture (ADA): calendar years, counted forwards from -8000
This is a neat trick but probably not expected from the user's point of view. It should either throw an error (could handled in validation – #7) or return an NA-era.
Which would check that:
It should be used in the yr() constructor, but not new_yr(), to maintain the ability to create (invalid) empty yrs internally.
And eliminate magrittr dependency.
Possibly adding the abbreviated era label.
There should be an attribute of era that specifies whether the label is conventionally placed before or after the value, e.g. "AD 1" vs. "1 BC".
Many are dependent on #15.
General resources:
Currently yr_era(x) == yr_era(y)
is used in several places but I don't trust it.
It also might be better to only selectively compare eras, e.g. consider eras with different labels equal if all the significant parameters are the same. Then they should be able to be combined, with a warning that the labels will be changed.
Prepare for release:
devtools::build_readme()
urlchecker::url_check()
devtools::check(remote = TRUE, manual = TRUE)
devtools::check_win_devel()
rhub::check_for_cran()
revdepcheck::revdep_check(num_workers = 4)
cran-comments.md
Submit to CRAN:
usethis::use_version('minor')
devtools::submit_cran()
Wait for CRAN...
usethis::use_github_release()
usethis::use_dev_version()
For (better) handling of sum, mean, etc. Most should strip era and return a numeric.
It could be possible to cast characters to era_yrs (i.e. the inverse of #11) in some circumstances. E.g. "1 BCE"
could be interpreted as yr(1, "BCE")
. But maybe this is too magical?
era("AD") == era("CE")
#> [1] TRUE
But sometimes you might want it to be FALSE
.
For different definitions of a year:
Resources:
After 86a6015 adding new definitions of standard eras is now quite straightforward. Documenting how to do it step-by-step might be a good way to encourage new contributions.
era("unknown era")
#> Error: Invalid era:
#> x `scale` must be positive
#> x `direction` must be -1 (backwards) or 1 (forwards)
#> Run `rlang::last_error()` to see where the error occurred.
Rather than trying and failing to construct an era with missing parameters, era() should recognise that the user has asked it for a predefined era that doesn't exist and give a more informative error.
library("era")
c(era("BP"), NA)
#> <era[2]>
#> Error in unitout[era_scale(x) == 1] <- era_unit(x)[era_scale(x) == 1]:
#> NAs are not allowed in subscripted assignments
The vctrs S3 vectors vignette suggests adding this lines to internal constructors for compatibility with S4:
methods::setOldClass(c("pizza_percent", "vctrs_vctr"))
But when I've tried it in new_yr I get an error:
era:::new_yr()
#> Error in assign(".S3MethodsClasses", S3table, envir = where):
#> cannot add bindings to a locked environment
yr_transform()
currently throws an error if either the source or destination era has an NA unit, following the R convention that NA == NA
is NA.
It might not be necessary to be this strict, for example to allow transformations between era("bp") and era("bce"), and just warn that there is an assumption that the units are comparable.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.