peterderivaz

I've been trying out this model on a 4090 to transcribe a Japanese grammar pdf (written in English with lots of Japanese examples) and it seems to be working very well from the small parts I have double checked. The output contains both the kanji/hiragana and English as appropriate without attempting any translation.

It has converted about 200 pages in an hour.

Reverse engineering the graphics from the 1998 3D Populous game.

The Raspberry Pi contains a Videocore processor (I wrote the original instruction set coding and assembler and simulator for this processor).

This is a general purpose processor which includes 16 way SIMD instructions that can access data in a 64 by 64 byte register file as either rows or columns (and as either 8 or 16 or 32 bit data).

It also has superscalar instructions which access a separate set of 32-bit registers, but is tightly integrated with the SIMD instructions (like in ARM Neon cores or x86 AVX instructions).

This is what boots up originally.

Videocore was designed to be good at the actions needed for video codecs (e.g. motion estimation and DCTs).

I did write a 3d library that could render textured triangles using the SIMD instructions on this processor. This was enough to render simple graphics and I wrote a demo that rendered Tomb Raider levels, but only for a small frame resolution.

The main application was video codecs, so for the original Apple Video iPod I wrote the MPEG4 and h264 decoding software using the Videocore processor, which could run at around QVGA resolution.

However, in later versions of the chip we wanted more video and graphics performance. I designed the hardware to accelerate video, while another team (including Eben) wrote the hardware to accelerate 3d graphics.

So in Raspberry Pis, there is both a Videocore processor (which boots up and handles some tasks), and a separate GPU (which handles 3d graphics, but not booting up).

It is possible to write code that runs on the Videocore processor - on older Pis I accelerated some video decode sofware codecs by using both the GPU and the Videocore to offload bits of transform and deblocking and motion compensation, but on later Pis there is dedicated video decode hardware to do this instead.

Note that the ARMs on the later Pis are much faster and more capable than before, while the Videocore processor has not been developed, so there is not really much use for the Videocore anymore. However, the separate GPU has been developed more and is quite capable.

Project Euler challenge involving Fractran: https://projecteuler.net/problem=308

In practice I would expect Knuth's DLX algorithm to be much faster, both for generating the first solution, and for counting all solutions (for any reasonable sized N).

There are some timing results for a (well-optimized) backtracking solver here: http://www.jsomers.com/nqueen_demo/nqueens.html

N=21 takes about 600,000 seconds on an 800MHz computer, i.e. around 500.10^12 computations.

In comparison, the algorithm in the paper has a complexity higher than 8^N, which is around 9,000,000.10^12 for N=21.

The number of solutions is growing by about an order of magnitude (sequence https://oeis.org/A000170) for each increment of N.

We paid a company called Metaware to make a compiler. I believe this compiler is still in use.

As it happens, while we were waiting for this compiler to be made for us, I ported GCC to the architecture for my own use. I don't remember it being all that painful, just a few pages of machine description and everything seemed to work fine.

This only supported the scalar instruction set. However, when we needed an MP3 decoder I found that it really needed 32bit precision to meet the audio accuracy, so I also made a different port of gcc that targeted the vector processor. I changed the float data type so any mention of float actually represented 16 lanes of a 16.16 fixed point data type implemented on the vector processor. From what I recall, mp3 decode required 2MHz of the processor for stereo 44.1kHz.

It was my first job out of University to design this instruction set which may explain some of the quirkiness...

Initially the instructions did all set the status flags but it caused a tight feedback loop in the processor. The choice was between a higher clock frequency for all instructions or better 64-bit arithmetic.

None of the initial video applications needed 64-bit support so it lost out, although I did get to put in the divide instruction just so my Doom port could run faster :)

Not the original poster, but one thing that confused me was that I can clearly draw a graph that cannot be two coloured with a single pen stroke if I am allowed to reverse direction and keep drawing back over the same line again (indeed it is of course possible to draw any connected graph this way). I wasn't sure which part of the conditions forbid this.

Perhaps it is no longer a graph if I have a bidirectional edge? Or perhaps it is not considered planar if two edges coincide?

I've found using nolearn and lasagne on top of Theano made Theano much easier to use while still being in Python with access to familiar graphics routines.

lasagne gives you ways of constructing neural network layers (implemented as Theano functions).

nolearn sits on top of lasagne and gives a Scikit learn style interface that makes it trivial to set up a standard deep network to predict values from given input data.

Using nolearn was a very similar experience for me to using the Torch7 framework.

I think in this formula the altitude should be in feet, while the result is in miles, so 30,000 feet actually gives 213 miles.

I ran some experiments to investigate the discrepancy.

The largest differences were caused by:

1. A variable quantiser being used for HEVC, but not for VP9 (as you described)

2. Keyframes being forced every 30 frames for VP9 in the first paper

HEVC also had I frames added every 30 frames, but these were not IDR frames, meaning that B frames were allowed to use the information from the I frame in HEVC.

However, in VP9, true keyframes were forced every 30 frames. The way VP9 works this meant that every 30 frames it encoded both a new Intra frame, and a new golden frame.

Making both codecs use a true fixed quantizer and removing the forced intra frames made the results more like Google's own paper.

I guess the moral is to not force frequent keyframes when encoding with VP9.

I don't know Colin's logic, but my personal reasoning would be:

1. If this were true then it gives a simple, efficient, deterministic method to test for primes. (You can compute P_n modulo n efficiently using matrix exponentiation.)

2. If there was such a method I am sure I would have heard of it before - and people wouldn't bother using Miller-Rabin or the complicated deterministic primality method

3. Therefore there must be a flaw...

The list is here: http://oeis.org/A013998

The first is P_(271441) with 33,150 digits

I ran into this when computing PSNR comparisons using a Numpy function that returned a numpy integer type:

    >>> import numpy
    >>> x=0
    >>> y=numpy.int32(2*10**9)
    >>> x+=y
    >>> x+=y
    >>> x
    -294967296

In later versions of Python this gives a RuntimeWarning so this is less likely to cause problems now.

Another similar idea is the Kempner series.

If you add 1/n for all natural numbers n, then the series tends towards infinity.

However, if you leave out any integers that contain a digit 9, then the series converges (to just under 23). (It would also converge if you left out numbers containing a digit 3, just to a different limit.)

I enjoyed this blog post and Javascript implementation of an interactive Quantum circuit inspector.

http://strilanc.com/quantum/2014/03/07/Building-your-own-Qua...

It is a lower level than the Google project and only suitable for 3 qbits circuits, but I found it very useful for building up an intuition about the basic logic gates.

The vector register file is a block of registers 64 bytes across by 64 down which can be accessed horizontally (H) or vertically (V), and in units of 16 bytes (H8), 16 shorts (H16 or HX), or 16 32-bit words (H32).

Each processor has an accumulator that can be cleared (CLRA) or used (ACC).

This code is basically equivalent to the following C code:

    uint8 in[2][16];
    int16 temp[2][16];
    int32 r1,r3,r5;
    uint8 *r0;
    do {
        ... code omitted
	// vmul  -,H(1,0),3 CLRA ACC
	// vadd  HX(3,0),H(0,0),2 ACC
	for(x=0;x<16;x++) {
	  temp[x]=inb[1][x]*3+in[0][x]+2;
	}
	//vasr  H(0++,0),HX(2++,0),2 REP 2
	//vst  H(0++,0),(r0+=r3) REP 2 
	for(y=0;y<2;y++) {
	  for(x=0;x<16;x++) {
		in[y][x] = temp[y][x]>>2;
		r0[y*r3+x] = in[y][x];
	  }
	}   
	//   add   r0,16
	//   addcmpblt r5,1,r1,loopacross
	r0 += 16;
	r5 += 1;
    } while (r5<r1);

This is code for the vector processor. This is not the same as the GPU cores which use a different architecture and instruction set (based around floating point calculations).

I wonder if you misunderstood his comment as a suggested method to solve the mathematical problem?

The way I read it, he was suggesting a possible way of reducing the size of the DRUP certificate from 13GByte by searching for common patterns, perhaps similar to the way bzip works.

I've been using Anki for learning Japanese. I've particularly appreciated the decks that include audio of complete sentences and have found that it has greatly improved my ability to understand spoken language.

One thing that I've wondered is whether it is a good idea to try to think up mnemonics for tricky words when using spaced repetition. It certainly seems effective in helping recall but I worry that I might train my brain to always rely on going via an indirect path to get to the information and that this will slow down my ability to understand real language.

Has anyone seen any research along these lines?

Have you seen crazybump?

There is a good tutorial on it at http://www.blenderguru.com/videos/the-secrets-of-realistic-t...

It is a program that takes a single image and generates diffuse/normal/occlusion/specular/displacement textures from it in such a way as can be easily used as a material in blender.

As you can see from the video, it can work amazingly well given the limited amount of input information.

Interestingly, Wikipedia disagrees.

For a radix of 10, there is thought to be no number with a multiplicative persistence > 11: this is known to be true for numbers up to 10 to the power of 50.

http://en.wikipedia.org/wiki/Persistence_of_a_number

I guess the problem is that when you multiply lots of digits together you become increasingly likely to end up with a 0 digit somewhere.

You could try my charityware WebGL game at http://www.penguinspuzzle.appspot.com/

I guess you could find the shortest path by iteratively deleting an edge and checking whether the best cost has got worse. If it does get worse, then put that edge back in and try deleting another edge. If it does not get worse, then permanently delete that edge.

I think this should terminate (after trying all edges once each) with an example of the shortest path (that consists of all remaining edges).

I've posted a Python version of the main max clique algorithm at https://github.com/peterderivaz/maxclique

This implements the algorithm as I understood it described in the paper.

A small implementation detail that might accelerate things (that I haven't yet implemented) might be to sort the neighbours of each vertex in order of decreasing degree.

This would then allow the calculation of the set in "Pruning 5" of Algorithm 1 to terminate as soon as d(w) <= max.

As far as I understand, the basic idea is to cooperate with a probability that depends on whether your opponent cooperated in the previous round. (Actually there are 4 probabilities because the strategy also depends on whether you cooperated in the last round.)

For example, you might say that you will cooperate with prob 75% if I cooperated, or 25% otherwise.

By choosing the probabilities carefully this can turn the game into one where the more I choose to cooperate, then the better I do - but you will always outperform me (unless I choose to always defect when we both end up equally lost).

Feels similar to only proposing win-lose business deals. You will never "lose" but will soon run out of people willing to deal.

The nicest use of a similar XOR trick I have seen is to eliminate dead cycles in hardware bus arbiters.

Suppose you need to multiplex between inputs A,B,C to make output D (e.g. you have a 3d block, a display engine, and a CPU all trying to access DRAM). The idea is to xor all valid inputs together.

When there is only one input this results in output=input. If all 3 are active then the output is A^B^C. The trick is that the next cycle only the granted input (say A) is removed so the output is B^C

Receivers are required to XOR two sequential values to extract the actual data. In this case (A^B^C)^(B^C)=A.

See the "NoX Router" for details and explanation of how this compares to alternative arbitration approaches: pharm.ece.wisc.edu/papers/micro2011_nox.pdf

I believe a standalone video phone should be quite easy. My understanding is that the chip can support 1080P encode or decode (so 720P bi-directional video should be fine) and that it will have OpenMAX libraries to allow you to drive the hardware codecs.

OpenMAX code is quite fragile in my experience (from trying to use such libraries on Android phones) so I was wondering about writing a Python wrapper (based on the ctypes module) for the video encode/decode to make it easier to use. (Unless someone has done this already?)