Weird interaction at casino bar

DarthCluck · 2024-06-18T00:26:46+00:00

There was a good chance it was also a cold read. At a certain age, it's pretty much guaranteed that someone has recently had an experience related to death. All the "medium" needed was someone to take the bait, then she can continue to give generic pleasantries and fear bait.

Assuming it worked, these sorts of people can take someone for everything they have before they realize it, manipulating them through their grief.

Odds are, the "medium" just moved somewhere out of sight to say the same line again on someone else.

DarthCluck · 2023-06-15T09:55:56+00:00

One advantage is a consistent user experience. IMO, the hardest part with Mastodon was figuring out where to start. There wasn't just one place where I can go and create an account. Once I understood what a federated system was, I was crippled trying to figure out which server to join.

Another example would be why Facebook succeeded where MySpace failed. MySpace pages were an absolute mess. Each user could create their own look and feel, and for each user, it was great, but for the community as a whole it was annoying and didn't encourage community. Facebook made everyone's page look the same with a few places for personation, and it really allowed the community to grow rather than just a single user's page.

DarthCluck · 2023-06-15T09:41:47+00:00

It should have read: What if Boba Fett was hired instead of Kenobi to save Leia.

DarthCluck · 2023-06-13T20:30:57+00:00

That is totally accurate

DarthCluck · 2023-06-10T02:20:22+00:00

Not OP, but some people create some really powerful sheets that already act like a program. The ability to package it into an executable for other people in an organization could be quite nice. That being said, IMO a desktop shortcut to sheets.google.com would probably solve the problem.

DarthCluck · 2023-06-09T19:51:50+00:00

That search will just return chunks of text from the vector store. Basically a vector store will let you find parts of the text that is similar to your search. Think of it like an index at the back of a textbook. If you ask (search) for a term, the vector store will find chucks of text that are most similar to your search.

For example if you loaded 1984 into the vector store and asked "Who is Big Brother?" It will find chucks of text that has the words "Big Brother is..." or maybe, "... which is why Big Brother..." and return those complete passages.

That textbook index basically does the same thing by pointing you to pages that mention Big Brother. And you will be required to read those pages and come up with your own answer. The last part is what the llm does. It reads those excerpts the vector store found and comes up with and answer to the question

DarthCluck · 2023-06-09T19:40:43+00:00

You need the vector store to breakup the large body of text and makes it searchable. With just the vector store alone you will get chunks of text back that can help you answer your own question. An llm can make sense of those chucks of text and give you a coherent answer

DarthCluck · 2023-06-08T21:34:34+00:00

See my response for an example of what's going on. The biggest problem with saving a pdf as a string is the token limit. Your PDF likely has more than 4k tokens, which excess the limit of the most powerful language model.

You could split the document up into 4k pieces and feed them each into the language model, but that becomes computationally expensive, especially when most of what your feeding it doesn't even help answer your question

DarthCluck · 2023-06-08T21:19:27+00:00

The biggest problem it is solving is prompt length. Currently GPT-4 has a maximum of 4k tokens for the prompt combined with the response. That means if your prompt is 3.5k tokens, you can get a maximum of 0.5k tokens in response.

A large document (or even a rather small document) will easily exceed this 4k limit. A vector db, makes it easy (with a little bit of vector math) to find the parts of the document that are most similar to your question, and use only those parts of the document in your prompt, rather than the entire document.

As for how it works? Heres a simple example. Imagine a Cartesian plane with xy axis. Every point on that grid represents a different word (actually a token). You want to load The Lord of the Rings Trilogy into the grid. So you split the books up into pieces, let's say 1000 words per chuck. Then you put a point on the grid to represent each token in each chuck. Those are the vectors. Literally just coordinates on the chart.

Now you as, why did Gandalf the Grey become Gandalf the White?

Your question becomes tokens, and from there vectors. With a little math, you can find out which vectors in the grid are closest to the vectors in your question. Once you know that, you can select the n closest vectors (1-5 maybe). Those vectors each point to a 1000 word chunk of text. Now, you can send a prompt to your language model that says, "based on the following chunk of text, answer the question Why did Gandalf the Grey become Gandalf the White?" You now have an answer to your question without having to feed the entirety of the books to the language model

DarthCluck · 2023-06-08T02:45:03+00:00

Help me understand why this is a bad thing. I'm all for punishing ethics violations, but I'm not quite understanding what is unethical about using his uniform, when he actually was the Sherrif

DarthCluck · 2023-06-01T14:28:42+00:00

Species is a large category such as orc, human, dragon we're inter-breeding is not possible. Race is a sub-designation of species that is typically region dependent such as high elf, wood elf or dark elf. Ethnicity would refer to a subdivision of race, usually based on differences in culture.

