Proposal - Arithmetic Operators #21
Replies: 6 comments 20 replies
-
Self Happy to try to account for community feedback. |
Beta Was this translation helpful? Give feedback.
-
Should we consider covering test cases for null and other extreme cases [
{
"description": "Addition with null values",
"rule": { "+": [null, 1, null] },
"result": 1,
"data": null
},
{
"description": "Addition with empty string",
"rule": { "+": ["", 1] },
"result": 1,
"data": null
},
{
"description": "Addition with non-numeric strings",
"rule": { "+": ["abc", 1] },
"result": 1,
"data": null
},
{
"description": "Addition with undefined/missing values",
"rule": { "+": [{"var": "missing"}, 1] },
"result": 1,
"data": {}
},
{
"description": "Addition with arrays",
"rule": { "+": [[1,2], 3] },
"result": 3,
"data": null
},
{
"description": "Addition with objects",
"rule": { "+": [{"foo": "bar"}, 1] },
"result": 1,
"data": null
}
] |
Beta Was this translation helpful? Give feedback.
-
It's my impression that a lot/most of the JSON Logic operators are “implied |
Beta Was this translation helpful? Give feedback.
-
Could you please highlight any differences between this proposal and what's currently defined in JSON Logic? The proposal makes sense, so I'll give it a |
Beta Was this translation helpful? Give feedback.
-
Perhaps I've missed it, but I feel like type coercion should be a discussion on its own. Especially when considering future equality operators. I personally would like to avoid coercion as much as possible, since I feel like their use case is rare, easily solved with explicit conversions and that implicit coercion is error prone for users. Additionally, when defining string parsing (preferably explicitly), I think it would be better to accept any valid json number as string (e.g. including scientific notation). |
Beta Was this translation helpful? Give feedback.
-
@json-logic/tc Calling for a revote, I've amended this to include error boundaries to answer https://github.com/orgs/json-logic/discussions/21#discussioncomment-11871756 I'm giving this a self +1. (For non-TC members, I'm going to assume the error boundaries did not change the vote unless otherwise announced... based on convos I've had) Current Votes
|
Beta Was this translation helpful? Give feedback.
-
Background
JSON Logic includes various arithmetic operators, namely:
+
,-
,/
,*
and%
.This proposal seeks to evaluate these operators and tests to recognize them in JSON Logic Core.
Proposal
As decided in a previous proposal, these operators are being defined with agnostic precision and from a pure mathematical perspective.
These operators are expected to coerce booleans and strings into numeric values.
+
-
*
/
%
Default unary behavior is just to return the argument coerced into a number.
The coercion behavior being defined at this time is the following:
string
is parsed as a JSON Number (e.g.1
,1.23
,1e5
should be valid). Empty string becomes 0.true
becomes 1false
becomes 0null
becomes 0There are two changes from mainline json-logic:
/
and%
follow the default unary behavior, injson-logic-js
{ "/": [1] }
returnedNaN
, I think it can make sense for them to return the first operand, especially since*
already worked this way./
and%
also support variadic functionality, for consistency.For the purposes of tests, I am not distinguishing between
-0
and0
to try to remain precision / implementation agnostic.-0
does not seem purely mathematical.These operators are variadic, with an implied foldLeft behavior.
{ "+": [1, 2, 3] }
is1 + 2 + 3
.Controversial: I am marking the tests that use fractional numbers with a
"decimal": true
property. The original JSON Logictests.json
did have a division test that resulted in a fractional number. Normally I'd omit it, but I'll carry the test for it forward as it is relatively precision agnostic, and we are aiming to honor the originaltests.json
.If someone chose to implement an integer-based version of JSON Logic Core, they can decide how they want to handle those tests (like truncating).
For our purposes, it changes nothing; it's just an annotation.
Tests
+
Operator-
Operator*
Operator/
Operator%
OperatorBeta Was this translation helpful? Give feedback.
All reactions