List of Comments

Thanks, will try that 🙂

Using 2x less memory. Probably faster too, if tested on non-busy server. class NumArray { int* const m_piSums; public: NumArray(vector& n) : m_piSums(&n[0]) { int s = n.size(); for (int i = 1; i < s; i++) { m_piSums[i] += m_piSums[i-1]; } } int sumRange(const int i, const int j) { return m_piSums[j] - (i ? m_piSums[i - 1] : 0); } };

It seems that WP has removed the tag I mentioned in my comment above. There are many html documents use <br> to represent as a soft break，not the slash one: <br/>. And <p>， in H5, it is valid. So they are not strict, well-formed XML. Many DOM parsers cannot handle them well.

doesn't matter, the PHPQuery recognizes self-closing tag. unclosed tag is not a valid HTML, which produces unexpected (unstable) results.

what about self-closing tag and the unclosed ？

I keep claiming it's full of bugs ! 1) ans[] MUST be initialized, or random values will poison the algorithm 2) the iteration on j for (j = 1; j <= n; j ++) { ans[j] = ans[j] + ans[j - 1]; } screws ans[] content - loop MUST be done backwards ! Just check my version against yours and see by yourself !

I'm afraid it is a bug: _ ans[] is not initialized, introducing potential bugs due to random values _ the loop for (j = 1; j <= n; j ++) { ans[j] = ans[j] + ans[j - 1]; } screws ans[] content proof: like this: ans[j] is always greater than ans[j-1], inacceptable for a line of Pascal's triangle ultimate proof: test my version against yours and see by yourself...

Please ignore my previous post (a -j should be a --j) The code for int pascal(int m, int n) is full of bugs ! Here’s a correct version: int pascal(int m, int n) { int ans[MAX]; int i, j; if (n > m) return 0; if (n + n > m) { n = m – n; // pascal(m, n) == pascal(m, m-n) – choose min(n, m-n) } if (n == 0) return 1; // n == m case now impossible ans[0] = 1; for (i = 1; i <= n; i++) { ans[i] = 0; //ans[] array MUST be initialized ! } for (i = 1; i <= m; i++) { for (j = n; 0 < j; --j) // j loop must be done backwards ! { ans[j] += ans[j – 1]; } } return ans[n]; }

It is not a bug. Just a recursion to illustrate the idea. Recursion can be optimised by iteration.

The code for int pascal(int m, int n) is full of bugs ! Here's a correct version: int pascal(int m, int n) { int ans[MAX]; int i, j; if (n > m) return 0; if (n + n > m) { n = m - n; // pascal(m, n) == pascal(m, m-n) - choose min(n, m-n) } if (n == 0) return 1; // n == m case now impossible ans[0] = 1; for (i = 1; i <= n; i++) { ans[i] = 0; //ans[] array MUST be initialized ! } for (i = 1; i <= m; i++) { for (j = n; 0 < j; --j) // j loop must be done backwards ! { ans[j] += ans[j - 1]; } } return ans[n]; }

(y)

16gb sd card+16gb usb flash disk Raid 0 Raspberry Pi 2 root@raspberry:~# hdparm -t /dev/md127 /dev/md127: Timing buffered disk reads: 114 MB in 3.03 seconds = 37.68 MB/sec root@raspberry:~# hdparm -I /dev/md127 | more root@raspberry:~# hdparm -T /dev/md127 /dev/md127: Timing cached reads: 670 MB in 2.00 seconds = 334.32 MB/sec root@raspberry:~# hdparm -T /dev/md127 /dev/md127: Timing cached reads: 664 MB in 2.00 seconds = 331.41 MB/sec root@raspberry:~#

thanks, good to know this trick!

I prefer using "cd. > file".

Thanks. I agree but in general i find the 'Bulk Optimisation' a useful tool.

Imagify seems a bit late to the game, there are so many image compression tools around. But very curious to see if it could beat the competition so gave it a try. It certainly looks very promising, but image compression doesn't seem intelligent enough. Some of the images I tried were compressed too much and others could easily be compressed much, much more.

Yes, it would be much more complex animation from left to right or right to left

Yes, you are right.

It may not be compatible (some image not showing with Lazy Load on) with the CloudFlare Rocket Loader.

my pleasure.

Thank you very much for all these tutorials. This was very interesting and help me get my feet wet in nes programming.

> The python console almost hangs.. So it is obvious a hidden power-mod rule applies. You are wrong 2**99999 % 50 is computed as simple exponentiation and then taking modulo, python does not do any optimization here. However if you write pow(2, 99999, 50) - you will get indeed the optimized version. Why then 2**99999 % 50 is immediate, while 2**99999 hangs? You should have written x = 2**99999 then the time will be the same (and even less). If you write simply 2*99999 in the console, python has to convert the number from the internal representation into decimal to print it, that's why it hangs.

HDD is lagging behind...

this is still 5.9.... windows are you @#$% kidding me?

sorry, i meant *value = randomizingFoo() 🙂