# Float64 comparison operator performance

**URL:** <https://discourse.julialang.org/t/float64-comparison-operator-performance/29179>\
**Category:** Performance\
**Created:** [September 26, 2019, 12:58am UTC](https://discourse.julialang.org/t/float64-comparison-operator-performance/29179 "2019-09-26T00:58:06Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![milesf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/milesf/32/9289_2.png) [@milesf](https://discourse.julialang.org/u/milesf)\
**Post date:** [September 26, 2019, 7:01am UTC](https://discourse.julialang.org/t/float64-comparison-operator-performance/29179/5 "2019-09-26T07:01:54Z")

</div>

> [@Tamas\_Papp](#):
>
> Why do you need to go through those constructs? Most APIs which need a comparison operator allow you to provide one.

That’s a good question.

My understanding is that passing an ordering type seems to be more flexible than passing a comparison operator or function.

For example, lets say you have a custom struct, and you want to include some additional information about how to perform comparisons on these structs. These comparison rules might also change as the program is running.

You can easily include all of these comparison rules as data in a `Base.Ordering` struct. Here’s a [code snippet](https://discourse.julialang.org/t/structs-with-custom-ordering-in-a-heap/28753) describing that process.

The alternative is to convert this comparison rule data into a new comparison function each time the rules change. I can speculate on the downsides of this latter approach, but I haven’t tried it out yet. I assume `Base.Ordering` was provided as an alternative.

Maybe another reader could offer more concrete info about the origins and benefits of `Base.Ordering`.

---

_[View the full topic](https://discourse.julialang.org/t/float64-comparison-operator-performance/29179)._