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

No need to write robust_pow function? #7

Open
thedjofsis opened this issue Jan 21, 2020 · 2 comments
Open

No need to write robust_pow function? #7

thedjofsis opened this issue Jan 21, 2020 · 2 comments
Assignees
Labels
bug Something isn't working

Comments

@thedjofsis
Copy link

Hello.
Firstly, the two variables used as g2 and g5 are the same. So I think the mathematical equations can be represented in 4 variables instead of 5 and so can be used in the code. As per the code here
g2 = label + ((-1) ** label) * sigmoid_pred
g5 = label + ((-1) ** label) * sigmoid_pred
Also, the only term being used when calling the function robust_pow to calculate the exponent for, is the g2 (or g5) and that value can never be negative. Here there are two cases, either the label is 0 or 1.
In case of 0, g2 becomes sigmoid_pred with range 0 to 1.
In case of 1, g2 becomes 1-sigmoid_pred with the range 1 to 0.
So I don't see the point of having a separate function than using the normal exponent operator of **. In case I'm wrong, please correct me.

@thedjofsis
Copy link
Author

Also robust_pow function is not exactly correct. I am wondering how does it change the calculations because as per this code, (-16)0.25 will be -2. But -24 is 16. And in case this is needed in fact, how about using the answer here ?

@jhwjhw0123 jhwjhw0123 self-assigned this Mar 18, 2020
@jhwjhw0123 jhwjhw0123 added the bug Something isn't working label Mar 18, 2020
@jhwjhw0123
Copy link
Owner

Hi, thanks for the comments. After checking the codes, I believe the robust_pow is the legacy of a previous (scrap) version with the wrong math derivation. That results in a (wrong) procedure which will incur (a negative number) ** (a fraction number).
In terms of the implementation of the focal loss, this shouldn't have any effect -- as you said g_{2} can only be [0,1]. I'll fix this in a later version. As for now, the performance of the software should be ok.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants