Request for Comments: Filter behavior on undefined values
Hello all! There are many cases when the filter reads an undefined route attribute. We have several variants how to behave then, all of them have their pros and cons. The current behavior is inconsistent and sometimes strange. Variants we thought about when an undefined attribute is to be read: 1 the filter fails with an error. 2 the value is set to default (zero or whatever) and then used 3 it is propagated as undefined until any comparison/match happens, then the comparison/match is always false What can happen then? We thought about several use cases. Let's assume there is a route without the ospf_metric1 attribute. A (in config) import where ospf_metric1 > 10; B (in config) import where ! (ospf_metric1 > 10); C (in config) import where check(); function check() { if ospf_metric1 > 10 then { return true; } else { return false; } }; D (in config) function update() { if defined(ospf_metric1) then { return; } if ospf_metric1 > 10 then { bgp_path.append(myasn); bgp_path.append(myasn); } } E (in cli) show route where ospf_metric1 > 10 F (in cli) show route where ! (ospf_metric1 > 10) We think generally that: Variant 1 may work in config as the admin shall write the filters correctly but it is too strict when it comes to CLI ad-hoc filters. Variant 2 is used now for BGP communities lists where the default is empty list. In other cases, the behavior is undefined. It is convenient as far as the default fits your purposes. Then it becomes almost the same as variant 1. Variant 3 is simple and convenient until you negate the condition. Note that the following two lines would do different things: where bgp_med != 201 where !(bgp_med = 201) We do not know which variant of filters behaviour is the best. We'd like you to think about your use cases for Bird's filters and contribute to this thread with your opinion. Also feel free to suggest other behavior variants if you think out some. Thank you! Maria
Hello!
Variants we thought about when an undefined attribute is to be read:
1 the filter fails with an error. 2 the value is set to default (zero or whatever) and then used 3 it is propagated as undefined until any comparison/match happens, then the comparison/match is always false
In the Sherlock Holmes search engine, we used a different solution, which could be applicable to BIRD filters, too. We added an undefined value to all types, including the boolean type. This leads to trivial tri-state logic, which can be modelled in this way: 1=true, -1=false, 0=undefined; AND is MIN, OR is MAX. Arithmetic operators with at least one undefined input yield undefined output. Relational operators with at least one undefined input yield an undefined boolean. Functions can handle undefined values as they wish. This is similar in spirit with your variant 3, but in particular it avoids the paradoxes with negations. Martin
On Tue, Jan 09, 2018 at 06:42:23PM +0100, Martin Mares wrote:
Hello!
Variants we thought about when an undefined attribute is to be read:
1 the filter fails with an error. 2 the value is set to default (zero or whatever) and then used 3 it is propagated as undefined until any comparison/match happens, then the comparison/match is always false
In the Sherlock Holmes search engine, we used a different solution, which could be applicable to BIRD filters, too.
We added an undefined value to all types, including the boolean type. This leads to trivial tri-state logic, which can be modelled in this way: 1=true, -1=false, 0=undefined; AND is MIN, OR is MAX. Arithmetic operators with at least one undefined input yield undefined output. Relational operators with at least one undefined input yield an undefined boolean. Functions can handle undefined values as they wish.
Hello Thanks for suggestion, this seems like an elegant solution. Assuming NOT is NEG and conditionals fail for non-true. Note that this is not Boolean algebra (as law of excluded middle is not satisfied), but De Morgan algebra, so perhaps we could also rename boolean datatype to de_morgan datatype ;-) . -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hello!
Assuming NOT is NEG [...]
Yes.
[...] and conditionals fail for non-true.
In Sherlock, we had three-way conditionals: if the condition was undefined, neither the "then" nor "else" branch was executed, but there could be an additional "undefined" branch. In retrospect, this probably wasn't a good idea, although it followed the three-way logic better.
Note that this is not Boolean algebra (as law of excluded middle is not satisfied), but De Morgan algebra, so perhaps we could also rename boolean datatype to de_morgan datatype ;-) .
;-) Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Homo homini lupus, frater fratri lupior, bohemus bohemo lupissimus.
participants (3)
-
Jan Maria Matejka -
Martin Mares -
Ondrej Zajicek