For each group in your data table, your code computes the coefficient b1 from a linear regression y = b0 + b1*x + epsilon, and you want to run this regression and obtain b1 for observations 1-12, 2-13, 3-14, ..., 989-1000. Right now you are separately calling lm for each data subset, which is a non-vectorized approach.

Vectorization of prediction models across datasets is in general not straightforward, but for the special case you have here (simple linear regression) is it possible because there is a simple closed-form expression for b1, the coefficient of interest. In particular, for given vectors x and y we have b1 = (mean(x*y) - mean(x)*mean(y)) / (mean(x^2) - mean(x)^2). The rolling coefficient value can therefore be computed using the rolling means of x*y, x, y, and x^2 with the appropriate window width.

The end result is a fully vectorized version of the code (I use the RcppRoll package to obtain rolling means):

library(RcppRoll)
rolling2 <- function(DT, window.length) {
  setNames(lapply(unique(DT$key.group), function(g) {
    regressed.DT <- DT[key.group == g]
    xyBar = roll_mean(regressed.DT$X*regressed.DT$Y, window.length)
    xBar = roll_mean(regressed.DT$X, window.length)
    yBar = roll_mean(regressed.DT$Y, window.length)
    x2Bar = roll_mean(regressed.DT$X^2, window.length)
    c(rep(NA, window.length-1), (xyBar - xBar*yBar) / (x2Bar - xBar^2))
  }), unique(DT$key.group))
}

We can confirm that this yields identical results to the code from the original post about 3 orders of magnitude more quickly:

set.seed(144)
DT <- data.table(   Y = rnorm(10000),
                    X = rnorm(10000),
                    key.group = rep(LETTERS[1:10], each = 1000))
system.time(X.coef <- run.rolling.regressions(DT, 12))
#    user  system elapsed
#  13.321   0.098  13.504
system.time(X.coef2 <- rolling2(DT, 12))
#    user  system elapsed
#   0.010   0.000   0.011
all.equal(X.coef, X.coef2)
# [1] TRUE

Note that I slightly modified the provided run.rolling.regressions function to take DT and window.length as input and to not print progress updates; I think it makes sense to separate the generation of the dataset from the function that computes the rolling means, and down the road it might be useful to have the window length as an adjustable argument instead of a fixed value.


I think you're thinking of this backwards. The point isn't that you need to define special subclasses to use the factory method. Rather, when you need to define special subclasses containing their own complex functionality, then you use the factory method.
From the Gang of Four:

Use the Factory Method pattern when a class can't anticipate the class of objects it must create, [or it] wants its subclasses to specify the classes it creates [...].

I think part of the problem is that your own example is a bit confusing. Interfaces are more for defining things different objects can do. You'll often hear people describe an interface as a sort of contract, because any object that implements an interface is required to implement every function of that interface. A Car would be more logically defined as a class because an Audi and a BMW are a type of car. On the other hand, it might make sense to define a Drivable interface, implemented by an abstract Vehicle class.
interface Drivable
{
    public function drive();
}

You could then define abstract base classes for each of the generic base object classes that implement this interface.
abstract class Vehicle implements Drivable
{
    abstract public function drive();
}

Once you do that, then you can implement functionality for each object.
abstract class Car extends Vehicle
{
    abstract public function drive();
}

class Audi extends Car
{
    public function drive()
    {
        //...
    }
}

abstract class Aircraft extends Vehicle
{
    abstract public function drive();
}

class Airbus extends Aircraft
{
    public function drive()
    {
        // ...
    }
}

Keeping with the literal nature of your example, think about how different an aircraft factory and a car factory are. They're both factories that make vehicles, sure, (which is why their respective factories could -and probably would- be derived from the same base abstract VehicleFactory class) but the process of building an aircraft is so different from that of building a car that you have to define special factory subclasses for each of them.
Getting more specific, let's focus on why and when you would use a factory. Suppose you're writing a game where a player can purchase a car. How do you know which car to instantiate until the user picks it?
A simple script might do something like this.
$car = null;

switch ($choice) {
    case 'BMW': {
        $car = new BMW();
    } break;

    case 'Audi': {
        $car = new Audi();
    } break;

    ...
}

$car->drive();

This is all the factory pattern is. The difference is that an actual factory class gives you several benefits that this simple script doesn't.
First of all, consider a CarFactory class that replicates the above script's functionality.
class CarFactory
{
    public static function create($car) : Car
    {
        switch ($car)
        {
            case 'BMW': return new BMW();
            case 'Audi': return new Audi();
            // ...
        }
    }
}

$car = CarFactory::create($choice);
$car->drive();

Right off the bat, you don't need null as the sentinel value for "the user hasn't picked a car yet." The car doesn't exist yet, so the car variable doesn't exist yet.
Second, a script can't inherit or be derived from anything; it just is. In contrast, if you wanted your player to also be able to purchase an Aircraft, or any kind of transport derived from the Vehicle class, you can define a base VehicleFactory class from which you can implement your CarFactory and AircraftFactory classes.
interface Build
{
    public static function build($choice);
}

abstract class VehicleFactory implements Build
{
    abstract public static function build($choice) : Vehicle;
}

class AircraftFactory extends VehicleFactory
{
    public static function build($aircraft) : Aircraft
    {
        switch ($aircraft)
        {
            case 'Airbus': return new Airbus();
            case 'Boeing': return new Boeing();
            // ...
        }
    }
}

class CarFactory extends VehicleFactory
{
    public static function build($car) : Car
    {
        switch ($car)
        {
            case 'BMW': return new BMW();
            case 'Audi': return new Audi();
            // ...
        }
    }
}

$aircraft = AircraftFactory::build($choice);
$aircraft->drive();

$car = CarFactory::build($choice);
$car->drive();

Hopefully this gives you an idea of why the factory pattern is useful. The upshot is that your base factory class defines the interface by which users will request an object be created, and the factory subclasses take care of the actual definition for how it happens. In addition, defining each factory's return type in terms of a base object (i.e..., the CarFactory returns a Car) allows us to choose the actual subclass of that object that actually gets created at runtime (users can pick a BMW or an Audi, both of which are Cars, all of which are Vehicles, all of which are Drivable).


As already mentioned, Ruby's Array comes with a built-in #transpose method.

But, for the purposes of an exercise, there are multiple ways to do the same thing.

For instance, one way (which only works for square matrices!) is to use #map:

def my_transpose(arr)
  arr.each_with_index.map do |_, index|
    arr.map { |row| row[index] }
  end
end

Or you can use reduce (this will work for rectangular matrices):

def my_transpose(arr)
  arr.reduce([]) do |transposed, row|
    row.each_with_index do |value, col|
      transposed[col] ||= []
      transposed[col] << value
    end
    transposed
  end
end

Or do basially the same thing, just using each_with_object:

def my_transpose(arr)
  arr.each_with_object([]) do |row, transposed|
    row.each_with_index do |value, col|
      transposed[col] ||= []
      transposed[col] << value
    end
  end
end

But keeping more of your code, you could use Array#new as your loop, since it accepts a block.

For instance:

def my_transpose(arr)
  rows = arr.count
  cols = arr.first.count
  Array.new(cols) do |col|
    Array.new(rows) do |row|
      arr[row][col]
    end
  end
end

Of course, you'll want to check a few things. Firstly, whether there are any rows in the matrix at all (if not, the arr[0].count will fail), and whether the matrix is actually rectangular:

def my_transpose(arr)
  return [] if arr.empty?

  rows = arr.count
  cols = arr.first.count

  raise ArgumentError unless arr.all? { |row| row.count == cols }

  Array.new(cols) do |col|
    Array.new(rows) do |row|
      arr[row][col]
    end
  end
end

There are yet more ways to do things, but again: It's already built in as arr.transpose.


Here is my lightweight solution that involves no operations at run time:

template<typename T>
struct type { static void id() { } };

template<typename T>
size_t type_id() { return reinterpret_cast<size_t>(&type<T>::id); }

struct A { };

int main ()
{
    cout << type_id<int>() << " " << type_id<int*>() << " "
         << type_id<A>() << " " << type_id<int>() << endl;
}

The type id of type T is nothing but the address of function type<T>::id, re-interpreted as a number. Being a static method, there is a unique such function per type. These addresses are assigned by the linker (I think), so they remain constant between different runs. The overhead in executable size is linear in the number of type ids requested (that is, the number of instantiations of type<T>).

This solution has been tested in gcc and clang, and works correctly across different compilation units, i.e. you get the same unique type id for the same type in different compilation units. However, I cannot quite explain why/how this happens.

type_id() is easily inlined, so has no run-time cost. However, since it contains reinterpret_cast (and since the function address is not known to the compiler), it cannot be made constexpr. But I don't see this as a problem: if you want to use something e.g. as a template argument, you can use the type directly instead of its id. The id is for run-time use only.

My original implementation is using const void* as the return type of type_id(), so I know it has the same size as any pointer. I adapted it to size_t to fit the question. I think this is still safe, but I can't see why const void* wouldn't be fair enough.

By the way, because I haven't used it very much, I'd be happy to hear if there may be problems with this approach.


Relative frequency of words in tree of documents

There are two reasons for the poor performance of the code in the post: first, it performs much unnecessary work, and, second, the operations that it does perform are carried out using inefficient data structures.

Let's look at the inefficient data structures first. The problem here is that the documents are represented as lists, and the occurrence of a word in a document is determined using Python's in operator: word in doc. But the in operator is not efficient for lists: Python has to potentially compare word with every element of doc in order to determine if it is there or not. For an efficient membership test we would need to convert the documents to use Python's set data structure. But as I'll try to demonstrate below, by careful organization of the work, we can avoid having to test words for membership of documents at all.

Now for the unnecessary work.

The main body of the function is a loop over the list of documents belonging to the child node:

for doc in child.documents:
    # Update occurlist[i] for all the words in doc
    for word in doc:
        # Update ratio_dict[word]

Much of this work is wasted because words are likely to occur in multiple documents, and only in the case of the last document containing the word will we get the ratio we want. (All previous computations of this ratio were wrong, but when the last document is reached the wrong ratio gets overwritten by the correct ratio.) To avoid the wasted work we can restructure the code like this:

for doc in child.documents:
    # Update occurlist[i] for all the words in doc
for word in occurlist[i]:
    # Update ratio_dict[word]

In this version of the code we only compute the ratio once for each word.
In this loop the code counts how many documents each word occurs in:

for word in wordSet:
    if word in doc:
        occurlist[i][word]+=1

