Github user asfgit closed the pull request at:
https://github.com/apache/metron/pull/693
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
Github user ottobackwards commented on a diff in the pull request:
https://github.com/apache/metron/pull/667#discussion_r133273527
--- Diff:
metron-stellar/stellar-common/src/main/java/org/apache/metron/stellar/dsl/functions/TextFunctions.java
---
@@ -0,0 +1,95 @@
+/**
+
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/681
Yeah, it's true, I suppose having `==` double as a `NaN` check is probably
not the right thing due to the transitivity of equality (I'd like to `SQRT(-1)
== NaN` to be `true` but `SQRT(-1) ==
Github user nickwallen commented on a diff in the pull request:
https://github.com/apache/metron/pull/667#discussion_r133258977
--- Diff:
metron-stellar/stellar-common/src/main/java/org/apache/metron/stellar/dsl/functions/TextFunctions.java
---
@@ -0,0 +1,95 @@
+/**
+ *
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/681
Thanks for clarifying @mattf-horton . That makes sense now that I've had
lunch.
Based on the original use case of detecting a function returning NaN, it
seems what we really need is
Github user mattf-horton commented on the issue:
https://github.com/apache/metron/pull/681
@ottobackwards , the validator for IS_NAN(x) in Java would be
Double.isNaN(double x).
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as
Github user mattf-horton commented on the issue:
https://github.com/apache/metron/pull/681
BTW, +/- Infinity **are** considered "real" values (essentially as tho via
rounding) and can be compared with equality and inequality. NaN is considered
a nonsensical or
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/686
@cestella do you have any inputs to the questions posed in the pr
description?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well.
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/681
We are not 'doing' the math here. What we are doing is introducing the
ability to use NaN in an expression correctly. Java is doing the math. The
tests are to verify that through stellar,
Github user ottobackwards commented on a diff in the pull request:
https://github.com/apache/metron/pull/667#discussion_r133247450
--- Diff: metron-stellar/stellar-common/README.md ---
@@ -411,6 +412,14 @@ In the core language functions, we support basic
functional programming
Github user mmiklavc commented on the issue:
https://github.com/apache/metron/pull/697
+1 by inspection. Thanks for the fix and for tweaking that @merrimanr
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/681
Based on the link that you embedded in the tests, your implementation seems
correct. I assume that these grammar rules are well reasoned and necessary,
but it surely seems counter-intuitive to
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/681
I see in the unit tests that @ottobackwards intended that any equality with
`NaN` to be false. But then how is that useful for the basic use case of
`FUNCTION(x) != NaN`?
```
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/681
Ok, that makes sense to me. `FUNCTION(x) != NaN`
The code changes look good to me @ottobackwards. I am going to pull it
down and play with NaN in the REPL just as a sanity check.
---
Github user nickwallen commented on a diff in the pull request:
https://github.com/apache/metron/pull/667#discussion_r133211499
--- Diff:
metron-stellar/stellar-common/src/main/java/org/apache/metron/stellar/dsl/functions/TextFunctions.java
---
@@ -0,0 +1,63 @@
+/**
+ *
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/686
+1 by inspection, this is good work!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/667
I'm fine with this so far, but will hold for @nickwallen 's +1. :)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project
Github user asfgit closed the pull request at:
https://github.com/apache/metron/pull/695
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/681
Just thinking, we might want +Infinity and -Infinity too as they're part of
the floating point standard.
---
If your project is set up for it, you can reply to this email and have your
reply
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/681
Some of our math functions return `NaN` (e.g. `SQRT(-1)`) and being able to
do `!= NaN` is a useful thing.
---
If your project is set up for it, you can reply to this email and have your
reply
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/696
+1 by inspection
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so,
21 matches
Mail list logo
