There have been multiple accounts created with the sole purpose of posting advertisement posts or replies containing unsolicited advertising.

Accounts which solely post advertisements, or persistently post them may be terminated.

magic_lobster_party

@[email protected]

This profile is from a federated server and may be incomplete. Browse more on the original instance.

magic_lobster_party , to programmer_humor in Not everything can be done in constant time, that's O(k)

It has been a pleasure having this internet argument with you. I learned a bit, and you learned a bit. It’s a win win :)

magic_lobster_party , to technology in Recommendation Algorithms & Advertising - Where do you draw the line?

Whether they intend it or not, these engines are built to funnel you back into the lowest common denominator, most broadly appealing stuff, because that's what the algorithm sees gets the most clicks from the average person.

That’s not my general experience. Spotify for example is good at recommending me songs with less than 10k plays which I vibe on. I’ve discovered many smaller artists thanks to Spotify recommendations.

magic_lobster_party , to technology in Recommendation Algorithms & Advertising - Where do you draw the line?

Recommendation is part of the service. If they know I like something, then it’s reasonable they recommend me something that’s similar. It’s like going to a restaurant and asking for recommendations.

Advertising is when things are promoted outside the service. It’s like going to a restaurant and they tell me about Raid Shadow Legends. I don’t want that.

I think recommendation should be linked to usage data like watch history on that particular service. Location and other external information shouldn’t be used. I don’t want my recommendations depend on which friends I have or recent activity on a different service.

magic_lobster_party , to programmer_humor in Not everything can be done in constant time, that's O(k)

My implementation: https://pastebin.com/3PskMZqz

Results at bottom of file.

I’m taking into account that when I update a hash, all the hashes to the right of it should also be updated.

Number of hashes is about 2.71828 x n! as predicted. The time seems to be proportional to n! as well (n = 12 is about 12 times slower than n = 11, which in turn is about 11 times slower than n = 10).

Interestingly this program turned out to be a fun and inefficient way of calculating the digits of e.

magic_lobster_party , to science_memes in Science memes

Normie numbers (aka natural numbers)

magic_lobster_party , to technology in Why we don't have 128-bit CPUs

Only thing I can find is that it has 128-bit graphics-oriented floating-point unit delivering 1.4 GFLOPS.

Probably only for marketing reasons. Everyone was desperate not to be worse than N64.

magic_lobster_party , to science_memes in Garfield

My interpretation is that Jon starts talking about how division by 0 is not possible. Garfield then goes on about how we can use limits to assign values to such expressions, which we can use to calculate derivatives. I guess Garfield starts to question whether dy/dx really exists after all this.

Jon then changes the subject to be about integrals, which Garfield is immediately annoyed about the missing +C.

It’s super funny.

magic_lobster_party , to technology in YouTube Seems to Be Cracking Down on a VPN-Powered Discount

It’s a poorly worded article. YouTube premium “limits ads” as in being completely ad free (besides in-video sponsorships). YouTube hasn’t gone down that route yet.

magic_lobster_party , to science_memes in Science memes

Does the meme making fun of all memes make fun of itself?

magic_lobster_party , to technology in YouTube Seems to Be Cracking Down on a VPN-Powered Discount

I don’t think it’s an unpopular opinion, but I’m not sure how YouTube can deal with it best. There’s sponsor block, but it’s relying on crowdsourced data.

magic_lobster_party , to technology in Why we don't have 128-bit CPUs

Probably not in consumer grade products in any foreseeable future.

magic_lobster_party , to technology in Why we don't have 128-bit CPUs

More complexity with barely any (practical) benefits for consumers.

magic_lobster_party , to technology in YouTube Seems to Be Cracking Down on a VPN-Powered Discount

Where are you getting that from? YouTube premium is ad free (so far).

magic_lobster_party , to technology in Why we don't have 128-bit CPUs

Not true 128 bit. It has 128 bit SIMD capabilities, but that’s about it. Probably mostly because of marketing reasons to show how much better it is than N64 (which also is “64 bit” for marketing reasons).

In that case, we’re having 512 bit computers now: https://en.wikipedia.org/wiki/AVX-512

magic_lobster_party , (edited ) to programmer_humor in Not everything can be done in constant time, that's O(k)

So in your code you do the following for each permutation:

for (int i = 0; i<n;i++) {

You’re iterating through the entire list for each permutation, which yields an O(n x n!) time complexity. My idea was an attempt to avoid that extra factor n.

I’m not sure how std implements permutations, but the way I want them is:

1 2 3 4 5

1 2 3 5 4

1 2 4 3 5

1 2 4 5 3

1 2 5 3 4

1 2 5 4 3

1 3 2 4 5

etc.

Note that the last 2 numbers change every iteration, third last number change every 2 iterations, fourth last iteration change every 2 x 3 iterations. The first number in this example change every 2 x 3 x 4 iterations.

This gives us an idea how often we need to calculate how often each hash need to be updated. We don’t need to calculate the hash for 1 2 3 between the first and second iteration for example.

The first hash will be updated 5 times. Second hash 5 x 4 times. Third 5 x 4 x 3 times. Fourth 5 x 4 x 3 x 2 times. Fifth 5 x 4 x 3 x 2 x 1 times.

So the time complexity should be the number of times we need to calculate the hash function, which is O(n + n (n - 1) + n (n - 1) (n - 2) + … + n!) = O(n!) times.

EDIT: on a second afterthought, I’m not sure this is a legal simplification. It might be the case that it’s actually O(n x n!), as there are n growing number of terms. But in that case shouldn’t all permutation algorithms be O(n x n!)?

EDIT 2: found this link https://stackoverflow.com/a/39126141

The time complexity can be simplified as O(2.71828 x n!), which makes it O(n!), so it’s a legal simplification! (Although I thought wrong, but I arrived to the correct conclusion)

END EDIT.

We do the same for the second list (for each permission), which makes it O(n!^2).

Finally we do the hamming distance, but this is done between constant length hashes, so it’s going to be constant time O(1) in this context.

Maybe I can try my own implementation once I have access to a proper computer.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • random
  • lifeLocal
  • goranko
  • All magazines
    •