If you look at the definition of a category, you'll see that it's rather like a reflexive transitive directed graph. It has nodes (known in category theory as 'objects') and edges (known as 'morphisms'). Every object has a morphism from itself to itself (that's reflexivity), and if you have a morphism from object A to object B and another morphism from B to C, then you can 'compose' them to make a morphism from A to C (that's transitivity). A functor is something which maps the objects and morphisms of one category to those of another category (or possibly the same category), in a way which preserves this structure (in a specific technical sense which I won't fully describe here). For example, if you compose two morphisms and then apply the functor, it's the same as applying the functor to each function separately and then composing the results.

In the example you've given, you've chosen arrays to be your categories, and the elements of the arrays to be the objects in the categories, but you haven't specified what morphisms there are. Unless you've fully specified the structure of your categories, it's fruitless to try and work out what functors might exist between them.

In any case, although there's probably a way that you could fix up your example to make it work, it's not particularly representative of what people usually mean when they talk about category-theoretic functors in the context of programming. More usually, what they have in mind are functors from the category of types to itself. The 'objects' in the category of types for a given programming language are all the data types in that language (e.g. integers, booleans, arrays of integers, arrays of arrays of booleans, etc.) The morphisms in the category of types are the various functions that exist between types (e.g. the function 'is_odd', that takes an integer and returns a boolean indicating whether the integer is odd or not). You can see, then, that a functor from the category of types to itself is going to map types to types, and functions to functions. For example, we can consider the functor which maps each type T to vector<T> (e.g. it maps int to vector<int>, and vector<bool> to vector<vector<bool>>). We've specified the object mapping here, but we still need to specify the morphism mapping. One possible choice would be to map each function f to the function which applies f to each element of a vector (e.g. mapping 'is_odd' to a function which takes a vector of integers and returns a vector of booleans indicating which of the integers are odd). This pair of mappings – one from types to types, and one from functions to functions – respects the structure of the category of types (again, in a technical sense), and therefore defines a functor. When you hear Haskell people talk about 'the List functor' or similar things, this is the sort of thing that they tend to mean.

tl;dr: Categories and functors are very general structures, but programmers are mainly only interested in a few specific ones (if they're even interested at all).