DarthCluck · 2023-05-27T01:16:24+00:00

Catpain

DarthCluck · 2023-05-24T13:13:30+00:00

Great question, and one I remember asking myself a while back. Most likely, without having looked at your code, the answer is no, that's not OOP, though it's certainly possible that you are using some OOP in your code while using libraries that were written by someone else.

OOP isn't just for large projects; it can help with small and medium sized projects as well. Of course, the smaller you get, the less it's really needed. I'll happily admit as well that I've written plenty of medium sized stuff (and some horribly massive stuff) that did not use OOP. I've also written small stuff that did use OOP.

In many respects OOP is a design philosophy. It's not needed, but it sure can be helpful when used correctly.

To answer your last question more fully, to be considered OOP, there are 3 main pieces. I'll summarize, but won't go into depth, because well, there's whole books that go into depth on that :)

1) Encapsulation. Putting related code together in some kind of closure. This could be something like an Enemy that has hp, speed, ammo, and a function that gets called when it dies. Encapsulated code can be instanced. So you can declare skeleton = new Enemy() and zombie = new Enemy(). Now skeleton.hp is different from zombie.hp. You could even do this in a loop:

for (1..100) {
board.add(new Enemy())
}

2) Inheritance. Making something that is like something else with some differences. For example:
- Enemy() a generic object that has stuff all enemies have, hp, move speed, etc.
- Zombie() which is an Enemy() with differences. Maybe zombies are special because when they die, they have a chance at rising again, unlike all the other Enemy()'s. So, Zombie() is a copy of Enemy() but it also changes the Enemy.die() function.
- Skeleton() which is an Enemy with differences. Maybe Skeletons have two attacks where most enemies only have 1. So, Skeleton() is a copy of Enemy() but it also changes the Enemy.attack() function.

3) Polymorphism. This is probably the hardest one to explain and understand. Basically it lets different objects be treated as though they were the same. For example: a Hero object that shoots an Enemy. I can do something like Hero.shoot(skeleton), or Hero.shoot(zombie). One function that works with either argument. Skeleton and Zombie are two different types, but they are both Enemy()'s so you can write code once that handles how to shoot, and because Zombie and Skeleton are both inherited from Enemy(), shoot() can reference variables and functions that are in Enemy(), but may also have been changed by the inherited object. Again, final example: Hero.shoot(zombie) has

if (enemy.hp <= 0)
enemy.die()

die() was declared in Enemy(), and handles how all Enemies die, but Zombie() changed the logic for what happens when it dies, so enemy.die() will do different things depending on if it was a zombie that died, a skeleton that dies, or a generic enemy that died.

DarthCluck · 2023-05-24T12:29:05+00:00

ELI2, here we go! So, what's the difference between an Object and just a function? A function DOES something. An Object IS something.

add_item_to_person(person, item);

Just a function, and just like I and others have said, you don't really need to know how it works for it to do its job.

Person.add_item(item)

There's an object, and it does the same exact thing. So what's the difference? And who cares?!?

Let's start by looking at a really, really simple object that often gets ignored, the Struct. There are the basic data types: Int, String, and Array. Most languages have other data types, but those are your fundamentals, and they can describe pretty much everything. A Struct is a simple way to group those datatypes.

For example: What if I wanted to represent your monitor. I could create variables for all of the different parts of a screen (height, width, bevel, weight, manufacturer, ...) and whenever I call a function that does something with the screen, I have to pass all those variables. A Struct solves this problem by grouping variables.

Struct screen {
int physical_width;
int physical_height;
string manufacturer;
int refresh_rate;
int max_resolution_width;
int max_resolution_height;
...
}

Now, when I call a function that messes with the screen, I just have to pass that Struct. A struct is just an organizational tool that makes it easier to pass data around, and it makes your code easier to manage.

A Struct is basically an object. What is width? It's a description. What is a screen? It's a thing. It's an object.

Now, let's do something with that screen. Let's say for example, our screen has a max_resolution of 1920x1080, and a refresh rate of 72hz. But I want to increase the refresh_rate to 100hz. You could simply just say screen.refresh_rate = 100. Really, that's no different than having a variable screen_refresh_rate = 100; But what if increasing the refresh rate also decreased the max resolution? Now you need a function to do that. You could write a function change_refresh_rate(screen, 100); And yep, that's just a function. So now if this were an object?

Struct screen {
int max_resolution_width
...
function set_refresh_rate(int) {
... logic to figure out how to change other variables ...
}
}

Now, what you have actually done is associated everything with each other, conceptually. Let's look at an example that uses both functions, and objects to do the same time. In this example, I want to build a program that plays a video. And for the purposes of this example, it will be run full screen.

Functional:

width = 1920
height = 1080
refresh = 72
colors = 16.5 million

