Objects, Indexes and Artificial Intelligence

Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
Post Reply
User avatar
SpyderTL
Member
Member
Posts: 1074
Joined: Sun Sep 19, 2010 10:05 pm

Objects, Indexes and Artificial Intelligence

Post by SpyderTL »

So, I got into a conversation a few months ago with a former co-worker about some recent developments in AI, and I decided to watch some YouTube videos on the subject.

At the same time, I have been personally working out how to store a large number of objects and be able to find them and organize them quickly at run-time. And I'm starting to see some overlap between the two subjects, and I thought I'd see what you guys thought about the subject.

First, in our conversation, we discussed how modern AI approaches break down the problem into nanoscopic sized components that simply take an input and return an output based on a simple measurement or process. So one component would be responsible for returning how "green" a pixel is, and another would be responsible for returning how "straight" a line is. And these would be combined with tens or hundreds of other components to build complex logic that could tell you how similar a picture is to a car, or a house, or whatever.

In the video I just watched (https://www.youtube.com/watch?v=s716QXfApa0), the presenter talks about how her company has built a system to take images, and break them down into subsets, and apply the same sort of logic units to each zone, and then compile the results.

So, in my case, I was planning on storing objects (which have properties) on a storage device, and then adding additional indexes on things like object name, file type, song title, album title, artist name, etc. But, if you combine the two ideas, and make it generic for any object, you can start to see how it could be incredibly useful for an operating system or an application.

So, what I'm starting to picture is the concept of "internal" vs "external" properties on objects. Internal properties are what we normally think of as object properties, and are stored "inside" the object. (Things like name, age, birth date, color, etc.)

External properties would be generated and stored externally to the object. So things like relative song volume, overall picture color, how often an object is used by a specific user, etc. could be calculated by an external component, and stored in an index, just like you would normally store things like the object name.

And these external property generators could follow any references to other objects and use them as related objects (parent, child, sibling, etc.) for the purposes of finding, say, the green-ness of each pixel in an image, or the objects with the fewest references to it, for purposes of garbage collection.

I think it's pretty interesting, and I'm definitely thinking about adding it to my list of features that I want to implement.
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
embryo2
Member
Member
Posts: 397
Joined: Wed Jun 03, 2015 5:03 am

Re: Objects, Indexes and Artificial Intelligence

Post by embryo2 »

SpyderTL wrote:So, what I'm starting to picture is the concept of "internal" vs "external" properties on objects. Internal properties are what we normally think of as object properties, and are stored "inside" the object. (Things like name, age, birth date, color, etc.)

External properties would be generated and stored externally to the object.
It is about thing called "decomposition". There can be many variants of decomposition of a problem area into some smaller fragments. The "external properties" can be represented as objects just like the "internal properties" or whatever you can think about. Essentially it is about a graph of objects and your ability to work with it. Of course, a large graph is too bad for our brain. But too small graph is too bad for the representation of a problem area. So, the goal of decomposition is to split the area into some manageable graph of entities. If you like the notion of "internal vs external" then it can help your brain a bit when you start working with graphs. But the name is mostly irrelevant because the only result we can get is - we are able (or unable) to work with a proposed graph. So, the goal is to create a graph that is as manageable as possible.
My previous account (embryo) was accidentally deleted, so I have no chance but to use something new. But may be it was a good lesson about software reliability :)
Post Reply