Reading a list of file paths and adding them to a map

Looks good overall (though I'm by no means a C++ expert).

In coming brain-dump though:

void argument lists are rare in C++. Yes, in C, int c() and int c(void) are different, but in C++, that's not the case. In C++, int c() is implicitly the same declaration as int c(void).

The no-op statements on argv and argc jump out as odd. If you did that so a warning of an unused variable won't be issued, you could always use one of the alternate main declarations (i.e. int main().

Opinion again, but I'm not a fan of comparison to booleans: if (file_name(s, name) == false).  It reads more easily as if (!file_name(s, name))

This might be on purpose, but the path property of filedata can be mutated from outside:

filedata f("name", 10);
f.filepath() = "new";

I would probably make these objects immutable since they seem to be value objects (I think you probably intended to do this, just non-intuitive references got you).

You should return either by value or by const reference from filepath. Even though it will create a usually unnecessary copy, I highly suggest the value route. If you return a const reference, you run the risk of a dangling pointer. Consider this (bad) example:

filepath* f = new filepath("blah", 10);
const std::string& s = f->filepath();
delete f;
// Any use of s past here is undefined behavior

s is essentially a const pointer to f->path. This means that when f is released, s becomes invalid. Note that if you immediately create a copy of a string based on the constant reference [i.e. if you had std::string s = ...] this does not apply. That still creates a copy though, so you might as well return a value.

(Also, obligatory note: raw pointers have very few legitimate uses in C++. Avoid pointers if at all possible, and use a smart pointer when not. The only (possible) exception is low level container implementations.)

I'm not a fan of print style member functions.  In this application this aversion doesn't make sense, but imagine if some third party library you used provided print methods for some of it's classes.  Do you think it would print out in exactly the format you want?  I prefer to use helper-type functions for printing rather than putting it as a member of the class.  (Though once again, on this application since it's so small, it matters nothing at all.)

(Oh, and this once again is opinion.)

filedata (void) : path(""), size(0) { }
filedata (const string& p, size_t s) : path(p), size(s){ }
filedata (const filedata& f) : path(f.path), size(f.size) { }

There's a bit of redundancy here.  Technically you could write this just as:

filedata (const string& p = "", size_t s = 0) : path(p), size(s){ }

Or if you wanted:

filedata (const string& p = string(), size_t s = size_t()) : path(p), size(s){ }

Though I'd probably go with the first.

The copy constructor doesn't need to be defined since it's the same as the implicit one. When using the same functionality as the implicit one, do not define one. The implicit one isn't prone to typos or a future failure to update the copier to reflect new properties.

I would give more descriptive names to p and s:

filedata (const string& path, size_t size) : path(path), size(size) { }

I'd probably go with something like uint64_t instead of size_t since size_t will probably be 32 bits on a 32 bit system. If you'd like to abstract away exactly what the type is, you could have a typedef ... size_type member of your class. Not only does that offer a more semantic meaning, it allows for easier future change (assuming consumers actually proper use the typedef...).

I tend to declare define the end of an iterator up front:

for (auto i = files.begin(), end = files.end(); i != end; ++i) {

Not only does it potentially offer a tiny performance advantage (though not really on any modern compiler), it has clearer meaning. With this version, there much more suggestion that end is not mutated inside of the loop (though it's still not guaranteed since end isn't const).

std::begin and std::end should be preferred in C++11. They have all the capabilities of the member-function versions plus a bit more.

stat failing probably shouldn't just return a size of 0.  You might end up accidentally deleting a file if something weird happens.  (Then again, most of the reasons stat would fail would also cause an attempt to delete a file to fail.)

If you had the input include the file sizes, you could reduce your program to pure text processing.  I'm also not sure if your program should be emitting rm commands.  Seems like a coupling of sorts.  Then again, the output would just be transformed into rm commands anyway, so might as well do it directly I guess :).

The data put out on stdout seems to be debugging-esque information whereas the stderr data seems to be what you're actually after.  Seems like these streams should be swapped.

I'd be tempted to use a reference instead of copying the item in the map:

filedata f(files[name]);

Could be:

filedata& f = files[name];

The performance difference is going to be non-existent; mostly just a (opinion-y) style thing. It would also allow you to simplify the reassignment from files[name] = ... to just f = ....

The filesize member of filedata can't permute size, so you might as well have the method be const.  Same for filepath() if it wasn't meant to allow the perumtation of path (as mentioned earlier).

Another personal-style thing: I don't like implicit visibility scoping:

class filedata {
    std::string path;
    size_t size;

os << size << " " << path << "\n";
return os;

Can be simplified to:

return os << size << " " << path << "\n";


Trait accessing variables of classes using it

Though you now have seen the light, and know not to use traits in this way, I'm going ahead and post my review here anyway. I'll be updating it along the way, seeing as this is something I can rant on about for some time.
Your trait suffers from a couple of (severe) issues:

It constitutes both a breach of contract, and enforces a bad contract.
Traits requiring properties are like using global in a class
It's not a valid use-case for a trait. At all.
Its namespace is wrong

Now these are just the first things I could think of, each of which are problematic enough to ditch the trait as you rightfully did.
Allow me to explain, though, what these one-liners mean:
Breach of Contract + enforcing a bad one:
Classes define a contract. That's a given. If you pass an instance of class X to a function, you make a deal with that function. You're essentially saying "This object has this specific job, and you can call these methods on it, and/or access these properties". When you extend a class, it's important to respect the contract. You can add things, but never change the promises made by the base class.
If the base class' constructor, for example, expects 1 argument of the type array (enforced through type-hinting), then all of its children should either use the same constructor or, if they choose to override it, define a constructor that takes 1 array argument. They are allowed to loose the type-hint, but may not change it. They're free to add optional arguments, but can't force additional arguments to be passed to the constructor:
abstract class Base
{
    public function __construct(array $param)
    {}
}
class ValidChild extends Base
{}
class AnotherChild extends Base
{
    public function __construct(array $param, $opt = null)
    {}
}
class IffyButTheoreticallyFine extends Base
{
    public function __construct($param, array $opt = null)
    {}
}

These are all valid child classes, however: these are not. They are evil, but sadly commonplace:
class Bastard extends Base
{
    public function __construct()
    {
    }
}
class Ungrateful extends Base
{
    public function __construct(array $param = null)
    {}
}
class EvilTwin extends Base
{
    public function __construct(stdClass $param)
    {
        parent::__construct( (array) $param);
    }
}
class Psychopath extends Base
{
    public function __construct(PDO $db, array $parent = null)
    {
        if (!$parent) {
            $parent = [1, 2, 3];
        }
        parent::__construct($parent);
    }
}

Now, how does this apply to your case? Simple: A trait is a tool to reduce code-duplication. It's a nugget of often-needed functionality that a class (a contract) includes/uses to do its job. For a class to use a trait, the trait has no right to define that class' contract. A trait's relation to its user is, in some way, the same as that of a child's towards its parent: it's the child that inherits the contract, not the parent. Therefore, it must follow that any class, regardless of its job, has to be able to use a trait, without having to change its own contract and dependencies.
Your trait, then is not a valid use-case: all of its users are required, by definition, to add a $this->container property to its dependencies, which will of course have an impact on that class' contract and the contract of its children.
A new global in drag
I think it's safe to say that it's universally accepted that a class definition containing global $someVar is a tell-tale sign of bad code. A class is scoped, its methods are scoped and neither of them should rely on the global scope to function. The same applies to a trait: because it can be used in a variety of classes, a trait must be context (and scope) agnostic. If it requires a property to be present, the trait must define it. If that property has to be of a particular type, the only thing you could do is define a property, and enforce an abstract setter for it, which imposes type restrictions. However, this is unreliable, given that multiple traits can be used, it might cause conflicts with the user and the class itself has direct access to the property, too. Lastly: this approach brings us back to square one: a trait like this is no longer a trait.
This implies that a trait cannot have dependencies. If a trait has a dependency, it ceases to be a trait: it's either an abstract class, or an Interface, but definitely not a trait. There is, however a tiny sliver of grey-area here:
Whilst it's not my idea of best practice, one might argue that it's acceptable to write a trait, to be used in tandem with an Interface, for example: a single Interface that ensures data models are traversable, like the IteratorAggregate interface. In that case, a trait like this could perhaps be acceptable.
trait IteratorAggregateTrait
{
    public function getIterator()
    {
        if (!$this instanceof IteratorAggregate) {
            throw new \LogicException(
                sprintf(
                    '%s must implement IteratorAggregate to use %s',
                     get_class($this),
                     __TRAIT__
                )
            );
        }
        return new ArrayIterator($this);
    }
}

Valid use-case
For reasons I've explained above, it's clear that your example isn't something best handled with traits. It might be useful at this point to serve up a small, 100% valid example of a trait. Suppose you've got some models that represent either a DB record, user input (form data), or something else entirely. All of these models contain user information, including an email address. A model with setters is ideal to ensure that, whenever some data is gathered, that data is then validated (ie filter_var($email, FILTER_VALIDATE_EMAIL)). Because these classes represent different things (db record or form), they're likely to inherit from an abstract class already. Rather than duplicating the email setter, a trait can be used:
trait UserDataTrait
{
    public $email = null;
    public function setEmail($email)
    {
        if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
            throw new \InvalidArgumentException('bad email');
        }
        $this->email = $email;
        return $this;
    }
}

Wrong namespace
Just a little nit-pick: I don't like the fact that your trait is defined in the Model namespace, while it's pretty clear that it can't be used anywhere else but in the controller.

Update
Time for an update. While I stand (firmly) by what I've stated previously (traits not being in a position to impose a contract), there are certainly people who will argue that they can. Not in the least because PHP's trait construct enables you to declare abstract methods:
trait Evil
{
    protected $dependency = null;
    public function someMethod()
    {
        return $this->dependency->getValue();
    }
    abstract public function setDependency(SomeType $dep);
}

This trait, then, imposes a partial contract on its user: the class that uses the trait must define the setDependency method. So what's the problem, you might say? The problem is simple: traits were introduced to solve supposed problems that might require multiple inheritance, hence a class can use more than one trait, and it's possible for the class to resolve conflicts regarding method names by itself. So let's assume the trait above is being used, and you have a couple more traits lying around, one of which looks like this:
trait Pure
{
    public $dependency = null;
    public function setDependency(Container $container)
    {
        $this->dependency = $container;
        return $this;
    }
}

Now, imagine you have a class that uses both these traits (assume Evil::setDependency is not declared abstract here):
class FromHell
{
    use Pure, Evil {
        Pure::setDependency insteadof Evil;
    }
}

Congrats, the contract imposed by the trait is broken, along with its functionality, simply because the class has chosen to adhere to the contract imposed by Pure. It doesn't take a rocket scientist to realize that traits, whilst they can, in theory, impose a minimal contract, are not as potent at ensuring the contract is adhered to.
Now this was a simple example, but if you want a more plausible scenario: Assume 2 traits, A and B, both define a method logError, A::logError writes to a default log file, B is more generic, and expects you to pass a resource as an argument, or writes to stderr by default.
Because your project is rather large, you're dealing with multiple levels of inheritance and at some point, some classes end up implementing both traits. Of course, depending on what class it is, either A::logError is given a higher precedence, or B:logError. The latter is more likely to be used in workers/crons/backend code.
It's very likely that your project, seeing as you're relying on traits so much, contains code that looks like this:
$traits = class_uses($object);
if (isset($traits['A']))
{
    $object->logError('The error string');
}

Now if this object has chosen to override A::logError with B::logError, you'll probably waste a lot of time trying to work out why on earth logError doesn't write your error messages to the default log. In short:
Trait contracts are weak suggestions, and can be overridden easily
Back to the definition of abstract methods in a trait: I'll have to test it a bit more, but AFAIK, that's just bad design. Either an abstract class contains your abstract methods (because a class enforces a strong contract), or you implement the method in the class from the get-go. A trait is supposed to reduce code duplication, whereas an abstract method requires you to re-write the method's signature and implementation whenever you use the trait. If that's what you want, why bother using a trait in the first place?
The other issue I have with this is one I'll look into a bit more when I find the time, but classes can be composed out of 1 or more traits, and contain no other definitions of their own. That's fine, but what if we look at our 2 traits above (Pure and Evil). Is Pure::setDependency a valid implementation of the abstract Evil::setDependency method? If so, will that trait method be regarded as an implementation of the abstract method? If not, traits containing abstracts can't be used in classes that contain no definitions of their own, and therefore, such traits are special cases (because their usage is limited).
If Pure::setDependency is a valid implementation of the abstract method in Evil (Container being an alias of SomeType, or its parent class), and traits can be used to implement abstract trait methods, then another issue presents itself: maintenance HELL: Changing either one of these traits could break your code, depending on how, and where the traits are being used. You'll end up having to test all classes using both traits, whenever you change just one trait. When you look at it like that, I'd say some code duplication is the lesser of two evils.


If you can us the timeupdate event to detect start and finish events you could use a single event listener block.  You could also put the events an an array and increment the current position in the video being listened for.  Something similar to this:

function bindVideoEvents(ids) {
    var _events = [
        { time: 0.00, name: 'Started' },
        { time: 0.25, name: '25% Watched' },
        { time: 0.50, name: '50% Watched' },
        { time: 0.75, name: '75% Watched' },
        { time: 1.00, name: 'Finished 100%' }
    ];
    var _evPos = {};

    $.each(ids, function (idx, id) {
        _evPos[idx] = 0;
        $('#' + id).on('timeupdate', function () {
            var currentEvent = _events[_evPos[idx]];
            if (this.currentTime > (currentEvent.time * this.duration)) {
                console.log(currentEvent.name);
                ga('send', 'event', 'Videos', currentEvent.name, 'Video');
                _evPos[idx]++;
            }
        });
    });
}


Creating many random test database entries

It feels like (SELECT project_id FROM projects ORDER BY RAND() LIMIT 1) stands for "get random but still valid project_id". You could probably just iterate over all of your projects (with no randomness) and for every project add a random number of records. I don't think it affects your intention but this will probably work faster.


Here are my comments:

You should be passing in and choice as const reference to avoid unnecessary copies.
size should be of type size_t. In general, make sure you take care of whatever warnings the compiler throws at you.
Before we even come to algorithmic performance: are you sure this code works? I just did a bit of mental debugging, and it seems like you'll have an infinite recursion, since choice's size will never be zero. I'll assume for now that you accidentally commented out the line that erases from choice.
You have a defect in the code: consider a vector of [1, 1, 2, 2]. You'll return two permutations of [1, 2] [2, 1], while presumably you need [1 1 2 2] [1 2 1 2] etc. etc. This is because you delete all members of the same value from the vector rather than just delete at one index.
Indeed, there's way too much copying going on. If your goal is just to print all the permutations, or send them to some kind of consumer, then you should preallocate a single out vector, and replace members at given positions as you go through your recursion.


Refactor 2 regular expressions in Javascript into 1 statement

Shouldn't this work:

var dirty_url = ui.item.label;
var url = dirty_url.replace(/[-\s]+/g,'-')

Or, for more thorough:

var url = dirty_url.replace(/[-\s@#$%^&*]+/g,'-') // etc...

Though at this point, you might just want to remove all non word characters:

var url = dirty_url.replace(/\W+/g,'-')


An alternative solution could be a binary reader (see also: this code project article)

Implementation: (I just replaced the 2 try catch blocks with one using):

public static void ReadBinaryReader(string filePath)
{
    using (var stream1 = new FileStream(filePath, FileMode.Open, FileAccess.Read, FileShare.None))
    {
        stream1.Position = FILE_HEADER_SIZE; //Start stream after the file header

        using (var reader = new BinaryReader(stream1))
        {
            while (stream1.Position < stream1.Length) //While not at the end of the stream
            {
                var testStruct = FromReader(reader); //read data from binary file into STRUCTHEADER type struct
                stream1.Position += Math.Abs(testStruct.NumBytesThisRecord - STRUCT_HEADER_SIZE); //Advance to the end of current packet
            }
        }
    }
}

private static STRUCTHEADER FromReader(BinaryReader reader)
{
    STRUCTHEADER result = new STRUCTHEADER();
    result.MagicNumber = reader.ReadUInt16();
    result.SubChannelNumber = reader.ReadByte();
    result.NumChansToFollow = reader.ReadUInt16();
    result.Reserved1 = new []
    {
        reader.ReadUInt16(),
        reader.ReadUInt16(),
    };
    result.NumBytesThisRecord = reader.ReadInt32();
    result.Year = reader.ReadUInt16();
    result.Month = reader.ReadByte();
    result.Day = reader.ReadByte();
    result.Hour = reader.ReadByte();
    return result;
}

It is a little bis faster, but not significat... However, if you have to use a binary reader for reading the other content, maybe it is a reasonable alternative to PtrToStructure.

Reading the 6 mb file 60.000 times takes:

  PtrToStructure

  1) 3791 ms

  2) 3807 ms

  3) 3794 ms

  BinaryReader

  1) 3650 ms

  2) 3645 ms

  3) 3668 ms


Using RxJS Observables to mediate routes in nodejs

Are there any down sides to using RxJS on the backend

The way I see it, you get 2 benefits from RxJS

Reactivity
Streaming operations

Observables are effectively a form of event management. They run, listen to things, and execute code when something happens. They're a good way to respond when something happens in the app. However, when used in routing, your observable only lives during the duration of the request-response cycle. You lose all the benefits of a persistent event system when they're short-lived.

This leaves you with streaming operations which isn't something regular functions, promises, array methods and ternaries can't do. When observables are used this way, they effectively become what I call "fat promises". You're better off fully utilizing native constructs than using advanced constructs suboptimally.

Speaking of Node, async and await are available too, which makes life a bit easier:

// Routes
router.route('/').get(async (req, res) => {
  try {
    if (req.headers.data) {
      const res = await services.InviteService.authenticateInvite(req.headers.data)
      // respond with data
    } else {
      // respond with no header data error
    }
  } catch (e){
    // Something else went wrong
  }

});

// Service
class InviteService  {

  constructor(models) {
    this.models = models
  }

  async findInviteById(id) {
    return this.models.Invite.findOne({ where: { inviteId: id } })
  }

  async findUserById(email) {
    return this.models.User.findOne({ where: { email: email } })
  }

  async authenticateInvite(token) {
    const payload = jwt.verify(token, appConfig.SESSION_SECRET)
    const invite = await this.findInviteById(payload.inviteId)

    if(!invite) throw new Error('Invalid Invite ID')

    return invite._isScalar ? invite : this.findUserById(payload.email)
  }
}

module.exports = InviteService;

Also, if you end up doing more comparisons after getting authenticateInvite's return value, that means authenticateInvite is not abstracting correctly. I'd expect that after I call authenticateInvite, it should be boolean. It either resolves (auth passed) or rejects (auth failed) with the error object containing the reason for failure. All business logic (and errors) should go to the service class.


You don't necessarily need classes in Python. The helper class approach is the same direction as I would go, just with a plain module.
Basically, your resource_path and img_folder_path are constants, so I would simply create a module constants.py with the following:

import os

RESOURCE_PATH = os.path.join(os.path.realpath(__file__), 'Resources')
IMG_FOLDER_PATH = os.path.join(resource_path, 'Images')

You can then simply import constants.py everywhere you need to know those paths.


Obviously the code does have some redundancy, which violates the Don't Repeat Yourself principle.
This could be simplified by calling onChange() if allowedInput is falsey or if that is not the case then only when the call to the test method on it returns a truethy value:
const validatedOnChange = (event: ChangeEvent<HTMLInputElement>): void => {
    if (isDisabled) {
        return;
    }
    if (!allowedInput || allowedInput.test(event.target.value)) {
        onChange({ name, value: event.target.value });
    }
};

One could opt to take the return early approach, which might be more readable and decrease the indentation on the call to onChange() but would have an extra line:
    if (allowedInput && !allowedInput.test(event.target.value)) {
        return;
    }
    onChange({ name, value: event.target.value });


If I understand correctly, you want to sort lists by their length first, and then by "whatever lists are otherwise sorted by". I also assume that you want to pass your function as the cmp argument to the list.sort or sorted function.

You can do this in both a more natural to read, and computationally more efficient way, by using the key argument instead:

  In general, the key and reverse conversion processes are much faster
  than specifying an equivalent cmp function. This is because cmp is
  called multiple times for each list element while key and reverse
  touch each element only once.

(Source: https://docs.python.org/2/library/stdtypes.html#mutable-sequence-types)

This should be the appropriate key function for your case:

def length_first(lst):
    return len(lst), lst

Or simply:

lambda lst: len(lst), lst

Example:

>>> from random import randrange
>>> lists = [[randrange(5) for _ in range(randrange(3, 6))]
...          for _ in range(10)]
>>> print '\n'.join(map(str, sorted(lists, key=lambda lst: (len(lst), lst))))
[0, 0, 4]
[2, 3, 0]
[2, 4, 0]
[3, 4, 2]
[4, 1, 4]
[1, 0, 1, 0]
[2, 0, 1, 1]
[3, 1, 0, 4]
[0, 0, 0, 3, 2]
[4, 0, 1, 2, 1]


You can change your array packing to use map instead.

n, k, q = map(int, input().strip().split(' '))

When popping the last element you don't need to pass an argument.
Rather than popping each element, you can perform two slices and an addition. You would also have to use the modulo operator, %, for when \$k \ge n\$.

k %= n
a = a[-k:] + a[:-k]

You don't need to strip a number, as int will do this for you.

This can get you:

n, k, q = map(int, input().strip().split(' '))
a = list(map(int, input().strip().split(' ')))
a = a[-k:] + a[:-k]
for _ in range(q):
    print(a[int(input()])

If you however want some sugar you can use collections.deque, it comes with deque.rotate that can perform the rotation in (3) for you. which can result in:

from collections import deque

n, k, q = map(int, input().strip().split(' '))
a = deque(map(int, input().strip().split(' ')))
a.rotate(k)
for _ in range(q):
    print(a[int(input()])

The above is good enough for the hackerrank challenge, however performs worse than the code above it. Rotating the array is \$O(n)\$, where the deque is \$O(k)\$. But indexing the array is \$O(1)\$, where the deque is \$O(n)\$. This means the first code block is \$O(n + q)\$ and the second is \$O(k + nq)\$. To make the second \$O(n + q)\$ all you need to do is change it to an array before the for loop, via list.

whenever you profile code, you should always take more than one timing, with more than one input. Hai Vu done neither of these.
Using my wrapper to timeit, I wrote some code to profile; deque (Peilonrayz), adding slices (mkrieger), and deleting a slice (Hai Vu), as these are the fastest functions.
However to keep things unbiased I've made a couple of adjustments:

All code will be a Python function in __main__.
All functions work correctly with any \$k\$ and when \$n \ne 0\$. (I use % to do this.)
I run each function 10000 times per timeit.
I run each timeit 10 times, and take the average and interquartile range.

This should give each and every function call the same amount of overhead.
Here is the code that I use to time the functions.

from collections import deque

from graphtimer import time, GraphTimer, flat, time
import matplotlib.pyplot as plt

def mkrieger(a, k):
    k %= len(a)
    return a[-k:] + a[:-k]

def peilonrayz(a, k):
    a = deque(a)
    a.rotate(k)
    return a

def hai_vu(a, k):
    k %= len(a)
    b = a[-k:]
    del a[-k:]
    a[0:0] = b

class Timer(GraphTimer):
    functions = [
        'mkrieger',
        'peilonrayz',
        'hai_vu',
    ]
    inputs = [
        'a = list(range(100)); k = {}'
    ]
    domain = range(1, 101, 1)
    titles = [
        '100'
    ]

if __name__ == '__main__':
    fig, axs = plt.subplots(nrows=1, ncols=1, sharex=True)
    Timer(amount=10, number=10000, stmt='fn(a, k)').plot_axes(flat(axs), show_titles=True)
    plt.show()

Which outputs:


Performing add/delete/count operations on a list

You don't exploit the nature of the question.

  Constraints

  \$1 \le Q \le 200000\$
  \$0 \le s \lt 2 ^ {16}\$

Why are these important? It's so you can achieve greater performance, for a price in memory.

You know that there is \$2 ^ {16}\$ possible numerical inputs,
and there is a maximum of 200000 inputs.

If the last input is count, and all the rest are add,
you will be recounting numbers a lot. Leading to a dramatic performance loss.

First you would want to prevent recounting if possible.
One way to do this is to make a dictionary to count the occurrences of numbers.
However due to constant type changes you can just use a list instead.

lst = [0] * (2 ** 16)

This takes more time than using lst = [], but it will pay off.

If we look at the performance of your 3 functions.
I use the information from Python's time complexity page.

Add

lst.append(num)

This is average case \$O(1)\$, worst case \$O(n)\$, (not amortized worst case).

lst is internally stored as an array,
and so if you grow past the bounds all the data must move.

And so I will say this is \$O(n)\$.

Del

lst.remove(num)

This is average case \$O(n)\$, worst case \$O(n)\$.

And so this is \$O(n)\$.

cnt

for number in lst:
    if number & num == number:
        count += 1
print(count)

And again this is \$O(n)\$.

Overall

You can have 200000 calls to functions that are \$O(n)\$.
If you ask me that's not good on performance.

You can easly make add and del \$O(1)\$.

If you use lst = [0] * (2 ** 16).

if operation == 'add':
    lst[num] += 1
elif operation == 'del':
    lst[num] -= 1

It's like using a default-dictionary where the index is only numbers.
However this currently will have the drawback of cnt always being \$O(2 ^ {16})\$.

If you wish to fix that you can use a set, to store the numbers, so it is \$O(n)\$.

Here is a solution that passes a few more of the tests. It does not pass them all.

operations = int(raw_input())
nums = set()
storage = [0] * (2 ** 16)

for _ in xrange(operations):
    input_ = raw_input().split()
    operation = input_[0]
    num = int(input_[1])

    if operation == 'add':
        nums |= {num}
        storage[num] += 1
    elif operation == 'cnt':
        print(sum(
            storage[number]
            for number in nums
            if (number & num) == number
        ))
    elif operation == 'del':
        storage[num] -= 1

This uses a similar solution as yours, my lst is nums.
However, I aimed at obtaining \$O(1)\$ in both add and del.

I can't complete the problem.
The way Python programmers that solved this use [0] * (2 ** 16) and binary logic I don't know. Which make all the functions \$O(256)\$.


Reverse binary representation of an int (only significant bits)

You could use while loop instead of the for loop.
Thus you don't need to trim zero bits, because it will continue to loop only while there is at least one significant bit in a value.
Another advantage of this approach is that the result can be calculated using integer arithmetics only without using any kind of collections.

static int Reverse(int input)
{
    uint x = unchecked((uint)input);
    uint y = 0;
    while (x != 0)
    {
        y <<= 1;    // Shift accumulated result left
        y |= x & 1; // Set the least significant bit if it is set in the input value
        x >>= 1;    // Shift input value right
    }
    return unchecked((int)y);
}

Usage example:

int t = 0x103;
Console.WriteLine(Convert.ToString(t, 2));
Console.WriteLine(Convert.ToString(Reverse(t), 2));

Result:

100000011
110000001


The elegance of Mathematics:

def sum_below(n)
    n * (n + 1) / 2
end

def sum_squares_below(n)
    n * (n + 1) * (2*n + 1) / 2
end

limit = 1000
puts sum_below(limit) ** 2 - sum_squares_below(limit)

The Math under  n * (n + 1) / 2

We have some natural numbers and we want to find their sum, the list is:

1, 2, 3, 4 ... n

Now we can note that the sum of n + 1 is equal to the sum (n - 1) + (1 + 1) and is in turn equal to (n - 1 - 1) + (1 + 1 + 1). In practice in the following

1, 2, 3, 4, 5, 6

We can see that 1 + 6 == 2 + 5 == 3 + 4 == 7.

We must repeat this (sum that equals n + 1)  (n / 2) times so we arrive to the final formula:

sum_below(n) = (n + 1) * n / 2


Find meaningful words from the input string

I only have one minor objection for the moment...
...
...
Why are you not using dependency injection??
OK, it turned out to be a major one. (I did consider using caps-lock!)
Consider a situation where you would want to do this operation for English words, and then for French words. Instead of using all things static, make a public constructor
private final Set<String> dictionary;

public DictionaryValidWords(Set<String> dictionary) {
    this.dictionary = dictionary;
}

You might consider this as "outside the core part of the code" but it's really not. And it is a very important change to make, class-design wise and best-practices wise.
You could then use a DictionaryFactory class where you could have methods (static or non-static, as you prefer), for exampleDictionary (your current dictionary), english, french, etc...


Testing code that changes the DOM on page load

I think the real issue you are trying to solve is how to test code that has reach over the whole document. Just judging by your small snippet of code, you appear to be at least using "classes". Regardless of how you've written your application, you want to put yourself into this position when unit testing DOM manipulations:

describe("Something", function() {
    var div, something;

    beforeEach(function() {
        div = document.createElement("div");
        something = new Something(div);
    });

    it("modifies the DOM", function() {
        div.innerHTML = [
            '<form onsubmit="submit()">',
                '<label for="fieldPassword">Password</label>',
                '<input type="password" id="fieldPassword">',
                '<input type="hidden" name="username">',
                '<input type="submit" id="btnEnter" onclick="click()" value="Enter">',
            '</form>'
        ].join("");

        something.removeElements();

        expect(div.querySelector("form").onsubmit).toBe("");
        expect(div.querySelector("label")).toBe(null);
        expect(div.querySelector("input[type=password]")).toBe(null);
        expect(div.querySelector("input[type=hidden]")).toBe(null);
        expect(div.querySelector("input[type=submit]").onclick).toBe("");
    });
});

The code under test should have access to some sort of root element, which it then operates on. The beforeEach in your tests would create a new DIV tag, and a new instance of the object you want to test. This class should take the DIV tag as a constructor argument, ideally, but in the very least assign it as a property. Then your test is completely isolated from the rest of the DOM tree. There is no need to clean up these elements because they are all disconnected from the main document.

function Something(element) {
    this.element = $(element);
}

Something.prototype.removeElements = function() {
    this.element.find("#LoginForm").attr("onsubmit", "");
    this.element.find("#btnEnter").attr("onclick", "");

    // Modify form inputs.
    this.element.find("label[for=fieldPassword]").remove();

    this.element.find("#fieldPassword").remove();

    this.element.find("input[name=username][type=hidden]").remove();
};


Create quantile slices from dataframe columns

To answer your questions in order:

Yes: your code could be optimised by calculating .count() (with respect to each slice of pntls) only once per outer loop, instead of n + 1 times (where n is the value of .count()) as per your current implementation. In the full example below, I show how you can use pandas.qcut to make this much more efficient in the add_quantiles function.
Re-using calculations is more efficient, but a procedure that doesn't alter the dataframe is more flexible: in the exmaple below, the calculations are re-used, but the main dataset isn't changed (everything is done from a copy). This may not be desiarable if: (a) you don't intend on using this code for any other purpose (or for more than one use, where keeping the original dataset untouched means you can re-run the procedure), or (b) if the size of the data in memory is large.
It could be improved: if I have understood corretly, the results of calculating col_slice in the inner most loop is actually used hld_per number of times (except when the column being passed to col_slice is within hld_per columns from the end of the dataset). We can reduce the number of calculations of col_slice by a factor of hld_per, therefore, if we re-use the results. In the example I've given below, I show how you can do this to improve performance.
Only if you don't know your data structure ahead of time; you've used indexing by position rather than label to good effect.
Apart from the points above: your code was easy to read (thanks, too, for the detailed question!)!

My suggested re-write using the above suggestions is given below. The main function to run is create_csvs (nb: this uses label indexing instead of the positional indexes that you use - this could be switch out if you prefer). This will create csv files in the same format as your example code.

NB: I have assumed that the order of the rows in each column of the output CSVs doesn't matter. If this does matter, I can suggest a change.

    from collections import defaultdict

    colname = lambda col, suffix: '{}_{}'.format(suffix, col)

    def add_quantiles(data, columns, suffix, quantiles=4, labels=None):
        """ For each column name in columns, create a new categorical column with
            the same name as colum, with the suffix specified added, that
            specifies the quantile of the row in the original column using
            pandas.qcut().

            Input
            _____
            data:
                pandas dataframe
            columns:
                list of column names in `data` for which this function is to create
                quantiles
            suffix:
                string suffix for new column names ({`suffix`}_{collumn_name})
            labels:
                list of labels for each quantile (should have length equal to `quantiles`)

            Output
            ______
            pandas dataframe containing original columns, plus new columns with quantile
            information for specified columns.
        """
        d = data.copy()
        quantile_labels = labels or [
            '{:.0f}%'.format(i*100/quantiles) for i in range(1, quantiles+1)
        ]
        for column in columns:
            d[colname(column, suffix)] = pd.qcut(d[column], quantiles, labels=quantile_labels)
        return d

    def create_csvs(data, columns, hld_per=3, quantiles=4, suffix='quant'):
        """
            Input
            _____
            data:
                the full dataset
            columns:
                the ordered list of names of the date columns
            hld_per:
                holding period
            suffix:
                string suffix for quantile columns (no effect on output)
            quantiles:
                number of quantiles

            Output
            ______
            None

            Effect
            ______
            writes csv files
        """
        quantile_labels = ['{:.0f}%'.format(i*100/quantiles) for i in range(1, quantiles+1)]
        d = add_quantiles(data, columns, suffix, quantiles, quantile_labels)

        period_dict = lambda: defaultdict(list)
        ports = defaultdict(period_dict)
        for i in range(len(columns) - hld_per + 1):
            column = columns[i]
            period_columns = columns[max(i-hld_per, 0):i+1]
            for label in quantile_labels:
                for period in period_columns:
                    ports[label][period] += list(d[column][d[colname(column, suffix)] == label].values)

        for i, label in enumerate(quantile_labels):
            # Fill each list in `ports` with `np.null` so that they all have the same length of `maxlen`
            max_len = max(map(lambda v: len(v[1]), ports[label].items()))
            for c in ports[label]:
                ports[label][c] += [np.NaN]*(max_len-len(ports[label][c]))
            pd.DataFrame(ports[label]).to_csv("portstst2_" + str(i+1) + ".csv", sep=',', index=False, header=True)


A linear search implementation for any data type in C

I think you have chosen some of your types poorly. You write:

long long linear_search
    (
        const void *base, const void *x, const long long len, const int width,
        const int (*compare)(const void *, const void *)
    );

If you take a look at the definition of bsearch, you would do well to be inspired by that function. Obviously, someone thought about how it will work, and also there's the "principle of least surprise" to consider: why should two search functions have different argument types or return different results? Or even pass their arguments in different orders?

Let's change the parameter names, and compare:

long long linear_search(const void *ptr, const void *key, const long long count, const int size, const int (*comp)(const void*, const void*));
void*     bsearch      (const void *key, const void *ptr,       size_t    count,    size_t size,       int (*comp)(const void*, const void*));

Parameter Order

The search function puts the key first, then the details of the array to be searched. Why?

Because the key isn't related to anything else in the parameter list, and it's the "important" thing in the search expression:  Find me a needle! In this haystack, of such and such size. Use this comparator.

I'd suggest you reorder your parameters to conform with this. Not only is it a more sensible arrangement, it keeps your search function consistent with the "standard" search function. That means less to learn, and less chance for a silly bug.

Parameter Names

base, x, len, width, compare

versus

key, ptr, count, size, comp

I actually prefer base to ptr, but len and width aren't super clear. count and size are better in that regard.

Parameter Types

Your parameters are pointers, an array size, and a memory size. You got void * correct as the base type of the pointers (const because no changes). The array size and memory size should be size_t.

The numeric parameters, and the compare-function return type, do not need to be declared const. Declaring them const is a promise not to change them - but they're function arguments (& a return value)! Who cares if you change them, it's not like you're going to give them back! Get rid of those const declarations, since they provide no value to the caller.

Return Type

The bsearch function returns a pointer, rather than an index. Why?

Because it just found a pointer, and it's easier and faster to return the result that it has, instead of doing any math to maintain both a pointer and an index, or doing math to convert from pointer to index.

Also, because the likely next operation for the user who calls a search function will be to use the result of the call, which will require computing a pointer.

If you choose not to use a pointer, you will need a signed integral type that is adequate to store any array index. That would be ptrdiff_t, since it is signed and can express any value of the form (&a[i] - a). So long long should be replaced, either by void * or by ptrdiff_t.

Note that the return type of bsearch is declared as void * rather than const void *. Why? Because the data being searched is probably not constant, and that's the "most compatible" type - you can assign it to pretty much anything with less required casting than other options (char *, const void *, etc.).


Your program calls the write() method of the BufferedOutputStream
with a two byte array. These two bytes are stored in the
stream's buffer, and the buffer is written to standard output when it is
full.

On macOS 10.13 the fs_usage tool shows that the buffer size is 8 kB, and on my MacBook the

  java -cp . yes | pv > /dev/null

benchmark reports that the data is written with about 50 MB/s.

This can be improved by calling write() with a larger byte array:

public class yes {

    static final int BUFFERSIZE = 8 * 1024;
    static byte[] bb = new byte[BUFFERSIZE];

    public static void main(String[] args) throws IOException {

        for (int i = 0; i < BUFFERSIZE; i += 2) {
            bb[i] = 'y';
            bb[i+1] = '\n';
        }

        BufferedOutputStream writer = new BufferedOutputStream(System.out);
        for (;;) {
            writer.write(bb);
        }
    }
}

Now only one write() call is needed to write 8 kB data, instead
of 4096 calls. On my MacBook this increased the speed to
about 2 GB/s, that is a factor of more than 40.

This can possibly be further improved by choosing a larger buffer.

With a byte array larger that the stream buffer size, BufferedOutputStream does
not buffer anymore and writes the data to stdout immediately. Therefore the
"lower-level" unbuffered FileOutputStream would be sufficient:

    FileOutputStream writer = new FileOutputStream(FileDescriptor.out);
    for (;;) {
        writer.write(bb);
    }

However, I could not observe a difference in the performance.


Parsing command input with simple bimaps

Here are some things I saw and some suggestions for how you might improve your code.

Try not to repeat information

I don't much care for the two parallel maps because they have the same information but in two different places and in two different constructs.  What you actually seem to need is a way to go from a std::string to an int and vice-versa.  For that, I'd write a simple class that does this:

template <class T>
class Bimap
{
public:
    Bimap(std::initializer_list<T> init) : names{init} {}
    const T& operator[](int i) const { return names[i]; }
    int operator[](const T& n) const {
        for (unsigned i=0; i < names.size(); ++i) {
            if (names[i] == n)
                return i;
        }
        return -1;
    }
private:
    std::vector<T> names;
};

Note that is, in fact, a templated class so it could be used with std::string or std::wstring or any other class that implements operator== and can be placed in a std::vector.  The simple linear search is not as efficient as a std::map but it's probably just fine for short lists.  Using it in main is just this line:

const Bimap<string> dir{{"NORTH", "EAST", "SOUTH", "WEST"}};

Use const where practical

Your regex and std::map variables could and should be const.

Separate parsing from actions

The code is actually attempting to do two different things:  it is parsing a line from input and then calling some action based on what it finds.  It's probably useful to separate those two a little more clearly.  I'd probably use flex and bison if the commands become more complex, but for now you can simply use a more complete regex.  Here's one way to do that:

const Bimap<string> simplecmd{{"MOVE", "LEFT", "RIGHT", "REPORT"}};
enum scmd { MOVE, LEFT, RIGHT, REPORT };
const regex command("^(MOVE|LEFT|RIGHT|REPORT)|PLACE (\\d),(\\d),(NORTH|EAST|SOUTH|WEST)$");

By reusing the Bimap class defined above, we can change any command into an integer.  By expressing all possible commands within a regex, we can simply ignore any line which doesn't match (or perhaps print an error message).

I'm not happy about having the parallel constructs of simplecmd and the enum scmd but couldn't think of an easy way to avoid it in this case.  We can rationalize it by saying that if one wished to have, say, both French and English versions, only the simplecmd would need to changed and not the enum.

Use better variable names

Generally, single letter variable names other than i and j for loop variables, are best avoided in favor of longer names.  The variable m is not too terrible, but the variable l is definitely a poor choice, not least because it's easily mistaken for the digit 1 or the letter i.  I changed it to line in the rewrite I did.

Use a switch statement where appropriate

Because your parser is selecting some action based on the input, we can make that much more explicit (and easier to read and maintain) by using a switch statement instead of the chained ternary operator.  Here's one way to do it, incorporating all of the other suggestions:

smatch m;
string line;
while (getline(cin, line))
{
    if (regex_match(line, m, command)) {
        switch(simplecmd[m[1]]) {
            case MOVE:
                robot.move();
                break;
            case LEFT:
                robot.left();
                break;
            case RIGHT:
                robot.right();
                break;
            case REPORT:
                robot.report();
                break;
            default:   // must be PLACE
                robot.place(Point(std::stoi(m[2]), std::stoi(m[3])), dir[m[4]], table);
        }
    }
}


I can see three small improvement areas:
Use ctor instead of object initializer
Instead of this:
new DataColumn(v.Key) { DataType = v.Value.GetType() }

Use this:
new DataColumn(v.Key, v.Value.GetType())

Object initializer will run after ctor. If ctor accepts that parameter then prefer to provide it in the ctor.
Use early exist instead of guard expression
Instead of this:
if (Variables != null)
{
    computer.Columns.AddRange(Variables.Select(v => new DataColumn(v.Key, v.Value.GetType())).ToArray());
    computer.Rows.Add(Variables.Values.ToArray());
}
return computer;

Use this:
if ((Variables?.Any() ?? true)) return computer;

computer.Columns.AddRange(Variables.Select(v => new DataColumn(v.Key, v.Value.GetType())).ToArray());
computer.Rows.Add(Variables.Values.ToArray());
return computer;

Yes, I know it's against the single return statement. But with this approach you streamline your logic.
Use immutable collection instead of just readonly access modifier
Instead of this:
static readonly Dictionary<JTokenType, Type> conversions = new Dictionary<JTokenType, Type>()
{
    [JTokenType.Integer] = typeof(int),
    [JTokenType.Float] = typeof(float),
    [JTokenType.Boolean] = typeof(bool),
};

Use this:
static readonly ImmutableDictionary<JTokenType, Type> conversions = new Dictionary<JTokenType, Type>()
{
    [JTokenType.Integer] = typeof(int),
    [JTokenType.Float] = typeof(float),
    [JTokenType.Boolean] = typeof(bool),
}.ToImmutableDictionary();

With readonly you only prevent to replace the whole object. But you can still add and remove new items to the dictionary:
//Invalid operations
conversions = null;
conversions = new Dictionary<string, JTokenType> {};

//Valid operations
conversions.Add(JTokenType.Array, typeof(Array));
conversions.Remove(JTokenType.Integer);

With ImmutableDictionary the Add and Remove will return a new ImmutableDictionary so it will not have any effect on the original collection. Visual Studio will even worn you about it:


Why are you using a global? There seems to be no need for it, and in general it's something to avoid.
Why not factor out the common stuff? In your main loop you have a bunch of if cases which all start in the same way and then all call methods which are very similar. If you start by checking that it's a valid input you could pull out the calls to how_many() and start_point() and even the loop for a in range(howmanyof):.


Scala Play Controller - Refactoring out Duplication for Restful Web Services

for all the option matchers you could use getOrElse
And remember: Option is also a list with all given features

here an example

val resultsPerPageOption = request.queryString.get("numResults")
val size= resultsPerPageOption.map(_.head.toInt).getOrElse(defaultPageSize)
Ok(renderUserJson(getUserList(page.head.toInt, size)))


Direction

With latest version of Ecmascript we get async/await that allow us writing asynchronous code in synchronous style.

Consider an example where function f(...) returns you Promise<F>, and g(...) returns Promise<G>. We can use the following constructions then:

try {
  const resultF = await f();
  const resultG = await g(resultF);
  // keep working with as if we were writing "regular" synchronous code
} catch (anyError) {
  console.error(anyError);
}

This code has to be declared in an async function or arrow function to work. Otherwise, it's still a perfectly asynchronous code...

Sample

In your case, the transformed solution could look similar to this. Please understand this is not 100% working code, because I am not familiar with the particular API of ClassSection that your code deal with. This is more of a sketch to show the direction.

router.post('/teacher-schedule', async (req, res) => {
  const records = [];

  try {
    const schedules = await Schedule.find({school_id : req.body.schoolId});
    schedules.forEach(schedule => {
      ClassSection.findOne(
        { _id: schedule.class_section_id},
        (classSectionSearchError, classSection) => {
          if (err)
            throw new Error(classSectionSearchError);

            schedule.entry.forEach(entryFound => {
            if (entryFound.teacher_id === req.body.teacher_id) {
              const tempo = {
                class_section: classSection.class_title,
                class_section_code: classSection.code,
                schedule_id: schedules._id ,
                class_section_id: schedule._id,
                subject_id: entryFound.subject_id,
              };

              Subject.findOne(
                { _id: entryFound.subject_id},
                (subjectSearchError, subject) =>
                {
                  if (subjectSearchError)
                    throw new Error(subjectSearchError);
                  tempo.subject_title = subject.title;
                }
              );

              records.push(tempo);
            }
          })
      })
    });
    res.status(200).json({ records: records });
  } catch (errorCaught) {
    console.log(errorCaught);
    res.status(500).json({ details: "error occurred: " + JSON.stringify(errorCaught) });
  }
});

Bonus

There's whole lot more potential improvements unrelated to asyncronousity, though.

Use === instead of ==, unless you have a strong reason not to follow this advice.
Please setup eslint tool -- it's really hard to read the code which is formatted like that.
Use const for variable declarations. If something needs to get reassigned, use let. Do NOT use var unless it is necessary (which is super rare the case).
If you're using node.js consider using arrow functions.
In case of errors set status code to HTTP 500 Internal Server Error, whereas for success use 2XX (they vary depending on scenario).
Use proper names. array is too generic. records is actually what's being collected.
Use proper names. cla name means nothing to a reader...
Logging an object right after creation, but before population is meaningless:

tempo = {};
console.log("tempo fade" + tempo)

Do NOT declare all the variables before actually using them. Always try to achieve joint declaration and assignment: const recordsFound = [].


Enforcing correct input/output of integers

Avoid name collisions

#ifndef INTIO_H
#define INTIO_H

You should ideally prefix the include guard by something that is unlikely to cause a collision with any one using your library. As it stands now it is at risk of collision if some one else unluckily choose to use INTIO_H as their include guard.

Hide implementation details

To me it looks like the integer_IO class is not directly intended to be used by the user. In that case you should wrap it in an internal namespace so that the primary namespace that the user sees isn't cluttered with internal functions.

Naming

I think that the name integer_IO is kind of mixing two different case standards. To my knowledge there are kind of two major standards emerging, one is to use CameCase in which you would name your class IntegerIO and the other one is to use inderscore instead of space and all lower case so you would have integer_io. If you're going to allow upper case in names, then I would at least suggest that you use leading upper case like so Integer_IO. Any of the above are easier on my eyes than the current name.

Also I think that the intIO functions would be better named asInt:

std::cin>>asInt(x);

Universal references

This here is a universal reference, the parameter arg will inherit whatever qualifiers the constructor was called with.

  integer_IO(T &&arg) : val(arg) {}

If the constructor was called with a temporary like so auto iio = integer_IO(x + y) where x and y are int arguments, then arg would deduce to int&&. Which is an r-value reference, you are then storing the pointer to this temporary into val which refers to... you guessed it something that might be dangling as soon as the constructor returns.

The other constructor:

  integer_IO(T &arg) : val(arg) {}

will not bind to temporaries because it must be able to take the address of the argument. Other than that it will bind to reference to const because T will be deduced to const T. So this constructor covers all legal use cases that the one with universal reference does, so you can remove either one. I suggest you nuke the universal one because it is slightly harder to understand.

Stream operators

Your two stream operators:

friend std::istream &operator>> (std::istream &is, integer_IO<T> &&i)
friend std::ostream &operator<< (std::ostream &os, integer_IO<T> const &&i)

are using r-value references (NOTE: They are not universal references). Note that const r-value reference doesn't make any sense.

Anyway, I assume that this is because you only want to allow usage on the form:

std::cout<<intIO(x);

and prohibit some one from doing:

auto foo = intIO(x);
std::cout<<foo;

However I do not see the point of prohibiting this use at the cost of making the implementation harder to read (I had to reason about those functions for quite some while before I was sure they work and why they work). You could just as well have

friend std::istream &operator>> (std::istream &is, integer_IO<T> i)
friend std::ostream &operator<< (std::ostream &os, const integer_IO<T>& i)

and your code would be easier to follow and would generate the same code. And allow the above usage syntax.

Reading into a temporary??

This tickled my funny bone:

template
<class T, typename = typename std::enable_if<std::is_integral<T>::value>::type>
integer_IO<T> intIO(T &&arg)
{
  return integer_IO<T>(arg);
}

As you are using universal references this means that arg will bind to anything and retain it's qualifiers. Even r-value references... which means that the following will compile and run doing some manner of undefined behaviour:

std::cin>>intIO(3);

Jolly.

In summary

I can see how this can have some uses in template code but I believe that your implementation is too complicated. My advice is to stop trying to be fancy with && and just make something that works.

I would probably have implemented it like this:

#include <istream>
#include <ostream>
#include <iostream>
#include <limits>
#include <type_traits>
#include <cstdint>

#define ENABLE_IF_INTEGRAL(T)\
typename = typename std::enable_if<std::is_integral<std::decay_t<T>>::value>::type

namespace detail{
    template<class T, ENABLE_IF_INTEGRAL(T)>
    struct wrapper{
        T& x;
        wrapper(T& xx) : x(xx){};

        friend std::istream& operator >> (std::istream& is, wrapper<T> w){
            auto read = +w.x;
            is>>read;
            w.x = static_cast<std::decay_t<T>>(read);
            if(w.x != read){
                is.setstate(std::ios::failbit);
                //C++11 behaviour
                constexpr auto max = std::numeric_limits<std::decay_t<T>>::max();
                constexpr auto min = std::numeric_limits<std::decay_t<T>>::min();
                w.x = static_cast<T>(read < min ? min : max);
            }
            return is;
        }
    };
}

template<class T, ENABLE_IF_INTEGRAL(T)>
auto intoInt(T& x){ return detail::wrapper<T>(x);}

template<class T, ENABLE_IF_INTEGRAL(T)>
auto asInt(T x){ return +x; }

#undef ENABLE_IF_INTEGRAL

int oneplusone(){return 1 + 1;}

int main() {
    char foo;

    // Shouldn't compile
    //std::cin>>asInt(foo);
    //std::cin>>asInt(3);
    //std::cin>>intoInt(3);
    //std::cin>>intoInt(std::move(foo));
    //std::cout<<intoInt(std::move(foo));
    //std::cout<<intoInt(3);
    //std::cout<<intoInt(foo);

    // Readable into
    std::cin>>intoInt(foo);

    // Check status
    std::cout<< (std::cin.fail() ? "failed":"success")<<std::endl;

    // Binds to reference
    auto& ref = foo;
    std::cout<<asInt(ref)<<std::endl;

    // Binds to const reference
    const auto& cref = foo;
    std::cout<<asInt(cref)<<std::endl;

    // Binds to r-value reference
    std::cout<<asInt(std::move(foo))<<std::endl;

    // Binds to value returned function call (r-value really)
    std::cout<<asInt(oneplusone())<<std::endl;

    // Binds to literal
    std::cout<<asInt(31)<<std::endl;

    return 0;
}

In addition to being shorter and easier to comprehend, it also prohibits: std::cin<<asInt(3); from happening.


Create thumbnail in the original ratio without empty space

The first thing that's really needed are some comments describing the different conditions. Sure, you can work them out every time you read the code, but that's error-prone busy-work that you can avoid for future maintainers. You don't need to go crazy with ASCII graphics, though this is one case that might actually deserve them! :)

Here's an example:

if ( $originalRatio >= $targetRatio )
    // original is more landscape
    if ( $originalRatio >= 1 )
        // original is landscape; shrink horizontally
    else
        // both are portrait; shrink horizontally
else
    // original is more portrait
    if ( $originalRatio >= 1 )
        // both are landscape; shrink vertically
    else
        // original is portrait; shrink vertically

  Note: Assuming those comments are correct, your calculations in the third case are incorrect.

As for the calculations themselves, it may be more intuitive to calculate the source width/height in each block and move the origin calculations below. It's certainly less code since you can easily calculate the origin from the size. And if you start the source width/height equal to the original values, you only need to set one dimension in each if block.

$sourceWidth = $originalWidth;
$sourceHeight = $originalHeight;

... shrink $sourceWidth or $sourceHeight ...

$sourceX = ($originalWidth - $sourceWidth) / 2;
$sourceY = ($originalHeight - $sourceHeight) / 2;

This relatively-small function (by procedural coding standards) is very difficult to test. Refactor it into several small functions so that each function does one thing:

Read the original image size and type.
Calculate the trimmed original size.
Calculate the trimmed original origin.
Read the original image from disk. (imageCreateFromType)
Resize to a new image.
Write new image to disk.

1, 5, and 6 are single function calls to the GD library already, but I can see 4-6 making a nice "scale disk image" function together.

public function createThumbnail($imagePath, $thumbnailPath, $targetWidth, $targetHeight) {
    list ($originalWidth, $originalHeight, $originalType) = getimagesize($imagePath);
    $trimmedSize = $this->calculateTrimmedSize(
        $originalWidth, $originalHeight, $targetWidth, $targetHeight
    );
    $trimmedOrigin = $this->calculateTrimmedOrigin(
        $originalWidth, $originalHeight, $trimmedSize
    );
    $this->scaleDiskImage(
        $imagePath, $trimmedOrigin, $trimmedSize,
        $thumbnailPath, $targetWidth, $targetHeight
    );
}

I really don't like dealing with separate width, height, x, and y values and passing them around and would prefer to define Size and Point classes. If this function is the extent of the image manipulation, it's probably not worth the effort, small as it would be. But in larger applications they would clean up the code quite a bit.

Here's the same code as if we had those classes plus a custom ImageInfo that encapsulates the path, size, and type.

public function createThumbnail($imagePath, $thumbnailPath, $targetSize) {
    $original = $this->getImageInfo($imagePath);
    $trimmedSize = $this->calculateTrimmedSize(original->getSize(), $targetSize);
    $trimmedOrigin = $this->calculateTrimmedOrigin(original->getSize(), $trimmedSize);
    $this->scaleDiskImage($imagePath, $trimmedOrigin, $trimmedSize, $thumbnailPath, $targetSize);
}


Angular directive to toggle sidebar visibility based on window width

Yes, you're right. Your code is very hard to read.

I think you don't need that init stuff. Just remove it and add initialization to the controller.
You don't need jQuery for your directive. This is possible with Angular JS / pure Js. Use ng-show or ng-if for showing hiding your sidebar and use ng-class to add your class conditionally depending on a variable from your controller to do things differently for large screens.
Animation could be done with ngAnimate and animate.css.

There are some points that could be improved in my code:

Add options so it's better reusable.
Add default options for example start visible = false. with angular.module('adminApp').constants(...) then you can angular.extend(...) these in the controller of your directive.
Add an isolated scope for the directive so it can't modify the scope of your app. Somthing like scope: {} would be OK or {scope: { options: '@' } } for the sidebar options.
Remove restrict: M because it's not recommended to use directives as comments (see angular docs).

Please have a look at the demo below or in this jsfiddle.

function EventSidebarDirective($window) {
    var directive = {
        restrict: 'EAM',
        templateUrl: 'components/sidebar/template.html',
        controllerAs: 'ctrl',
        controller: function ($scope) {
            var self = this, // self needed because toggle is not bound to this ctrl.
             screenWidth;

            angular.extend(this, {
             visible: false,
             toggle: function () {
                    screenWidth = $window.innerWidth; //$(window).width();
                    self.visible = !self.visible; // toggle visibility
                    self.largeScreen = ( screenWidth >= 768 );
    }
            });
        },
        link: function (scope, element, attr, ctrl) {

        }
    };

    return directive;
}

EventSidebarDirective.$inject = ['$window']; // only need with-out ng-annotate for minification

angular.module('adminApp', ['ngAnimate'])
    .directive('eventSidebar', EventSidebarDirective);
.sidebar-content {
    width: 200px;
    height: 200px;
    background: lightgray;
}

.sidebar-content-animation.ng-hide-remove {
    -webkit-animation: fadeInLeft 1s;
    -moz-animation: fadeInLeft 1s;
    -ms-animation: fadeInLeft 1s;
    -o-animation: fadeInLeft 1s;
    animation: fadeInLeft 1s;
}

.sidebar-content-animation.ng-hide-add {
    -webkit-animation: fadeOutUp 1s;
    -moz-animation: fadeOutUp 1s;
    -ms-animation: fadeOutUp 1s;
    -o-animation: fadeOutUp 1s;
    animation: fadeOutUp 1s;
}

<link href="https://cdnjs.cloudflare.com/ajax/libs/animate.css/3.4.0/animate.min.css" rel="stylesheet"/>

    <event-sidebar></event-sidebar>


I have zero experience with Kotlin, but I can tell you how to make your implementation run faster. You could allocate the auxiliary space only once throughout the entire algorithm, and you essentially merge from one array to other, then at a higher recursion level, you swap their roles and merge in opposite direction. You can learn about this approach here.

Also, one nitpick: in most languages (I know), the sorting method/function does not return any list; they just modify the input array.

Hope that helps.


Go through every pixel of an image and then dispose of it

I think your Bitmap property shouldn't have a setter. If you use it, you don't dispose the old Bitmap and you don't reset size. Both seem to be erroneous to me.

public Bitmap Bitmap
{
    get { return (source); }
    set { source = value; }
}

Why is source in parentheses?

Also, this could be an auto-property. You would then use the (possibly private) setter instead of the field in the constructor.

catch(Exception)
{
    throw;
}

This doesn't do anything, get rid of it.

public BGRA* this[int x, int y]
{
    get
    {
        return (BGRA*)(baseLine + y * width + x * sizeof(BGRA));
    }
}

If the type of baseLine was BGRA* (and you also changed width not to include the size), then the return statement could be simplified to:

return &baseLine[y * width + x];

Also, I would consider returning BGRA directly, I think that's more natural (assuming doing that doesn't decrease performance noticeably).


Multiply vector elements by a scalar value using STL and templates

I would use the second version that you posted. Here are some problems with the first version:

1. Prefer passing by value rather than making an explicit copy.

This is a problem in both versions of your code. You pass A via constant reference. Normally this is a good thing, but then you then make a copy of A explicitly. In this case, it is possible to miss out on a compiler optimization called copy elision (second reference here). Passing by value would not cause any variable aliasing problems.

Update: Imagine somebody (maybe you) using your function.

std::vector <int> v1 = // ... insert elements
auto v2 = 3 * v1 ;

For simplicity, let's say variable v2 is located at address 0x10.
When you do 3 * v1, you are calling your function.

R would then be created at let's say address 0x20. When your function returns, the contents of R would have to be copied from 0x20 to v2 at 0x10 and then the destructor for R would have to be called. Without copy elision, this would require copying every element from R into v2.

Now in C++11, there is something called move semantics. This means, that without copy elision, R would not have to copy every element into v2, it could swap pointers. This is much faster, but it is still slower than copy elision.

With copy elision, instead of creating R at 0x20, it uses address 0x10 and builds v2 in place. With copy elision, nothing has to be copied and no pointers have to be swapped because v2 is built in place.

Here's how I would re-write the function:

template <class T, class Q>
std::vector <T> operator* (const Q c, std::vector <T> A)
{
    std::transform (A.begin (), A.end (), A.begin (),
                 std::bind1st (std::multiplies <T> () , c)) ;
    return A ;
}

2. If you have to use an index-loop for some reason, rather than a range-loop or iterators, make sure you are comparing compatible types.

You could do something like this:

typedef std::vector <T>::size_type size_type ;
for (size_type i = 0; i < A.size (); ++i)

C++11 has expanded the functionality of the using keyword. So instead of a typedef, you could also do:

using size_type = decltype (A.size ()) ;

Update: The reason you want to use compatible types is because overflowing a signed number is undefined behavior in C++. This means anything can happen. Consider this example:

const unsigned size = std::numeric_limits <int>::max () + 5 ;
std::vector <char> v1 (size) ;

for (int n = std::numeric_limits <int>::max (); n < v1.size (); ++n) {
    std::cout << n << ',' << v1.size () << '\n' ;
}

Different compilers on different platforms will do different things with the code above because there is undefined behavior (an int can never reach std::numeric_limits <int>::max () + 5).

3. Consider wrapping the std::vector into a class.

Programs typically use std::vector for many things. Overloading a global operator like you do would make me uncomfortable using your code.

4. Obligatory avoid using namespace std;.

5. Use more meaningful variable names and typenames.

Unless A, R, Q, etc are commonly understood names for special variables in your scientific community, use more meaningful names.

6. Do not omit braces for if-statements or loops.

This is more a subjective style guideline than anything.


Fetching / formatting / storing tweets to my database

wp_remote_get(
        'http://twitter.com/statuses/user_timeline/'
        . $options['username'].'.json?count='.$options['count'] )

I'd use at least a local variable which stores the url:

$url = 'http://twitter.com/statuses/user_timeline/' .
    $options['username'] . '.json?count=' .$options['count'];
wp_remote_get($url);

A function would be more better. It makes the code easier to read.

Use longer variable names to avoid comments:

function timespan($create_time_input)
{
    $current_timestamp = strtotime("now");
    $create_time = strtotime($create_time_input);
    $diff_seconds = $current_timestamp - $create_time;

    $one_minute = 60;
    $one_hour = $one_minute * 60;
    $one_day = $one_hour * 24;
    $one_week = $day * 7;

    if(is_numeric($d) && $d > 0) {
        if ($diff_seconds < 3) {
            return "right now";
        }
        if ($diff_seconds < $one_minute) {
            return floor($diff_seconds) . " seconds ago";
        }
...

Now the code itself says what the comments said before.

Unnecessary floor:

if($d < $minute) return floor($d) . " seconds ago";

$d looks an integer, so floor is unnecessary.


I believe you're looking for std::prev:

std::prev(tape.end());

The linked page even states the exact comparison of the two:

  Although the expression --c.end() often compiles, it is not guaranteed to do so: c.end() is an rvalue expression, and there is no iterator requirement that specifies that decrement of an rvalue is guaranteed to work. In particular, when iterators are implemented as pointers, --c.end() does not compile, while std::prev(c.end()) does.

I do have some additional points as well:

typedef isn't needed for enums in C++.
Since tape is a storage container of a primitive type (ints), the default constructor will zero-initialize it automatically.  As such, you don't need to assign to {0}.

std::list<int> tape;

In case you want to verify it right away, take a look at this test.
It may be more useful to use auto with head:

auto head = tape.begin();

This allows for less typing and for any iterator type (if it ever changes).
You could put these "test machines" in a separate file or somewhere separate from the main implementation.  Proper unit testing may be preferred, but I don't have much to say about that.  I'd also rename them as such as it's best not to use single-variable names outside of loop counters.

Another note: you can omit the = for each std::array for C++11 list initialization.
main() seems to be handling too much of the logic.  Have other functions handle it and only have main() initialize variables, call these functions, then output the results.
return 0 or similar isn't needed at the very end of main(); it'll always do the same return at this point.


Return characters in a string in alphabetical order

What other 'Pythonic' elements am I missing (again, aside from using the sorted method)?

If you want to more heavily use the standard library, you can use a collections.Counter along with the alphabet constants string.ascii_uppercase and string.ascii_lowercase.

Things are also simpler if you store the counts in a dict (map) instead of the implicit map-by-ord()-value that you're currently using. The ordering of the counts doesn't really matter, just the order in which you output them.

from collections import Counter
from itertools import chain
import string

def alphabetize(s):
    counts = Counter(s)

    return ''.join(
        char * counts[char]
        for char in chain(*zip(string.ascii_uppercase, string.ascii_lowercase))
    )

The counts = Counter(s) line does essentially this:

counts = collections.defaultdict(int)

for char in s:
    counts[char] += 1

where the defaultdict (a handy class) is a dict that auto-initializes values based on the constructor you pass in, instead of throwing an exception for missing keys.

The chain(*zip(...)) is zipping together the uppercase and lowercase alphabets, then flattening them via chain() into a single list, ['A', 'a', 'B', ...].

  Should this be a class?

Nope. This makes sense as a function in Python since it has no external state.

  As somebody that is more comfortable in Java, things that aren't in classes make me irrationally uneasy.

Java ties files to classes, but each Python file is already a module, which is a good level of encapsulation. As a very rough rule, avoid classes in Python except when you want to hold shared state, in which case class away. Or, at least, don't reach first for classes.


Not bad.  I just have a few nitpicks.

You can iterate over characters of a string directly without splitting it into an array first:

for ($i = 0; $i < strlen($string); $i++) {
    $char = $string[$i];
    ...
}

I believe that the PHP interpreter isn't smart enough to recognize that strlen($string) is invariant, so you might get better performance with

$strlen = strlen($string);
for ($i = 0; $i < $strlen; $i++) {
    $char = $string[$i];
    ...
}

I find the else if in escapedExplode() slightly jarring.  Either use if and continue everywhere, or if, else if, else if, else without continue.


Cycle through an array of available colors repeatedly

The code you've written seems to be reasonably elegant (to me at least!). You can make this slightly simpler by:

storing the colors array rather than getting each time (I've used a by lazy but you could use a nullable var or a lateinit var if you prefer)
Store the cardCount elsewhere rather than locally and incrementing it each time

I've put an example of these changes below. I would strongly recommend extracting out the color logic into its own class in order to make it more testable, reusable and better separation of concern.
private val colors: IntArray by lazy{
    resources.getIntArray(R.array.cardColors)
}

private val cardCount = 0

private fun getCardColor(): Int {
    val color = colors[cardCount % colors.size]
    cardCount.inc()
    return color
}

Also, you could use the @ColorInt annotation to make it clear that the Int being returned is a ColorInt.


Music collection with lyric songs and instrumental pieces

Polymorphic classes must include a virtual destructor. Otherwise they are not truly polymorphic: you cannot delete such an instance using the pointer to the base class.

A class hierarchy should (typically) be designed according to the Liskov Substitution Principle. This means that any derived class must be substitutable for the base class: anywhere a base class is expected to work, the derived class must as well. Your hierarchy conforms to this, but I wanted to point it out.

  Will there be a way to know what type of Song I work with, in case of iterating over an array of Song pointer that point to various song types?

That's what dynamic_cast is for - it returns nullptr when the object is not of the desired type.

Song * song = ...;
auto isong = dynamic_cast<InstrumentalSong*>(song);
if (isong) {
  /* it's instrumental */
  ...
}
auto lsong = dynamic_cast<LyricSong*>(song);
if (lsong) {
  /* it's lyric */
  ...
}

The type of isong is deduced to InstrumentalSong*, etc.

A basic question to be asked is: do you even care about a class structure? What do you do with all that song data?


Breaking after one of several string replaces occur

This seems to be a fine case for a loop over the expressions:

function format_input(input) {
    // decouple DOM things from pure functionality!
    input.value = format_number(input.value);
}
function format_number(str) {
    var replacements = [
        [/regex1/, 'replace1'],
        [/regex2/, 'replace2'],
        [/regex3/, 'replace3'],
        [/regex4/, 'replace4'],
        [/regex5/, 'replace5'],
        [/regex6/, 'replace6'],
        [/regex7/, 'replace7'],
        [/regex8/, 'replace8'],
        [/regex9/, 'replace9'],
        [/regex10/, 'replace10'],
        [/regex11/, 'replace11'],
        [/regex12/, 'replace12'],
        [/regex13/, 'replace13'],
        [/regex14/, 'replace14'],
        [/regex15/, 'replace15'],
        [/regex16/, 'replace16'],
        [/regex17/, 'replace17']
    ];
    for (var i=0; i<replacements.length; i++) {
        var copy = str.replace(replacements[i][0], replacements[i][1]);
        if (str != copy)
            return copy;
    }
    return str;
}


Simple framework for Google Code Jam problems

#pragma once

This really only makes sense in a header, but the rest of your code doesn't really look like a header (but maybe it's intended to be one anyway--not really sure). If it is a header, I'd recommend adding normal #ifndef/#define/#endif style header guards as well, since some compilers don't support this #pragma.

template <typename ContainerT>
ContainerT splitString(const std::string & source) {
    ContainerT cont;
    std::stringstream ss(source);
    typedef typename ContainerT::value_type ElementT;
    std::copy(std::istream_iterator<ElementT>(ss), std::istream_iterator<ElementT>(), std::back_inserter(cont));
    return cont;
}

I think I'd use something a bit simpler, such as:

template <typename ContainerT>
ContainerT splitString(const std::string & source) {
    std::stringstream ss(source);
    ContainerT cont{std::istream_iterator(ss), std::istream_iterator()};
    return cont;
}

If you're stuck with C++03 instead of 11, you'll need to use:

    ContainerT cont((std::istream_iterator(ss)), std::istream_iterator());

...instead (note the double parens around the first param, to avoid the Most Vexing Parse).

As @Mat already alluded to in a comment, the fact that this contains a pure virtual function indicates that it's intended to be used as a base class for derivation. If so, you almost certainly want to make the destructor virtual as well--this is needed if the user might ever create a pointer to the base class, and destroy an instance via that pointer to the base.

To be honest, this scenario strikes me as somewhat unlikely though. Such a virtual function is generally useful when you have something like a heterogeneous container that might contain pointers to objects of any of a number of derived classes, so the correct function to call must be determined individually for each item.

In this case, it appears more likely (at least to me) that the intent is to have only one derived class per program, so what we really have is "static polymorphism" -- i.e., in a given program, there will be only one derived class, so one program will really only have one implementation of solve.

If that's correct, it would probably be better to model that a bit more directly, such as by passing the solve as a template parameter instead:

template <class solve>
class CodeJam {
// ...
    void solveAll() {
        // ...
        for (curCase = 1; curCase <= testCases; ++curCase) {
            // Note that the syntax is only minimally affected:
            solve()(curCase);
            std::cout << "Test " << curCase << " of " << testCases << std::endl;
        }
    }
};

This seems to improve flexibility at least somewhat, because the user is no longer required to write a class that's derived from CodeJam.

At the same time, I feel obliged to point out what seems to me an even greater problem (and one that's not so easily fixed either, I'm afraid). This comes down to the simple fact that your code simply doesn't seem to provide all that much functionality. I can hardly imagine how anybody could hope to save even 10 whole minutes by using your code rather than starting from nothing at all--and in some cases, I can see where this code might easily be no more than a break-even proposition.

In short, you're placing constraints on how code is written, but providing rather minimal functionality in return. I question whether it provides enough return on investment to justify itself.


I notice my controller headers seem fairly bloated, mostly because of the need to include the the modules, services, and factories in them. So maybe something like

You can use the implicit method of dependency injection, where as long as the variable names match the dependency name, Angular will figure it out for you. However, for production, you'll need ngAnnotate to convert it back to the explicit form before minification.

  I understand I could use something like RestMod or Restangular to reduce multiple query calls.

If this means wiring up multiple API calls to generate cohesive data (merging data from multiple calls), then I believe this calls for a service which hides stuff away from the controller. Multiple calls can be done in parallel.

// SomeMergedDataService
getSomethingFromMultipleResources: function(){
  return $q.all($http.get(), $http.get(), ...).then(function(values){
    // `values` is an array containing the results of each ajax call
    // Do the merge logic here
    return mergedData;
  });
};

// meanwhile... in your controller
App.controller('MyController', function(SomeMergedDataService){
  SomeMergedDataService.getSomethingFromMultipleResources().then(function(data){
    // you got merged data!
  });
});

Another way to do this is via the route's resolve property. It's essentially the same thing, except that instead of injecting the service and calling a method to get the data, the injected resolve is the data. A resolved property takes a function that can return a promise. You can feed the result of your $q.all().then() as the return.

  a bunch of setting at the end of one page only to have to do a lot of getting at the beginning of the next

One way to do it is by way of $rootScope. You can treat $rootScope as the global space of the application.

If you don't want to pollute $rootScope, you can also do it like how React+Flux, by using services as storage locations. This does entail getters and setters though, which I think you're already doing now.

If you want the state pushed down to the controller level, you can nest controllers. Descendant controllers have access to the $scope properties of the enclosing controller. This means that you can put stuff on the parent controller and have access to it from any descendant.

  I've been feeling free to mix AngularJS with regular JS but the more I read the more it seems I should try to keep things in Angular as much as possible.

It's perfectly fine to mix. They're all JS anyways. It's really up to you. Angular is pretty flexible despite its crazy conventions.

Angular does provide some very handy modules which are usually optimized to how Angular internals work. I especially use $timeout instead of setTimeout, or $log instead of console.

However, I certainly dislike certain built-ins such as $q as it doesn't behave like the native promises. This makes $http and resources weird as it uses $q internally.

  A lot of tutorials go over certain facets of angular but very few seek to put everything together.

I suggest you go over and look at JHipster. It's a stack that uses Angular+Spring. I'm not suggesting you go over to Java, but it has a good way of structuring an Angular app front-to-back. I suggest you go try to run it's setup and see how it provides the default services, controllers, templates etc. and how it's made to talk to the server.


Unbalanced Binary Search Tree insertion and search with random and sorted values

The global variable rootNode is never used, and is confusing due to similar local variables, so remove it.

As we're ignoring all command-line arguments, we can use the simpler signature for main():

int main(void)

Prefer to use unsigned types for counting:

const unsigned int SIZE = 10000;
...
for (unsigned int i = 1;  i < SIZE;  ++i)

That addresses most of the compiler warnings I get for this code.  The remaining warning is best eliminated with a cast to indicate that we don't care about preserving the correct value in this signed → unsigned conversion:

    srand((unsigned)time(NULL));

Prefer to use the size of the variable than of its type when allocating memory.  This makes it easier for reviewers to confirm that the sizes match:

if (!*n) {
    *n = malloc(sizeof **n);
    (*n)->BSTLeft = NULL;
    (*n)->BSTRight = NULL;
    (*n)->data = i;
}

and

int *a = malloc(sizeof *a * SIZE);

Use a memory checker; at the moment, we leak the entire BST:

Inserting values to BST with 10000 random nodes...
==12434== Conditional jump or move depends on uninitialised value(s)
==12434==    at 0x1091FC: BSTInsert (209085.c:24)
==12434==    by 0x109388: test_scenario1 (209085.c:54)
==12434==    by 0x10956F: main (209085.c:96)
==12434==
Done. Took 3.30890200 seconds

==12434== Conditional jump or move depends on uninitialised value(s)
==12434==    at 0x10926D: BSTSearch (209085.c:33)
==12434==    by 0x10940C: test_scenario1 (209085.c:64)
==12434==    by 0x10956F: main (209085.c:96)
==12434==
==12434== Conditional jump or move depends on uninitialised value(s)
==12434==    at 0x10927B: BSTSearch (209085.c:35)
==12434==    by 0x10940C: test_scenario1 (209085.c:64)
==12434==    by 0x10956F: main (209085.c:96)
==12434==
Searching random values in BST...
Done. Took 0.00558500 seconds

Inserting values to BST with 10000 sorted nodes...
Done. Took 3.36596000 seconds

Searching sorted values in BST...
Done. Took 3.96642300 seconds

==12434== 240,000 (24 direct, 239,976 indirect) bytes in 1 blocks are definitely lost in loss record 22 of 23
==12434==    at 0x483577F: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==12434==    by 0x1091B9: BSTInsert (209085.c:19)
==12434==    by 0x109388: test_scenario1 (209085.c:54)
==12434==    by 0x10956F: main (209085.c:96)
==12434==
==12434== 240,000 (24 direct, 239,976 indirect) bytes in 1 blocks are definitely lost in loss record 23 of 23
==12434==    at 0x483577F: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==12434==    by 0x1091B9: BSTInsert (209085.c:19)
==12434==    by 0x1094AA: test_scenario2 (209085.c:79)
==12434==    by 0x109579: main (209085.c:97)
==12434==

Those early reports of using uninitialised values are certainly worth investigating, too.

Try to be consistent where that helps readers.  Consider this fragment:

else if((*n)->data == i)
   return ;
else if(i > (*n)->data)

See how it's easier to see the relation between the two tests if we write the operands in the same order:

else if (i == (*n)->data)
   return;
else if (i > (*n)->data)

Use the standard error stream for error messages:

if (*n == NULL)
    fprintf(stderr, "Value does not exist in tree!\n");

And prefer to write complete lines to output (especially relevant when it's connected to line-buffered devices, such as terminals and terminal-emulators).

Consider using more braces to enclose conditional commands.  It's easier to avoid silly mistakes:

if (*n == NULL) {
    *n = malloc(sizeof **n);
    (*n)->BSTLeft = NULL;
    (*n)->BSTRight = NULL;
    (*n)->data = i;
} else if (i > (*n)->data) {
    BSTInsert(i, &((*n)->BSTRight));
} else {
    BSTInsert(i, &((*n)->BSTLeft));
}

We could make that code a lot clearer by copying *n into a local variable:

void BSTInsert(int i, node **n)
{
    node *node = *n;
    if (!node) {
        *n = node = malloc(sizeof **n);
        node->BSTLeft = NULL;
        node->BSTRight = NULL;
        node->data = i;
    } else if (i > node->data) {
        BSTInsert(i, &node->BSTRight);
    } else {
        BSTInsert(i, &node->BSTLeft);
    }
}

On the other hand, in the search function, we don't need to pass by pointer, and we can use const.  We probably ought to return something, too:

const int *BSTSearch(int i, const node *n) {
    if (n == NULL) {
        fprintf(stderr, "Value does not exist in tree!\n");
        return NULL;
    } else if (i == n->data) {
       return &n->data;
    } else if (i > n->data) {
        return BSTSearch(i, n->BSTRight);
    } else {
        return BSTSearch(i, n->BSTLeft);
    }
}

Obviously, the call sites would then need to pass rootNode by value, rather than &rootNode pointer.

The parallel structure of insert and search suggests that we're missing a condition for (i == n->data) in the insert; in that block, we should avoid inserting a duplicate node and instead return early:

void BSTInsert(int i, node **n)
{
    node *node = *n;
    if (!node) {
        *n = node = malloc(sizeof **n);
        node->BSTLeft = NULL;
        node->BSTRight = NULL;
        node->data = i;
    } else if (i == node->data) {
        return;                 /* already exists */
    } else if (i > node->data) {
        BSTInsert(i, &node->BSTRight);
    } else {
        BSTInsert(i, &node->BSTLeft);
    }
}

(It might be this change that eliminated the Valgrind warning about uninitialised data - I'm not sure when that disappeared).

We're missing the check that malloc() didn't return a null pointer.  That can happen any time we call an allocation function, so we must always test the result before using it.  In particular, there's no guarantee that the subsequent use of a null pointer will crash the program, as some authors seem to think.

bool BSTInsert(int i, node **n)
{
    node *node = *n;
    if (!node) {
        *n = node = malloc(sizeof **n);
        if (!node) return false;
        node->BSTLeft = NULL;
        node->BSTRight = NULL;
        node->data = i;
        return true;
    } else if (i == node->data) {
        return true;            /* already exists */
    } else if (i > node->data) {
        return BSTInsert(i, &node->BSTRight);
    } else {
        return BSTInsert(i, &node->BSTLeft);
    }
}

Don't forget that this means that the callers of BSTInsert now need to check that it succeeded!

Lastly (and leastly), this comment is inaccurate:

// Main function for these three scenarios.

Either change the word "three" to "two" or remove the comment (it's stating the obvious, so doesn't add any value).


Walk recursively through dictionaries and return result without using global variable

1. Review

There's no docstring, and so it's not clear exactly what this function is intended to compute. In particular, it's not clear what you want to get in these cases:

(a) if there are no items in the data structure with the key "type"?

(b) if there are multiple items in the data structure with the key "type"?

The code you posted raises an exception in case (a):

NameError: name 'ftype' is not defined

and in case (b) it returns the value of the last visited item with that key (which could be any item, since dictionaries may be iterated over in any order).

I'm going to assume that in case (a) you'd actually like to get the default value 'string', and that in case (b) you don't care which value you get and any item with the right key is fine.
The values 'type' and 'string' seem arbitrary, and so it would make sense for them to be parameters to the function.

2. Non-local exit

The problem here is to implement a non-local exit — that is, when you find the value you're after, you want to return all the way up the call stack to the original caller, bypassing all the intermediate calls. This is a job for an exception.

def get_field_type(mapping, key='type', default='string'):
    """Return a value corresponding to the specified key in the (possibly
    nested) mapping. If there is no item with that key, return
    default.

    """
    class Found(Exception):
        pass
    def search(mapping):
        for k, v in mapping.iteritems():
            if isinstance(v, dict):
                search(v)
            elif k == key:
                raise Found(v)
    try:
        search(mapping)
    except Found as exc:
        return exc.args[0]
    else:
        return default

3. Stack of iterators

Alternatively, you could avoid using recursion and instead maintain the current search state using a stack of iterators. Then there's no difficulty: when you find the item you want you can return it immediately.

def get_field_type(mapping, key='type', default='string'):
    """Return a value corresponding to the specified key in the (possibly
    nested) mapping. If there is no item with that key, return
    default.

    """
    stack = [mapping.iteritems()]
    while stack:
        for k, v in stack[-1]:
            if isinstance(v, dict):
                stack.append(v.iteritems())
                break
            elif k == key:
                return v
        else:
            stack.pop()
    return default

(In Python 3 you need to write iter(mapping.items()) instead of mapping.iteritems() and similarly iter(v.items()) instead of v.iteritems().)


Disclaimer: I am biased towards singletons. I think it is an anti-pattern, that has no place in modern C#.

First, here is a great article on how singletons become a disaster when you try to unit test a code, that heavily relies on them. Your case is even more complex, because you also have to initialize additional parameters. And you can't change those. So you can't test Host with different "environments" unless you try to bypass your own exception with reflection.

I would just register non-static Host class as singleton inside IoC container, and be done with it. It will solve all your problems:

Parameters of Host are no longer exposed.
Container guaranties, that there is going to be a single instance of Host.
Host is exposed as service (IHost) and not as implementation (Host).
You can mock IHost in unit tests.
You can easily unit-test Host implementation with whatever parameters you want, because now it has public constructor and can be re-created as often as it is required by your tests.
Classes that depend on IHost will now require it as dependency, instead of secretly accessing it via global static property.


With the output DataFrames being about 1.5Gb in file, the reason your performance is slow may be that you have insufficient memory to perform these operations quickly.

One way to reduce the amount of memory used is to is to use the inplace keyword argument common to some of the pandas.DataFrame methods. Setting inplace=True, when available, makes the operation augment the DataFrame in place; otherwise, inplace=False will create a copy (which can consume more memory).

One quick suggestion, therefore, might be to replace:
df = df.sort_values(by=1)
with df.sort_values(by=1, inplace=True).

This answer on StackOverflow may also be of interest (it talks about different optimisations for holding data in DataFrames; including inplace): https://stackoverflow.com/a/39377643/6852391