-
Notifications
You must be signed in to change notification settings - Fork 7
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
Add tracing for head arithmetic #374
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not confident that evaluating everything as f64
is the correct thing to do here.
nemo/src/model/rule_model/term.rs
Outdated
@@ -367,6 +375,58 @@ impl Term { | |||
Term::Function(sub) => sub.subterms.iter().any(Self::aggregate_subterm_recursive), | |||
} | |||
} | |||
|
|||
/// Evaluates a constant (numeric) term | |||
/// We do this by casting everything to `f64` as it seems like the most general number type. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's really not, for example, 9007199254740992.0 + 1.0 == 9007199254740992.0
holds for f64
, but surely not for i64
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could add something like https://crates.io/crates/bigdecimal for "compile time" arithmetic.
Maybe not for this PR though as this as this is a feature that is needs to demonstrated next week and its good enough
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It turns out I had the type information there all along and its not too complicated to use the evaluation code from the physical layer for the evaluation here
nemo/src/model/rule_model/term.rs
Outdated
BinaryOperation::Addition(_, _) => Some(value_left + value_right), | ||
BinaryOperation::Subtraction(_, _) => Some(value_left - value_right), | ||
BinaryOperation::Multiplication(_, _) => Some(value_left * value_right), | ||
BinaryOperation::Division(_, _) => Some(value_left / value_right), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if value_left = value_right = 0
, this will produce a Double
holding a NaN
, which shouldn't happen, and since we currently only have checks for NaN
in the Double
constructors, this will just lead to weird behaviour later on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, I could do the checked_
versions for all the operations here
…t expressions during tracing
Allows tracing for rules that compute new values in the head. For example: