It's still fibonacci. The sequence is exactly the same. The only thing that is different is the starting index.

Thanks for your kind feed: to tell the truth, it was not a matter of missing parentheses (Python would not even run without it), but a nasty edge case I never encountered in my tests (basically if both numbers of X length have a sum of less than X length, like summing 0023+0633); fixed with .zfill and tested for a while, so you should now be safe on that.

The Ruby translation should have been always good, as I implemented another approach to solve it (no fun otherwise); let me know if you find any more trouble or if I can do anything else for you :)

¢ is in the extended ASCII range (char code 162, more than 7 bits) and has to be stored as 2 bytes in UTF-8.

Javascript handles UTF-8 seamlessly (up to a certain limit), so "¢".charCodeAt(0) yields the expected char code, 162. But if you're trying to handle UTF-8, encoding 162 would be wrong, because it's not a single byte encoding. Breaking it into 8-bit sections would also be wrong, unless you're encoding UTF-16 (and then, every character is encoded as 16 bits, including standard ASCII characters).

There are four possible ways of encoding ¢:

// "¢" is code point u+00a2
"\xa2"     // ASCII, supports up to 8 bits
"\xc2\xa2" // UTF-8, encodes up to 7 bits as 1 byte, 8-11 bits as 2 bytes
"\0\xa2"   // big-endian UTF-16, supports up to 16 bits, MSB first
"\xa2\0"   // little-endian UTF-16, supports up to 16 bits, LSB first

And to encode グ:

// "グ" is code point u+30b0
"\xb0"         // ASCII, truncate to 8 bits or throw an error - it can't be properly represented
"\xe3\x82\xb0" // UTF-8, encodes 12-16 bits as 3 bytes
"\x30\xb0"     // big-endian UTF-16
"\xb0\x30"     // little-endian UTF-16

For comparison, to encode a standard ASCII character such as A:

// "A" is code point u+0041
"A"   // ASCII, one byte
"A"   // UTF-8, one byte
"\0A" // big-endian UTF-16
"A\0" // little-endian UTF-16

"Courtesy of ProjectEuler.net" :)

I wonder if it will work for me? Carry - Arithmetic

It works if you replace '(' with %28 and ')' with %29

"グ".charCodeAt(0).toString(2);

Ah. Fair enough. Interestingly, though "¢".charCodeAt(0).toString(2) == "10100010", which is 8 bits anyway. Have you got a different example to hand?

"¢¢".length == 2

I thought multi-byte characters were seen as single-byte characters when made into a JavaScript string. So if a string had a single multi-byte character in it, its length would still be 2, and you would still access each half as two separate characters. I think that's right?

The kata specifies ASCII as the character set, which precludes multibyte characters. Multibyte characters would definitely be a more difficult problem.

Looks like the link is now totally gone (but you might be editing it as I'm writing this)

Well, now I feel dumb. I just realized that I wasn't understanding how valueOf was supposed to work because I was testing with valueof -with a lowercase o. I'm resubmitting with a cleaner solution! :-P

You are right. Did a new submission with this corrected.

Do you gain memory from having functions in the closure instead of each of the objects?

How does javascript engines actually store function instances? If there are properties attached to a function instance these obviously has to be stored somewhere. In the case above does it matter if eval and toString are bound to functions in the closure? The toString and eval functions above are semantically different for every Operator instance, but are all these stored as different entities internally in the javscript engine, seems more naturally treat the actual logic of functions as immutable and just apply these logic entities to different objects.

Secondly if the functions are placed in the outside closure as edalorzo suggested will changing, for example reduce (in edalorzos solution), change the behaviour of all Operators or will they still be bound to the original reduce, if they were created before the change?

Well, on a kata like this, where the efficiency is probably 2-3 orders of magnitude off, I think the extra memory for the functions is negligible. ;-)

And I made a tiny mistake about the 0 instead of new Value(0). The val() function itself still serves a purpose, as it's DRYer than typing out the .eval().valueOf() on each parameter. I could have removed the test for a single expression though. (oops!)

Finally, regarding the 0 and this.expressions tests, I don't believe your description made it clear if you needed to test for edge cases or not. I just did it out of habit.