alglib::heap::min_heap< elt_t, key_t > Class Template Referenceabstract

#include <heap.h>

Inheritance diagram for alglib::heap::min_heap< elt_t, key_t >:
alglib::heap::binary_heap< elt_t, key_t >

Public Member Functions

virtual void insert (const elt_t &elt, const key_t &key)=0
 
virtual const elt_t & get_min_elt () const =0
 
virtual const key_t & get_min_key () const =0
 
virtual void delete_min ()=0
 
virtual void replace (const elt_t &elt, const key_t &key)=0
 
virtual int size () const =0
 
virtual bool empty () const =0
 
virtual void update_key (const elt_t &elt, const key_t &key)=0
 

Detailed Description

template<typename elt_t, typename key_t>
class alglib::heap::min_heap< elt_t, key_t >

Abstract class for a heap Any heap must conform to this interface

There are two types of ordering of the type elt_t - natural ordering and priority ordering. The operator< defines the natural ordering and the keys associated with the elements define the priority ordering. The former ordering is defined by the class and the latter by the client of this library. The natural ordering is used to establish the equality of two elements. If none of the two elements is greater than the other, then they are equal. Hence, the min_heap class is configurable with different schemes of priority ordering by supplying corresponding keys. In case, none is supplied, the ordering chosen by the min_heap defaults to natural ordering.

The reason of having another variable key for ordering the elements is to decouple the scheme of ordering from the object itself. If we use operator< of elt's class, it would be far too restrictive. It would allow only one type of ordering - the one defined by the class. In many situations, that may not be the scheme we require. Worse still, it precludes any non-comparable item from being used to make a min-heap. To make this more concrete, consider a use-case in which a shopkeeper services the requests of his customers. The customers are of Person type that doesn't have any total-ordering relation. The shopkeeper, however, can have different schemes of prioritizing his customers, some of them are - Prioritize the shop's investor. Prioritize senior citizens. Prioritize acquaintances ... and so on. The essence of this methodology is that the criterion of ordering should be specified by the min_heap user, not by the class.

Why not use a functor? Using a functor can potentially lead to inconsistency of the heap. Since by allowing the user to supply a user-defined functor, we allow him to change the priority order arbitrarily and as many times as the user wishes, but the heap requires that every change be followed by a sift up or a sift down.

Member Function Documentation

template<typename elt_t, typename key_t>
virtual void alglib::heap::min_heap< elt_t, key_t >::delete_min ( )
pure virtual
template<typename elt_t, typename key_t>
virtual bool alglib::heap::min_heap< elt_t, key_t >::empty ( ) const
pure virtual
template<typename elt_t, typename key_t>
virtual const elt_t& alglib::heap::min_heap< elt_t, key_t >::get_min_elt ( ) const
pure virtual
template<typename elt_t, typename key_t>
virtual const key_t& alglib::heap::min_heap< elt_t, key_t >::get_min_key ( ) const
pure virtual
template<typename elt_t, typename key_t>
virtual void alglib::heap::min_heap< elt_t, key_t >::insert ( const elt_t &  elt,
const key_t &  key 
)
pure virtual
template<typename elt_t, typename key_t>
virtual void alglib::heap::min_heap< elt_t, key_t >::replace ( const elt_t &  elt,
const key_t &  key 
)
pure virtual
template<typename elt_t, typename key_t>
virtual int alglib::heap::min_heap< elt_t, key_t >::size ( ) const
pure virtual
template<typename elt_t, typename key_t>
virtual void alglib::heap::min_heap< elt_t, key_t >::update_key ( const elt_t &  elt,
const key_t &  key 
)
pure virtual

The documentation for this class was generated from the following file: