Tpetra: FixedHashTable says it has one pair when default initialized - expecting zero

[romintomasetti]

Description

@tpetra

When default-initializing Tpetra::Details::FixedHashTable, the numPairs method returns 1. I think it should return 0.

Here is a minimal example:

TEST(FixedHashTable, num_pairs_when_default_initialized)
{
    using fixed_hash_table_t = Tpetra::Details::FixedHashTable<int, int, Kokkos::Serial>;

    fixed_hash_table_t table {};

    ASSERT_EQ(table.numPairs(), 1); // I would expect 0 here
}

The culprit is:

Trilinos/packages/tpetra/core/src/Tpetra_Details_FixedHashTable_decl.hpp

Lines 324 to 331 in 1c10ee0

	KOKKOS_INLINE_FUNCTION offset_type numPairs () const {
	// NOTE (mfh 26 May 2015) Using val_.extent(0) only works
	// because the table stores pairs with duplicate keys separately.
	// If the table didn't do that, we would have to keep a separate
	// numPairs_ field (remembering the size of the input array of
	// keys).
	if (this->hasContiguousValues ()) {
	return val_.extent (0) + static_cast<offset_type> (lastContigKey_ - firstContigKey_);

because when default initialized, FixedHashTable::hasContiguousValues() returns true, lastContigKey_ = ::Kokkos::ArithTraits<int>::min() and firstContigKey_ = ::Kokkos::ArithTraits<int>::max().

Note that I can workaround the problem by constructing the table with a default-initialized view of keys:

fixed_hash_table_t table( typename fixed_hash_table_t::keys_type {} );

[csiefer2]

That looks... not right. Will look at a fix for that once the AT has cleared out the current mess.

[csiefer2]

PR posted. @romintomasetti That look good?