<commit_before>---
layout: page
title: Image Processing
permalink: /image_processing/
---

## Computers of Space Exploration: Why it Matters


For the final project for the class Computer Architecture, our team of four decided to delve into research regarding computers of space exploration. We especially looked into the architecture and the physical properties of computers that were part of famous space missions, such as the Voyager mission, and the Apollo Program. Of the many potential topics that were available in this area, we decided to focus on the effect the harsh environment of space have on computers, and how different space exploration computers of history overcame them.


The culture of Franklin W. Olin College of Engineering tends to structure classes to be highly experienced based, project based, and design based. Naturally, most of the activities in Computer Architecture were based on labs and application of what we learned during class. Our team wanted a change in pace; we wanted to satisfy our curiosity for a topic rather than develop intuition and design sense regarding application. Therefore, we decided to lean towards a more research based project. (We are not saying application based classes are bad at all! We just wanted a little diversity in our experience.)


In addition to expanding our knowledge, this research project offered us the opportunity to push our learning and understanding of Computer Architecture to its limits. When an individual is designing a computer, there are a long list of specs he or she may consider, such as clock speed, instructions per cycle, throughput, and so forth. The previous specs are heavily considered in a standard computer architecture class, but what if the computer were to be sent into space? Computers of space travel have a weight of extra criteria thrown onto them. They must be able to function in dire conditions, even at the cost of efficiency. Our team felt that there would be great merit in understanding a Computer Architecture with different goals from the material we learned in class. This will also allow our fellow peers to think outside the box when we share our discoveries with them.


## Our Project Path and Story

Our team members initially gathered together with a deep curiosity of space exploration that we did not know how to channel. Of the recommended project directions offered from our instructor, we decided to “Teach somebody something cool about Computer Architecture,” by discussing computers of space travel. We immediately hit the school library and online databases to broaden our understanding and to narrow on a topic more specific than “space computers”. We found the Olin Library database to be especially helpful.


Despite our initial engagement with the project, our team struggled greatly in the following few days as members of our team suffered serious burnout and exhaustion. The rigor of classes outside of Computer Architecture contributed greatly to our burnout, but our team also felt very unfocused and unmotivated as we did not have a clear final goal for the project. We knew that we wanted to share with the class about computers that could endure the extreme conditions of space, but we did not know how to carry that out. A lack of communication was clear, as some of us thought we would explicitly study the Apollo Guidance Computer, while others quietly craved an implementation due to their Olin DNA.


The accumulation of our frustration and anxiety almost drove us to a pitfall; we wanted to build the Apollo Guidance Computer in verilog and get the project out of the way. Thankfully, our instructor stopped us from taking such a path, as we would have failed to achieve any of our team goals (listed in the first section!). The AGC as a standalone did not cover the interactions between the environments of space and the architectural decisions of the computer, as there were an abundant amount of understanding the user needed to operate the machine correctly. In other words, the astronauts operating the AGC had to take into consideration the harsh environments of space when inputting instructions, rather than just the computer being fail-proof to the environment.


After avoiding the pitfall, our team gathered to discuss and set a clear end product for the project. We reminded ourselves to stay loyal to our initial goal of teaching our peers to think differently about Computer Architecture. From there, we set our end product for the project to be a presentation to our peers that discussed the harsh conditions of space that would ruin a standard computer, space exploration computers from the past that tackled these issues, and two specific techniques such computers used: radiation hardening and redundancy management. Once we had our outline and key words communicated with one another, we were able to continuously work together as a team to achieve our end product.
<commit_msg>documentation pt 3<commit_after>---
layout: page
title: Documentation
permalink: /documentation/
---

## Computers of Space Exploration: Why it Matters


For the final project for the class Computer Architecture, our team of four decided to delve into research regarding computers of space exploration. We especially looked into the architecture and the physical properties of computers that were part of famous space missions, such as the Voyager mission, and the Apollo Program. Of the many potential topics that were available in this area, we decided to focus on the effect the harsh environment of space have on computers, and how different space exploration computers of history overcame them.


The culture of Franklin W. Olin College of Engineering tends to structure classes to be highly experienced based, project based, and design based. Naturally, most of the activities in Computer Architecture were based on labs and application of what we learned during class. Our team wanted a change in pace; we wanted to satisfy our curiosity for a topic rather than develop intuition and design sense regarding application. Therefore, we decided to lean towards a more research based project. (We are not saying application based classes are bad at all! We just wanted a little diversity in our experience.)


In addition to expanding our knowledge, this research project offered us the opportunity to push our learning and understanding of Computer Architecture to its limits. When an individual is designing a computer, there are a long list of specs he or she may consider, such as clock speed, instructions per cycle, throughput, and so forth. The previous specs are heavily considered in a standard computer architecture class, but what if the computer were to be sent into space? Computers of space travel have a weight of extra criteria thrown onto them. They must be able to function in dire conditions, even at the cost of efficiency. Our team felt that there would be great merit in understanding a Computer Architecture with different goals from the material we learned in class. This will also allow our fellow peers to think outside the box when we share our discoveries with them.


## Our Project Path and Story

Our team members initially gathered together with a deep curiosity of space exploration that we did not know how to channel. Of the recommended project directions offered from our instructor, we decided to “Teach somebody something cool about Computer Architecture,” by discussing computers of space travel. We immediately hit the school library and online databases to broaden our understanding and to narrow on a topic more specific than “space computers”. We found the Olin Library database to be especially helpful.


Despite our initial engagement with the project, our team struggled greatly in the following few days as members of our team suffered serious burnout and exhaustion. The rigor of classes outside of Computer Architecture contributed greatly to our burnout, but our team also felt very unfocused and unmotivated as we did not have a clear final goal for the project. We knew that we wanted to share with the class about computers that could endure the extreme conditions of space, but we did not know how to carry that out. A lack of communication was clear, as some of us thought we would explicitly study the Apollo Guidance Computer, while others quietly craved an implementation due to their Olin DNA.


The accumulation of our frustration and anxiety almost drove us to a pitfall; we wanted to build the Apollo Guidance Computer in verilog and get the project out of the way. Thankfully, our instructor stopped us from taking such a path, as we would have failed to achieve any of our team goals (listed in the first section!). The AGC as a standalone did not cover the interactions between the environments of space and the architectural decisions of the computer, as there were an abundant amount of understanding the user needed to operate the machine correctly. In other words, the astronauts operating the AGC had to take into consideration the harsh environments of space when inputting instructions, rather than just the computer being fail-proof to the environment.


After avoiding the pitfall, our team gathered to discuss and set a clear end product for the project. We reminded ourselves to stay loyal to our initial goal of teaching our peers to think differently about Computer Architecture. From there, we set our end product for the project to be a presentation to our peers that discussed the harsh conditions of space that would ruin a standard computer, space exploration computers from the past that tackled these issues, and two specific techniques such computers used: radiation hardening and redundancy management. Once we had our outline and key words communicated with one another, we were able to continuously work together as a team to achieve our end product.

{'fraction_non_alphanumeric': 0.020022246941045607, 'fraction_numerical': 0.00010112245929821013, 'mean_word_length': 4.756693830034925, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5239004', 'n_tokens_mistral': 2003, 'n_tokens_neox': 1904, 'n_words': 1599}