Hacker Newsnew | past | comments | ask | show | jobs | submit | eatitraw's commentslogin

You do realize that everyone (especially the hosts) was in on the joke, right? I did chat to the hosts afterwards!

What joke? You presented this all as a completely factual thing that happened, and that you were the sole guardian of... non-cringe authenticity?... in the place, and that some loser thanked you for your service.

Now you're saying that the whole article was a lie?

Congrats, you're now even more disappointing of a person than originally presented.


The entire article is true. And if joke isn't clear to you, I won't be explaining it.

You have a tremendous amount to learn about writing, and communication in general. Good luck

The two minutes is a very short amount of time — much shorter than a typical speed dating slot of 5-10 minutes. People chat about all sorts of things: from work to previous relationships to “where are you from”-style questions.

With regular speed dating I had all sorts of chats, it usually enough for 1-3 threads of conversations.


Looks like it's applying the old advice by multiplying your estimates by the universal constant _pi_.

Well spotted. Yeah I said a million years and it came back "Actual estimate: 3141593 years from now"

This depends on your views on personal identity. It's not necessarily true that "you" exist from death to birth. Consciousness could be a singleton, and "You" could be everyone in the universe. Or perhaps "you" is only a single person-moment instantiated for a split second.

http://www.galactanet.com/oneoff/theegg_mod.html

https://qualiacomputing.com/2015/12/17/ontological-qualia-th...


Telegram is more of a social media platform than a messenger. It has public 'channels' - read-only blogs without likes and comments. The biggest Belarusian channel 'Nexta' has 2M+ subscribers.


> Evolved player makes invalid moves far away in the board, causing opponent players to run out of memory and crash

Well, this sounds like speedrunning. People have found arbitrary code execution vulnerabilities in SNES and used them to jump to the credits (which counts as completed the game) in less than a minute: https://www.youtube.com/watch?v=Jf9i7MjViCE

They also used the same technique to inject runnable code in the game: https://www.youtube.com/watch?v=jnZ2NNYySuE


Nah that’s not the same thing.

In this case it’s just choosing an option that involves very large numbers because it’s learned that it’s opponent can’t handle large numbers. There’s no code injection


The SMB3 ACE is one of the most technically interesting glitches. The usual skips and saves are much more mundane.

My point here is that there is similarity between (some) human players and some AI players. Even the discussion whether exploiting a glitch is actually 'winning' also looks very similar.


I guess it depends on your definition of arrays, and what you expect from them. For example, Ruby calls a similar thing array: https://docs.ruby-lang.org/en/2.0.0/Array.html

To me it is kind of self-growing array that can hold objects of different types. The C++-ish equivalent would be something like std::vector<void*> / std::vector<MagicObjectBoxType> (there is no MagicObjectBoxType of course).


I think you have a point about C or C++ notion of arrays having the same type.

I'll probably rewrite that paragraph, since the main point is to tell people unfamiliar with Python that lists aren't actually linked lists.


So... Because lists are dynamically typed and heterogeneous, does that mean the underlying C is basically a contiguous segment of memory of python object references? Then in cpython the actual list contents are Python objects sitting on the heap in a non-contiguous manner?

And when the list needs to be resized and doubles itself, it's just doubling the space for object references?


> Because lists are dynamically typed and heterogeneous, does that mean the underlying C is basically a contiguous segment of memory of python object references?

Yep, it is an array of pointers: https://github.com/python/cpython/blob/3.7/Include/listobjec...

> And when the list needs to be resized and doubles itself, it's just doubling the space for object references?

Basically yes. The growth pattern is not as aggressive as doubling though: https://github.com/python/cpython/blob/3.7/Objects/listobjec...


I keep forgetting just how readable cpython source is. I'm still mentally stuck in my beginner years, where it was all Greek to me.

Thanks for sharing these links.


Interesting:

"The growth pattern is: 0, 4, 8, 16, 25, 35, 46, 58, 72, 88, ..."

What is the big-o amortized cost of using this pattern? Doubling has a easy proof that it's O(1) amortized.


The growth pattern is still exponential, instead of going x -> 2 * x, you go x -> 9/8 * x + 6. I think it should still be O(1) amortized, you just need to adjust your proof for doubling a bit.


Mathematically the best is not doubling but fibonacci. for the start doubling is used because it's much faster to compute.


> So... Because lists are dynamically typed and heterogeneous, does that mean the underlying C is basically a contiguous segment of memory of python object references?

Yes. Every Python object is held by the interpreter as a pointer to a PyObject struct on the (C) heap.


Not something I would put into production, but had a fun application of this on a side project. I had the `id` of a function (but not the function object itself) and needed to recover the function. In CPython, `id` of a function corresponds to it's memory address (not sure if that can be overridden). By casting the id to a PyObject, I was able to recover the original.

    func = ctypes.cast(int(address), ctypes.py_object).value
Was kinda cool actually seeing that work.


It is indexable, and it is used as an array, so I guess it is an array in all implementations.

But good point, I should check this.

Dicts are definktely implemented differently in different implementations, and I mention this.


IIRC, vaping pure nicotine might be less addictive than smoking tobacco because tobacco contains a ton of other chemicals


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: