Generic Vector with Cardinality Type Safety

Swift use value as generic

Swift does currently not support values as generics.

Generic Value Parameters is listed as "Maybe" in the generics manifesto.

You could use a code generator (like gyb, which Apple uses for the Swift Standard Library) to generate different sized matrix structures.

How to replace (or speed up) the parallel comparison when the number of pairs are extremely huge?

(This is not a complete answer. It only solves part of your problem; the part about bit manipulation.)

Here's a class you might be able to use to calculate the number of intersections between two sets (the cardinality of the intersection) rather quickly.

It uses a bit vector to store the sets, which means the universe of the possible set members must be small.

#include <cassert>
#include <vector>

class BitVector
{
    // IMPORTANT: U must be unsigned
    // IMPORTANT: use unsigned long long in 64-bit builds.
    typedef unsigned long U;
    static const unsigned UBits = 8 * sizeof(U);

public:
    BitVector (unsigned size)
        : m_bits ((size + UBits - 1) / UBits, 0)
        , m_size (size)
    {
    }

    void set (unsigned bit)
    {
        assert (bit < m_size);
        m_bits[bit / UBits] |= (U)1 << (bit % UBits);
    }

    void clear (unsigned bit)
    {
        assert (bit < m_size);
        m_bits[bit / UBits] &= ~((U)1 << (bit % UBits));
    }

    unsigned countIntersect (BitVector const & that) const
    {
        assert (m_size == that.m_size);

        unsigned ret = 0;
        for (std::vector<U>::const_iterator i = m_bits.cbegin(),
             j = that.m_bits.cbegin(), e = m_bits.cend(), f = that.m_bits.cend();
             i != e && j != f; ++i, ++j)
        {
            U x = *i & *j;

            // Count the number of 1 bits in x and add it to ret
            // There are much better ways than this,
            // e.g. using the POPCNT instruction or intrinsic
            while (x != 0)
            {
                ret += x & 1;
                x >>= 1;
            }
        }

        return ret;
    }

    unsigned countUnion (BitVector const & that) const
    {
        assert (m_size == that.m_size);

        unsigned ret = 0;
        for (std::vector<U>::const_iterator i = m_bits.cbegin(),
             j = that.m_bits.cbegin(), e = m_bits.cend(), f = that.m_bits.cend();
             i != e && j != f; ++i, ++j)
        {
            U x = *i | *j;

            while (x != 0)
            {
                ret += x & 1;
                x >>= 1;
            }
        }

        return ret;
    }

private:
    std::vector<U> m_bits;
    unsigned m_size;
};

And here's a very small test program to see how you can use the above class. It makes two sets (each with 100K maximum elements), adds some items to them (using the set() member function) and then calculate their intersection 1 billion times. It runs in under two seconds on my machine.

#include <iostream>

using namespace std;

int main ()
{
    unsigned const SetSize = 100000;
    BitVector a (SetSize), b (SetSize);

    for (unsigned i = 0; i < SetSize; i += 2) a.set (i);
    for (unsigned i = 0; i < SetSize; i += 3) b.set (i);
    
    unsigned x = a.countIntersect (b);
    cout << x << endl;

    return 0;
}

Don't forget to compile this with optimizations enabled! Otherwise it performs very badly.

POPCNT

Modern processors have an instruction to count the number of set bits in a word, called POPCNT. This is quite a lot faster than doing the naive thing written above (as a side note, there are faster ways to do it in software as well, but I didn't want to pollute the code.)

Anyways, the way to use POPCNT in C/C++ code is to use a compiler intrinsic or built-in. In MSVC, you can use __popcount() intrinsic that works on 32-bit integers. In GCC, you can use __builtin_popcountl() for 32-bit integers and __builtin_popcountll() for 64 bits. Be warned that these functions may not be available due to your compiler version, target architecture and/or compile switches.

IndexedSeq[Int] vs Array[Int]

There are, in general, two different styles of collection operation libraries:

type-preserving: that is what you are confused about in your question
generic (not in the "parametric polymorphism sense" but the standard English sense of the word) or maybe "homogeneous"

Type-preserving collection operations try to preserve the type exactly for operations like filter, take, drop, etc. that only take existing elements unmodified. For operations like map, it tries to find the closest super type that can still hold the result. E.g. mapping over an IntSet with a function from Int to String can obviously not result in an IntSet, but only in a Set. Mapping an IntSet to Boolean could be represented in a BitSet, but I know of no collections framework that is clever enough to actually do that.

Generic / homogeneous collection operations always return the same type. Usually, this type is chosen to be very general, to accommodate the widest range of use cases. For example, In .NET, collection operations return IEnumerable, in Java, they return Streams, in C++, they return iterators, in Ruby, they return arrays.

Until recently, it was only possible to implement type-preserving collection operations by duplicating all operations for all types. For example, the Smalltalk collections framework is type-preserving, and it does this by having every single collections class re-implement every single collections operation. This results in a lot of duplicated code and is a maintenance nightmare. (It is no coincidence that many new object-oriented abstractions that get invented have their first paper written about how it can be applied to the Smalltalk collections framework. See Traits: Composable Units of Behaviour for an example.)

To my knowledge, the Scala 2.8 re-design of the collections framework (see also this answer on SO) was the first time someone managed to create type-preserving collections operations while minimizing (though not eliminating) duplication. However, the Scala 2.8 collections framework was widely criticized as being overly complex, and it has required constant work over the last decade. In fact, it actually lead to a complete re-design of the Scala documentation system as well, just to be able to hide the very complex type signatures that the type-preserving operations require. But, this still wasn't enough, so the collections framework was completely thrown out and re-designed yet again in Scala 2.13. (And this re-design took several years.)

So, the simple answer to your question is this: Scala tries as much as possible to preserve the type of the collection.

In your second case, the type of the collection is Array, and when you map over an Array, you get back an Array.

In your first case, the type of the collection is Range. Now, a Range doesn't actually have elements, though. It only has a beginning and an end and a step, and it produces the elements on demand while you are iterating over it. So, it is not that easy to produce a new Range with the new elements. The map function would basically need to be able to "reverse engineer" your mapping function to figure out what the new beginning and end and step should be. (Which is equivalent to solving the Halting Problem, or in other words impossible.) And what if you do something like this:

val seq1: IndexedSeq[Int] = for (i <- 1 to 10) yield scala.util.Random.nextInt(i)

Here, there isn't even a well-defined step, so it is actually impossible to build a Range that does this.

So, clearly, mapping over a Range cannot return a Range. So, it does the next best thing: It returns the most precise super type of Range that can contain the mapped values. In this case, that happens to be IndexedSeq.

There is a wrinkle, in that type-preserving collections operations challenge what we consider to be part of the contract of certain operations. For example, most people would argue that the cardinality of a collection should be invariant under map, in other words, map should map each element to exactly one new element and thus map should never change the size of the collection. But, what about this code:

Set(1, 2, 3).map { _ % 2 == 0 }
//=> Set(true, false)

Here, you get back a collection with fewer elements from a map, which is only supposed to transform elements, not remove them. But, since we decided we want type-preserving collections, and a Set cannot have duplicate values, the two false values are actually the same value, so there is only one of them in the set.

[It could be argued that this actually only demonstrates that Sets aren't collections and shouldn't be treated as collections. Sets are predicates ("Is this element a member?") rather than collections ("Give me all your elements!")]

How to join (merge) data frames (inner, outer, left, right)

By using the merge function and its optional parameters:

Inner join: merge(df1, df2) will work for these examples because R automatically joins the frames by common variable names, but you would most likely want to specify merge(df1, df2, by = "CustomerId") to make sure that you were matching on only the fields you desired. You can also use the by.x and by.y parameters if the matching variables have different names in the different data frames.

Outer join: merge(x = df1, y = df2, by = "CustomerId", all = TRUE)

Left outer: merge(x = df1, y = df2, by = "CustomerId", all.x = TRUE)

Right outer: merge(x = df1, y = df2, by = "CustomerId", all.y = TRUE)

Cross join: merge(x = df1, y = df2, by = NULL)

~~Just as with the inner join, you would probably want to explicitly pass "CustomerId" to R as the matching variable.~~ I think it's almost always best to explicitly state the identifiers on which you want to merge; it's safer if the input data.frames change unexpectedly and easier to read later on.

You can merge on multiple columns by giving by a vector, e.g., by = c("CustomerId", "OrderId").

If the column names to merge on are not the same, you can specify, e.g., by.x = "CustomerId_in_df1", by.y = "CustomerId_in_df2" where CustomerId_in_df1 is the name of the column in the first data frame and CustomerId_in_df2 is the name of the column in the second data frame. (These can also be vectors if you need to merge on multiple columns.)

How to get the property data type in FileNet P8

This should give you an idea of what you need to do:

    //SymbolicName of the property we will search for.
    String strSearchName = PropertyNames.DATE_LAST_MODIFIED;
    //Document (or other object) that we will use to get classDescription.
    Document document = (Document) arg0; 

    PropertyDescription objPropDesc = null;
    PropertyDescriptionList pdl = document.get_ClassDescription().get_PropertyDescriptions();
    Iterator<?> iter = pdl.iterator();
    while (iter.hasNext())
    {                                               
        objPropDesc = (PropertyDescription) iter.next();                      

       // Get SymbolicName property from the property cache
       String strPropDescSymbolicName = objPropDesc.get_SymbolicName();

       if (strPropDescSymbolicName.equalsIgnoreCase(strSearchName))
       {
          // PropertyDescription object found
          System.out.println("Property description selected: " + strPropDescSymbolicName);
          System.out.println(objPropDesc);

          TypeID type = objPropDesc.get_DataType();
          System.out.println(type.toString());
          break;
       }
    }

The idea is to:

Take an object (Document in this case).
Get its Class Description.
Get the list of Property Descriptions from the Class Description.
Loop through the Property Descritpions until you locate the Description you are trying to find.
Get the TypeId from the Property Description.
The TypeId contains the information you need to know what the Type is of the Property.

I borrowed code from here : Working with Properties

You should also familiarize yourself with this : Properties

Edit to add a different method:

In the case of creating documents, we need to be able to obtain the Class Description object. This means we will need to perform additional round trips.

// Get the ClassDescription
String strSymbolicName = "myClassName";
ClassDescription objClassDesc = Factory.ClassDescription.fetchInstance(myObjStore, strSymbolicName, null);

// find the PropertyDescription     
PropertyDescription pds = null;
PropertyDescriptionList pdl = objClassDesc.get_PropertyDescriptions()‌;
Iterator<?> itr = pdl.iterator();
while(itr.hasNext()){ 
    pds = (PropertyDescription) itr.next();
    System.out.println("Symbolic Name is "+pds.get_SymbolicName()+" DataType is "+pds.get_DataType().toString()); 
}

// You can now use it in a loop of several documents if you wish.
...

Take a look here as well : Working With Classes

How to filter a listview with and edit box - Android

On Android you don't need a editbox to make that happen. And it's not advised to do so.

Instead just implement Filterable for your Custom Adaptor, and once the user will type in something while views the list it will filter. The onscreen keyboard as usual comes up with holding Menu

Here is a tutorial that has code to implement Filterable

Obtaining a powerset of a set in Java

Yes, it is O(2^n) indeed, since you need to generate, well, 2^n possible combinations. Here's a working implementation, using generics and sets:

public static <T> Set<Set<T>> powerSet(Set<T> originalSet) {
    Set<Set<T>> sets = new HashSet<Set<T>>();
    if (originalSet.isEmpty()) {
        sets.add(new HashSet<T>());
        return sets;
    }
    List<T> list = new ArrayList<T>(originalSet);
    T head = list.get(0);
    Set<T> rest = new HashSet<T>(list.subList(1, list.size())); 
    for (Set<T> set : powerSet(rest)) {
        Set<T> newSet = new HashSet<T>();
        newSet.add(head);
        newSet.addAll(set);
        sets.add(newSet);
        sets.add(set);
    }       
    return sets;
}

And a test, given your example input:

 Set<Integer> mySet = new HashSet<Integer>();
 mySet.add(1);
 mySet.add(2);
 mySet.add(3);
 for (Set<Integer> s : SetUtils.powerSet(mySet)) {
     System.out.println(s);
 }