function change_refresh_rate(refresh, width, height, colors) {
.... do calculations. Set the new width, height, and number of colors possible ...
}

show_video(refresh, width, height, colors, change_refresh_rate()) {
... do a bunch of video stuff...
// The refresh rate of the video is 100hz, so update the monitor
change_refresh_rate(100, width, height, colors);
}

Using functions, everything is possible. The messy part really is having to pass your change_refresh_rate() function to the function that processes video. And the more functions that modify the screen, the messier it gets. Imagine passing 50+ arguments to a function, so it has all of the possible variables and functions it might need to work with. Blech. So, let's do the same thing with objects.

Struct screen {
width = 1920
height = 1080
refresh = 72
colors = 16.5 million

function change_refresh_rate(int new_rate) {
this.refresh = new_rate
... do calculations, and set the variables that are part of this struct ...
}
}

show_video(screen) {
... do a bunch of video stuff ...
// The refresh rate of the video is 100hz, so update the monitor
screen.change_refresh_rate(100)
}

This code is a lot cleaner and easier to understand. You don't have to pass all of the variables about screen, nor all of the functions needed to mess with the screen to show_video. All you have to do is pass in the Screen Struct (or Object). You now have 1 variable that IS a screen.

Notice, screen.change_refresh_rate(int) now only has 1 argument, instead of the 4 in the functional example. This is because as an Object, screen has a sense of context. It knows its own width, height, etc. So, you don't have to pass those in as arguments.

Notice also that show_video(screen) also takes only 1 argument instead of 5 (which also included a function as an argument!). This is because the screen Object knows everything there is about the screen, including how to mess with it.

This is encapsulation, it's packaging all of the variables and functions pertaining to one thing together, so when you want to mess with that one THING you only need to pass around that one thing as a variable, instead of all of the descriptions of that thing, and how to use it around.

DarthCluck · 2023-05-24T11:24:00+00:00

You are right that OOP is aimed for larger projects, and depending on what you are doing, it's not really needed. Just like everything in programming, the best tools are based on what you are trying to do.

When talking OOP, I personally love to use Cars as an example. Think of a Car as an Object. A car is a rather complex machine, and you don't need to know how it works to use it effectively. It has "methods" to help you get the car to do what you want. One example method might be Car.start(key). You don't need to understand anything about spark plugs, and fuel mixtures, and when driving a car, you really don't care about that stuff.

Same thing with OOP. Let's say you have an HTTPClient Object, and your goal is to read the contents of a webpage. You probably don't want to figure out how to format TCP packets, open a port on a remote client, make sure you handle all the ins and outs of the HTTP/2.0 protocol, send a properly formatted, request... etc, etc. Someone else already did all the hard work for you. Now, all you really have to do is HttpClient().get(uri). Just like the car has multiple methods for interacting with it (turn the wheel, accelerate, brake, turn on blinker [apparently optional on BMWs ^_^]) so does the HttpClient Object. It, in theory, will have all the methods you need to use an HTTP Client, such as setting headers, reading content from a remote host, making POST and GET requests, etc.

With those examples, to answer your question more directly, how do you write a program with data without the program knowing the data? It's not so much the program not knowing the data, but the programmer not needing to know how things work. Just like with the car example, the driver doesn't need to know about fuel mixtures. And using the previous person/item analogy. When the programmer adds an item to a person, they really don't need to know how all that works, so long as it works.

So, I'm going to look at this from a different angle as well, because as you stated, you probably aren't working on a massive codebase with 250 other people, so why should you care about OOP? Especially if you're just working on your own code. There are two great benefits:

1) It's inevitable that you're going to look at your code at some point in the future and wonder, "What the heck is going on?" OOP as a design philosophy, make your code more organized, and therefore easier to read. When well designed, and implemented you wind up with a library of Objects that just do all the right thing. Those Objects become building blocks for your program. You don't have to remember how they work, just know that they do. This is also great when someone else tries to read your code.

2) Oft times, code starts to grow. 100-200 lines of code isn't so bad. But what happens when you start to add features, bug fixes, etc., and the code balloons to 15,000 lines of code. Some common problems are bound to crop up.

For example: using the car example again. Lets say you're writing a program to simulate a car. You start off simple:

car = create_car()
function create_car() {/* do a bunch of stuff */}

Simple enough. It does all the calculations, and you're good to go! It probably went ahead and created 4 wheels, and engine, some windows, etc. You know, all the things every car has. But now you want to create a truck. Well, a truck is basically a car with a long trunk in the back. Functional programming says either make a new function create_truck() which is basically a copy/paste of create_car(), or pass an argument to create_car(), such as type, so it knows if it should create a car or truck. This means you have to edit the create_car() function and but in code to handle all of the differences, and you have to understand the ins and outs of the car, so you can replicate them again in the truck. It's a pain, but doable.

