GithubHelp home page GithubHelp logo

oxcaar's People

Contributors

ctietze91 avatar dakni avatar dirkseidensticker avatar joeroe avatar martinhinz avatar nevrome avatar nfrerebeau avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

oxcaar's Issues

Tests

Currently there is only a dummy test. This is not a satisfactory state! We aim for the 💯 % coverage!

Problems reporting in years before present instead of BC/AD

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.)

Push Coverage over 80% again

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

oxcAAR crashes for large ages and/or very low precisions

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.

Changing resolution causes error

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?

Remove warning in windows

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?

give some advice on installing Oxcal

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?

no display(?) for dates with high ages or low precision

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.

Improving the plot output

Three things to do here (?):

  • add an ggplot output option
  • implement a curve plot with bp std ranges indicated (inspiration @nmueller18 )
  • Add other oxcal-typical plots (any ideas?)

make it run under windows

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?

Graceful fail for downloading oxcal requested

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

Further Functionality

Proposals:

  • Summing data with one function
  • computation of confidence interval for summing

Tidy Output

implement functions that extract informations from the resulting oxcAAR objects and present them in easily processible formats (vector, data frame)

Candidates are:

  • raw probabilities (dataframe of dates and probabilities)
  • sigma ranges
    ...?

Improve documentation

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?

Allow to select the output directory in executeOxcalScript

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();).

Loss of information when transforming to rcarbon caldate

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.

Parsing on sigma ranges sometimes fails

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

Question: Interoperatibility with Bchron

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?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.