`ratio` should allow to specify which class to target when resampling

[lmittmann]

TomekLinks and EditedNearestNeighbours only remove samples form the majority class. However both methods are often used rather for data cleaning (removing samples form both classes) but undersampling (only removing samples form the majority class). Thus SMOTETomek and SMOTEENN are not implemented as proposed by Batista, Prati and Monard (2004), because they use TomekLinks and ENN for removing samples from the majority and the minority class.

It would be great to have a parameter that lets you choose whether to remove samples from both classes or only from the majority class.

[glemaitre]

You are right.

In fact, we should call the function is_tomek with the different classes as target.

For ENN, we will need to change the function _sample and allow avoid this line.

@chkoar @dvro What are you thoughts? Thinking about the problem, we could maybe move these cleaning function inside a side module from which we could ask the user what are the targeted classes to clean, with the minority class as default one. In that case, it means deprecation ;)

The issue would be that a lot of the function can be in fact considered as cleaning:

• CNN
• ENN
• NCL
• OSS
• Tomek

[lmittmann]

@glemaitre Regarding other affected methods: I agree, except of OSS which is an undersampling method since minority samples are never removed.

[dvro]

@glemaitre I don't know if you remember, but, originally, I wanted a keep parameter in which the user could select which classes (if any) he wanted to keep.

IMO, we should implement these techniques removing samples from ALL classes, and provide a way in which the user could specify a class he wanted to keep (either specifying the class label or 'minority' where the minority class would be detected online).

It would be like this for all undersampling methods.

[glemaitre]

I don't recall but it was a good idea that I didn't notice a that time.

I would go for a variable called something liketarget_classes which could be:

• a tuple containing the class to sample from,
• a string minority, majority, all.

I see this too possibilities but they could even be combined. It look like the ratio which can be either auto or a number.

And yes, it could be specific for the under-sampler. But what do you think about moving some of the methods in a new module cleaning or something like that?

[dvro]

@glemaitre that way would be great.

I believe cleaning is more related to noise removal, and that is not necessarily what all those techniques are doing (For example, CNN doesn't remove noise). I'd personally rather leaving all of them in the under_sampling module.

[chkoar]

@glemaitre agree. It could be placed optionally as parameter in samplemethod to override the object's parameter on demand. No?

[dvro]

@glemaitre @chkoar how should we proceed here, someone could make the first change and we'd follow (I can change this for ENN, RENN, AllKNN, and IHT).

PS: I have a presentation on aug 19th, until then I'll probably won't be able to do much.

[dvro]

@glemaitre where we stand on this issue?

[glemaitre]

@dvro myself is more hanging than standing right now :). I could not touch the issue since a while since that I was travelling last week for a conference.

I am back now but I have to actually close a paper before to be able to do anything more. It could take couple of days. Feel free if you want to start with the issue, I will take whenever I can.

[glemaitre]

@dvro @chkoar Thinking about the problem, shall we change only the methods which do not take a ratio parameter.

In fact if a method is having a ratio parameter, it seems has an infinite loop to remove sample from majority class to get the ratio and then the minority class to answer to the other request.

I see the possibility to implement this method for methods without the ratio parameter.

[dvro]

@glemaitre if the target class is not the minority class, the ratio would be ignored.