Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

timeseriesweka.filters.shapelet_transforms #16

Closed
TonyBagnall opened this issue Feb 6, 2019 · 8 comments
Closed

timeseriesweka.filters.shapelet_transforms #16

TonyBagnall opened this issue Feb 6, 2019 · 8 comments

Comments

@TonyBagnall
Copy link
Member

yikes! I will have a little tidy up (GraceShapeletTransform) but I think this needs a bottom up reconstruction. Perhaps do the python version first. I think James has a start on the slimmed down version?
image

@james-large
Copy link
Member

I only did a very quick/very minimal/very minimally tested 2d shapelets version for the bags project, I think just ignore that

@ABostrom
Copy link
Member

I think we need to define what we want shapelets to be able to do.

Do we want to be able to find shapelets. construct transforms from them. construct trees from them?

Support the different distance measures, and quality measures etc.

@TonyBagnall
Copy link
Member Author

So the core functionality of the shapelet_transform is to search the data for shapelets. Lets just get that a bit tidied up first. Can any of the above be removed (e.g GraceShapeletOptions and ApproximateShapeletTransform) and can any others be nested? e.g. Do we need to see Shapelet and ShapeletCandidate? I'll remove ShapeletTransformLight. I would like a single filter class in the directory filters. The rest can stay in its own directory, but do we really need a package class_value, and if we do, could it not move to utilities? Oh and: comment your code!

@ABostrom
Copy link
Member

The general structure of the subapackages is: there are two different types of class values, but they share a common interface. This could go into utilities. A classifier shouldn't necessarily need to know whether it is using a binary or regular encoding. so it's wrapped up.

distance/quality/search functions are self explanatory subpackages.

Distance measures are bespoke implementations for ST. Quality measures are bespoke to ST also.
I believe both of these could be majorly tidied up, and be more general purpose implementations.

SearchFunctions atm are bespoke to searching for shapelets, these are used with ST. but could just as readily be used in a forest or tree implementation. if we wanted to. Could build contract random shapelet forest very simply.

@TonyBagnall
Copy link
Member Author

so please refactor/tidy/comment when and if you get a chance, but push regularly as I am also background working with shapelets for the STC, so dont want to get out of sync.

@TonyBagnall
Copy link
Member Author

in fact I just refactored ShapeletTransformLight, so will push it now!

@ABostrom
Copy link
Member

Yeah. I'll put it on my list.

@TonyBagnall
Copy link
Member Author

I've done/am doing this, so will close the issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants