ShamanLand Blog

Pulsing sequence generator

2016-10-09T11:55:00+03:00

Imagine you need to generate a “pulsing” sequence of numbers which continuously repeats, going up and down between the given values, like this: 5-6-7-8-9-10-9-8-7-6-5-6-7…

Such a sequence may serve different purposes, but in any case, we want a universal solution even for this simple problem. The algorithm is simple too…

class Stairs {
    private int min;
    private int max;
    private int diff;
    private int value;

    public Stairs(int min, int max) {
        this.min = min;
        this.max = max;
        this.diff = max - min;
        this.value = diff - 1;
    }

    public int next() {
        value = (value + 1) % (2 * diff);
        return min + Math.abs(value - diff);
    }
}

Source code and output of the program are available at the end of this post. Moreover, you can try to play with it using the plotter below: change min and max values.

min max

Source code

Example.java

import java.util.*;
import java.lang.*;
import java.io.*;

public class Main {
    public static void main (String[] args) {
        Stairs s = new Stairs(5, 10);

        for (int i = 0; i <= 20; ++i) {
            System.out.println(s.next());
        }
    }
}

class Stairs {
    private int min;
    private int max;
    private int diff;
    private int value;

    public Stairs(int min, int max) {
        this.min = min;
        this.max = max;
        this.diff = max - min;
        this.value = diff - 1;
    }

    public int next() {
        value = (value + 1) % (2 * diff);
        return min + Math.abs(value - diff);
    }
}

Output

Composite Iterator. Java

2016-03-08T03:03:00+02:00

Imagine you have two collections with different types of data. Both of them are sorted by some rule. You need to iterate over both collections, preserving their sort order. Like this:

We want to share a simple but effective technique using the Iterator and Iterable interfaces.

Let’s suppose that we have the following class hierarchy:

class Foo implements Comparable<Foo> {
    final int id;

    Foo(int id) {
        this.id = id;
    }

    @Override
    public int compareTo(Foo other) {
        return id - other.id;
    }

    @Override
    public String toString() {
        return getClass().getName() + "-" + id;
    }
}

class Bar extends Foo {
    Bar(int id) {
        super(id);
    }
}

class Qux extends Foo {
    Qux(int id) {
        super(id);
    }
}

Method compareTo() compares objects by the id field in natural order. Method toString() returns the exact name of the object’s class and its id.

Once upon a time we faced a similar hierarchy in production code. In addition, there were two types of lists: List<Bar> and List<Qux>. Let us remind you that both lists are sorted!

List<Bar> list1 = Arrays.asList(new Bar(10), new Bar(20), new Bar(50), new Bar(80), new Bar(90));
List<Qux> list2 = Arrays.asList(new Qux(30), new Qux(40), new Qux(60), new Qux(70), new Qux(100));

So, the task is to iterate over these two lists efficiently: linear time complexity O(n), no copies of collections, no additional sorting, no unnecessary loops.

“The simplest” solution is to write two loops, then get two elements (one from each list), compare them, decide which one to use, and iterate again. If one list becomes empty too early, we need to handle this situation in a separate loop. This code will be too complex and not reusable. (We don’t want to provide an example here; you may write it yourself as an exercise.)

On the other hand, we can avoid a lot of complications by using the Iterator interface. Let’s declare the CompositeIterator class this way:

public class CompositeIterator<T> implements Iterator<T> {
    private final Iterator<? extends T> it1;
    private final Iterator<? extends T> it2;
    private final Comparator<T> comparator;

    private Iterator<? extends T> lastUsed;
    private T obj1;
    private T obj2;

Fields it1 and it2 refer to the iterators of both collections. Comparator is used for ordering. Field lastUsed stores the iterator which was last used to return a value. Fields obj1 and obj2 refer to the objects retrieved from it1 and it2 respectively. Well, how will it work?

public boolean hasNext() {
    return obj1 != null || obj2 != null || it1.hasNext() || it2.hasNext();
}

public T next() {
    if (obj1 == null) {
        obj1 = (it1.hasNext()) ? it1.next() : null;
    }

    if (obj2 == null) {
        obj2 = (it2.hasNext()) ? it2.next() : null;
    }

    if (obj1 != null && obj2 != null) {
        if (comparator.compare(obj1, obj2) < 0) {
            return obj1();
        } else {
            return obj2();
        }
    } else if (obj1 != null) {
        return obj1();
    } else if (obj2 != null) {
        return obj2();
    } else {
        throw new NoSuchElementException();
    }
}

private T obj1() {
    lastUsed = it1;
    T result = obj1;
    obj1 = null;
    return result;
}

private T obj2() {
    lastUsed = it2;
    T result = obj2;
    obj2 = null;
    return result;
}

public void remove() {
    if (lastUsed == null) {
        throw new IllegalStateException();
    }

    lastUsed.remove();
    lastUsed = null;
}

Method hasNext() checks whether at least one object (obj1 or obj2) has already been retrieved. If both of them are null, it checks whether at least one of the iterators has more elements by calling hasNext().

If one of these four conditions is true, we can proceed to the next() method. Here we need to make sure that we use both iterators, so if obj1 or obj2 is null, we need to get it from its iterator. If both of them are not null, we need to compare them and choose which one to return. Otherwise we just return the one which is not null. If both of them are still null at this point, it means that next() was called incorrectly, so we need to throw NoSuchElementException.

Pay attention to the two methods obj1() and obj2(). They are used to save a reference to the last used iterator and to clear the reference to the object which was returned.

Method remove() uses the lastUsed field to remove the last returned element from the proper iterator.

To make this iterator easy to use, we will create a simple implementation of the Iterable interface, which creates a new CompositeIterator every time the iterator() method is called:

public class CompositeIterable<T> implements Iterable<T> {
    private final Iterable<? extends T> iterable1;
    private final Iterable<? extends T> iterable2;

    public CompositeIterable(Iterable<? extends T> iterable1, Iterable<? extends T> iterable2) {
        this.iterable1 = iterable1;
        this.iterable2 = iterable2;
    }

    @Override
    public Iterator<T> iterator() {
        return new CompositeIterator<T>(iterable1.iterator(), iterable2.iterator());
    }
}

That’s all! Don’t believe it? Try it!

public static void main(String[] args) {
    List<Bar> list1 = Arrays.asList(new Bar(10), new Bar(20), new Bar(50), new Bar(80), new Bar(90));
    List<Qux> list2 = Arrays.asList(new Qux(30), new Qux(40), new Qux(60), new Qux(70), new Qux(100));

    Iterable<Foo> composite = new CompositeIterable<>(list1, list2);

    for (Foo foo : composite) {
        System.out.println(foo);
    }
}

Wow! We didn’t even expect such pretty code. Here is the output:

Bar-10
Bar-20
Qux-30
Qux-40
Bar-50
Qux-60
Qux-70
Bar-80
Bar-90
Qux-100

In addition, we want to mention that you can use this approach for any number of wrapped collections. Two, three, four — it doesn’t matter! You can wrap them in pairs many times.

We hope this solution will help you process collections better. You may find all files from this example at the end of this post. Thanks for reading!

Source code

CompositeIterator.java

import java.util.Comparator;
import java.util.Iterator;
import java.util.NoSuchElementException;

public class CompositeIterator<T> implements Iterator<T> {
    private final Iterator<? extends T> it1;
    private final Iterator<? extends T> it2;
    private final Comparator<T> comparator;

    private Iterator<? extends T> lastUsed;
    private T obj1;
    private T obj2;

    public CompositeIterator(Iterator<? extends T> it1, Iterator<? extends T> it2) {
        this(it1, it2, null);
    }

    public CompositeIterator(Iterator<? extends T> it1, Iterator<? extends T> it2, Comparator<T> comparator) {
        if (it1 == null) {
            throw new NullPointerException();
        }

        if (it2 == null) {
            throw new NullPointerException();
        }

        this.it1 = it1;
        this.it2 = it2;
        this.comparator = comparator != null ? comparator : defaultComparator();
    }

    public boolean hasNext() {
        return obj1 != null || obj2 != null || it1.hasNext() || it2.hasNext();
    }

    public T next() {
        if (obj1 == null) {
            obj1 = (it1.hasNext()) ? it1.next() : null;
        }

        if (obj2 == null) {
            obj2 = (it2.hasNext()) ? it2.next() : null;
        }

        if (obj1 != null && obj2 != null) {
            if (comparator.compare(obj1, obj2) < 0) {
                return obj1();
            } else {
                return obj2();
            }
        } else if (obj1 != null) {
            return obj1();
        } else if (obj2 != null) {
            return obj2();
        } else {
            throw new NoSuchElementException();
        }
    }

    private T obj1() {
        lastUsed = it1;
        T result = obj1;
        obj1 = null;
        return result;
    }

    private T obj2() {
        lastUsed = it2;
        T result = obj2;
        obj2 = null;
        return result;
    }

    public void remove() {
        if (lastUsed == null) {
            throw new IllegalStateException();
        }

        lastUsed.remove();
        lastUsed = null;
    }

    @SuppressWarnings("unchecked")
    private Comparator<T> defaultComparator() {
        return (o1, o2) -> ((Comparable<T>) o1).compareTo(o2);
    }
}

CompositeIterable.java

import java.util.Iterator;

public class CompositeIterable<T> implements Iterable<T> {
    private final Iterable<? extends T> iterable1;
    private final Iterable<? extends T> iterable2;

    public CompositeIterable(Iterable<? extends T> iterable1, Iterable<? extends T> iterable2) {
        this.iterable1 = iterable1;
        this.iterable2 = iterable2;
    }

    @Override
    public Iterator<T> iterator() {
        return new CompositeIterator<>(iterable1.iterator(), iterable2.iterator());
    }
}

TestCompositeIterator.java

import java.util.Arrays;
import java.util.List;

public class TestCompositeComparator {

    public static void main(String[] args) {
        List<Bar> list1 = Arrays.asList(new Bar(10), new Bar(20), new Bar(50), new Bar(80), new Bar(90));
        List<Qux> list2 = Arrays.asList(new Qux(30), new Qux(40), new Qux(60), new Qux(70), new Qux(100));

        Iterable<Foo> composite = new CompositeIterable<>(list1, list2);

        for (Foo foo : composite) {
            System.out.println(foo);
        }
    }

}

class Foo implements Comparable<Foo> {
    final int id;

    Foo(int id) {
        this.id = id;
    }

    @Override
    public int compareTo(Foo other) {
        return id - other.id;
    }

    @Override
    public String toString() {
        return getClass().getName() + "-" + id;
    }
}

class Bar extends Foo {
    Bar(int id) {
        super(id);
    }
}

class Qux extends Foo {
    Qux(int id) {
        super(id);
    }
}

How to move an object along a sine curve in Unity?

2016-03-01T13:02:00+02:00

Today we solved a small task of moving objects along a given trajectory. In our case it was a sine curve.

Scene setup.

There is a minimal set of objects in the scene: a camera, a light, a cube and a sphere. The camera is rotated by 90 degrees around the X axis and lifted up along the Y axis, so we’re looking at the scene from above. The cube has a Rigidbody attached, with the Use Gravity property disabled. The sphere has just a regular SphereCollider.

Mathematical background.

We want to move the Cube towards the Sphere, adding a sinusoidal vibration perpendicular to the direction of movement. First, we need to calculate the direction vector and a vector orthogonal to it. We will multiply the orthogonal vector by the result of the sine function (time is the argument).

Scripting.

Attach the Mover script to the Cube object. In the Start() method we save both vectors and the start time. Finally, the main magic happens in a single line of code in the FixedUpdate() method. We need to calculate the magnitude of the orthogonal vector using the classic formula of periodic vibration: y = a * sin(w * x), where a is the amplitude of vibration, w is the frequency of vibration, and x is time in our case. After that, we add the two vectors and assign the result to the Rigidbody’s velocity.

using UnityEngine;
using System.Collections;

public class Mover : MonoBehaviour {
    public Rigidbody rb;

    public Transform target;
    public float speed;
    public float amplitude;
    public float frequency;

    private float startTime;
    private Vector3 direction;
    private Vector3 orthogonal;

    void Start() {
        startTime = Time.time;
        direction = (target.position - transform.position).normalized;
        orthogonal = new Vector3 (-direction.z, 0, direction.x);
    }

    void FixedUpdate () {
        float t = Time.time - startTime;
        rb.velocity = direction * speed + orthogonal * amplitude * Mathf.Sin (frequency * t);
    }
}

That’s all! You can download all sources from GitHub.

Binary search tricks

2016-02-25T01:05:00+02:00

The array is probably the most popular data collection. Everyone has used, is using and will use it. If an array is sorted, you can simplify your life while processing it. We want to share a simple but effective trick with the binary search algorithm.

Imagine you have a sequence of N numbers which splits the space into N + 1 segments. The two segments on the edges are infinite. For instance, here is a fuzzy thermometer:

The idea is to display a single word describing the weather. In other words, this is a function which accepts a temperature as an argument (in Celsius in this example) and returns a single word as a string.

The simplest solution may look like this:

public class Thermometer {
    int[] values = {-10, 0, 5, 20};

    String[] labels = {"ice", "frosty", "cold", "warm", "hot"};

    String getLabel1(int value) {
        int n = values.length;
        for (int i = 0; i < n; ++i) {
            if (value <= values[i]) {
                return labels[i];
            }
        }

        return labels[n];
    }

The algorithm is: iterate over the array and get the label by the index of the first suitable element. It works because our array is sorted, and we know it. The complexity of this method is linear — O(n). It’s not a problem for 4 values in an array, but in general it’s not a good solution, and everyone should keep this in mind.

Well, let’s add another method which is much better than the first one:

    String getLabel2(int value) {
        int index = Arrays.binarySearch(values, value);
        if (index < 0) {
            index = -(index + 1);
        }

        return labels[index];
    }

We’re trying to find the index of the given value in the array. What if this value is missing from the array? The binarySearch() method will return -(insertion point) - 1, where insertion point is defined as the point at which the key would be inserted into the array: the index of the first element greater than the key, or a.length if all elements in the array are less than the specified key — exactly what we need!

Thus, we can check if the result is negative, and then convert it to the positive value we need. After that, we just return the label by index. The complexity of the binary search algorithm is logarithmic — O(log2 n). This means that even with 1 million elements you will find the result in no more than 20 iterations.

Let’s test this new method:

    public static void main(String[] args) {
        Thermometer t = new Thermometer();
        t.test(-15);
        t.test(-10);
        t.test(-5);
        t.test(0);
        t.test(1);
        t.test(5);
        t.test(15);
        t.test(20);
        t.test(25);
    }

    void test(int value) {
        System.out.println(value + " " + getLabel1(value) + " " + getLabel2(value));
    }

Here is the output:

-15 ice ice
-10 ice ice
-5 frosty frosty
0 frosty frosty
1 cold cold
5 cold cold
15 warm warm
20 warm warm
25 hot hot

We can see that both methods work correctly. But the second method looks much more elegant and works dramatically faster on large arrays! Full source code is available at the end of this post. Thanks for reading!

NOTE: If the value exactly matches one from the array, we associate it with the left category (e.g. -10 is treated as ‘ice’). If you want to associate it with the right category, you need to replace operator <= with operator < inside getLabel1(), and replace binarySearch(values, value) with binarySearch(values, value + 1) inside getLabel2(). In this case -10 will be treated as ‘frosty’.

Source code

Thermometer.java

import java.util.Arrays;

public class Thermometer {
    int[] values = {-10, 0, 5, 20};

    String[] labels = {"ice", "frosty", "cold", "warm", "hot"};

    String getLabel1(int value) {
        int n = values.length;
        for (int i = 0; i < n; ++i) {
            if (value <= values[i]) {
                return labels[i];
            }
        }

        return labels[n];
    }

    String getLabel2(int value) {
        int index = Arrays.binarySearch(values, value);
        if (index < 0) {
            index = -(index + 1);
        }

        return labels[index];
    }

    public static void main(String[] args) {
        Thermometer t = new Thermometer();
        t.test(-15);
        t.test(-10);
        t.test(-5);
        t.test(0);
        t.test(1);
        t.test(5);
        t.test(15);
        t.test(20);
        t.test(25);
    }

    void test(int value) {
        System.out.println(value + " " + getLabel1(value) + " " + getLabel2(value));
    }
}

Thermometer.out

-15 ice ice
-10 ice ice
-5 frosty frosty
0 frosty frosty
1 cold cold
5 cold cold
15 warm warm
20 warm warm
25 hot hot

Android. Support library. Nested fragments and startActivityForResult()

2014-01-14T09:08:00+02:00

This post is dedicated to nested Fragments from the support library and to their big issue.

Fragment has the following methods: startActivityForResult() and onActivityResult(). The first one just delegates the call to FragmentActivity.startActivityFromFragment(), and the second one is called from FragmentActivity.onActivityResult().

If this behavior is just a wrapper around Activity, then how is the result delivered to the Fragment instance?

All the magic is hidden in the method’s argument requestCode. FragmentActivity allows only the lower 16 bits to be used for external purposes. The higher 16 bits are used to store the private index of the Fragment inside FragmentManager:

// FragmentActivity.java

/**
 * Modifies the standard behavior to allow results to be delivered to fragments.
 * This imposes a restriction that requestCode be <= 0xffff.
 */
@Override
public void startActivityForResult(Intent intent, int requestCode) {
    if (requestCode != -1 && (requestCode&0xffff0000) != 0) {
        throw new IllegalArgumentException("Can only use lower 16 bits for requestCode");
    }
    super.startActivityForResult(intent, requestCode);
}

/**
 * Called by Fragment.startActivityForResult() to implement its behavior.
 */
public void startActivityFromFragment(Fragment fragment, Intent intent,
        int requestCode) {
    if (requestCode == -1) {
        super.startActivityForResult(intent, -1);
        return;
    }
    if ((requestCode&0xffff0000) != 0) {
        throw new IllegalArgumentException("Can only use lower 16 bits for requestCode");
    }
    super.startActivityForResult(intent, ((fragment.mIndex+1)<<16) + (requestCode&0xffff));
}

FragmentActivity replaces requestCode with a modified one. After that, when onActivityResult() is invoked, FragmentActivity parses the higher 16 bits and restores the index of the original Fragment. Look at this scheme:

Well, this dirty bitwise hack allows us to start an Activity for result from a Fragment and handle the answer inside the Fragment. So, what’s the problem?

If you have a few fragments at the root level, there are no problems. But if you have nested fragments, for example a Fragment with a few tabs inside a ViewPager, you will definitely run into a problem (or already have).

Method Fragment.onActivityResult() will not be called for nested fragments.

// FragmentActivity.java

/**
 * Dispatch incoming result to the correct fragment.
 */
@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
    mFragments.noteStateNotSaved();
    int index = requestCode>>16;
    if (index != 0) {
        index--;
        if (mFragments.mActive == null || index < 0 || index >= mFragments.mActive.size()) {
            Log.w(TAG, "Activity result fragment index out of range: 0x"
                    + Integer.toHexString(requestCode));
            return;
        }
        Fragment frag = mFragments.mActive.get(index);
        if (frag == null) {
            Log.w(TAG, "Activity result no fragment exists for index: 0x"
                    + Integer.toHexString(requestCode));
        } else {
            frag.onActivityResult(requestCode&0xffff, resultCode, data);
        }
        return;
    }

    super.onActivityResult(requestCode, resultCode, data);
}

This happens because only one index is stored inside requestCode: the index of the Fragment inside its FragmentManager. When we use nested fragments, there is a child FragmentManager, which has its own list of Fragments. So, it’s necessary to save the whole chain of indices, starting from the root FragmentManager.

How can we fix this? Only 16 bits of requestCode are available to us. We tried to skip the default behavior completely and use all 32 bits, but FragmentActivity throws an exception inside its methods (see the first code snippet above) if you try to use the higher 16 bits yourself. We created an issue on the bug tracker which describes this situation.

Until it is fixed, all we can do is use the lower 16 bits to store both the chain of fragments and the externally used requestCode.

A real app doesn’t have that many Fragments. A typical app has from 1 to 4 Fragments on one screen. An app rarely has a deep structure of nested fragments — usually just 1 or 2 levels of nesting with ViewPager. An int variable is far too big to store such an index (one int per index). So, we can significantly reduce the number of precious bits used to store indices.

For example, with 3 bits we can store numbers from 0 to 7. Reserving 3 levels of depth, we spend just 9 of the 16 allowed bits. The remaining 7 bits (values from 0 to 127) are available for external use.

You can clone and check this solution on GitHub. If you check out “Initial commit”, you will see the problem described above. In the HEAD of the repository the problem is fixed.

Of course, this solution adds more restrictions:

We can’t use a requestCode greater than 127.
We can’t have more than 3 levels of nested fragments.
We can’t use more than 7 fragments at one level.

But look at real apps — these limits are quite acceptable!

Well, if you’re reading this, the post was interesting for you. Thanks so much!

Sources from this post are available on GitHub.