viadee / anchorsonr Goto Github PK

Preferable CRAN-hosted packages with no or few options and with a non-GPL license from your existing short-list. :)

Coverage identification does not work properly, as of now.
Additionally, the perturbations needed to calculate coverage are created each time the coverage identification is called. This can happen once at initialization time.

Since we did not find a non-GPL CRAN-hosted package, that discretizes continuous data in an unsupervised manner #44 , an unsupervised discretizer should be implemented directly.
It could resemble the implementations of viadee in the 'javaAnchorAdapters' package.
https://github.com/viadee/javaAnchorAdapters/tree/master/DefaultConfigsExtension/src/main/java/de/viadee/xai/anchor/adapter/tabular/discretizer/impl

Useful discretizers could be equalfrequency (PercentileMedianDiscretizers) and manual cutpoints (ManualDiscretizer).

and should discretize as shown in the tests:

https://github.com/viadee/javaAnchorAdapters/tree/master/DefaultConfigsExtension/src/test/java/de/viadee/xai/anchor/adapter/tabular/discretizer

In R/connections.R -> initAnchors() the JVM is started. Til now, the function just falls asleep for 5 seconds to let the JVM start. Clearly not a good solution. We need to find a dynamic way to handle this.

.anchors.startJar(ip = ip, port = port, name = name, ice_root = tempdir(), stdout = stdout, bind_to_localhost = FALSE, log_dir = NA, log_level = NA, context_path = NA)

Sys.sleep(5L)

The application would greatly benefit from utilizing multiple threads. For R, this is no easy task and comes with plenty overhead. However, there are multiple options we should think about. There could be multiple threads, for example, listening to incoming calls to create multiple local explanations in parallel.

Contrary to #16, this issue is not about reducing communication overhead but actually enabling threading.

If multiple cases are explained, there should be a possibility to streamline explanations printouts. For instance, if several 'setosa' instances are explained, the resulting anchors - if similar/identical could be unified.

Example:
====Result====
IF Petal.Length IN [1,2.63333333333333) (ADDED PRECISION: 1, ADDED COVERAGE: -0.509)
THEN PREDICT 'setosa'
WITH PRECISION 1 AND COVERAGE 0.491
====For Explained Instances 15, 18 ====
====15====
Sepal.Length = 5.8
Sepal.Width = 4
Petal.Length = 1.2
Petal.Width = 0.2
WITH LABEL = 'setosa'
====18====
Sepal.Length = 5.8
Sepal.Width = 4
Petal.Length = 1.2
Petal.Width = 0.2
WITH LABEL = 'setosa'

Another nice-to-have would be the possibility to just print the rules without the instance details, e.g. via a verbosity parameter?

The explained prediction is set in a_dataframe.R by
prediction = predict_model(explainer$model, instance, type = o_type)

The user needs to be able to customly set the parameter he or she would like to explained. Thus, make this a parameter.

bin_contiuous, n_bins, quantile_bins and use_density should be moved elsewhere and produce a discretized dataset that can then be passed to anchors.

See javaAnchorAdapters issue

Further investigation required

should not be restricted like that

AnchorsOnR is currently waiting busily for responses. Is this best practice?

better understanding/checking of printed explanations: do predict values (as number) fit to instance label?

It seems there is high relative communication overhead.
We should try to communicate less with the Java backend.

Idea: Increase the initSampleCount, use KL_LUCB with high batchSize. Then, enable parallelization in anchorsOnR.

This helps us to develop an understanding of which processes take most time

IsInIntervall("2.9",c("[2,2.9)","[2.9,3.2]") returns TRUE TRUE

Issues need to be addressed so that we have maintainable code that gets accepted by CRAN

in RPerturbFun_tabular_featureless(Disc): parameter perturbFun in RPerturbFun_tabular_featureless(Disc) not used
input not needed? or rather: should be used...

One can control the parameters bin_contiuous, n_bins, quantile_bins and use_density to discretize variables.
To my understanding, all variables are then discretized using the same options.

This, however, does not suffice:

1. in most cases, variables need to be discretized differently.
2. there need to be more options than these few.

In other words: the user needs full control over the discretization settings.

We have a few options here (non exhaustive list):

1. submit a second dataset which contains the discretized values
2. submit a collection of discretization functions

Which other options can you think of? Which would you prefer?

Write a comprehensive documentation with examples

The current perturbation generation function is in need of performance improvement.
Generating all perturbations that were asked for at once would help to reduce the total runtime.

See here

Since we did not find a non-GPL CRAN-hosted package, that discretizes continuous data in a supervised manner #44 , a supervised discretizer should be implemented directly.
It could resemble the implementations of viadee in the 'javaAnchorAdapters' package.
https://github.com/viadee/javaAnchorAdapters/tree/master/DefaultConfigsExtension/src/main/java/de/viadee/xai/anchor/adapter/tabular/discretizer/impl

Useful discretizers could be FUSINTER (FUSINTERDiscretizer.java) see:
FUSINTER_A_Method_for_Discretization_of_Continuous.pdf

or Ameva (AmevaDiscretizer.java) see:
AMEVA 2009-Gonzalez-Abril-ESWA.pdf

or another discretizer, as supervised discretizations are currently being implemented and evaluated for the Java implementation of Anchors.

These should discretize as shown in the tests:

https://github.com/viadee/javaAnchorAdapters/tree/master/DefaultConfigsExtension/src/test/java/de/viadee/xai/anchor/adapter/tabular/discretizer/impl

We need to prepare anchorsOnR to be available on CRAN.

Parameters such as tau etc. should be specifiable

Merge javaAnchorAdapter changes as preparation for jar download

There's some undocumented and unrelated code

Why does a train set need to be passed to anchors()?
Anchors is able to run without a data set. Just the default perturbation should require a dataset

AnchorsOnR is currently limited to a certain type of model (mlr/h2o).
Can we make this more generic or implement an own interface that the user can use?

A large share of the application's logic lies currently within a few classes such as a_dataframe.R. This should be split up as it resembles very different concepts.

Following the dependency changes, the examples do not work anymore.

• Create required meta files
• Pick a version number.
• Run and document R CMD check.
• Check that you’re aligned with CRAN policies.
• Update README.md and NEWS.md.
• Submit the package to CRAN.
• Prepare for the next version by updating version numbers.
• Publicise the new version.

We need a visualization that is independent from ggplot

Add categorial. should be simple, but need data for testing.

The perturbation code contains many "historical" legacy burdens. Based on outdated considerations, it was designed to be as flexible as possible so that different perturbation functions can be used for tabular data, images, etc. Thus, the perturbation code is accordingly complex. Since we now assume that the perturbation functions essentially exist as they are (i.e. one perturbation function for tabular data), the code could be significantly streamlined.

discretization and ML model should be same to increase probability of comparable results

E.g.:

====Explained Instance 100 ==== Sepal.Length = 5.7 Sepal.Width = 2.8 Petal.Length = 4.1 Petal.Width = 1.3 WITH LABEL Species = 'versicolor' ====Result==== IF Petal.Width IN INLC RANGE [0.867,1.6) (ADDED PRECISION: 0.910299003322259, ADDED COVERAGE: -0.391) THEN PREDICT '1' ('setosa') WITH PRECISION 0.910299003322259 AND COVERAGE 0.609

The java jar lies currently within the project.
The file needs to be removed and the current version downloaded from the maven central repository.

Programatically..