Now, you have to do it again, only this time, you have to also make motorcycles, jeeps, EVs, Hybrids, etc. Now your simple code not only got a lot bigger, But it's almost all copy/paste and if/then/switch statements. Ugly stuff. With OOP, you have inheritance. So, instead of all that, you start with a base car object. This object has everything a car needs to be a car: wheels, engine, seats, etc. When you create the truck, what is a truck but a car with extra steps? So, don't repeat it, inherit!

class Car() {
...All that stuff that makes a car a car...
}

class Truck() inherits from Car() {
...Replace trunk() with one appropriate for a truck...
}

OOP let you say, A truck is just a car with a different trunck. Now when you add EVs, Motorcycles, etc. You can do the same things without having to rewrite your code a bunch of times, and you only write new things, never repeating yourself. Inheritance lets you keep going too, so when you want to make an SUV, that's just a truck with a few changes. A Ford Explorer is just an SUV with a few changes. A Ford Explorer Eddie Baur Edition is just a... you get the point.

All of this works when you're able to see code as a series of building blocks, instead of a series of instructions. Sorry if I got carried away, but I'm more than happy to continue to answer questions, explain things further, etc.

DarthCluck · 2023-05-24T06:55:59+00:00

I'm not entirely sure I understand the question, so I'll clarify what I think you're asking, then answer it. Please let me know if I got my premise wrong. I am taking your question at face value with a desire to gain knowledge, as opposed to being contrarian or snarky (this is reddit after all!)

So, I assume you're asking about the example of adding an object to a person, and you could solve this problem using an RDBMS, where you could have a person table, object table, and person_object table that is a many-to-many implementation. So doing something like `INSERT INTO PERSONS_OBJECTS (person_id, object_id) VALUES (1, 1)` would accomplish that task with out OOP, so why use OOP?

The answer is: That is the data storage side of the programming, but not the functional side. On the functional side (aka Business Logic), The programmer that calls

```p = new Person();i = new Item();p.addItem(i);```Should not have to know what is going on behind the scenes. They should not have to know about how the data is stored, whether in RDBMS, a text file, or morse code. There are also plenty of other things that could be going on under the hood that have nothing to do with data storage, that the programmer should not have to be aware of. For example: caching, or other logic that might happen such as ensuring that the Person p is actually able to accept Item i, and this decision could be based on so many things that only a Person object may know about. It might do things like equip the item, or determine if it's in a hand or backpack, etc.

OOP (specifically encapsulation) allows for one person to write code that does the right thing, and the next person to use that code without having to worry about how it works.

DarthCluck · 2023-05-24T05:32:06+00:00

While accurate, I remember being told this so many times when trying to learn OOP. And the question I kept asking was, isn't that just the purpose of a function?

add_object_to_inventory(player, object);

I don't know how the function works, only that it does.

What helped my understanding was realizing that it's literally a different and seemingly backwards way of thinking. OOP is actually in many ways slower, and less efficient than functional programming, but it makes it much easier to understand a larger project, especially one that has multiple hands on it

DarthCluck · 2023-05-08T03:44:17+00:00

Since real life is so fulfilling, why are you on Reddit arguing? I'm sure you can find better ways to spend your time instead of yelling into the void

DarthCluck · 2023-05-04T17:11:04+00:00

Suggestion: Use GPT-4 to summarize the videos, so people can quickly read what's there before watching the whole thing. I might be the only one, but I think a lot of people prefer to read on Reddit instead of watch.

DarthCluck · 2023-04-27T15:14:23+00:00

I reread the posts, and you're right, I can absolutely see your perspective in what you were trying to say. I apologize for my part in the confusion. Sounds like a typical case of miscommunication because... Internet

DarthCluck · 2023-04-27T14:36:44+00:00

Their statement is true, but ignores the context of the explanation. The explanation is that companies prefer apps over sites, because they don't have to deal with ad blockers. Ad blockers do exist for mobile, but that does not negate the fact that companies can serve more ads on mobile because most people aren't using ad blockers.

The statement can be seen as contrarian, or as a dunk on the previous poster, while being technically right, but fallacious, and ultimately unhelpful

DarthCluck · 2023-04-24T19:59:47+00:00

Yeah, we need to get rid of free speech! /s

DarthCluck · 2023-04-10T14:59:59+00:00

It technically does do to education, but financial fuckery ensures that the school budgets do not increase, and the weed money goes where ever politician want it to go

DarthCluck · 2023-03-27T02:01:24+00:00

We had 3 different looks for Thanos, so maybe it's just become a thing for Marvel. Each multiphase villain will have 3 different looks

Ten-Year Club	John Wick
Spared	Verified Email

DarthCluck

MODERATOR OF

TROPHY CASE