but some of this will be wasted because not every word in wordSet will occur in doc. This waste could be avoided by only looking at the words that occur in doc:

for word in set(doc):
    occurlist[i][word] += 1

The use of set here ensures that we only count unique words.
Looking at the overall structure of the algorithm in word_frequency, we can see that if a node has \$k\$ children, then we will be computing ratio dictionaries for each of those \$k\$ children, and that will mean counting the occurrences of the words in the \$k-1\$ siblings. But this means that the documents for each child have to be counted \$k\$ times: once for its own ratios, and again for the ratios of each of its siblings.

We can avoid this duplicate work by counting the occurrences for each node just once, and storing the counts in the node. The natural way to implement this would be to add a property to the class of node objects, like this:

from collections import Counter

class Node(object):
    # ... other methods here ...

    @property
    def occurrence(self):
        """Mapping from words to number of documents at this node that contain
        the word.

        """
        if not hasattr(self, '_occurrence'):
            self._occurrence = Counter()
            for doc in self.documents:
                self._occurrence.update(set(doc))
        return self._occurrence

Here I've used collections.Counter, which is a specialized data structure for counting things. Notice the convenience of being able to call the update method instead of having to write a loop.

The occurrence property is a cached property, by which I mean that after computing the result, it caches the answer in a private attribute (self._ocurrence) and then on subsequent calls it returns the answer previously computed, instead of computing it again.

(There are libraries that help you simplify the writing of cached properties, for example, in Python 3 you would use functools.lru_cache, and in Python 2.7 there's a backport package.)
Now that we have an occurrence mapping for each node, we can compute the sibling occurrences by summing the occurrence mappings for the siblings of each node. This is easily done because in my implementation above these occurrence mappings are Counter objects, and when you add two Counter objects you get a new Counter object with the sum of the counts. (See the section starting "several mathematical operations..." in the Counter documentation.)

Then having summed the siblings, we can use this sum to compute the ratios. Again, it would make sense for the ratios to be a cached property on the class of node objects, like this:

from __future__ import division
from collections import Counter

class Node(object):
    # ... other methods here ...

    @property
    def ratio(self):
        """Mapping from words to the ratio of the occurrences of the word in
        documents at this node to the occurrences of the word in
        documents at the siblings of this node.

        """
        if not hasattr(self, '_ratio'):
            self._ratio = {}
            documents = len(self.documents)
            sibs_occurrence = sum((sib.occurrence for sib in self.siblings),
                                  Counter())
            sibs_documents = sum(len(sib.documents) for sib in self.siblings)
            for word, count in self.occurrence.items():
                sibs_count = sibs_occurrence[word]
                if sibs_count == 0:
                    r = 1e6 * count / documents
                else:
                    r = count * sibs_documents / (sibs_count * documents)
                self._ratio[word] = r
        return self._ratio

Notes: (i) I've used the __future__ module to get Python-3-style division. This avoids the need to call float in each division. (ii) I didn't implement the feature where you adjust the ratio so that it's negative if it was less than one. In comments you indicated that you didn't care about these ratios, so I think there's no point in adjusting them. If you don't want to store these ratios at all, you could add a guard like if r >= 1: before storing them. (iii) I did fix the bug whereby if the ratio was 1 exactly then it would not be stored.

Now there is no remaining need for the word_frequency function. When you need the word frequency ratio mapping for node, then you write node.ratio and this computes it if needed, or returns the cached result if not, and there is little remaining duplicated work.

Summary. The code in the post computes the same intermediate results many times. The code can be sped up by organizing the work so that each result is computed just once. A convenient way to ensure this is to cache the results when they are computed.

Exercise. After making the changes suggested in this answer, which intermediate results are still computed many times, and how could this be avoided?


While your approach is simple and straightforward to implement there are some important drawbacks to realize.

First, it doesn't take advantage of the power templates offer. Since you're specializing for every possible usage of string_cast there's no opportunity for the compiler to generate code for you. A consequence of this is that you have a lot of 'clipboard heritance', copy and pasting the same function and changing parts of it to do what you want. This is a form of code duplication.

The approach does not lend itself to extendibility. What happens if you want to add support for another string type later on? The combination of functions you have to write would explode!

So there're clearly opportunities for some major improvement. Let see how we can refactor this so that it better adheds to DRY. If you take a step back and think about how string_cast is used you'll find there are really just 3 scenarios it has to support:

cast to the same string type.
cast to a different string type.
cast from a raw pointer representation into a string type.

Each of these cases can be handle by writing a template for them. Starting with the string_cast function that acts as an interface:

template <typename Td, typename Ts>

string_cast now takes 2 template parameters. Keeping your naming convention, I use Ts to indicate the source type. (TO and FROM are probably better names.)

Td string_cast(const Ts &source)
{

We use type deduction to identify what we're casting from.

    return string_cast_imp<Td, Ts>::cast(source);

Once we know what type Td and Ts is we delegate to string_cast_imp and the appropriate template will be instantiated.

}

Let's handle the easy case first:

template <typename Td>
struct string_cast_imp<Td, Td>
{
    static const Td& cast(const Td &source)
    {
        return source;

For casting to the same string type, we don't need to do anything. Just return back what was given. Since this is nothing more than a pass-through returning by reference is ok. string_cast will make a copy before going out of scope since it's return by value.

    }
};

Now for the important case, the reason for writing string_cast in the first place! The basic process is the same, only certain aspects are different:

conversion function used. eg. WideCharToMultiByte vs MultiByteToWideChar
buffer type used. eg. vector<char> for string vs vector<wchar_t> for wstring
string type returned. That's captured by our template parameter Td so we don't have to worry about this as much.

You can extract those differences into a trait-like policy class.

template <typename Td, typename Ts>
struct string_cast_imp
{
    static Td cast(const Ts &source)
    {
        int length = string_traits<Ts>::byte_convert( CP_ACP, source.data(), source.length(),
                                                      NULL, 0 );
        if( length == 0 )
        {
            return Td();
        }

Here I removed the string.empty() check since it's not really needed. If the string is empty length will be 0 anyway so this is properly handled.

        vector< typename string_traits<Td>::char_trait > buffer( length );

Here we use our policy class to tell us the proper character-type to use for our buffer. If Td = string then string_traits<Td>::char_trait will be a char. If it's a wstring then string_traits<Td>::char_trait will evaluate to a wchar_t.

        string_traits<Ts>::byte_convert( CP_ACP, source.data(), source.length(),
                                                 &buffer[ 0 ] , length );

Similiarly, byte_convert acts as a wrapper to the correct byte function to call. This attrib is captured by our policy class as well.

        return Td( buffer.begin(), buffer.end() );
    }
};

We define our string_traits policies like this:

template <typename T>
struct string_traits;

Declare the general base-form but don't define it. This way if code tries to cast from an illegit string-type it will give a compile error.

template <>
struct string_traits<string>
{
    typedef char char_trait;
    static int byte_convert(const int codepage, LPCSTR data  , int data_length,
                                                LPWSTR buffer, int buffer_size)
    {

You might want to play around with the parameters it accepts but this should give you the general idea.

        return ::MultiByteToWideChar( codepage, 0, data, data_length, buffer, buffer_size );
    }
};

And now for the last case. For raw pointer types we can just wrap it into an appropriate string type and call one of our above string functions. We have to overload string_cast here because our base form accepts a reference type. Since reference types to arrays do not decay into a pointer type, this second template form will specifically handle that case for us.

template <typename Td, typename Ts>
Td string_cast(Ts *source)
{
    return string_cast_imp<Td, typename string_type_of<const Ts *>::wrap >::cast(source);

Notice I'm using const Ts * as template parameter for string_type_of. Regardless of whether Ts is const or not we always use template form <const Ts *> to get the information we need.

}

string_type_of is another policy we define as follows:

template <typename T>
struct string_type_of;

This policy class tells us what string-type to use for a given raw pointer type.

template <>
struct string_type_of<const char *>
{
    typedef string wrap;
};

With this refactor, you've reduced the number of written functions from 8 down to just 4 and eliminated code duplication. Perhaps more importantly adding support for another string-type is significantly easier, just specialized another policy for that string-type and you're done.


Serialize data into one byte array using ByteBuffer

A minor aesthetics advice

You can save some typing by using the method chains over ByteBuffer:

private int getBufferCapacity(final Map<byte[], byte[]> keyDataHolder) {
    int size = 36;
    for (Map.Entry<byte[], byte[]> entry : keyDataHolder.entrySet()) {
        size += 1 + 1 + 8 + 2;
        size += entry.getKey().length;
        size += entry.getValue().length;
    }
    return size;
}

public byte[] serialize2() {
    ByteBuffer byteBuffer = ByteBuffer.allocate(getBufferCapacity(keyDataHolder))
            .order(ByteOrder.BIG_ENDIAN);
    // Use chaining:
    byteBuffer.put(addressedCenter)
            .put(version)
            .putInt(keyDataHolder.size())
            .putInt(getBufferUsed(keyDataHolder))
            .putLong(location)
            .putLong(locationFrom)
            .putLong(locationOrigin)
            .put(partition)
            .put(copy);

    for (Map.Entry<byte[], byte[]> entry : keyDataHolder.entrySet()) {
        byte keyType = 0;
        byte[] key = entry.getKey();
        byte[] value = entry.getValue(); // A map mapping is often called a
        // key/value -pair.
        byte keyLength = (byte) key.length;
        short valueLength = (short) value.length;

        ByteBuffer dataBuffer = ByteBuffer.wrap(value);
        // Short cut:
        long timestamp = valueLength > 10 ? dataBuffer.getLong(2) : 0;

        // Chaining:
        byteBuffer.put(keyType)
                .put(keyLength)
                .put(key)
                .putLong(timestamp)
                .putShort(valueLength)
                .put(value);
    }

    return byteBuffer.array();
}

Also, when you deal with maps, the conventional terminology for a mapping is a key/value-pair. For this reason, I would rewrite

byte[] key = entry.getKey();
byte[] data = entry.getValue();

to

byte[] key = entry.getKey();
byte[] value = entry.getValue();

Then, later on in the code, I would change

byte keyLength = (byte) entry.getKey().length;

with

byte keyLength = key.length;

Instead of

long timestamp = 0;

if (dataSize > 10) {
    timestamp = dataBuffer.getLong(2);
}

you can write an one-liner:

long timestamp = valueLength > 10 ? dataBuffer.getLong(2) : 0;

Finally, since you know your file format, you should be able to come up with a function that computes the exact size of the file for particular set of data; call it foo. Now, you would normally do:

ByteBuffer byteBuffer = ByteBuffer.allocate(foo(keyDataHolder));

Hope that helps.


Convert list of parameters to a string that can be invoked

Here's what I've been able to come up with so far. It could probably be improved further.

function Pack {
    param(
        [Parameter(Mandatory=$true)]
        [string] $nuspec,

        [string] $OutputDirectory,

        [string] $BasePath,

        [ValidateSet("normal", "quiet", "detailed", IgnoreCase = $true)]
        [string] $Verbosity,

        [switch] $Symbols
    )

    # these parameters are passed as name - value pairs
    $named = @('OutputDirectory', 'BasePath', 'Verbosity')

    # these parameters are passed as switches
    $keyed = @('Symbols')

    $p = $PSBoundParameters
    Write-Log "Creating package..." -ForegroundColor Green
    $output = Invoke-Command {
            .\NuGet.exe "pack" $nuspec ($p.Keys | foreach {
                If ($named -contains $_) { "-$_", $p[$_] }
                ElseIf ($keyed -contains $_) { "-$_" }
            })
        } -ErrorVariable error

    Write-Log $output
    Write-Log $error Error
    Write-Log " "

    $global:ExitCode = $LastExitCode
}


Count character 'a' in first n characters of indefinitely repeating string s

Your getCount() method is a little difficult to read, on one long line like that, and way too complicated. s.count(_ == 'a') is both concise and efficient.

It's not clear why the number of s repetitions possible in n is called duplicate. It seems an odd choice for that variable name.

Your algorithm is sound, I just find it excessively verbose, especially for a language that prides itself on being both expressive and concise.

val sLen = s.length
s.count(_ == 'a') * (n/sLen) + s.take((n%sLen).toInt).count(_ == 'a')


Sequence-based enumeration of permutations in lexicographic order

Performance

I'm not particularly surprised that the version of permutations(of:) which uses AnySequence and AnyIterator is so slow.

You're paying for the cost of both:

Heap allocation and reference counting for both the captured array and done flag.
Copy-on-write upon mutating the array in the defer block, as a copy of the array needs to be taken in order to return it to the caller prior to the mutation.

Therefore immediately you can speed things up by simply reducing the amount of closure capture – for example if you just removed the AnySequence wrapper and just returned an AnyIterator:

func permutations<T: Comparable>(of a: [T]) -> AnyIterator<[T]> {
    var current = a.sorted()
    var done = false
    return AnyIterator {
        if done { return nil }
        defer { done = !current.permute() }
        return current
    }
}

You can still use an AnyIterator in a for-in loop due to the fact that it conforms to Sequence itself, and just returns itself as its own iterator. Iterating through it will 'consume' the elements returned, but you get the same behaviour by wrapping it in an AnySequence due to the fact that it's ultimately capturing the same array.

From AnySequence to AnyIterator improves my benchmark time (using the same measurement setup as shown in your question) from ~1.1 seconds to ~0.95 seconds.

However, as you note, we can do better than that by removing the closures entirely by simply declaring our own custom iterator type – PermutationSequence.

struct PermutationSequence<T: Comparable>: Sequence, IteratorProtocol {
    private var current: [T]
    private var done: Bool

    init(elements: [T]) {
        self.current = elements.sorted()
        self.done = false
    }

    func makeIterator() -> PermutationSequence {
        return self
    }

    mutating func next() -> [T]? {
        if done { return nil }
        let retval = current
        done = !current.permute()
        return retval
    }
}

This reduces my benchmark time down to ~0.75 seconds.

However, the problem with this implementation, as @dfri points out, is that we're still paying the cost of copy-on-write at each iteration due to the fact that both retval and current have a view onto the underlying array buffer.

The solution to this is fairly simple, as you noted, we return the array after the mutation has taken place, and just maintain a flag so we don't do a mutation on the first iteration. This could look like:

struct PermutationSequence<Element : Comparable> : Sequence, IteratorProtocol {

    private var current: [Element]
    private var firstIteration = true

    init(startingFrom elements: [Element]) {
        self.current = elements
    }

    init<S : Sequence>(_ elements: S) where S.Iterator.Element == Element {
        self.current = elements.sorted()
    }

    mutating func next() -> [Element]? {

        // if it's the first iteration, we simply return the current array.
        if firstIteration {
            firstIteration = false
            return current
        }

        // do mutation – if the array has changed, then return it,
        // else we're at the end of the sequence.
        return current.permute() ? current : nil
    }
}

Note that I've also:

Removed the makeIterator() implementation as there's already a default implementation for this when the sequence is its own iterator.
Renamed the generic placeholder from T to Element, as it's a more descriptive name for it.
Added an init(startingFrom:) initialiser, as I suspect it will be quite useful to allow the sequence to resume from a given permutation, rather than always starting at the first.
Removed the argument label from init(elements:), as it was already clear what the initialiser does and made it take a generic Sequence input for increased flexibility.

Now we're no longer paying for the cost of an array copy at each iteration due to the fact that the iterator always has a single view onto the array's buffer (though the current property), reducing my benchmark time down to ~0.1 seconds (the target is ~0.02 seconds for directly applying permute() in repeat-while loop).

The key to achieving the target performance weirdly appears to be avoiding having multiple exits in the implementation of next().

If we refactor the iterator's next() method like this, so that there's only one return:

mutating func next() -> [Element]? {

    var continueIterating = true

    // if it's the first iteration, we avoid doing the permute() and reset the flag.
    if firstIteration {
        firstIteration = false
    } else {
        continueIterating = current.permute()
    }

    // if the array changed (and it isn't the first iteration), then return it,
    // else we're at the end of the sequence.
    return continueIterating ? current : nil
}

we are able to achieve the desired benchmark time of ~0.02 seconds. Exactly why this reduces the time so dramatically, I'm not too sure – it appears that having multiple points of exit in the method prevents the compiler from performing some important optimisation.

It also appears to be related to inlining, as when marking the next() method with the @inline(never) attribute, the use of an additional return has no significant impact on the performance. I'd certainly be interested if anyone else knows more about exactly what's going on here.

Regarding your comment about making shouldContinue (renamed to continueIterating here) a let constant – I could not observe a difference in performance in doing so, so I left it as a var.

Separating the sequence and iterator

Depending on your usage, it may be useful to separate your permutation sequence implementation from its iterator in order to allow for non-destructive iteration (this isn't required for a sequence, but can be useful in places).

This would just be as simple as having the sequence keep its own constant copy of the array prior to mutation, which gets passed to the iterator on its creation.

In Swift 3.1, this can be expressed rather nicely with a nested generic type:

struct PermutationSequence<Element : Comparable> : Sequence {

    // constant copy of the elements to pass to the iterator on its creation.
    let elements: [Element]

    init(startingFrom elements: [Element]) {
        self.elements = elements
    }

    init<S : Sequence>(_ elements: S) where S.Iterator.Element == Element {
        self.elements = elements.sorted()
    }

    struct Iterator : IteratorProtocol {

        private var current: [Element]
        private var firstIteration = true

        // you should create a PermutationSequence rather than invoking this
        // initialiser directly.
        fileprivate init(startingFrom elements: [Element]) {
            self.current = elements
        }

        mutating func next() -> [Element]? {

            var continueIterating = true

            // if it's the first iteration, we avoid doing the permute() and reset the flag
            if firstIteration {
                firstIteration = false
            } else {
                continueIterating = current.permute()
            }

            // if the array changed (and it isn't the first iteration), then return it,
            // else we're at the end of the sequence.
            return continueIterating ? current : nil
        }
    }

    func makeIterator() -> Iterator {
        return Iterator(startingFrom: elements)
    }
}

This shouldn't adversely affect the performance in any way (benchmarking doesn't reveal any significant difference) – an initial copy of the array may have to be taken upon the first mutation, but that's also true for the previous version of PermutationSequence due to the fact that the caller has a view onto the array buffer.


FP overflow

A ridiculously long fractional part causes decplace to reach inf, and the perfectly valid number is converted to nan.
Testing for NAN and INF

Using strncmp would be much more clear.
DRY

The integer conversion loop is repeated at least twice (for whole part and exponent). It is a strong indication that you need to factor it out into a function. You may want to have this function to handle fractional part as well.
Best effort

The function fails to convert certain numbers which stdlib version does handle, e.g.

    char * s ="10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001E-200";

(a ridiculously long whole part compensated by E-200 exponent). I suppose that stdlib version anticipates such inputs and normalizes them prior to conversion.


Feedback on automatic form filling with reflection

Just to tell you upfront, your code looks good, is easy to read and everything is well named. But it can be improved nevertheless.

First thing, public methods should always validate its method arguments. Passing null would lead to a nasty NullReferenceException at the start of the most outer foreach loop.

I would suggest making the constants a class level variable being filled in the constructor, because the types won't usually change while your code is running.

By restricting FieldType of the constants to KeyValuePair<string, string> will eliminate the if inside the most inner loop and will limit the constants to a smaller number.

Omitting braces {} although they may be optional can be dangerous because it may lead to hidden and therfor hard to find bugs. I would like to encourage you to use them.

Implementing the mentioned points will look like this

private readonly List<FieldInfo> constants = new List<FieldInfo>();
public ctor()
{
    constants.AddRange(typeof(AuthConsts).GetFields());
    constants.AddRange(typeof(ClientConsts).GetFields());
    constants.AddRange(typeof(ContactConsts).GetFields());
    constants.AddRange(typeof(AddressConsts).GetFields());
    constants.AddRange(typeof(ReferenceConsts).GetFields());
}

public List<BindDto> GenerateBinds(IEnumerable<Form> forms)
{
    if (forms == null) { throw new ArgumentNullException(nameof(forms)); }

    var neededType = typeof(KeyValuePair<string, string>);
    var binds = new List<BindDto>();
    var keyValueConstants = constants.Where(c => c.FieldType == neededType);

    foreach (var form in forms)
    {
        var formResponses = form.response.ToObject<Dictionary<string, string>>();

        IEnumerable<string> formFields = formResponses.Keys;

        foreach (var field in formFields)
        {
            foreach (var constant in keyValueConstants)
            {
                var templateString = (KeyValuePair<string, string>)constant.GetValue(this);

                if (templateString.Key == field)
                {
                    binds.Add(new BindDto(templateString.Value, formResponses[field]));
                }
            }
        }
    }

    return binds;
}


<?php
    // this code goes into your controller
    $visitor_rows = [];

    // lets do all the hard work here
    while($visitor = $visitors->fetch_object()) {
        $time = $visitor->time;
        $visitor = new User($visitor->viewer_id);
        $visitor_rows[] = [
            'id' => $visitor->id,
            'profile_image' => $visitor->profile_image,
            'name' => $visitor->name,
            'time' => $time->convertToAgo($time),
        ]);
    }

    // the template only needs to know about $visitor_rows now
?>

 Visitors

                <?php foreach ($visitor_rows as $row): ?>
                    <?= $this->insert('visitors/visitor', $row) ?>
                <?php endforeach ?>


inb4 Scott :-)

Use functions more. Composability is not very important in this example, but it's good to get into that habit early on.

In that spirit, turn the non-trivial value bindings into functions instead of closing over a previously defined value. Also try turning the non-trivial lambda expressions into functions; that gives them a name and makes the call site more readable.

Also, pipe more. :-) Especially for the list/sequence functions that take a higher order function, it's more readable to pipe the list into them, because it makes it more obvious what you're starting from.

Also, in my experience, defining "constant" values and functions first before actually doing any work makes the code much easier to follow, because you don't have to think about what values you already "have" at which point.

Oh, and while tail recursion is a very cool thing to have, it's not very useful here and actually makes the code quite a bit less understandable.

Did you put the type annotations in on purpose? In most cases, you don't need them because of F#'s powerful type inference. They can sometimes make code more easy to follow, but they might also constrain it where it could actually be more generic, and in general not having to specify types all the time is one of the really nice things about F#. :-)

Edit: Reading this again made me think of another important point: The individual function declarations don't belong in the main function; moving them out of there makes the distinction between "parts" and the actual "running" program even clearer.

With these things taken into consideration, your code could look like this:

open System
open System.IO

// It's a tiny bit more maintainable to keep this list separate, and makes it more readable where it is used
let separators = [|' ';'_';';';':';'(';')';'\\';'/';'>';'<';'{';'}';'0';'1';'2';'3';'4';'5';'6';'7';'8';'9';'.'|]
let fileNamePattern = "*Tests.cs"

// Function with the directory and pattern as a parameter
let getFileNames fileNamePattern directory =
    Directory.EnumerateFiles(directory, fileNamePattern, SearchOption.AllDirectories)
    |> Seq.toList

// Function with the list of filenames as a parameter
let getAllLines fileNames = fileNames |> List.collect (System.IO.File.ReadLines >> Seq.toList)

// Function with the list of lines as a parameter
let getAllWords lines =
    lines
    |> List.collect (fun (line : string) ->
        line.Split(separators, StringSplitOptions.RemoveEmptyEntries)
        |> Seq.toList)

// Reordered parameters for pipeability
let countOccurrences allWords word =
    // The = operator can be used as a function that takes two arguments.
    let count = allWords |> List.filter ((=) word) |> List.length
    word, count

// Function that takes a sequence of "anything" and returns a list of the distinct values
let distinctWords = Seq.distinct >> Seq.toList

// F# string formatting is strongly typed and compiler checked; take advantage of that, don't just use %A
let printWordCount (word, count) = printfn "%s: %i" word count

// Now that everything is "set up", we can "run" with the current data:
[<EntryPoint>]
let main args =
    // This binding isn't really necessary, but it's nice to give the value a name
    let directory = args.[0]

    // We now have a clear execution path that is very easy to follow
    let allWords =
        directory
        |> getFileNames fileNamePattern
        |> getAllLines
        |> getAllWords

    let distinct = distinctWords allWords

    distinct
    |> List.map (countOccurrences allWords)
    |> List.iter printWordCount

    0


Generate next combination in lexicographic order

My advice here is this: throw away your requirement of not having any state. The number sequence \$\binom{i}{\lceil i \rceil}\$ grows fast, so you won't be able to deal with combinations whose state is "large". Also, I see no point doing templates here. Instead you could write a simple class that manages indices in such a way that indirection is lexicographic:

#include <iostream>
#include <iterator>
#include <sstream>
#include <vector>

class lexicographical_combination_generator {
public:
    lexicographical_combination_generator(size_t set_size,
                                          size_t combination_size);
    bool increment();
    size_t get_set_size()                      { return m_set_size; }
    size_t get_combination_size()              { return m_combination_size; }
    size_t get_combination_index(size_t index) { return m_indices[index]; }
private:
    size_t              m_set_size;
    size_t              m_combination_size;
    std::vector<size_t> m_indices;

    void check_arguments(size_t set_size, size_t combination_size);
};

lexicographical_combination_generator::
lexicographical_combination_generator(size_t set_size, size_t combination_size)
{
    check_arguments(set_size, combination_size);
    m_set_size = set_size;
    m_combination_size = combination_size;

    for (size_t index = 0; index < m_combination_size; ++index)
    {
        m_indices.push_back(index);
    }
}

void lexicographical_combination_generator::
check_arguments(size_t set_size, size_t combination_size)
{
    if (combination_size > set_size)
    {
        std::stringstream ss;
        ss << "combination_size("
           << combination_size
           << ") > set_size("
           << set_size
           << ")";
        throw std::runtime_error{ss.str()};
    }

    if (set_size == 0)
    {
        std::stringstream ss;
        ss << "set_size is zero";
        throw std::runtime_error{ss.str()};
    }
}

bool lexicographical_combination_generator::increment()
{
    if (m_indices[m_combination_size - 1] < m_set_size - 1)
    {
        m_indices[m_combination_size - 1]++;
        return true;
    }

    for (int i = (int)(m_combination_size - 2); i >= 0; --i)
    {
        if (m_indices[i] < m_indices[i + 1] - 1)
        {
            m_indices[i]++;

            for (int j = i + 1; j < m_combination_size; ++j)
            {
                m_indices[j] = m_indices[j - 1] + 1;
            }

            return true;
        }
    }

    return false;
}

template<typename Iter>
void print(lexicographical_combination_generator& gen, Iter begin)
{
    for (size_t i = 0; i < gen.get_combination_size(); ++i)
    {
        std::cout << gen.get_combination_index(i);
    }

    std::cout << ": ";

    for (size_t i = 0; i < gen.get_combination_size(); ++i)
    {
        auto iter = begin;
        std::advance(iter, gen.get_combination_index(i));
        std::cout << *iter;
    }

    std::cout << "\n";
}

int main(int argc, const char * argv[]) {
    std::vector<char> alphabet = { 'a', 'b', 'c', 'd', 'e' };
    lexicographical_combination_generator gen(5, 3);
    do {
        print(gen, alphabet.begin());
    } while (gen.increment());
}


The first suggestion I would like to make is for you to become familiar with Inversion of Control (IoC) and Dependency Injection (DI). These two principles state that dependencies should not be hardcoded into your classes, but should be "injected" into them. This ensures that your class does not become dependent upon a single entity and can thus be extended. This is most commonly combined with type hinting.

Type hinting ensures that a parameter is of the proper type, otherwise PHP will terminate execution of the script with an error. You can use the class you are expecting, or you can instead use a parent class or interface so that any similar class can be used, thus making it more extensible. I will demonstrate using the former as I don't know if there is a parent class or interface to use.

public function __construct( CredentialsManager $credentials ) {
    //etc...
}

//usage
$log = new Logger( CredentialsManager::GetCredentials() );

You should also become aware of the Arrow Anti-Pattern. Through it you learn that unnecessarily indented code is bad. To illustrate this they usually show code that comes to peaks to form an arrow. The easiest way to refactor your code to avoid this anti-pattern is to return early. For example, if we reverse your first if statement in your RecordLog() method we can return early thus making the else statement unnecessary and removing an entire level of indentation from that method.

if( ! $this->openConnection() ) {
    return FALSE;
}

//etc...

Speaking of that else statement. PHP inherently requires braces, otherwise you would not be forced to add them after your statements reached more than one line. Adding them helps ensure no mistakes are made and keeps your code consistent. I would strongly recommend adding braces, even if you think they are unnecessary.

else {
    return FALSE;
}

Always avoid assigning variables in statements. There are quite a few reasons for this:

They are extremely difficult to debug. I actually missed this the first time through and thought you were using globals.
They decrease legibility. Usually they increase line length and make statements more complex.
There is usually no way for the reader, or your IDE, to determine if this was done accidentally. Therefore it is fairly easy to accidentally assign a value to a variable when you actually meant to compare it.

There are exceptions to this rule, such as when setting up an iterator, but typically this should be avoided.

//common
for( $i = 0; $i < $count; $i++ ) {
//not as common, but fine
while( ( $buffer = fgets( $handle, 4096 ) ) !== false ) {
//as it should be
$stmt = $this->_mysqli->prepare( 'INSERT INTO logz (log) VALUES (?)' );
if( ! $stmt ) {

When you want a boolean return value that reflects a boolean state of what you are comparing, you can simply return the comparison and skip the unnecessary if/else structure.

return $stmt->affected_rows > 0;

Your RecordLog() method violates the Single Responsibility Principle. This principle states that your methods should do one thing and delegate everything else. Instead you have this method doing everything. A better way to rewrite this is to call the logger whenever an error is encountered and pass that error to it. Instead you are calling the logger to perform the functionality that might produce errors in order to catch them. This is backwards.

if( ! $this->performAction() ) {
    $this->RecordLog( $error );
}

Expanding upon this concept, and those mentioned previously, our classes should be equally singular. It may not be as obvious, but your logger should really only be concerned with logging the errors, not with the how of it. If you instead inject the database into this class, then that database can change without needing to modify the logger. So you should be able to go from using a MySQLi database to PDO or any other database without needing to modify this class. Though this is more advanced and I wouldn't suggest trying to tackle this until you are more comfortable with the rest.

$log = new Logger( $mysqli );
$log = new Logger( $pdo );

The way you are currently connecting to your database restarts the connection every time RecordLog() is called. This is bad. You only need one connection per instance of the class. Creating it in the constructor ensures this. In fact, since you are not reusing any of those connection properties, you could probably get away with openConnection() BEING the constructor. If you just directly apply the credentials then declaring them as properties will become unnecesary.

$this->_mysqli = new mysqli(
    $credientials[ 'host' ],
    $credientials[ 'user' ],
    $credientials[ 'pass' ],
    $credientials[ 'database' ]
);

If you take my advice about that RecordLog() method, then you can "log" the connection error from the constructor as well, thus making your code more uniform.

if( $this->_mysqli->connect_errno ) {
    $this->RecordLog(
        "Failed to connect to MySQL: "
        . $this->_mysqli->connect_error
    );
}

So, something you should begin to notice from all of these suggestions is that your class now doesn't do much. You have a constructor and a logger. The constructor is a wrapper for the MySQLi class' constructor and as such can be abstracted out. This leaves just the logger method, and if we look at what this is doing, then we can also determine that this is unnecessary. Assuming you are planning on modifying this functionality to do more than just echo the error, then that leaves just the one method. This is not enough to justify a class. A function yes, but not a class. I would say forgo the class and just use PHP's MySQLi class directly. Extending, or in this case, pseudo extending, a class is unnecessary unless you are planning on doing something DRASTIC with that extension. Just creating a connection is not enough. However, it is a good start to trying to understand OOP concepts.


In my first quick scan through, here are some things I want to bring up:

If you are going to overload operators, do it the way the users of the language expect, or don't do it at all.  I expect operator++ to return something, not be a void.
Does block_offset really need to be public?
On that same note, do your actual concrete implementations of the iterators need to be public, since you have methods to create them that are public?  Would it make sense for anyone to ever want to create them a different way?


Detecting if two strings are anagrams using TreeMap

Replace the TreeMap with a HashMap since a TreeMap offers \$O(log(n))\$ lookup (containsKey and get) and insertion (put) time whereas a HashMap offers amortized constant or \$O(1)\$ time for those same methods.

The time complexity of this algorithm (with a HashMap) is in fact O(length(s1)) or rather \$O(n)\$ because the contains, add and remove methods of a HashMap work in amortized constant or \$O(1)\$ time (it is \$O(n)\$ when the internal arrays have to be expanded).

You can make the code cleaner by getting rid of all those ifs in the loop. The get method returns null if the key doesn't exist, which helps us remove that containsKey call.

    for ( int i=0 ; i<s1.length() ; i++ ) {
        Integer freq = charFrequencyS1.get(s1.charAt(i));
        charFrequencyS1.put(s1.charAt(i), freq == null ? 1 : freq.intValue() + 1);

        Integer freq = charFrequencyS2.get(s2.charAt(i));
        charFrequencyS2.put(s2.charAt(i), freq == null ? 1 : freq.intValue() + 1);
    }

You could even go a step further and extract those two lines into a method, like

void addCharToMap(Map<Character, Integer> charMap, Character char) {
    Integer freq = charMap.get(char);
    charMap.put(char, freq == null ? 1 : freq.intValue() + 1);
}

And use the above method twice.

One thing to note is that if you are sure that your input is going to be numeric or alphanumeric, you can set the initialCapacity of the HashMap to be 26 or 36 respectively, because that amount is the maximum number of possible unique characters in the strings.


Direction array to support multiple keydowns in 4-directional movement

If you don't need to support IE8 and under, you could cut out those for-loops by using indexOf().

// Only add the direction if it doesn't exist yet
Keys.prototype.add = function (dir) {
    if (!~this.keys.indexOf(dir)) {
        // you could also do this.keys.indexOf(dir) == -1
        this.keys[this.keys.length] = dir;
    }
};

// Find the index of the first occurrence and splice the array there without it
Keys.prototype.remove = function (dir) {
    // you could also save this in a variable to use the second time
    if (~this.keys.indexOf(dir)) {
        this.keys.splice(this.keys.indexOf(dir), 1);
    }
};

Instead of this.keys[this.keys.length] = dir;, you could just push():

this.keys.push(dir);

Your check in Keys.prototype.getLast is redundant. It'll either return an item from the array, or nothing (undefined). A nonexistant array index also returns undefined, so you could just cut it out:

Keys.prototype.getLast = function () {
    return this.keys[this.keys.length - 1];
};

If you need to support oldIE, you could at least optimize Keys.prototype.remove by adding a return statement after removing the item:

Keys.prototype.remove = function (dir) {
    for (var i = 0; i < this.keys.length; i++) {
        if (this.keys[i] == dir) {
            this.keys.splice(i, 1);
            return;
        }
    }
};


You are creating an array of strings (using str.split(" ")) as well as an array of numbers (wordLengthArray), then sorting wordLengthArray.  All three of those operations are wasteful, if you are aiming for performance.

function findLongestWordLength(str) {
  let maxLen = -1;
  for (var i = 0, j; (j = str.indexOf(" ", i)) != -1; i = j + 1) {
    maxLen = Math.max(maxLen, j - i);
  }
  return Math.max(maxLen, str.length - i);
}

console.log(6 == findLongestWordLength("The quick brown fox jumped over the lazy dog"));
console.log(5 == findLongestWordLength("May the force be with you"));
console.log(6 == findLongestWordLength("Google do a barrel roll"));
console.log(8 == findLongestWordLength("What is the average airspeed velocity of an unladen swallow"));
console.log(19 == findLongestWordLength("What if we try a super-long word such as otorhinolaryngology"));

Depending on the browser/interpreter, your function is 33% to 86% slower than mine.


Monty Hall simulation with any number of doors

I would have used an helper function in the first version so that your monty_hall function is:

def monty_hall(amount, doors=3):
    if doors < 3:
        raise ValueError(f'doors must be greater than three, not {doors}')

    return sum(player_wins_a_car(doors) for _ in range(amount))

This also applies to the second version but removes some of the speed optimizations you made there; so not sure if it’s worth keeping.

However, in the first version, I would use list-comprehensions to reduce a bit the memory needed. It would also exhibit the actions more like a real player would do. Since creating the set from range will already iterate over each elements, using the list-comp won't be much more costy:

import random

def player_wins_a_car(doors):
    player_choice = random.randrange(doors)
    car_placement = random.randrange(doors)
    shown_door = random.choice([door for door in range(doors)
                                if door not in (player_choice, car_placement)])
    final_choice = random.choice([door for door in range(doors)
                                  if door not in (player_choice, shown_door)])

    return final_choice == car_placement

For the second version, if you were to keep two functions that could lead to more explanatory stuff like:

def player_wins_a_car(doors):
    # Choose a door that hide a car. Car is never behind door 0,
    # if it were behind door 0, consider door 0 and 1 to be
    # swapped so that host always open door 0.
    car_placement = random.randrange(doors) or 1
    # Consider an initial choice of door `doors - 1` and host
    # showing door 0 unconditionaly. Always choosing a random
    # door out of these two.
    final_choice = random.randrange(1, doors-1)

    return car_placement == final_choice

I’m using or here as the only value triggering max would be 0, not sure which one performs better.


Drawing thousands of lines in WebGL or Canvas

As a first step instead of 20k graphics objects containing each a single line use a single graphics object and put the 20k lines in it

var container = new PIXI.Container(),
    i,
    renderer = PIXI.autoDetectRenderer(1000, 1000);
renderer.backgroundColor = 0xFFFFFF;
document.body.appendChild(renderer.view);

line = new PIXI.Graphics();
line.lineStyle(1, 0x888888, 1);
for (i = 0; i < 5000; i++) {
    line.moveTo(0,0);
    line.lineTo(10*i,1000);
}
container.addChild(line);

renderer.render(container);
<script src="https://cdnjs.cloudflare.com/ajax/libs/pixi.js/3.0.8/pixi.js"></script>

PIXI will then batch all those lines into a single buffer and draw it using a single draw Elements command.


Cloud Function: Deleting from both Firestorage and Firestore in a kind of "batch"

I must admit that I haven't really used firebase or done any android development and thus cannot answer your questions about the correctness of the code. I did wonder if using a transaction would help satisfy the need to prevent deletion of items if other items cannot be deleted, but maybe the batch handles that... Maybe the process to delete the file (i.e. deleteFile) should be added to batch, although maybe that not possible because it is the firestorage document.

Good things

The code makes good use of const for values that don't get re-assigned.

Indentation is consistent and helps readability of the code.

Functions aren't overly long.

There aren't many indentation levels because the first function will exit early in an error state.

Suggestions

I don't see any comments. The code does seem mostly explanatory as it is but it would be helpful to have some insights about the code - at least function parameter types, return types, etc. Over time it might become difficult to remember why you may have done something a certain way.

Many variables are declared and then only used once. There is little point in doing this. Many of those variables can be eliminated - e.g. the_post, promise, stored_image_name, filePath, updateUserLikes.

The variable name deleteDbEntry could be confusing to other readers of your code. A more appropriate name might be dbEntryToDelete.

The lambda function passed to .then() of Promise.all() could be simplified to an arrow function - e.g.

return Promise.all([deleteFile, batch_commit]).then(_ => 1)


I guess the problem is in the inner loop:

for(int j=0;j<n;j++){
  if(j+1>=a && j+1<=b){
    //...
  }
}

If 'n' value is big and the gap between 'a' and 'b' is small enough iterations will be useless most of the time.
Also in my opinion, using of int[] array is more suitable here.

You can try in this way:

public final class Solution {

  public static void main(String[] args) {
    final Scanner scanner = new Scanner(System.in);
    final int n = scanner.nextInt();
    final int m = scanner.nextInt();
    final int[] l = new int[n];

    for (int i = 1; i <= Math.min(m, n - 1); i++) {
      final int a = Math.max(0, Math.min(scanner.nextInt() - 1, n - 1));
      final int b = Math.max(0, Math.min(scanner.nextInt(), n - 1));
      final int k = scanner.nextInt();
      for (int j = a; j < b; j++) { // iteration in useful range
        l[j] += k;
      }
    }
    int total = l[0];
    for (int i = 1; i < n; i++) {
      if (l[i] > total) {
        total = l[i];
      }
    }
    System.out.println(total);
  }
}


Here are the changes I would make to your code in terms of both style and efficiency:

    def sortedRanges(lo: Int, hi: Int, reps: Int): List[List[Int]] = reps match {
        case 0 => Nil :: Nil
        case _ =>
          List.range(lo, hi) flatMap (x =>
            sortedRanges(x, hi, reps - 1) map (xs =>
              x :: xs))
      }

    def combinationsWithReplacement(stuff: Vector[T], reps: Int): List[List[T]] =
      sortedRanges(0, stuff.length, reps) map (xs =>
        xs map (x =>
          stuff(x)))

Style Comments

Methods which take functions as parameters (flatMap and map in this case) should be invoked using infix notation. That is, if there were a god of Idiomatic Scala Style he would prefer xs map (...) to xs.map(...)

Defined functions should use camel case, e.g. combWithRep over comb_with_rep.

In general, and you will get a feel for this the more you use Scala, pattern matching is preferred over if-statements. You will notice that in your function sortedRanges I've swapped your if-else statement for a pattern match on the value reps.

The last style tip I have for you is to break a chain of higher order functions over several lines. This last one can be fudged in some cases, but in general I find that it improves readability.

Efficiency Comment

The one change that I made in the name of efficiency was to change the container type of stuff from List[T] to Vector[T]. The reason I made this change is that accessing an item in a List takes linear time on the length of the list, whereas accessing an item in a Vector is almost constant. And as you know, you are accessing elements of stuff by index is in the last line of combinationsWithReplacement.


Python decorator for retrying w/exponential backoff

First of all, when I start writing decorators of more than moderate complexity, and especially if they take parameters, I usually transition to writing them as classes - I find that easier to reason about and understand.

Second of all, in 100% of decorators I've ever written, I've wanted the decorator to look like the wrapped function.  To do this, just use functools.wraps().

Next, I think you have some weirdness in your api. I would expect logger to default to some default logger, and I would expect logger_attr to only be used to override whatever that logger is.  I also don't like that you're explicitly calling print in the decorator - instead you should always use the logger, and if they want one that just calls print, or if that is the default, you should provide that.  As an additional note, if logger_attr is a string then you can simplify the implementation a bit to look like this

logger = getattr(instance, attr_name, logger)
logger.log(level, message)

Next, you've limited yourself to some pretty static forms of backoff by making it a number. Instead, make it be a generator.  Then you can do something like this

def doubling_backoff(start):
    if start == 0:
        start = 1
        yield start
    while True:
        start *= 2
        yield start

def no_backoff(start):
    while True:
        yield start

and then in your decorator, it looks like this

backoff_gen = backoff(delay)
while max_tries > 1:
    try:
        return f(*args, **kwargs)
    except exceptions as e:
        message = "Exception {} caught, retrying {} more times.".format(e.message, max_tries)

        instance = args[0]
        logger = getattr(args[0], attr_name, logger)
        logger.log(level, message)

        time.sleep(delay)
        delay = next(backoff_gen)
        max_tries -= 1

This lets you add much more complex backoff algorithms as needed.

Lastly, I think your comments don't really add much value to the code - reading the code is self-explanatory. I also don't think that promoting the values to local variables is worthwhile, but given that this is somewhat time sensitive then it might be. I removed that, but YMMV.

My end result looked something like this:

import time
import logging
import functools

class DefaultLogger(object):

    def log(self, level, message):
        print(message)

def doubling_backoff(start):
    if start == 0:
        start = 1
        yield start
    while True:
        start *= 2
        yield start

def no_backoff(start):
    while True:
        yield start

class RetryAndCatch(object):

    def __init__(exceptions_to_catch, num_tries=5, logger=DefaultLogger(), log_level=logging.ERROR, logger_attribute='', delay=0, backoff=no_backoff)
        self.exceptions = exceptions_to_catch
        self.max_tries = num_tries
        self.tries = num_tries
        self.logger = logger
        self.level = log_level
        self.attr_name = logger_attribute
        self.delay = delay
        self.backoff = backoff

    def __call__(self, f):
        @functools.wraps(f)
        def retrier(*args, **kwargs):
            backoff_gen = self.backoff(delay)
            try:
                while self.tries > 1:
                    try:
                        return f(*args, **kwargs)
                    except self.exceptions as e:
                        message = "Exception {} caught, retrying {} more times.".format(e.message, self.tries)

                        instance = args[0]
                        self.logger = getattr(args[0], self.attr_name, self.logger)
                        self.logger.log(self.level, message)

                        time.sleep(self.delay)
                        self.delay = next(backoff_gen)
                        self.tries -= 1

                return f(*args, **kwargs)
            finally:
                self.tries = self.max_tries
        return retrier

As an aside, I wrote a somewhat similar decorator and asked about it here Memoizing decorator that can retry, but the backoff idea is pretty cool and I might incorporate that into mine.


Ensure multiple steps work/saving multiple models via a service

A couple of issues I see here:

What happens if an Author is saved, and then Tomato creation fails? Should the author record remain in the database? (In most cases the answer would be no)
How does a caller differentiate between a successful call and a failure to save an Author? In both cases, call returns an Author object. Would they have to always call author.valid? to check?

  Not raise an ActiveRecord if I can (slow). (Is this something that I am even supposed to think about or am I overkilling this?)

This seems like a micro-optimization to me, I'd use whatever makes code easier to read.

The generic pattern to handle such cases is to use a transaction. Transactions aren't specific to Rails, they are a feature that most databases offer. ActiveRecord supports transactions out of the box.

In your case, this would be reduced to

def create_author_and_tomato!
  ActiveRecord::Transaction.do
    Tomato.create!(tomato_params)
    Author.create!(author_params)
  end
end

If any of those steps fail, the transaction will be rolled back (i.e. all databases changes reversed) before an exception is raised. Also, the Author object is returned if everything succeeds.

If you need to perform a different action if saving one record fails, catch the ActiveRecord::RecordInvalid exception.

begin
  author = create_author_and_tomato!

  # Use `author` for whatever
rescue ActiveRecord::RecordInvalid => e
  # `e.record` can be used to access the invalid object
end


"switch" with intervals to snap to a 15-minute mark

You can do it 'mathematically' like this:

function fixMinutesToQuarter($minutes) {
  return sprintf('%02d',15*(round($minutes/15) % 4));
}

What does it do?

Divide by 15 so the minutes fall in a range from 0.0 to 3.933.
Rounding so it is either 0, 1, 2, 3 or 4.
Take the 'modulo' so 4 becomes 0. See:
http://php.net/manual/en/language.operators.arithmetic.php
Multiply by 15.
Format the output to be two digits with leading zero.

I tested it with this code:

for ($minutes = 0;$minutes < 60;$minutes++) {
  echo $minutes.' gives '.fixMinutesToQuarter($minutes).'<br>';
}

It returns:

0 gives 00       15 gives 15        30 gives 30       45 gives 45
1 gives 00       16 gives 15        31 gives 30       46 gives 45
2 gives 00       17 gives 15        32 gives 30       47 gives 45
3 gives 00       18 gives 15        33 gives 30       48 gives 45
4 gives 00       19 gives 15        34 gives 30       49 gives 45
5 gives 00       20 gives 15        35 gives 30       50 gives 45
6 gives 00       21 gives 15        36 gives 30       51 gives 45
7 gives 00       22 gives 15        37 gives 30       52 gives 45
8 gives 15       23 gives 30        38 gives 45       53 gives 00
9 gives 15       24 gives 30        39 gives 45       54 gives 00
10 gives 15      25 gives 30        40 gives 45       55 gives 00
11 gives 15      26 gives 30        41 gives 45       56 gives 00
12 gives 15      27 gives 30        42 gives 45       57 gives 00
13 gives 15      28 gives 30        43 gives 45       58 gives 00
14 gives 15      29 gives 30        44 gives 45       59 gives 00

In case you can have negative minutes, or minutes > 59 you should limit the range.

If you still prefer your 'if .... else' conditional approach you could now simplify it to:

if     ($temp_minute > 52) $minute = '00';
elseif ($temp_minute > 37) $minute = '45';
elseif ($temp_minute > 22) $minute = '30';
elseif ($temp_minute > 7)  $minute = '15';
else                       $minute = '00';

This can be further shortened by using the ternary operator, but it will then become quite unreadable, and not any faster, so I wouldn't do that.

Personally I prefer the 'mathematical' approach.


One immediate change I'd make is how you're handling errors.  While try-catch blocks are extremely common in other programming languages, I actually don't see them all that very often in Objective-C.

That doesn't mean we won't have errors.  It just means error handling is typically handled differently in my experience with Objective-C.  Just take a look at some of the Foundation methods as example:

stringWithContentsOfFile:encoding:error:

You can send nil as the argument for the error, but otherwise, you send the method an NSError object, and when the method returns, if there was an error, you can check the object to find out what it was.  In the case of an init method, if an error occurred, you'd also want to return nil as well as loading the error description in the passed error object.

For completeness, it seems like it might be a good idea to create a corresponding PDFPage class.  And instead of imageForPage:size: being called over and over to create pages, the end user would create instances of PDFPage.  The PDFDocument in turn isn't much more than an array of PDFPages with some logic for adding a single page, array of pages, remove pages, from front, back, specific index, etc.


This is a utility method. There's nothing wrong with it being static. Its readability would benefit greatly from (a) using guard clauses instead of having multiple nesting levels, (b) using java bracket style, and (c) using java spacing. You might also want to add logging to indicate why there's no signed-in user, which is presumably a WARN or ERROR, but should at least be a DEBUG.

public static int getSignedUpUser() {
    final SecurityContext ctx = SecurityContextHolder.getContext();

    if (ctx == null) {
        LOGGER.debug("No security context available");
        return 0;
    }

    final Authentication auth = ctx.getAuthentication();
    if (auth == null) {
        LOGGER.debug("No authentication available in security context {}", ctx);
        return 0;
    }

    final Object principal = auth.getPrincipal();
    if (!(principal instanceof AUser) {
        LOGGER.warn("Principal {} is not an instance of AUser!", principal);
        return 0;
    }

    final AUser au = (AUser)principal;
    return au.getId();
}


Python algorithm mimicking mark/sweep garbage collection

There are several suboptimal areas of this solution that are interrelated. Please feel free to ask questions if anything I've written here is unclear.

The solution is not "modeling" memory and then performing mark-and-sweep as it probably should be. Instead it is preserving the data-input file in node_pointer_list and repeatedly walking it to find what is needed, because of your for x in node_pointer_list: in node_trace(). This is causing the solution to unnecessarily iterate over the node_pointer_list inside each call to node_trace(), which is making its running time O(N^2) when it should be O(N). It is also making the code 2-3x longer than it should be. Further, the solution is quite hard to read.

I'll try to break down those issues one at a time, though keep in mind they are all interrelated. I'm intentionally explaining rather than providing code, so you can do the learning work to make a better solution. I'll start by talking about code readability.

The way you use if not RepresentsInt(item[0]): to determine if a line is a "pointer" line is very non-intuitive. It would be easier to read if the literal "ptr" appeared somewhere near where you are testing if it is a line containing "ptr", such as:

if item[0].find("ptr") == 0:

Why do you have both "marked" and "traversed" flags? They contain the same information.

A code line like this below, is very hard for anyone to read the meaning of. Someone reading the code is forced to dig around to find out the meaning of the zeroes and ones to understand it.

nodes_dict[x[1]][0] = 1

To make it more readable, you need to get the word "TRAVERSED" in there somewhere, since what you are doing is setting a traversed flag. If you stick with your two element arrays, you can make a TRAVERSED_FLAG symbol to make it more readable, as in:

nodes_dict[x[1]][TRAVERSED_FLAG] = 1

Better style would be to define a class, and give the class a .traversed field. If you also make some of the other changes I highlight below, this access becomes:

current_object.traversed = 1

I don't know if you are comfortable with classes or not, so I'll provide one explanation based on classes, and one based on arrays...

With Classes

You can put the marked field, and the list of an object's references in a single class that represents a memory position in your heap. The class definition would look something like:

class MemoryObject:
    def __init__(self):
        self.marked = 0
        self.references = []  # list of either <int> or <MemoryObject>

First you would instantiate an array of these for the number of memory-spaces according to your data-file, with an additional one as the RootMemoryObject. Then you would walk the file's references, adding to each MemoryObject's references list. You can either store an int reference in the list, and look it up later, or you can look up the MemoryObject now and store that directly in references. When you see a "ptr" entry, you put that in the RootMemoryObject.

The first step of mark-and-sweep is to walk all memory locations and set .marked=0. Then you would call node_trace(RootMemoryObject), which would mark the object visited, and recurse through the objects referenced by that object's .references. Because you have the list of that object's references, you don't need the inefficient loop for x in node_pointer_list:.

Without Classes

Instead of node_pointer_list, you want an array of lists of references. As you walk the datafile, you would insert each reference into the appropriate list for that pointer number. Further, you want an additional "root_references" list to hold references which appear in "ptr" entries.

To start the recursion, you would do for reference in root_references: node_trace(reference), which would mark the reference visited (returning if it was already visited), then look up each child reference and recursively call node_trace(child_reference) on it. Because you have the list of that object's references, you don't need the inefficient loop for x in node_pointer_list:.

Other Factors

The running time you are shooting for is O(N), where N is the number of nodes in your memory. You are currently O(N^2). After you remove the extra loop in node_trace(), you will be properly O(N) because you already have a check to be sure you're not traversing a set of children more than one.

Using recursion is good. An alternative is to use a work-list. To use a work list, you put the root(s) in a list, and then while the work-list is non-empty, you remove an item from the work-list and call node_trace() on it. node_trace puts any child nodes that need to be visited into the work list, and exits.

Both will have the same O(N) running time, but can potentially have different memory consumption. The recursive version's maximum memory consumption is proportional to the depth of object references. The work-list version's maximum memory consumption is hard to calculate, as it can be wildly different based on how you prioritize the work list and what your in-memory objects look like.

If you have 1000 objects in a linked list, each pointing to the next, the work-list will only require 1 entry, whereas the recursive version will require a 1000 depth stack. However, if instead you have 1 object with 999 pointers to leaf objects, then the recursive version will only require a maximum of 1 stack frame, while the work list will have a maximum of 999 entries. So you can see neither is better universally, there are just tradeoffs.


The standard trick is to skip portions of the search space that cannot bring a better solution than the ones found so far. For this you need to:

Remember the best solution found so far (or several best solutions, if you want).
Estimate an upper bound on possible scores that can be achieved from a given game state.

Then, given a partial game state, you compare the estimated upper bound to the current best solution, and if it's lower, there is no need to process the game state. The better the estimate, the more unnecessary processing is skipped.

Depending on the game it's might or it might not be possible to make a precise estimate. If it's not possible, you can use approximate examples. But there is a trade-off: The less precise estimate the higher chance you'll miss the best solution (but most likely the returned solution would be good enough).


Well, at least you know what's wrong here:

#include <string> //random headers because it's been awhile :P

You actually need: <iostream>, <string>, <ctime> and <cstdlib>.
You are using using namespace std;.
That's a bad idea, read "Why is “using namespace std;” considered bad practice?".
It's safer and more flexible to use a std::vector, though admittedly insignificantly less efficient.

std::vector<std::string> names;

There's no good reason why you first generate all the data and safe it in memory just to dump it all afterwards in one go.
There's a reason while(!found_end) {read_some_more; process_it;} doesn't work:
You only know you have reached the end after you tried to read beyond it.

for (std::string line; std::getline(myFile, line) && !line.empty(); )
    names.push_back(std::move(line));

If you extract the code to read names from a file into a function your code does not only get cleaner, you can also reuse it.
You are re-seeding the old toy-RNG repeatedly in a relatively tight loop. Can you see where that might not be all that great for randomness?

Anyway, C++11 provides far better RNGs in <random>. See "Seed std::mt19937 from std::random_device" for how to properly seed one.
Ending main with return EXIT_SUCCESS; is equivalent to ending it with return 0; which can be omitted (but only for main).

Following my suggestions lets you loose <ctime> and <cstdlib> but adds <vector>, <utility>, <functional>, <random> and <algorithm>.

#include <iostream>
#include <string>
#include <vector>
#include <utility>
#include <functional>
#include <random>
#include <algorithm>

static std::vector<std::string> read_names(const std::string& filename)
{
    std::vector<std::string> names;
    std::ifstream file(filename);
    for(std::string name; std::getline(file, name) && !name.empty(); )
        names.push_back(std::move(name));
    return names;
}

static const std::string& choose_any(
    std::mt19937& rng,
    const std::vector<std::string>& names
) {
    return names[std::uniform_int_distribution<size_t>(0, names.size() - 1)(rng)];
}

static std::mt19937 ProperlySeededRandomEngine()
{
    std::mt19937::result_type random_data[std::mt19937::state_size];
    std::random_device source;
    std::generate(std::begin(random_data), std::end(random_data), std::ref(source));
    std::seed_seq seeds(std::begin(random_data), std::end(random_data));
    std::mt19937 seededEngine (seeds);
    return seededEngine;
}

int main()
{
    auto firstnames = read_names("firstnames.txt");
    auto lastnames = read_names("lastnames.txt");
    auto rng = ProperlySeededRandomEngine();
    for(int i = 0; i < 10; ++i)
        std::cout << choose_any(rng, firstnames) << ' '
            << choose_any(rng, lastnames) << std::endl;
}


As Dvorak said in the comments, your code is fine as-is. Still, I have some suggestions:

I'd forego the *Cookie suffix on the function names. Seems too verbose, considering the constructor is called Cookies already. Only trick is that you can't have function called delete as that's a reserved word, but remove works fine too.
I think you have a bug: In deleteCookie you call your own setCookie with a negative lifetime - but setCookie doesn't take a lifetime argument, so the cookie won't be deleted as expected.
I'd fix this by adding such a 3rd argument to setCookie but making it optional:

function setCookie(name, value, lifetime) {
  var date, expires = '';
  // default to cookieLifeTime if no arg was passed
  if( typeof lifetime !== 'undefined' ) {
    lifetime = cookieLifeTime);
  }
  if( lifetime ) {
    date = new Date();
    date.setTime(date.getTime() + lifetime);
    expires = '; expires=' + date.toGMTString()
  }
  document.cookie = name + '=' + value + expires + '; path=/';
}

The getCookie can be made considerably shorter with a bit or regular expression magic.

function getCookie(name) {
  var pattern = new RegExp(name + '=([^;]+)', ''),
      match = document.cookie.match(pattern);
  if(match) {
    return match[1];
  }
  return null;
}

As RoToRa says in another answer, a simple object literal might be neater, if you're willing to either skip the cookieLifeTime instance variable, or make it completely global. Here's how I'd probably write it:

// lowercase, as it's no longer a constructor
window.cookies = {
  set: function (name, value, lifetime) {
    var date, expires = '';
    // for mysterious reasons `NaN` is a number in JS,
    // so check for NaN too
    if( typeof lifetime === 'number' && !isNaN(lifetime) ) {
      date = new Date();
      date.setTime(date.getTime() + lifetime);
      expires = '; expires=' + date.toGMTString()
    }
    document.cookies = name + '=' + value + expires + '; path=/';
  },

  get: function (name) {
    var pattern = new RegExp(name + '=([^;]+)', ''),
        match = document.cookie.match(pattern);
    if(match) {
      return match[1];
    }
    return null;
  },

  remove: function(name) {
    window.cookies.setCookie(name, '', -1);
  }
};


I think the solution reads better if you separate concerns a bit more instead of rolling it all into one mega function.

For instance, with these helper functions (that each do one—and only one—thing):

let fib =
  Seq.unfold
    (fun (cur, next) -> Some(cur, (next, cur + next)))
    (0I, 1I)

let isEven n = n % 2I = 0I

you can express the solution at a high level (almost at the level you would explain it in words!):

fib                                        //given the set of fibonacci numbers
|> Seq.filter isEven                       //take those that are even
|> Seq.takeWhile (fun n -> n <= 4000000I)  //not exceeding 4,000,000
|> Seq.sum                                 //and sum them


There's a few things that can be reviewed:

Your indentation and spacing are incorrect, use JSFiddle's TidyUp function to clean it up.

All of the e.keyCode == matches shouldn't be matched to magic numbers, but moved to a kind of enum or something similar:
var KEYS = {
    Enter: 13,
    DownArrow: 40,
    UpArrow: 38
};
// ...
if (e.keyCode == KEYS.Enter){

suggList:
Don't sacrifice readability for a few characters: suggestedList is more than fine.

console.error:
Instead of console.error, use throw instead: console.error('No sourceList provided for customAutoComplete') into: throw 'ACError: No sourceList provided for customAutoComplete'


No more Fizzbuzz. How about Hello World instead?

Just a slight optimization: instead of evaluating the modulo twice just declare two booleans an evaluate them upfront.

Public Function Convert(ByVal number As Integer, _
                        Optional ByVal fizzDivisor As Integer = 3, _
                        Optional ByVal buzzDivisor As Integer = 5, _
                        Optional ByVal fizzWord As String = "Fizz", _
                        Optional ByVal buzzWord = "Buzz")

    Dim fizzState As Boolean
    fizzState = (number Mod fizzDivisor = 0)

    Dim buzzState As Boolean
    buzzState = (number Mod buzzDivisor = 0)

    If fizzState And buzzState Then
        Convert = fizzWord & buzzWord
    ElseIf fizzState Then
        Convert = fizzWord
    ElseIf buzzState Then
        Convert = buzzWord
    Else
        Convert = number
    End If

End Function

Also you may not want to include as many newlines in the arguments as I did but you don't want a line over 200 characters long or use a horizontal scroll-bar.


It is difficult to tell "which one is better". As Jan mentioned in a comment:

"tell which one is better" - what does "better" mean? performance? code readability? ... ?

The notion of better is subjective.
I am drawn to the first solution as it uses the fewest lines, though readability suffers because the lines are quite long and there are nested ternary operators.
I notice Solution 2 uses ES6 features like arrow functions (as all solutions do) yet it uses the var keyword. Some believe there is no use for var in modern JS. The variable newLines could be declared with const if instead of re-assigning it in the else if block the length property was set to 0 to truncate it and the mapped values were spread into a call to the push method. Using const instead of let helps avoid accidental re-assignment and other bugs.


Merging three CSV files with a primary key

if it's really your first time coding, then that's great: you actually managed to use some parts of the Python standard library that people being exposed for the first time to the language tend to needlessly reinvent, such as the csv module :)

Python version

The first big question: you used Python, but why did you use the version 2.7? This version (minus the bugfixes) is already 5 years old and its maintenance should have been dropped this year (it has been extended to 2020 since it's still widely used). But if you start from scratch, you might as well start with a fresh new version, such as Python 3.4. Generally speaking, don't use Python 2.7 unless you're forced to (there are still reasons); try to adapt to the most recent version instead.

Commented out code

Generally speaking, you should never leave commented-out pieces of code in your code. They will only hinder readability. I must admit that you probably don't use source control source control software if it's your first time programming, but you might want to look at software like Git in the future so that every version of your code is saved somewhere and you don't have to keep outdated remnants of code in your source.

Useless stuff in general

More generally, remove from your code what is unneeded, such as unused variables or unused includes. In your case, you could get rid of the re, os and time imports: you don't use re, you only use os in commented-out code that shouldn't belong, and what you use from time is actually also available in datetime.

The with statement

One thing that is easy to forget is closing files. You didn't forget to close them, which is great, but Python provides a superior alternative to closing files in the form of the with statement. Here are your first lines of code rewritten with it:

with open("Welcome-"+yesterday.strftime('%Y%m%d')+".csv","wb") as f:
    output=csv.writer(f)

    for row in new_data:
        output.writerow(row)

As you can see, I didn't manually call f.close(), this is automatically done when we leave the with block. Actually, with isn't limited to closing files, it can do many other things, but it depends on the type you use it with.

Use the PEP 8

Python has a style guide which is rather good and people tend to follow it. Therefore, you could try to rewrite your code following that style guide so that it looks more like what people want to read when they read Python code. For example, I will rewrite once again the previous piece of code, following the PEP8:

with open("Welcome-" + yesterday.strftime('%Y%m%d') + ".csv", "wb") as f:
    output = csv.writer(f)

    for row in new_data:
        output.writerow(row)

Basically, it's still the same. I only added spaces. But even those can matter when you read code :)


Dictionary Key look up with variable length inputs

Code duplication is a sin

You could use shorter and more readable code using a simple for loop:

int applicationIdentifier = Convert.ToInt16(pi.Substring(1,4));
for (int i = 100; i >= 1; i /= 10)
{
    int maybeId = applicationIdentifier / i;
    if (gs1AiDict.TryGetValue(maybeId, out aiDataOut))
    {
        id = aiDataOut.Item1;
        format = aiDataOut.Item2;
        func = aiDataOut.Item3;
        abrv = aiDataOut.Item4;
        return;
    }
}
Console.WriteLine("No Application Identifier found!");

You should also consider making your data object something along the lines of a Dicitionary<int, ApplicationInfo>, that 4-member tuple doesn't help readibility. Then you could also return an ApplicationInfo object instead of copying the fields to local variables.


Initializing global object from one thread and waiting for it in other threads

Seems reasonable to me. Just a few nits first:

You should never using namespace std; in real code. Just write std::string, and so on. It'll save your readers some confusion, and it'll avoid subtle bugs related to ADL that you'll only learn about much later in life.
using namespace std::chrono_literals is presumably a type for using namespace std::literals or maybe using namespace std::literals::chrono_literals.
You've got some spurious semicolons: }; should be } in at least one place.

Unless the value of the bool being passed through the future — true or false — is meaningful, it shouldn't be part of your program. In this case you could (and therefore should) be using std::shared_future<void> instead of std::shared_future<bool>.

There is a simpler and therefore perhaps better thread-synchronization mechanism, if all your threads are launching from the same spot at the same time. Use a mutex which is locked when the threads spawn, and force each thread to "check in" by locking that mutex before it's allowed to continue. For example:

// global A object which threads of type B want to use
std::unique_ptr<A> gA;

void initA(std::unique_lock<std::mutex> lk)
{
    // do setup here

    gA = std::make_unique<A>();

    // now signal that it's okay for the B threads to start
    lk.unlock();
}

void funB(std::string name, std::mutex& checkpoint)
{
    // do initial setup here

    checkpoint.lock(); checkpoint.unlock();

    gA->talk(name);
}

int main() {
    std::mutex checkpoint;
    std::unique_lock<std::mutex> lk(checkpoint);
    auto tB1 = std::thread(funB, string("B1"), std::ref(checkpoint));
    auto tB2 = std::thread(funB, string("B2"), std::ref(checkpoint));
    auto tB3 = std::thread(funB, string("B3"), std::ref(checkpoint));
    initA(std::move(lk));
[...]

Notice that the lk.unlock() in initA isn't strictly needed, as written, because the destructor of lk was going to drop that lock anyway. But you could put more code after lk.unlock() if you had more things to do that didn't affect gA.

Also notice that I'm using make_unique instead of reset(new ...). Always prefer to use make_unique and make_shared instead of raw new and delete — again because it helps avoid subtle exception-related bugs which if you're lucky you'll never see in the wild; but also because if you get in the habit of never writing new or delete yourself, you'll be able to spot more easily when other people's code incorrectly uses new or delete. Ideally, you want to get in a situation where you can install a git commit hook that does a git grep \bnew\b and fails if it finds any!


Trying to find a better way of finding something rather then looping through list from top to bottom.

Can your context rules be precomputed into any sort of hierarchical match tree once at application initialization?

HashMap<String, HashMap<String, List<ContextRule>>> contextRuleMap

public boolean match (Context context, Map<String, Map<String, List<ContextRule>> contextRuleMap)
{
    Map<String, List<ContextRule>> rulesByApplication = contextRuleMap[context.getUser()];

    for (ContextRule contextRule : rulesByApplication[context.getApplication()]) {
         // Existing logic for remaining 'match' of service and operation
    }

    return false;
}

You can pre-compute your 'match tree' to as many 'levels deep' as you need to by User -> Application -> Service -> Operation to achieve the necessary performance.


Your algorithm is not efficient (thats the brutal part of the answer).

Searching in a list of  t values is a task that can be accomplished using O(log(t)) comparisons. Here we have t=m*n values so it should be accomplished using O(log(m*n)) = O(log(m))+O(log(n)) comparisons. I suspect your algorithm may execute the while loop about matrix.length times so it is not O(log(m)) (where m is the number of rows).

The algorithm could work in the following way:

if the searched value is smaller then the first column in the first row then the searched value is not contained in the matrix.
Then do a binary search on the first column of the matrix to find the largest  entry smaller or equal to the searchd value
if the value found macthes you are done.
otherwise do a binary search on the row found.
if the value found matches the searched value you are done
otherwise the searched value is not in the matrix

Annother way is to treat the problem like a single dimension sorted array as it is proposed in the comment of @Azar.

Even a small piece of code can have a lot of errors so it does make sense to try to use library methods to accomplish this task and not implement the binary search by yourself (but I don't know if this is the intention of the poser of the problem).

This blog entry discusses an example of a buggy implementation in Java. It references the following SUN  bug report because there was an errornous implementation of the binary search even in the JDK.


Naming
The method name load_Directory_Files is a bit odd. To follow general Java naming conventions, it would be something like loadDirectoryFiles. This is called camel case.
File filtering
You can use a FileFilter to accept or discard files for the
listFiles call, no need to do it yourself:
import java.io.File;
import java.io.FileFilter;
import java.util.List;
import java.util.Arrays;

public class VideoOrDirectoryFilter implements FileFilter {

    private static final List<String> ALLOWED_EXTENSIONS = Arrays.asList(
        ".mp4",".ts",".mkv",".mov",".3gp",".mv2",".m4v",".webm",
        ".mpeg1",".mpeg2",".mts",".ogm", ".bup", ".dv",".flv",
        ".m1v",".m2ts",".mpeg4",".vlc",".3g2",".avi",".mpeg",
        ".mpg",".wmv",".asf"
    );

    @Override
    public boolean accept(File file) {
        return file.isDirectory()
            || ALLOWED_EXTENSIONS.contains(file.getName().toLowerCase());
    }
}

Null check
In loadDirectoryFiles, you can return early if the listFiles call is null:
File[] files = directory.listFiles(new VideoOrDirectoryFilter());
if (files == null) return;

Looping
Instead of the for loop with an index variable, you could use a foreach loop. That makes for cleaner code, as you directly get the object in the list. Also, you don't need to check the length of the list before looping. If it's empty, the loop will be a no-op.
for (File file : files) {
    // Do your thing with file here
}

Reimplementation
Here's a reimplementation of the loadDirectoryFiles method with the above enhancements included.
public static void loadDirectoryFiles(File directory) {
    File[] files = directory.listFiles(new VideoOrDirectoryFilter());

    if (files == null) return;

    for (File file : files) {
        if (file.isDirectory()){
            loadDirectoryFiles(file);
        } else {
            Constant.allMediaList.add(file);
            String fileName = file.getName();
            String size = Function.humanReadableByteCountSI(file.length());
            String duration = Function.getDurationFF(file.getAbsolutePath());
            String folderName = file.getParentFile().getName();
            String path = file.getAbsolutePath();
            Log.d(TAG, "load_Directory_Files: "+ duration + "" +size + "" + fileName);
            Constant.allMediaListWithModel.add(new AllVideoModel(fileName, path, folderName, size, duration));
        }
    }
}


Review

Python and recursion are not the best match, instead use loops
It could even be done with list comprehension
return [ip if ip not in exclude for ip in subnet]

Alter your imports to use one of the two not both
I suggest to use from ipaddress import IPv4Network because that seems to be only thing imported from the library.

Use sets!
Lists are O(N), while sets are O(1)!
Secondly it's quite easy to subtract sets simply use set(c) = set(a) - set(b)

Example
from ipaddress import IPv4Network

exclude = set(IPv4Network('1.1.0.0/25')) | set(IPv4Network('1.1.0.128/26'))
net = set(IPv4Network('1.1.0.0/24'))

print(net - exclude)