-
Notifications
You must be signed in to change notification settings - Fork 1
Add basis interpolation methods to tourr package
The tour is a technique to visualize high-dimensional data from a sequence of low-dimensional projections. It can be used to explore data for clusters, outliers and non-linear relationships. It is also for useful with modeling, to check assumptions such as multicollinearity, and for checking boundaries between classes in supervised classification problems.
This project will build on the existing tourr package. The current interpolation method for the grand tour, and parts of the other tours is geodesic. This interpolates between planes, by finding the shortest angle between them, and it ensures that all of the rotation in a tour path is out of the viewing plane.
This project is related to Issue 110 on the tourr GitHub repo. The task is to take existing R code for doing basis interpolation and integrate it as an alternative interpolation method for tour, writing a vignette explaining the interpolation methods and why and where to use each one.
This package is one of the few available for visualising high-dimensional data. It is used in many university courses on multivariate data, and machine learning. It is also reasonably broadly used in industry.
MENTORS: fill in this part. each project needs 2 mentors. One should be an expert R programmer with previous package development experience, and the other can be a domain expert in some other field or application area (optimization, bioinformatics, machine learning, data viz, etc). Ideally one of the two mentors should have previous experience with GSOC (either as a contributor or mentor). Please provide contact info for each mentor, along with qualifications.
IMPORTANT: you MUST write "EVALUATING" for one mentor, who will be required to do the three evaluations of the contributor during the summer. In previous years we have had issues with mentors who do not fill in evaluations, and when this happens R project is penalized (money is taken away), although contributors are not penalized (contributors are passed by default if no mentor eval is submitted). Therefore one mentor must take responsibility for doing the evaluations, and you must indicate that here, and your contributor must indicate that as well in the application. If it is not clear which mentor will be the EVALUATING mentor then your project will not be accepted. Example:
Contributors, please contact mentors below after completing at least one of the tests below.
- EVALUATING MENTOR: Ursula Laa ursula.laa@boku.ac.at is the author of the slice tour and section pursuit code in the tourr package.
- MENTOR dicook@monash.edu is the maintainer of the tourr package, and developer of several methods provided in the package.
Contributors, please do one or more of the following tests before contacting the mentors above.
MENTORS: write several tests that potential contributors can do to demonstrate their capabilities for this particular project. Ask some hard questions that will give you insight about how the contributors write code to solve problems. You'll see that the harder the questions that you ask, the easier it will be for you to choose between the contributors that apply for your project! Please modify the suggestions below to make them specific for your project.
- Easy: something that any useR should be able to do, e.g. download some existing package listed in the Related Work, and run it on some example data.
- Medium: something a bit more complicated. You can encourage contributors to write a script or some functions that show their R coding abilities.
- Hard: Can the contributor write a package with Rd files, tests, and vignettes? If your package interfaces with non-R code, can the contributor write in that other language?
Contributors, please post a link to your test results here.
- EXAMPLE CONTRIBUTOR 1 NAME, LINK TO GITHUB PROFILE, LINK TO TEST RESULTS.