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

added log and log1p functions #225

Merged
merged 7 commits into from Jun 22, 2020
Merged

added log and log1p functions #225

merged 7 commits into from Jun 22, 2020

Conversation

StrikerRUS
Copy link
Member

log1p function is needed for #221.

I extracted this part into separate PR to not overcomplicate original one.

Custom implementations of log1p are based on

https://github.com/statgen/topmed_freeze3_calling/blob/master/vt/lib/Rmath/chebyshev.c
https://hackage.haskell.org/package/statistics-0.8.0.0/docs/src/Statistics-Math.html

Comment on lines +136 to +137
if self.logarithm_function_name is NotImplemented:
raise NotImplementedError("Logarithm function is not provided")
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, I didn't find anything that we could use as a fallback expression for LogExpr. All methods are based on reduction technique which requires frexp implementation.
Refer for example to https://golang.org/src/math/log.go

@coveralls
Copy link

coveralls commented May 26, 2020

Coverage Status

Coverage increased (+0.05%) to 94.758% when pulling a6d2046 on log_expr into 813d2e9 on master.

Copy link
Member

@izeigerman izeigerman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One small comment, looks fantastic otherwise 👍 I can't believe you ported the log1p function to all those languages 😮 Admire your dedication 💪

self.logarithm_function_name, nested_result)

def interpret_log1p_expr(self, expr, **kwargs):
self.with_math_module = True
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe we should set this flag only in case when we don't follow the fallback path. In case of the fallback we technically don't require the math module, although subsequent expressions that constitute the fallback expression may choose to enable it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't believe you ported the log1p function to all those languages

Thanks! Actually it was not so hard. All imperative languages are so similar! 😄

I believe we should set this flag only in case when we don't follow the fallback path.

Sorry, I'm not sure I fully understood you. Do you mean the following?

if self.log1p_function_name is NotImplemented:
            return self._do_interpret(
                fallback_expressions.log1p(expr.expr), **kwargs)
self.with_math_module = True

If so, it seems reasonable for me. But we should double check cases when fallbacks use functions from math module.

Anyway, I believe that this should be addressed in a separate PR because all other expressions follow the same pattern for now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this is exactly what I mean!

But we should double check cases when fallbacks use functions from math module.

Yep, but those functions will also be interpreted and the flag will be set accordingly if needed.

Anyway, I believe that this should be addressed in a separate PR because all other expressions follow the same pattern for now.

I'm fine with that. We may want to address this for other functions as well.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I created new issue for that to not forget: #246.

@izeigerman
Copy link
Member

@StrikerRUS I believe we now have to add __eq__ and __hash__ for new expressions before merging this PR, right?

@StrikerRUS
Copy link
Member Author

Thanks a lot for the reminder! Done in a6d2046.

@izeigerman izeigerman merged commit bc52cff into master Jun 22, 2020
@izeigerman izeigerman deleted the log_expr branch June 22, 2020 16:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants