# Speculation chained comparison optimization (possibly with outlining)

**URL:** <https://discourse.julialang.org/t/speculation-chained-comparison-optimization-possibly-with-outlining/1354>\
**Category:** Offtopic\
**Created:** [January 8, 2017, 5:09pm UTC](https://discourse.julialang.org/t/speculation-chained-comparison-optimization-possibly-with-outlining/1354 "2017-01-08T17:09:06Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [January 8, 2017, 3:55pm UTC](https://discourse.julialang.org/t/speculation-chained-comparison-optimization-possibly-with-outlining/1354/2 "2017-01-08T15:55:03Z")

</div>

> [@A != b != c](https://discourse.julialang.org/t/a-b-c/1347/4):
>
> point is that \< is an arbitrary user-defined function,[…]
> 
> The a \< b \< c implementation does not compare a \< c, it only compares a \< b and b \< c.

Some future Julia implementation could check a \< c first (and probably a better strategy for speed). [I guess you’re saying the current 0.5 or 0.6 doesn’t] but while not done now, not ruled out in the future(?).

Comparison chaining for: a op b op c … is not defined for any possibly op-function, right, only a limited set e.g. \<, \<=, \> etc. all functions that are transitive (and also defined as operators).

Limiting those functions to only transitive is a good idea, but can it (is?) be enforced? If not either the optimized can’t use the default, or it must figure out if had been overloaded and block optimizations otherwise. I’m not sure I would trust a compiler to be that brainy.

Since I’m here,

> **[Short-circuit evaluation](https://en.wikipedia.org/wiki/Short-circuit_evaluation)**
>
> Short-circuit evaluation, minimal evaluation, or McCarthy evaluation (after John McCarthy) is the semantics of some Boolean operators in some programming languages in which the second argument is executed or evaluated only if the first argument does not suffice to determine the value of the expression: when the first argument of the AND function evaluates to false, the overall value must be false; and when the first argument of the OR function evaluates to true, the overall value must be true.
> I...

Footnote 2. on C++ (seemed insane), then I noticed 4. [Do you know the story behind it? Early versions of Fortran with eager, then short-circuit adopted from Lisp? Or is eager allowed (for old compatibility) but other allowed (considered a superset?); either used in the same compiler of different code parts?!]:

1. When overloaded, the operators && and || are eager and can return any type.  
[…]
2. Fortran operators are neither short-circuit nor eager: the  
language specification allows the compiler to select the method for  
optimization.

---

_[View the full topic](https://discourse.julialang.org/t/speculation-chained-comparison-optimization-possibly-with-outlining/1354)._