Add logical operators to the library

[EgorBron]

Hey there,
I’ve been playing around with your library—really cool work! While testing it out, I noticed there’s no built-in support for logical operations like NOT, AND, OR, EQUALS, and so on. I figured these might be useful in some cases, so I put together a PR that adds basic support for them as functions.

Would love to hear your thoughts—do you think this is something that fits the library’s scope? I'm also happy to adjust or improve anything you'd like.

[notKamui]

That is indeed within the scope of this library.

In fact, you could make those as part of the DEFAULT_OPERATORS (don't forget to define ! with KevalBothOperator, if kept at all)

Although, I'm not too sure about them being operators, I would prefer them to only be functions. Currently, as you know, there is a limitation in operator names: they can only be one character (i kind of regret this, and now that i changed the grammar, it should theoretically be possible to have operators with more than one character), anyway; this leads to inconsistent operators like = not having its counterpart !=.

Also, because they do kind of go outside of algebraic maths, functions seem better suited to me. If the user still wants operators, its not too hard to add by themselves.

Final reason is linked to #54 : ambiguity with bindings with =

[notKamui]

• make the logical set part of the default set of resources
• only use functions

[EgorBron]

Thanks for your review! Now I think that using only functions is clearer and better than defining corresponding operators, even if we would to define them in way with multiple characters.

But I have one question before I will fix the things you highlighted: should we limit ourselves to using short names for functions (e.g., eq, gt) or should we also adopt longer, more descriptive names—or perhaps both?

[notKamui]

But I have one question before I will fix the things you highlighted: should we limit ourselves to using short names for functions (e.g., eq, gt) or should we also adopt longer, more descriptive names—or perhaps both?

Hi ! I would generally advise against abbreviations, but I feel in this case they're so within well-known standards that it is acceptable. As whether to keep both or not, I think only the abbreviations will suffice.

so

eq, ne, gt, ge, lt, le, not, or, and, nor, xor, and finally, xnor and nand for completeness

[EgorBron]

As whether to keep both or not, I think only the abbreviations will suffice.

Got you, I’ll keep only the abbreviated names.

and finally, xnor and nand for completeness

Ah, right! Will add them too, with also implication (IMPLY) and nonimplication (NIMPLY).

Note just for myself: logical operations on regular numbers is an interesting case in here. E.g., the XNOR operation, is also known as *logical equality*, which evaluates to "either both numbers are zeros or not equal to zero".

[EgorBron]

I’m also gonna make all of these functions variadic (except comparisons for greater/lower and for implications), just in case. If the resulting overhead of processing DoubleArrays to compute results of operations is not what we need, let me know!

[EgorBron]

Everything seems done, now awaiting for your review!

P.S. I’ll leave the README editing to you.

[notKamui]

Great PR, thank you very much for your time and help ! Will publish ASAP (I hope Maven Central didnt change too much since the last publish 🥲)