After having spent about 200 workdays of my life getting familiar with the fields of AI/AGI/ML, I think it is a good moment for me to reflect back on my learning experience.
Artificial General Intelligence
#
Of the three domains, AGI is the least well defined. It has to do with general intelligence, but our definition of intelligence is still up for debate. Furthermore, the different known approaches in the field have different opinions regarding what sort of agent an AGI system should be. Should it be a self-contained entity with its own goals and purpose? Or should it be a system that is exhibiting human capabilities while being the servant of a human being or a group of human beings?
Artificial Intelligence
#
Next is AI, which encompasses many different types of approach to try and solve high level goals such as deciding, planning, organizing,, understanding, etc. AI is about the discovery of strategies to solve problems without having to provide the whole solution. I think it is also where goals for the ML field have been defined.
Machine Learning
#
Finally, ML is about using statistical approaches to solve problems. These problems have to be formalized and specify their input/output in the shape of data, may it be as text, audio, video, or simply vectors of numbers. Most of the recent and exciting development that has happened in ML is due to deep learning, which is the ability to develop deep neural networks that can learn to accomplish certain tasks without writing any explicit logic. This logic would be discovered by the network itself, with some help of the developer which would define a composition of modules that would process the data in order to create associations between the input and outputs.
Why AGI?
#
When I initially started my “adventure”, I was interested in AGI. I wanted to know how a machine would be able to exhibit human behavior without having to tell it too much about it. I wanted to learn how you could teach a machine as you would teach a child. The AGI field itself does not currently have any curriculum as to what you should learn about, nor a reference book you can refer yourself or others to (when asked “What should I first read if I want to learn AGI?”). One can be interested in anthropomorphic aspects such as memory, intelligence, perception/senses, processing and so on, while others may be more interested about a computational oriented approach, such as the algorithms, the implementations, the computational complexity of diverse approaches and so on. I think it makes AGI a very interesting topic/field, however it lacks the definiteness of the other fields. One can see this by reading the various iterations of the book “Artificial General Intelligence”, which is a collection of articles by various researchers that is generally published every year in relation to its conference.
When I started learning about AGI, I decided I would explore various venues and determine the approaches that matched the most my own interests and which looked the most promising. I looked at different venues such as cognitive science, set theory, logic, universal artificial intelligence, biology, and philosophy amongst others.
Along the road, AGI research has challenged many of my beliefs as well as how I see life. For those two reasons alone, I’m grateful I have been able to dedicate some of my time on it.
See Also
#
One thing I’ve been wondering about lately is when should one write blog articles (short articles ranging from 250 to 1000 words) or articles (1000+ words) which would be updated (in)frequently but not be as easily consumable.
The main reason I’ve preferred articles over blog articles is that it makes it possible to keep articles “alive”, while once a blog article has been published, it will not evolve over time. By the time it is posted, it is effectively dead and has very little reason to change.
Being a programmer, I’ve always enjoyed seeing software project evolve over the years. They start small and grow big and complex over time. I like the satisfaction of seeing something grow step by step, and because of that, I’ve liked the idea of writing about specific topics and seeing these topics and articles change over time.
The problem with articles however is that it is difficult for visitors to consume. Some articles might grow large and complex. Furthermore, it is difficult for visitors to notice any changes from the last time they’ve come onto the blog.
Another thing is that articles allow the author to “refactor” what he has written, or rewrite/rephrase/reword, such that the article itself improves over time. With a blog article, it is still possible to do so, but the expectation is that a visitor that has already seen the blog article will not re-read it. And here’s the important difference between the two: I expect blog articles to be consumed once, but articles to be consumed multiple times. This expectation is likely wrong. The only person that is likely to consume the same article over and over is its author. Visitors may come to the blog many times, but they are unlikely to expect articles to change over time. An extreme example of this idea would be Wikipedia. People will consult the page of the topic they are interested in, but once they’ve read it, they aren’t likely to come back to it again. The only reason they might do so is if they contribute to it.
What this means is that it is still acceptable to improve both blog articles and articles. The difference lies in how we expect our audience to consume each ones. Articles are likely to be seen as references while blog posts are likely to be perceived as an ephemeral observation. One should expect both to be consumed at best once by a visitor, and that the visitor will not come again to see if it has changed.
Thus, in the end, what matters is what we want to communicate with our audience. Do I want to tell you about a thought (a blog article) or do I want to tell you about some information that is likely to evolve over time (an article).
In the case of my machine learning and artificial general intelligence research, what makes sense is to communicate discoveries or shifts in approaches through blog articles while using articles as a location for thoughts to be worked on.
Context
#
Learned in this study
#
Things to explore
#
Overview
#
AWS
#
AWS has the concept of groups, users, roles and policies.
Groups
#
A group is a list of users to which are assigned policies (permissions).
A useful feature they also provide is the Access Advisor, which allows administrators to observe when certain policies are being used and by which users.
To keep things simple, groups cannot be nested into other groups.
Users
#
Users represent an entity that has access to the AWS platform. They may access AWS either programmatically and/or through the console to administer the account.
During the using creation process, the creator has the ability to assign the user to a group, copy permissions from an existing user or attach policies to the user.
Upon creation of a user with programmatic access, the user is generally given an access key with its corresponding secret.
Roles
#
Roles are very similar to groups conceptually, but instead of being “persistent”, they are temporary. While you will generally assign one or many groups to a user, roles are not assigned to a user (or vice-versa, a user is not assigned one or many roles) but given based on certain criteria. A user takes a given role and only receives this role’s policies/permissions until he returns to his own identity.
Policies
#
A policy is a set of rules that determines the permissions given to a user, group or role. It has a name, description and a policy document, which describes the permissions.
The policy document is a JSON formatted object which contains a version and a list of statements. Each statement has an effect (Allow/Deny), a list of actions and a list of resources to which it applies.
You can learn more about 
AWS policies evaluation logic. Their IAM Policy Reference might also prove useful in understanding the various bits that compose the policy document.
Actions
#
Within AWS, each service has a unique lowercase identifier. Within each of these services, a list of actions exists, which can be granted (or denied) to an identity. Examples of actions are:
*: Allowed to use all actions under all servicess3:*: Allowed to use all actions under the s3 services3:GetObject: Allowed to use the GetObject action under the s3 service
Resources
#
Resources represent entities within their given service. For example, arn:aws:s3:::some-bucket/* represents the content under the some-bucket bucket in the s3 service.
Format : arn:$partition:$service:$region:$account-id:$resource
See also
#
References
#
Steps
#
- Build a list of task/items
List everything that you want to get out of your head. The goal here is to make explicit as much as possible.
- Deconstruct tasks into their pre-requisites and follow-up tasks
There are a couple of important things to consider when one wants to prioritize their task list. One is that even if a task is at the top of the list, it might not be possible to do it until its dependencies are fulfilled. This in turn means that all dependencies will have a superior priority to this task automatically.
However, it frequently happens that what we consider dependencies can in fact be delayed or temporarily replaced by another solution which takes less time to implement or costs less (or for whatever other reason can replace the original dependency).
- Split tasks into 2 groups (and repeat this process)
The idea here is to quickly filter out as many tasks as possible. As you may have noticed, I have not specified the filtering predicate. It is up to you to filter out your tasks such that you will have the least amount to filter at once. Examples of predicates you could use are “will/will not do”, “want/do not want”, “need/do not need”, “like/do not like” and so on.
- Prioritize the tasks that will have to be done
After a certain number of iterations of the previous step, you should arrive at a point where the items you have all need to be done, but you do not know in which order you have to do them (or want to do them).
Methods
#
4 Quadrants Method
#
This method, also known as the Eisenhower Matrix, involves categorizing tasks into four groups: Urgent/Important, Not Urgent/Important, Urgent/Not Important, and Not Urgent/Not Important. By sorting tasks this way, you can focus on what truly matters and avoid spending time on less critical activities.
Analytic Hierarchy Process
#
The Analytic Hierarchy Process (AHP) is a structured technique for organizing and analyzing complex decisions. It involves breaking down a problem into its components, comparing them pairwise, and assigning weights to determine the relative priority of each task.
Binary Search Tree
#
Using a binary search tree for prioritization means inserting tasks based on their priority value, allowing for efficient retrieval and reordering. This approach is useful for dynamically managing and updating a list of tasks as priorities change.
Planning Game
#
The Planning Game is a collaborative method often used in agile development, where stakeholders and team members estimate and prioritize tasks together. It encourages discussion, negotiation, and consensus to determine which tasks should be tackled first.
100-Point Method
#
In the 100-Point Method, each participant is given 100 points to distribute among a list of tasks or requirements according to their perceived importance. The tasks with the highest total points are prioritized, reflecting the collective preferences of the group.
Prioritizing reading
#
- What you feel like reading
- Reading dependencies
- ROI evaluation
References
#
- Karlsson, Joachim, Claes Wohlin, and Björn Regnell. “
An evaluation of methods for prioritizing software requirements.” Information and Software Technology 39.14 (1998): 939-947.
- Karlsson, Joachim, Stefan Olsson, and Kevin Ryan. “Improved practical support for large-scale requirements prioritising.” Requirements Engineering 2.1 (1997): 51-60.
- Ahl, Viggo. “An experimental comparison of five prioritization methods: investigating ease of use, accuracy and scalability.” (2005).
- Gill, Nasib Singh. “A Comparison among Various Techniques to Prioritize the Requirements.” International Journal of Computer Science and Management Studies (IJCSMS) www. ijcsms. com 1.12: 601-607.
http://www.gwern.net/Resorter
https://www.amazon.ca/XCSOURCE-20X-800X-Microscope-Endoscope-Magnifier/dp/B00N4K22OA/