The reason that chimps are always winning is also related to the mentioned issue. Chimps buy randomally (buy_count = int(max_buy * random.random())), it never buys everything possible. So it never gets bankrupt by the controller bug (unless a random output of 1 and controller bug happen at same moment which will be very rare).

@Night2 the way the bug is happening, they will go bankrupt if they are close enough to 1. It doesn't necessarily need to be 1

As far as I can tell, as long as the controller is never passed a #e# value it should work. The problem is that once it is given an e value it starts working with floats instead of integers

This should be fixable if you coerce values to int in the controller

This happens because the long integer type has infinite precision while float can round either up or down.

Anyone online who could answer a JavaScript question?

what do you want to know?

The problem is that since my JS instance uses UTF-8 strings, when I do "message.charCodeAt(i)", I don't get the true binary value. I just want the literal binary representation of the string

Where does that string come from

*?

I suppose it would be a better idea to put it in something like an UInt8Array, but you'e have to have it in there in the first place already, because going via a UTF-8 encoded string is potentially a lossy process

So this is all happening in an Atom plugin I'm trying to make to save myself time. I have an instance of the current editor widow and retrieve my text via a .getText() call. The idea is that I have files I want to read that are encoded in EBCDIC, so I want to open them then run the plugin so that it converts it to viewable ASCII text

I have absolutely no idea how the Atom plugin api works :p

But I'd wager you can get the raw bytes in some way as well

Because how would you otherwise edit a binary file

This is the API page for the editor window I have access to: atom.io/docs/api/v1.29.0/TextEditor

What do you get when you call that getText method on a file that contains, say, the 256 bytes \x00...\xff ?

python3 -c 'print("".join(chr(i) for i in range(256)) + "\n")'

Into a file

It seems to output the same thing

Like my conversion process correctly grabs that file's raw binary

@tomsmeding this room should be left as the stock exchange discussion. Try to use the nineteenth byte for this conversation