isaakiel / oxcaar Goto Github PK
View Code? Open in Web Editor NEWR Package - Interaction with Oxcal
License: GNU General Public License v2.0
R Package - Interaction with Oxcal
License: GNU General Public License v2.0
Currently there is only a dummy test. This is not a satisfactory state! We aim for the 💯 % coverage!
#17 added support for posterior values (sigma ranges and raw probabilities) to parseOxcalOutput()
and the plotting functions, but get_tidy_oxcalresult()
seems to have been missed.
Calibration results seem to be returned in YBP or in BC/AD by some internal logic that determines which is preferable. However, when I create a script that includes the command "BCAD=FALSE" and execute it using executeOxcalScript()
, which in the Oxcal web interface would cause it to return the calibrated dates in YBP, it does not seem to have any effect.
Is there a way to return the calibration results reliably in YBP? If not, is this a bug?
It's possible I am misinterpreting the results and it is ALWAYS reporting in BC/AD and never in YBP, in which case this is an issue but I have an easy workaround by simply adding 1950 to all the dates.
(There does not appear to be an option in the built-in R functions (eg. oxcalCalibrate()
) to report results in ybp, but I assume this was a deliberate design choice.)
For enabling Sequential calibration, some convenience functions would be nice to have.
Some inspiration:
R_Phase
Boundary
wrap_in_boundaries
Sequence
See the CAA2018 Tutorial for a preliminary implementation of that.
With 1.1 Flora test coverage has dropped below 70%. I suggest we bring it up again to at least over 80% with 1.2 Gwen
Salvador Herrando-Perez wrote:
I have tried the new version, and the problem has been solved for the sigma thresholds stated in my first email, however the script continues to crash for large ages and/or very low precisions. For instance, for uncalibrated ages of 40, 50 and 60 ky, the crashing occurs at precisions somewhere within intervals 9 to 10, 1.7 to 1.8 and 6 to 7 ky, respectively.
Add a ggplot2 versions of the plot functions. Related to #7.
From a user:
I am trying to use oxcAAR, which seems to be a nice tool for R user when
calibrating 14C dates. I have a problem when changing the Resolution
option to 1 year instead of the default (5 years). The simple following
script works perfectly:
res=executeOxcalScript("R_Date("test", 1120, 30);")
OxCal v4.4.2 (c) Bronk Ramsey (2020)
res2 <- readOxcalOutput(res)
res3 <- parseOxcalOutput(res2)
and produce an adequate output (.js) file.
But, changing the resolution gives an error:
res=executeOxcalScript("Options(){Resolution=1;}; R_Date("test",
1120, 30);")
OxCal v4.4.2 (c) Bronk Ramsey (2020)
res2 <- readOxcalOutput(res)
res3 <- parseOxcalOutput(res2)
Error in seq.default(from = calcurve_start, by = calcurve_resolution, :
'from' must be of length 1
The output .js file is built (I attach it to this mail), but
"parseOxcalOutput" fails to read its content.
Do you have any idea where does this error come from?
Checking the changes and the functionality, as well as al necessities for an cran release of 1.1 Flora
When oxcal is called from within windows, there is a warning that the program has not terminated with status 0 (or better, that it terminated with status 1).
Either there is a way to convince oxcal to terminate without error (as it does on linux), or we just suppress warnings?
Hi @MartinHinz !
I want to calibrate dates from your RADON database in R and struggle with installing Oxcal. Do you plan to have a small intro into installing Oxcal on different OS? If so, where would be the place to put these information?
oxcAAR should be able to accept and process multiple calibration curves for individual dates. Problem occurred first time in relation to #27
Salvador Herrando-Perez wrote:
An additional caveat is that xlim and ylim in oxcalCalibrate() seems to have an upper bound around 45 ky - so for old ages and/or very low precisions the calibration curve might fail to display or not show the error bars.
On request, and also as already standing idea, the user should be able to select the calibration curve.
possible list:
Three things to do here (?):
oxcAAR is currently not running under windows. @MoritzMennenga had tested it some time ago, the error was related to path names resp. spaces in them under windows.
There must be general better ways to implement external programs into R, is there a best practise that works under all OS?
Prof. Brian Ripley wrote 28th of June 2021:
Dear maintainer,
Please see the problems shown on
https://cran.r-project.org/web/checks/check_results_oxcAAR.html.
Please correct before 2021-07-12 to safely retain your package on CRAN.
It seems we need to remind you of the CRAN policy:
'Packages which use Internet resources should fail gracefully with an informative message
if the resource is not available or has changed (and not give a check warning nor error).'
This needs correction whether or not the resource recovers.
The CRAN Team
Since we aim for using the sequential possibilities of OxCal, we should include the ability to read them from the OxCal output and display them in summary and plots.
@nevrome suggested for formatFullSigmaRange:
Do you really need 6 decimal places for the %-value? Maybe 2 would be enough?
Request from Raiko:
Ist es vielleicht auch bald möglich, die archäologisch gereihten Daten durch Expansion und Permutation innerhalb der einzelnen stratigraphischen Einheiten in die Kurve einzupassen? Das wäre zu schön!
Proposals:
implement functions that extract informations from the resulting oxcAAR objects and present them in easily processible formats (vector, data frame)
Candidates are:
The documentation should be checked in respect to comprehensibility and language. The vignette might also be improved to reflect all the possibilities that this fine package offers.
When done from the functional point of view, @ctietze91 might also proofread it again?
When running an OxCal script with executeOxcalScript()
, the output files are generated in a temporary directory. Would it be possible to let the user choose the output directory (with a default value to tempfile()
)?
This could be useful when you want to keep specific files (e.g. the csv produced by MCMC_Sample();
).
Remarks of @nevrome regarding PR ggplot branch, should be considered before merging rcarbon-sync-branch
Not sure if this is perfectly clean.
> my_uncal_dates <- data.frame(bp=c(5000,4500,4000), std=c(45,35,25), names=c("Date 1", "Date 2", "Date 3") ) > my_cal_dates <- oxcalCalibrate(my_uncal_dates$bp, my_uncal_dates$std, my_uncal_dates$names) > as.CalDates(my_cal_dates) %>% str() List of 3 $ metadata :'data.frame': 3 obs. of 11 variables: ..$ DateID : chr [1:3] "Date 1" "Date 2" "Date 3" ..$ CRA : num [1:3] 5000 4500 4000 ..$ Error : num [1:3] 45 35 25 ..$ Details : logi [1:3] NA NA NA ..$ CalCurve : chr [1:3] "data" "data" "data" ..$ ResOffsets: logi [1:3] NA NA NA ..$ ResErrors : logi [1:3] NA NA NA ..$ StartBP : logi [1:3] NA NA NA ..$ EndBP : logi [1:3] NA NA NA ..$ Normalised: logi [1:3] TRUE TRUE TRUE ..$ CalEPS : num [1:3] 0 0 0 $ grids :List of 3 ..$ Date 1:Classes ‘calGrid’ and 'data.frame': 545 obs. of 2 variables: .. ..$ calBP : num [1:545] 6009 6008 6007 6006 6005 ... .. ..$ PrDens: num [1:545] 0 0 0 0 0 0 0 0 0 0 ... ..$ Date 2:Classes ‘calGrid’ and 'data.frame': 635 obs. of 2 variables: .. ..$ calBP : num [1:635] 5474 5473 5472 5471 5470 ... .. ..$ PrDens: num [1:635] 0 0 0 0 0 ... ..$ Date 3:Classes ‘calGrid’ and 'data.frame': 585 obs. of 2 variables: .. ..$ calBP : num [1:585] 4814 4813 4812 4811 4810 ... .. ..$ PrDens: num [1:585] 0 0 0 0 0 ... $ calmatrix: logi NA - attr(*, "class")= chr [1:2] "CalDates" "list"
> rcarbon::calibrate(c(5000,4500,4000), errors=c(45,35,25)) %>% str() [1] "Calibrating radiocarbon ages..." |=====================================================================================================| 100% [1] "Done." List of 3 $ metadata :'data.frame': 3 obs. of 12 variables: ..$ DateID : chr [1:3] "1" "2" "3" ..$ CRA : num [1:3] 5000 4500 4000 ..$ Error : num [1:3] 45 35 25 ..$ Details : logi [1:3] NA NA NA ..$ CalCurve : chr [1:3] "intcal20" "intcal20" "intcal20" ..$ ResOffsets: num [1:3] 0 0 0 ..$ ResErrors : num [1:3] 0 0 0 ..$ StartBP : num [1:3] 55000 55000 55000 ..$ EndBP : num [1:3] 0 0 0 ..$ Normalised: logi [1:3] TRUE TRUE TRUE ..$ F14C : logi [1:3] FALSE FALSE FALSE ..$ CalEPS : num [1:3] 1e-05 1e-05 1e-05 $ grids :List of 3 ..$ 1:Classes ‘calGrid’ and 'data.frame': 336 obs. of 2 variables: .. ..$ calBP : num [1:336] 5922 5921 5920 5919 5918 ... .. ..$ PrDens: num [1:336] 1.11e-05 1.29e-05 1.49e-05 1.77e-05 2.10e-05 ... ..$ 2:Classes ‘calGrid’ and 'data.frame': 443 obs. of 2 variables: .. ..$ calBP : num [1:443] 5432 5431 5430 5429 5428 ... .. ..$ PrDens: num [1:443] 1.10e-05 1.27e-05 1.47e-05 1.42e-05 1.37e-05 ... ..$ 3:Classes ‘calGrid’ and 'data.frame': 270 obs. of 2 variables: .. ..$ calBP : num [1:270] 4611 4610 4609 4608 4607 ... .. ..$ PrDens: num [1:270] 1.19e-05 1.35e-05 1.91e-05 2.14e-05 2.14e-05 ... $ calmatrix: logi NA - attr(*, "class")= chr [1:2] "CalDates" "list"
There is some factual loss of information, e.g. in the
CalCurve
field.
The parsing of the sigma ranges from the oxcal output seems to fail occasionally. Using SHCal13 and I think it relates to the possibility of getting multiple values in the range and perhaps one empty e.g., with a ",..." value . It means that occasionally . Oxcal reports the lower values but in the three sigma range in particular fails to set the structure up and report the lower sd value (can handle if the higher one is just NA). I figure it is in the sigma_extract function.
E.g.,
R_Date: BP = 229, std = 35
unmodelled: posterior:
one sigma
1659 AD - 1678 AD (14.2%)
1734 AD - 1800 AD (54%)
two sigma
1640 AD - 1710 AD (27.9%)
1720 AD - 1812 AD (61.2%)
1836 AD - 1848 AD (1.3%)
1858 AD - 1880 AD (2.5%)
1928 AD - NA (2.4%)
^^^^ Where the three sigma range ^^^
NA
Should we aim at having a similar structure for the 14C dates as bchron? From what I remember I already was inspired by their data structure, I have to check whether it is already a copy. But if not, is it worth adapting?
Write a function that plots 14C dates on the cal curve. Related to request of @nmueller18 in #7.
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.