Showing posts with label Technology. Show all posts
Showing posts with label Technology. Show all posts

Tuesday, July 4, 2023

Climate Change

Yesterday I posted to social media (Facebook) the following:

Well, here's one of the dumbest things coming out of the Biden administration that I've heard of in a while - https://www.foxnews.com/.../white-house-report-signals...

Let's spray aerosol into the atmosphere to prevent the sun rays from reaching the earth in order to negate climate change. It's called Solar Radiation Modification (SRM). There's a great quote near the end of the article - "SRM offers the possibility of cooling the planet significantly on a timescale of a few years."

Yes, folks, instead of the impact of "global warming" (and there are those who believe it as well as those who don't), we'll just use SRM and bring on the next ice age. Anyone else see the potential for significant downside to these "experiments"?

 

Several hours later, someone responded to this posting:

You only have half the info as this is a fox report. Go read other sources. There is NO plan to do this. It was a federally mandated base research report.

You are a smart man, so use multiple resources to get your information before making claims.

Here is one example of research but there are others as well: https://www.cnbc.com/.../white-house-releases-report-on...

 

I have both friends and relatives who disagree with me, and I have no problem with that. We (myself included) can all learn from each other as long as we agree to be civil about our interactions. So, let me look at some of the aspects of this response. This is too long for a social media posting, so I’m choosing to turn this into a blog entry that I can then refer to.

 

Go read other sources

This is good advice and is something that I regularly do. Beside our local paper, I have three news sources pinned that I read regularly – Fox, CNN, and BBC. I have each of these three for a reason.

Fox – I generally agree with the conservative viewpoints reflected here. However, I avoid reading the opinion articles of Hannity and others as they are designed to inflame rather than to inform.

CNN – In order to balance the definite “right wing” Fox views, I have chosen CNN as a representative of the more “left wing” viewpoints. I could have chosen CNBC (as referenced above), or MSNBC, or something else, but I wanted to have one representative of the MSM (mainstream media) so I can see both sides of any current issues.

BBC – I’ve done enough international traveling that I recognize that both of the above sources are heavily weighted to US news and as a result important things taking place outside of the US are often not covered well. When I got stranded in Europe following 9/11, I greatly appreciated being able to watch the news from the non-US perspective. Again, I could have chosen others, but I regularly check the headlines on BBC to ensure that I don’t get bogged down in the US-centric views of news importance.

When there are important news stories that I really want to get involved in and understand, I will also do further research (thanks Google). So I’m primarily relying on the above three sources to keep me informed about what’s going on and to spur that further research.

As I mentioned, I also read our local newspaper. But I do not rely on it to trigger any further research into non-local issues as it tends to be repeats of what was reported elsewhere the day before.

 

You only have half the info

I disagree. While the article title on Fox is (as is often typical of them) designed to inflame the reader (“White House report signals openness to manipulating sunlight to prevent climate change”), the closing sentence in the article reads:

“In a separate statement, the White House assured readers that ‘there are no plans underway to establish a comprehensive research program focused on solar radiation modification.’”

This parallels a line in the CNBC article which reads:

“The Biden-Harris administration has no plans underway to launch a comprehensive research program into solar radiation modification, according to a senior administration official.”

As a reflection of the way that news articles can be biased, I should note that the above line in the Fox article was at the very end of the article, where the parallel statement in the CNBC article was at the beginning of the article. So the same info was in both but with this perhaps unnoticeable (to most) tweaking of the order that reflects the two organizations support or non-support of the current administration.

 

Climate Change

I have both a science-engineering background as well as a minor in mathematics in my college career. I tend to look at things from those perspectives. There are a few aspects I’d like to mention here that bother me when encountering “scientific” topics like climate change. One is giving too much credit to short-term trends and ignoring the longer-term data. Another is choosing data to fit a pre-determined narrative and ignoring data which does not fit that narrative. And finally is the use of alarmist scenarios. Let’s look at some examples of each in the climate change “debate”.

 

Short-term v. Long-term

Here is a chart from temperaturerecord.org showing temperature variations for the last 1000 years.

[Temp chart]

 


Looking at this chart can cause one to be concerned. The temperature rise in the last 100 years certainly looks dramatic. One could conclude that this is all since the industrial revolution with the burning of fossil fuels, and the result of human activity. And 1000 years seems like a long period of time. But now let’s look at a chart prepared by NOAA (climate.gov) that shows the estimated temperature over the last 500 million years.

[Temp chart]

 


Gives a very different perspective, doesn’t it? Even with the blip in the very end of the data, we are still in a relatively cool period in Earth’s history. And those red areas in our past are definitely not manmade. Let me give an illustration with just four data points.

Consider the data series 4, 3, 1, 2. If I look at the last two points (1, 2), I can exclaim, “the numbers are up by a factor of two!” But if I plot a trendline using all four points I get just the opposite result, “the trend is downward by a factor of two!” There is a saying, “figures don’t lie, but liars figure.” While I don’t mean to imply that the climate alarmists are deliberately lying, one needs to ask what is the basis of their conclusion.

 

Predetermined Narrative

I recently read an article by the president of the Copenhagen Consensus Center, Bjorn Lomborg. He stated the following (see https://imprimis.hillsdale.edu/thinking-smartly-about-climate-change/):

U.N. Secretary General António Guterres and many Western leaders, including the current administration in the U.S., tend toward the end-of-the-world point of view: “The world is facing a grave climate emergency. . . . Every week brings new climate-related devastation. Floods. Drought. Heatwaves. Wildfires. Superstorms. . . . We are in a battle for our lives. . . . Climate change is the biggest threat to the global economy.” These claims are echoed endlessly in the media. But are they true?

Consider the supposed rise in “superstorms” such as stronger hurricanes. What do we actually know? The annual number of hurricanes that make landfall in the U.S. since 1900 is slightly declining, not increasing. The same is true for major hurricanes (category three and above) hitting the U.S. We see the same thing if we look at world data for total hurricane energy in the satellite era, 1980-2022. In fact, 2022 was the second lowest recorded year. Did you hear that reported anywhere? No, because it doesn’t fit the dominant narrative.

What about the supposed increase in wildfires due to climate change? A typical example was the media coverage of the forest fires in Australia in 2019 and 2020, which left readers and viewers with the impression that almost all of Australia was burning. Looking at the satellite imagery, however, it was clear that although there were a lot of fires close to where the news crews lived in Sydney and Melbourne, it was one of the lowest levels of burning due to fire on record for Australia as a whole.

As for the amount of burned area due to fire on a global level, satellite data shows a dramatic decline over the past 25 years. Journals like Science and Nature have covered this story, but it’s not what you see on television or read in newspapers. Perhaps the implementation of a strong climate policy might reduce instances of fire, but even if we do nothing, the number of fires will almost certainly continue to decline. In other words, the world is not going to go up in flames, contrary to what you hear from politicians or read in The New York Times.

 

In both the case of superstorms and fires, the news reports are alarmist and we don’t get the figures that don’t support that narrative. These are just two examples – there are many others.

 

Alarmist Attitudes

In 2007, Al Gore made the following statement.

“Last September 21, as the Northern Hemisphere tilted away from the sun, scientists reported with unprecedented distress that the North Polar ice cap is ‘falling off a cliff.’ One study estimated that it could be completely gone during summer in less than 22 years. Another new study, to be presented by U.S. Navy researchers later this week, warns it could happen in as little as 7 years.”

This was accompanied in the news by pictures of polar bears floating on very small ice floes, getting thinner as they could not move around as before. However, fast forwarding to 7 years later, an article in Commentary magazine was entitled, “Good News for Polar Bears. Bad News for Al Gore.” This article noted:

“…satellite photographs confirm that not only has the ice not vanished, in the last two years it has increased somewhere between 43 and 62 percent since 2012. … since the evidence shows that the ice cap is larger than at any point since 2007, it’s certainly worth noting.”

The article also talks about the “global cooling” that has been going on since 1997. Wait a minute! Global COOLING? Which is it, global cooling or global warming? Since both of these terms keep getting it wrong, why do you think the current term of “climate change” is being used? It’s because no matter whether temps are going up or down it’s still “changing” and so this new terminology is never wrong.

US Representative Alexandria Ocasio-Cortez claimed in 2019 that the world will end in twelve years if we don’t address climate change! We’re now four years into that twelve year period – and it doesn’t look like the world is ending, Miami FL is not yet under water, the polar ice caps are doing just fine, etc.

But we will continue to get bombarded by alarmist statements. It reminds me quite a bit of the story of the boy who called “wolf”. After a while, no one believed him anymore.

 

Conclusion

I hope that we are not at the point like the boy who called wolf. There are things that we ought to do. History has shown again and again that human ingenuity is good at solving problems. But we need to really think through things and not mandate solutions by government fiat.

The town of Scottsbluff NE had converted to solar power – but they found out last week that one hail storm could wipe out their entire farm of solar panels. Electric cars have their place – but currently they require mining of cobalt by children in Africa and we’re not yet sure how to deal with the problem of old batteries. The power lines on the street where I live do not have sufficient capacity to even support half of the homes putting in fast chargers if we went to electric cars in our neighborhood.

We also need to be careful in thinking that we can “play God”. Humans make mistakes. A slight miscalculation in implementing any solution such as those being researched in the Solar Radiation Modification that I referenced at the beginning of this blog could wipe out mankind instead of being a solution.

In the words of Yogi Berra, “You’ve got to be very careful if you don’t know where you are going, because you might not get there.” Or to quote Elmer Fudd, “Be vewy vewy careful!”

Saturday, October 22, 2022

VW Engine

As I recall, it was the fall of 1960. In those days all the auto manufacturers released their new models at the same time. Although I was only 12, I was really into cars and could tell you the make, model, and year of every car we passed on the road. (FYI – my grandson Isaiah can do the same thing now.) On that weekend each year my father and I would travel around to many of the dealers in the area so see all the new cars coming out.

This particular year the local VW dealership decided to do something special in order to get people like my father to stay longer – and thus increase the chances of people buying a VW instead of something else. So, they arranged for a demonstration. They not only advertised it in the paper but mailed invitations to the VW owners in the region – of which we were one as my father had bought his first VW the previous year.

My father and I thus were at the VW dealer – first just looking at the new cars in the showroom, then, when the sales manager announced that the demo was going to start, going out into the shop area of the building. They had totally cleaned the shop, so there were no vehicles there and the floors had been newly painted. At the appointed time, one of the garage doors was opened and a new VW Beetle driven in – the purpose being that we could see that this was a running vehicle. Parking it in the middle of the small crowd who had gathered, the shop manager announced what would be happening. Two of their lead mechanics moved to the back of the car and opened the door of the engine compartment. They also brought over a tool box – in which they naturally had all the tools they needed and all organized appropriately.



Upon a signal, they began quickly moving to disassemble the engine. First, they removed all the electrical components (spark plug wires, distributor, battery, etc.), then took off all the other easily reached items (v-belt, pulleys, carburetor, etc.) While doing this, one of them put some pans underneath and drained the fluids from the transmission and engine. One got underneath and removed the muffler. Then the two of them disconnected the engine from the transmission and lifted the flat-4 engine out of the compartment.

Setting the engine on a drop cloth, they then proceeded to disassemble it – taking off the heads, removing the cover over the crank shaft, disconnecting all the pistons, removing the valves, etc. Meanwhile the shop manager was keeping up a running commentary about what they were doing so that those of us standing around the car in a large circle understood the various steps. They only thing they did not disassemble was taking the rings off the pistons.

I should also note that since the flat-4 VW engine is air cooled, there is no radiator and no coolant to drain. This eliminates several components that you find on other engines.

Now we had spread out in front of us, and neatly arranged, a disassembled engine and the Beetle sitting there without an engine in it. They gave us a few minutes to walk around and see all the components. Then, working just as quickly, the two mechanics began to put the engine back together – following all the steps they had just completed in reverse.

Adding back the fluids that they had drained – or more accurately, adding new fluids to replace the ones they had drained, they then put a small amount of gasoline in the carburetor, one of them got in the driver’s seat, and they started up the engine, opened the garage door and drove back outside.

Total time for the complete disassembly and reassembly – less than one hour! It was quite an impressive demo. Of course, the purpose of doing this was to not only show potential VW buyers not only how easy it was to work on these cars, but to showcase the skills of their mechanics and thus make everyone want to use the dealer’s services in the future.

As a 12-year-old, and the youngest member of the audience, I know that I was impressed. My father had just bought his first VW the year before and it was the first of a few that he bought there. And in 1973, after I had married and while I was living in CT for a few years before my wife and I moved to PA, I also bought a vehicle from that same dealership – in my case a VW Dasher station wagon, which I bought sight unseen as the Dasher was a brand-new line and they didn’t even have any in stock yet. So, I guess their “demonstration”, at least in my case, paid off.

These days, with all the computer-controlled parts of the engine and all the emissions components, it is far more complicated to work on vehicle engines. Doing the work yourself is all but impossible and they even color-code those things that the vehicle owner is allowed to touch (adding oil, adding coolant, changing/charging a battery) and everything else is off-limits. But in 1960, the air-cooled VW engine was a thing of great simplicity and enabled the demo that I had the pleasure of witnessing.


Thursday, January 30, 2020

Y2K Bites Again


My son recently sent me a link to an article (http://catless.ncl.ac.uk/Risks/31/54/#subj31.1) titled, “A lazy fix 20 years ago means the Y2K bug is taking down computers now”. The first paragraph in this article read:

“Programmers wanting to avoid the Y2K bug had two broad option: entirely rewrite their code, or adopt a quick fix called ‘windowing’, which would treat all dates from 00 to 20, as from the 2000s, rather than the 1900s. An estimated 80 per cent of computers fixed in 1999 used the quicker, cheaper option.”

The article gave several examples of systems which failed during the transition from 2019 to 2020 because of the windowing code. I’d like to recount my own experience of dealing with the Y2K problem over 20 years ago, why our company had very few Y2K problems, and the various problems that we did experience.


Because of my membership in two professional societies (ACM and IEEE-CS), I had read articles about Y2K earlier than most people. In 1980, I designed and oversaw the creation of a standardized date subroutine that handled every type of date manipulation we could think of – date comparison, number of days between dates, date conversion from one format to another, etc. Since we had to be able to deal with dates with two-digit years, we did have to make assumptions about what century digits to assume and we chose 1940-2039 as our “window”. We chose 1940 since that was the year of the company’s founding and it would be unlikely that we would encounter any dates prior to that in most situations (the only exception was personnel because people had birth years prior to 1940, but those were stored as four-digit years).

We knew that by doing so we would have 60 years before our window would cause issues. But we took additional precautions, one being that we ensured that our object code could NOT be combined into any other program. This way, if we ever needed to update the subroutines, we could do so and ensure that no one was using an “old” version of the code.

We mandated that any program needing date manipulation use this subroutine. Thus, our main concerns were (1) programs which had been written before 1980 which would still be used after 2000, (2) purchased software, and (3) programs which did no date manipulation but still had dates in them.

About 10 years later, in 1990, with an increasing number of articles being written about the upcoming date rollover, I started asking that management address the problem. It took a few years, but eventually around 1996-1997 I received permission to investigate one system, make any necessary changes, and document what would have happened if the changes had not been made.

I chose our corporate accounts receivable system because is was in category (2), i.e. the original source code was a purchased package. After doing a thorough investigation and fixing any problems related to the year rollover, I presented my report to management. They were shocked!

Among the problems were (1) the balance on all accounts would be flagged as past due, interest charged, and past due notices mailed to every customer, and (2) any payments made would be rejected as having invalid dates. That got management’s attention!

In fairly short order we created a project team to address the issue. We purchased some software that could examine COBOL programs for any date usage and flag any potential issues. Then we fixed and tested everything that we needed to change. Programs written in other languages were scanned by hand. In the process we found that there were a couple of old programs where we no longer had the source code, so we tested the function of the program. I was responsible for checking all programs in our Gases Group as well as coordinating all the checking in our joint ventures and subsidiaries around the world.

On the night of the date rollover, I was on duty as the date change worked its way around the world. In every time zone we shut down our operating plants before midnight as a precaution, then restarted them after midnight and local operators called back to our headquarters to report any problems. I was also in charge of logging any errors both during the run-up to the date rollover (some programs do date lookahead), and in the weeks that followed (as some programs only ran monthly).

I logged over 60 errors during this period. All but two were fairly simple ones of just a few types. One type was where the output field for a date had a format code of “ZZ” or “Z9” so the leading zero was suppressed the date was printed as “_0” instead of “00”. Another type was where a “19” was hardcoded to print on a report so it printed “1900” instead of “2000”. There just a few where both types coincided and the report read “19_0”. These did not cause major issues and were easily fixed later.

There were only two errors where there was any significance consequence:

One of these was in our executive payroll system (yes, senior executives get special treatment). We had not been allowed to examine the source code in this system because it was labeled as company confidential. The person in charge of that system told us that he had tested it, but not being a part of the team working on the project he was not as thorough. As a result, during the date rollover the system took several payroll deductions twice and short paid all our executives. This was embarrassing as we had to credit the executives for the double deduction, but it only affected a few individuals and the credit was done before they received their checks for the pay period.

The other problem happened at one our locations in Liberal, Kansas. The US Government runs a helium extraction plant in the panhandle of Texas and runs a helium pipeline across the Oklahoma panhandle into Kansas. Our company took helium out of the pipeline and there was an IBM PC which monitored the flow and periodically calculated the amount of product taken over an elapsed period and billed the company for the helium. Because that PC was owned by the US Government, we not allowed to examine or test it for any Y2K issues. During the rollover period the difference between the date/time at the beginning of the period and the date/time at the end of the period was negative instead of positive. Thus, instead of billing the company for the helium taken, we were given a credit. The amount was relatively small, so the credit was processed as normal and no effort was made to correct the mistake.

Not too many years later the company moved to using SAP and all the old programs on our mainframe were eliminated, so there would not be any additional Y2K issues in code under our control. Thus, we did in fact eliminate all those old programs before the expiration of the 1940-2039 window. But there are still many companies running some old programs and their 1920-2019 windows are now giving them problems.

I know that the programmers working on these old systems that are now failing are not enjoying the problems that they have to fix. If they’d taken the time, as our company did, to fix them right the first time then they could have avoided these problems.


Sunday, November 10, 2019

Making Shoes


Knowing a bit of math has always given me a leg up in my career. In the summer of 1968 I had just finished my second undergraduate year (I don't say sophomore, because I graduated in three years). I was able to get an internship in the MIS department of Uniroyal through a friend of my parents. The first day they gave me the IBM Programming Aptitude Test (the standard of the time) that was kind of like the math part of an SAT. I blew them away with the speed and accuracy with which I completed it. Then I had an interview with the department manager. He had originally hired me to help convert a bunch of old Autocoder programs to RPG, but realized that my skills were way beyond that. He had a problem to solve that he felt that he would have to do himself because he didn't have anyone on his staff who could handle it (he had a master's degree in math). So, he outlined it for me and that became my project for the next several weeks (*2).

Project Background

This was for the footwear division of Uniroyal - the former US Rubber - and they made US Keds and Redball Jets among a lot of other footwear. Footwear is constructed by starting with what's known as a "last" - a foot-shaped piece of material that the shoe is constructed around (see *1 for more details). Because these were sports shoes, the lasts were primarily aluminum. There are different types of lasts for different types of shoes.

Lasts also come in different sizes. But these sizes don’t match the shoe size. In the US there are ranges of sizes for men, for women, and for children. But a men’s size 6 is made on the same last as a woman’s size 8, etc. So, these different ranges must be converted to a common “last size”.

Finally, shoe production must be scheduled in full cases, not in pairs. For smaller shoes, there are generally twelve pairs to a case, but for larger shoes, there are only six pairs in a case.

The Production Problem

For each week in the shoe factory, we start with the “wish list” of the sales department, i.e. how many pairs of shoes in each style and size they believe they can sell for the coming week, e.g. 30 pair of style 123, women’s size 9. We also know that we have so many pair of lasts of type AB in each size. (Oh, and we have to take account of the fact that some shoes can be made fairly quickly so we would be able to use the same last more than once in that week.) The question then become, do we have enough of that type of last to make all the shoes that the sales department would like?

The “Shape” of the Program

To solve this problem, we need a couple of matrices. Envision the primary one as a large square matrix (N by M) where the rows are the different styles and the columns are the different sizes (of the lasts). Then there is a smaller (N by 1) matrix containing the various styles and another smaller (1 by M) matrix containing the available last inventory.

We are going to process one type of last at a time. We first load in (from mag tape at the time), the last inventory and populate the 1xM matrix. Then we read (from a second tape), all the sales department desires, put the particular style and attributes (Men/Woman/Child) in the Nx1 matrix and the desired production in the NxM matrix (after doing all the conversion from shoe size to last size).

Now for the hard part. Going one column at a time, we add up the sales desired for the column and compare it to the available last inventory for the column. If we have enough, then great, we’re done for that column. But let’s say that we only have enough lasts to cover X% of the sales desires. We spread the last inventory over the desires, giving X% to each desire. Then we take each result and “round down” to case amounts, so if the desire for a particular style/size was 180 (of a size that we can get 12 pairs in a case) and we only have allocated enough lasts to make 153, then we round down the 153 to 144 (a multiple of 12). After going through all the desires in a column, then the residual (9 in our example cell) from all the rows is unused lasts. We take all the unused lasts, and go through the process again, seeing if we can, in the fairest way possible, manage to make any of the cells up to the next case-lot. After possible multiple passes of spreading and rounding down to case lots, if we cannot fill any more cases, then we advance to the next last size and repeat for each column. (Don’t worry if you don’t understand all the nuances of the above, that’s why it took someone with an understanding of math to write this program).

Once we’re done with all the iterations of the above, we spit out the answers in the form of revised production for each style/size.

Consequences of 1960’s Technology

This program ran on an IBM360 model 40 with 128K of memory. There were limitations on input, memory, and CPU speed. While we had disk drives, they were only available for things like the customer master (in indexed file) and not for other uses. The memory partitions were limited to 82K for the main partition plus a couple of small foreground partitions as well as space for the operating system. We were only allowed 4 tapes drives per partition.

Thus, the coding had to be as concise as possible and there were limits on the size of the matrices as well. We also used 3 tape drives – one for last inventory, one for sales desires, and one for the production results. The latter would be printed in the form of production schedules by a later program.

But because there were so many calculations take place as the program worked through each column of the matrix in order, spreading inventory, rounding down to case lots, re-spreading leftover inventory, etc. the program would use a lot of CPU time and put out the “wait light” on the CPU. Most programs of the time were I/O bound as they were usually waiting for the tape drives. But this one would read a bunch of stuff from the two input tapes, by compute-bound while it did all the calculations, then would write a bunch of stuff on the one output tape. The operator instructions were generally, if the wait light on the CPU goes out that means that the program has gone into a loop and is not working, so they needed to cancel it. This was the only program in the entire installation of its kind and I had to write instruction on it, “this program puts out the wait light, do NOT cancel it!”

The Results

As these were the days of punched cards for programming, everything had to be written on coding sheets and submitted to the keypunch department – with a wait time depending on how big your program was. Getting changes made required the same process, so one was constantly waiting on others. Program compiles and tests were overnight submissions since daytime was reserved for production runs. So, things took a lot longer than they do now.

As a result, it took several weeks to write and test the above program. In between I did things like write the print routine for the production schedule, made some other minor changes to other programs, and even debugged a few of those pesky Autocoder programs that I had been hired for in the first place. My boss was happy with my work.

I was hired for a second summer the following year – writing a funding model for the corporation’s international division. And when I finished grad school, even though it was the middle of a recession in 1971, I was hired full-time. After a little over a year, the MIS director took early retirement and went to work as VP of Finance for Olin-Winchester. He then called me and asked me to join him there. But that’s another story (*3).

Notes:


Thursday, April 25, 2019

Humble Pi


Recently I happened upon a YouTube video by Matt Parker called What Happens When Maths Goes Wrong? (https://www.youtube.com/watch?v=6JwEYamjXpA). I’ve listened to a number of his videos over the years on channels like standupmaths and Numberphile, so I knew I was in for an entertaining hour. Matt is a mathematician from the UK. This particular video was based on a book he recently wrote called Humble Pi (available on amazon.com), and is subtitled A Comedy of Maths Errors. (Note that “Maths” is the appropriate word in British English for what we would call “Math” here in the US.)

I knew even before finishing watching the video that I needed to buy the book. It came this week and I’ve absolutely enjoyed reading it. Since I have a degree in computer science from the college of engineering and I also have a minor in math, I have all the background necessary to understand many of the nuances in his entertaining examples, but even if you do not, you would still enjoy it.

I’m not going to be a spoiler, but I’d like to give a few examples from my own experience that illustrate some of the points in the book. So, without delay, here goes.


Y2K

When describing the coming problems with Y2K38, Matt makes a passing reference to the Y2K problem when he says, “Through a massive effort almost everything was updated… It’s risky to be complacent because Y2K was handled so well.” But as one of those who spent a couple of years of my professional life being part of that “massive effort”. I’d like to recount a few real examples of the kinds of math errors that we had to correct.

Error Checking – In an effort to try and detect errors in incoming data, one program I encountered checked to see if any dates were for years before 1940 as that was the year the company started business. But with only 2-digit years that was coded IF YEAR < 40. When the year rolled over from 99 to 00 that would have rejected all the good data as well. It was a well-intended reasonability check, but with unintended consequences after Y2K.

Negative Charges – One system measured flow rate between two times and used the product of the two to calculate how much product to be charged for. But that presumed that the difference between the starting time and ending time would be a positive number. When the clocks we “backward” from year 99 to year 00 the time difference was negative and thus the system calculated a negative amount in the multiplication and gave a product credit instead of a charge.

Early/Late Errors – It’s easy to assume that all the Y2K errors happened during the actual rollover of the year at midnight on 31 December 1999. But sometime we actually perform mathematical calculations on dates make it happen earlier or later. One such example is that invoices from many companies give a discount for quick payment or a late charge for late payments. Such a system might give a 2% surcharge for any payments after 30 days. So if an invoice was dated on say 15 December [19]99, they would add 30 days to get the late payment date, coming up with 14 January [20]00. But with a 2-digit year, the result would be that a payment on say, 25 December, would look like it was 99 years too late. There are similar errors in any look-back calculations.


Pre-test v. Post-test

Higher-level computer languages have one or more constructs that enable the repetitive execution of a block of code. This block of code is repeated until some condition is met. There are two ways of checking this condition – before the block is executed the first time (called a pre-test) of after the block has been executed at least once (called a post-test). For a good explanation see the “While loop” in Wikipedia (*1) and the “Do while loop” (*2). Each of these constructs is valuable, however, some computer languages only have one of them, or if they have both the syntax may be so similar as to be confusing. Consider the examples in Wikipedia:

            While (A = TRUE) Do B End While
                                    v.
            Do B While (A) End While

Errors can be introduced into a program in at least a couple of ways. First, if a programmer is used to one language and its syntax, he/she may inadvertently choose the wrong type of pre/post-test if moving to another language. Secondly, the test may be coded in a way that an Off-By-One-Error (an OBOE as Matt calls it) may occur. As an example, consider the following:

            I=1; While (I < 5) Do B; End While;
                                    v.
            I=1; Do B While (I < 5); End While;

            B: Print “Hello World”; I=I+1;

The first construct prints “Hello World” 4 times, while the second construct prints it 5 times.


Conclusion

The above few examples are just a few from the world of programming, but the book contains many, many examples from architecture, engineering, finance, and other fields. All the examples have a common thread in that the introduction of a “maths error” caused either abject failure or at least an unintended consequence. Some of these failures resulted in death, so they are not just abstract textbook examples. I heartily recommend this book.


Notes:



Wednesday, April 10, 2019

Engineering Problems


There have been several news articles recently about the problems with the Boeing 737 MAX, including two planes that crashed – one in Indonesia, one in Ethiopia. It appears that the root cause of the problem is the fact that because the plane has been stretched (the reason for the MAX part of the plane’s name) the nose of the plane has a tendency to tip down and it requires sophisticated software to keep the plane’s attitude nose up. When one of the external sensors is not working properly, the software is not handling the situation properly and the plane keeps going nose down until it is unrecoverable and the plane crashes.

I have a background in engineering and many years of experience in writing computer software, but the intricacies of this are difficult for even me to totally understand. So, I thought I’d write about some less complicated transportation problems that might illustrate the kinds of issues that engineers deal with and how simple things can lead to complicated problems. These two examples are real ones that people I knew had to deal with about 40-50 years ago.


The Oil Filter

A car manufacturer (I seem to recall it was Ford, but that’s not important to the story) came out with a new model of a popular car that had a more powerful engine than the prior year. A friend of mine bought one of these new cars and loved it. After a month or so it was time for the first oil change. The dealer he bought it from included with the car a free first oil change (this is a good marketing strategy as if you can get in the habit of going to them for this kind of service you are more likely to keep coming back – and making money for the dealership). So, he scheduled his new car for an oil change. Figuring that it would not take too long, he stayed in the waiting room where he had a view of the service bays.

He could see his car on the lift and watched the mechanic unscrew the oil drain plug in the bottom of the engine and drain out the used oil. But then the mechanic seemed to be under the car for an extended period of time and he began calling others over until nearly everyone in the garage was gathered underneath his car. Wondering what was going on, my friend went to the service desk and inquired if there was a problem with his new car. The response that he got was that they were unable to remove the oil filter!

Because this was a new model with a newer engine, the engineers who design it have to take into account all the various parts of the engine and its attachments to ensure that everything will both fit properly in the engine compartment and also be able to be taken out. They had done so properly. But the space in the engine compartment is pretty tight (as anyone who has looked under the hood of most modern cars can see). Thus, the amount of space between some components is quite small. The oil filter is generally near the bottom of the engine and in this case was right up against the engine frame with a fraction of an inch clearance.

But the engineers had forgotten a small point – that when you need to change the oil filter it must be unscrewed and that means that there must be enough clearance between the filter and whatever it is next to (the frame in this case) to allow that extra fraction of an inch for an unscrewed filter. But they had not done so, so there was not enough room to remove the filter.

If the item that interfered had been some other component, they could have loosened the other component – that would have been bad enough. But in this case the other component was the car’s frame. Thus, the only way to change the oil filter was to loosen the motor mounts, use a jack to push up the entire engine that fraction of an inch, unscrew and change the filter, then lower the engine and retighten the motor mounts.

The consequence of that minor mis-calculation meant that most people would not be able to do their own oil change, that they could not take it to a Jiffylube or some other such establishment, and that the labor and time involved were not just a simple 15 minutes, but a couple of hours of work! Fortunately for my friend, the first oil change was free, but the long-term prospects were not great.

The dealer notified the manufacturer who very quickly got their engineers involved. The solution – make a new oil filter that was a fraction of an inch shorter so it could be unscrewed in that tight space. They also had to change the specifications in the owner’s manual, get a large quantity of the filters manufactured so they could be available on the assembly line for all cars not yet built, then contact all the car owners to schedule a recall – each of these cars needing to be put on a lift, the motor mounts loosened so the filter could be replaced, etc. It was a massive effort for the next several months – and all because the engineers forgot that unscrewing a $4 oil filter means you need a little bit of clearance!


The Computer Reset

I began teaching computer courses to adults in an evening program in 1980. My students were working adults who took classes three nights a week for ten weeks. In the first week of one of these classes a few of the students were talking together before class started and one of them shared that he had had a car problem on the way to class that night.

His route to school meant that he had to take one of the limited access roads in the Lehigh Valley (22, 309, or I-78). Some of the access ramps on the former two are quite short, in fact a few of them have stop signs at the end of the ramp so you have to stop, wait for a clear spot in the traffic, then accelerate rapidly to match the flow of traffic as there are no merge lanes. Also, these roads are all concrete and not always in the best shape (PA roads are notorious for potholes). It was at one of these short ramps that he had the problem.

As he was accelerating rapidly so that the traffic behind him did not run him over, his engine suddenly slowed to an idle speed and the RPMs dropped. He initially thought that the engine had died and began quickly looking for a place to pull over – but there are usually no spots for doing this either, so he was beginning to panic. Then, just as quickly as it began, the crisis ended and the engine once again began working properly and he was able to get back to the required speed. It was this moment of panic that he was relating to the others in the room.

Things went well for several classes, then one night it happened again – the engine RPMs quickly dropped and the car’s speed decreased accordingly, then after a few seconds everything began working again. Now he knew it was not a fluke and that there was a real problem. He took it to a car dealer but their tests showed nothing wrong. He took it to a local mechanic who could also find nothing wrong. The car was working properly all the rest of the time except under these times of acceleration on the short ramps – when the problem reoccurred a few more times over the coming weeks. What was going on?

Finally, he had another mechanic look at it – and this new mechanic found the problem. As on most cars, there are a number of wires in the engine compartment that are connected a number of “computers” that govern the operation of the engine. One of these sensor wires had come loose from the bundle that it was part of and was somewhat floppy. It would bounce around a little – especially on the bumpy sections of the PA roads when the car was at higher speeds and it had developed a small section where the insulation around the wire had worn through. Now when it made contact during one of those bounces it was shorting out. This was giving a phony signal to the computer to which it was connected.

At high RPMs, the phony signal generated from the bouncing on the roads gave conflicting information to the computer and the computer didn’t know how to handle the conflict. So, the solution, programmed by the engineers, was to “reset” the computer, then process the various sensor signals one at a time until it took the appropriate course of action. But this reset meant that the engine speed was also reset (to idle) until the computer could process the conflicting signals. And of course, by then, the loose wire was no longer in contact and shorting out, so the computer properly interpreted everything, including the fact that the driver was pushing on the accelerator pedal, and the car began working properly.

While the best solution would be for the engineers to do something other than a reset and drop the vehicle speed instead of just maintaining the current speed. But in this case, the mechanic just did the next best thing – wrapping some electrical tape around the bare spot in the wire and securing it so that it wouldn’t flop around anymore.

Tuesday, February 26, 2019

Ten seconds!

Just got to witness one of the marvels of technology. I was sitting upstairs in our living room and out of the corner of my eye noticed a truck coming down our lane and seeming to slow down as he approached our house. I got up from the sofa and moved to the window where I could see the section of the lane in front of our house as well as the driveway below me. By the time I got there, I could see the truck driver at the rear of the truck getting a box out of the back. I could tell from the markings on the box that it was an order we had placed at the end of last week for several books from Christian Book Distributors (christianbook.com) (CBD).

I knew from an email received on Saturday that this was being delivered by FedEx, although from my vantage point I could not see the front part of the truck where it was marked. As the driver walked from the lane to our front door (about 50 feet), he was using a portable device to scan the label on the box. He set the box down on the front door right below me and walked back toward the truck. As he disappeared from my view and walked around the front of the truck, I heard a ding on the smartphone in my pocket indicating a new email. I pulled my phone out and saw that I had a message from the book company noting that my order had been delivered. Marveling at the speed of the response, I was still shaking my head as I observed the truck backing up into the driveway across the street in order to turn around.

Think of what just happened. In the space of about 10 seconds, the wireless device in the driver's hand sent a notice of delivery via the cellphone network back to the FedEx headquarters noting that the driver had scanned a particular barcode while delivering the box. The FedEx computers matched that barcode to the delivery order and connected it to the company who had submitted that delivery order. They then sent a notice of delivery to CBD via the Internet with the identification of the shipment. CBD matched the shipment id to the order that I had placed, constructed an email with the list of books that were in that box and sent an email over the Internet where it got routed to a gmail server (which might be anywhere in the US). It was then routed to the several devices which are connected to my email address (my laptop, my smartphone, and my wife's smartphone), and each of these devices made the appropriate response to that incoming message - a beep on our smartphones, and a different sound on my laptop.

Ten seconds for all the above - starting with a scanned barcode on the driveway below me, routing of messages between computers and other devices located all across the US, and ending up with an email on the device in my pocket and an audible notice to me - and all before the driver even had a chance to get back in his truck and drive off!

When I went off to college in 1966 I didn't even know what a computer was. I was fortunate enough to recognize their potential, to major in that field as soon as a degree program became available in 1968, and to work in the computer field for the next several decades. But I am still amazed at where technology has taken us.

Ten seconds!

Tuesday, August 7, 2018

Accreditation


During my early years in the computing field I was very interested in being “professional”. This included becoming a member of both of the preeminent computer science professional societies – ACM (Association for Computing Machinery), and IEEE-CS (Institute for Electrical and Electronic Engineering, Computer Science). I had joined ACM as an undergraduate and IEEE-CS shortly after entering the work force.

Because of my ACM and IEEE-CS memberships, I became aware of an emerging effort to accredit university computer science programs.  Program-level accreditation is extremely common in academia and as the two leading professional societies (and with many of their members being in academia as well), ACM and IEEE-CS were the obvious places for such accreditation efforts to begin.  They jointly formed a new organization called the Computing Sciences Accreditation Board (CSAB) with one initial accrediting commission under it – the Computer Science Accreditation Commission (CSAC).  This was modeled after ABET (the Accrediting Board for Engineering and Technology) that existed in the engineering field which had separate commissions for the different branches of engineering (several years after my association with them CSAB merged with ABET).  They issued a call for participation.  While there were many in academia to choose from, they were especially interested in having participation from those in industry and government – to give the organization some legitimacy – and so I was accepted as an evaluator for the initial round of certification visits in 1985.  There were a few days of training in Las Vegas, as well as the couple of days involved in the accreditation visit, but my manager approved my participation.

That first year I was assigned to a team that would be visiting Mississippi State University.  The team chair (there were three on each team) was a professor from Houston who was also one of the board members of CSAB.  I must have done well, as he recommended me as a team chair for the next year’s cycle. The team chair’s responsibility was to make all the university contacts and schedule the visit, to lead the team during the three-day visit, to interview all the appropriate university leadership (president, provost, deans, etc.), to compile the visit report with input from the other team members, to correspond with the university to get their response to the report and verify any corrective actions taken, and finally to represent the team at the annual CSAC meeting in the spring.  CSAC was composed of all the team chairs from that year and their vote on the presentations from each team chair determined whether the university program would be accredited.

The universities that wanted to be considered for accreditation were essentially on at least a two-year cycle. They would spend at least a year in self-study, producing a sizable document that they would submit to their assigned team chair. Some of the standards that the institution must meet are not negotiable – such as the program being accredited must have actually had graduates that had taken the curriculum that they offered, i.e. we were accrediting real programs, not pieces of paper. But many of the standards are measures of quality that can only be assessed by the team visiting the institution. They then hosted the team for a visit in the fall. Between the end of the visit and the CSAC meeting in the spring they would have to present evidence of what changes they made based on the visiting team’s recommendations, and the vote of CSAC would take place in the spring.

The team members would each receive a copy of the self-study (from the team chair) and read it before the visit. The team would individually fly in and they would all meet the night before the visit to plan who was going to do what the following day. The next morning the team would initially meet with the department chair to go over their plans. We would also view all the other materials that the institution had prepared for us. This would include copies of all syllabi for required courses, copies of the textbooks used, copies of graded exams, and transcripts for a few students who had graduated from the program (with identifying information obscured as appropriate). Each member of the team would have scheduled some time during the day to review this material.

The team would then split up so they could cover as much ground as possible that day. We would try to interview as many faculty members as we could in the CS department, interview students (often by going into a lab and asking several students there if they would like to talk to us – so the institution couldn’t “cherry pick” the students we talked to), and see the facilities and labs that the institution had. We would also interview representatives of supporting departments (essentially any department where CS students had required courses – like math, physics, and English). We would also visit the library to review their CS reference book collections and subscriptions to significant periodicals in the field. In addition to covering some of these areas, the team chair would visit with the dean of the college that the CS department was in, the vice-president of institutional research (to get an idea of what the faculty were doing for research), and the university president. That night the team would meet after dinner to review the events of the day, decide what follow-up visits were needed the next day, and the team chair would charge each team member to write the various sections of the report. It was a very full day.

The next day the team would do any follow-up visits and over lunch and into the early afternoon they would draft their preliminary findings, including commendations and recommendations. Before leaving that afternoon, there would be an exit report given by the team chair to the president and dean (and whomever else those individuals wished to hear the results such as the department chair). The primary information delivered would be a verbal presentation of the commendations and recommendations (usually with those listening fiercely taking notes). No report would be made of what the recommendation of the team chair to CSAC would be made, since there were several months for the institution to rectify any deficiencies.

Over the following months the team chair would get the written reports from the team members (based on the assignment that he/she had made), correspond with the institution on what corrective actions they had made (with verification), and prepare a short presentation to be given to the full commission when they met in the spring. The chair could recommend to the commission to not accredit, to give full accreditation, or to give accreditation for a shorter amount of time during which the institution would have to correct some specified issues.

Because accreditation is valued so highly, the ability of the accreditation team to influence changes in the institution was always impressive to me. I personally witnessed one CS department, as part of their corrective action plan, get allocation from the institution for another full professorship. At another, we noted that the physics department, which was only a service department since the institution did not offer a degree program in physics, was still using WWII surplus oscilloscopes. Based on our report that they needed to expose the CS students to more modern equipment, the physics department was able to get a $50K allocation from the institution for equipment – something that the department had unsuccessfully been trying to get for several years. I also witnessed another team that had visited one of the military service academies. Getting additional funds required not only approval of the institution, but approval from much higher up the chain at the senior levels in the Pentagon. But because the team identified a particular need, the team chair was impressed that they got approval from a normally slow-moving government agency in a matter of weeks! The institutions generally welcomed our recommendations since they saw that we were trying to help them improve.

Over the next several years I had to pleasure of chairing a team each year to different universities – University of Southern Mississippi, University of South Alabama, Benedictine College (near Chicago), Norfolk State University, NE Louisiana University and Pace University (outside of NYC).  As one of the very few industry representatives in this very academic endeavor (I was one of only a couple of non-academics who was a team chair), I was often met by some skepticism by university administration (i.e. presidents).  They asked, “How can someone from outside of academia know what we do and critique us?”  But one president remarked to me, “You missed your calling” once I had made my report visit to he and his staff at the end of our visit.  Appointment to CSAC was limited to two three-year terms, so after six years of serving in this capacity, my final CSAC meeting was in 1992.

I believe that accreditation is a process that, while arduous, can be of great benefit to the institution. And I also believe that it is a combination both of a rigorous set of standards and an accreditation team that applies appropriate interpretation of those standards to the institution that makes it successful. You need both.


Monday, August 6, 2018

My Early PC Experience


Since I received my BS in Computer Science in 1969 and my MS two years later, I was at the forefront of those in the computer field. But I was not a hobbyist as some were who bought some of the early home computers, often by putting them together themselves. Rather, as a user of computers in business, I lagged a few years until the initial bugs were worked out. But still I was an early adopter once the home PC market began to develop.

Being an early adopter

I bought my first IBM-PC (actually the only one actually marketed by IBM that I ever bought) some time around 1983. It came with 64K. I had my choice of a single-sided or double-sided floppy drive (I chose the latter). I also bought a color monitor, a copy of DOS 1.1, an Okidata 82 printer (with NLQ (Near-Letter Quality) print capability), and a printer cable (everything was unbundled those days). I paid about $2,200 for all of those – a hefty sum in those days. For software, I purchased a copy of Volkswriter (*1), a relative cheap package, but one that was far superior to IBM’s Easywriter and easier to use than WordStar which had just come out. I also got a copy of WordProof which was a companion piece that did spell/grammar checking. These were my primary tools – remember that things like email didn’t come along until 10 years later in 1993.

Over the coming several years I made a number of upgrades. First, I got a second floppy drive and upgraded the memory from 64K to 256K (maxing out the motherboard as I inserted the chips myself). Later I replaced one of the floppy drives with a hard drive that stored a whopping 5M and upgraded to DOS 2.0 in order to support it. Eventually I replaced that original IBM PC with a 286 machine from Northgate. Over the years I’ve had a continuing series of machines, each much more powerful that the last, but interestingly the basic price remained in the same range.

I’d like to take the rest of this article to give an overview of one of the most significant projects that I was involved in that stretched the ability of that first PC.

A major project

I was still operating that original PC, now upgraded with more memory and a second floppy drive, in the winter of 1984-1985. A man who I’d gotten to know over the prior several years (and who has been a good friend ever since), Dick Gehman, was a missionary to Kenya. I used to pick up he and his family at JFK airport every four years as they came home on furlough and then take them back to JFK a year later when they returned to Kenya. In 1984 the Gehmans came home for year and his task for that year was to work on his Doctorate in Missiology – in particular on completing and submitting his dissertation to Fuller Seminary in CA. Fuller’s standards at the time included a requirement that the dissertation be typed on an IBM Selectric typewriter. Dick heard that I had a PC and asked if it were possible to use this “new” technology to prepare his dissertation. I agreed and printed out a sample document in NLQ (with a new ribbon) and he submitted it to Fuller and asked if that printing was acceptable. They said yes.

Starting in January 1985, and continuing for two full months, Dick would come to my house each morning before I left for work. He had never used a computer before and had no idea on how to do basic functions like starting it up, saving his work, etc. I got the PC set up before he arrived. He brought his lunch with him but basically spent the entire day typing. When I came home I would save his day’s work. When he finished a chapter, I would run it through WordProof and do a basic read through and edit myself, then print out that chapter which he would take home to his wife for further proofreading. Corrections would eventually come back to me, I would make the changes and then print the final chapter.

African languages, Greek and Hebrew

There was one major issue that I had to work through and that tested my skills. Dick’s dissertation was on African Traditional Religion. Part of the dissertation included some words from three of the tribes in Kenya that he worked with. While these words used primarily Latin characters, some of the letters had diacritical marks. These were not too bad to deal with. But the final portion of the dissertation was a study on the biblical interpretation of some of the subjects. For this, Dick would reference the original words in Greek or Hebrew (the language of the New and Old Testament). But these characters did not exist in any word processor of the time. So, what was I to do – other than leave blanks in the document for them to be hand-written in later?

The solution lay in the fact that the Okidata printer supported what was known as downline loadable fonts. Basically, I could design my own characters/fonts by creating a bit pattern stored in binary, then send them to the printer to be stored in its local memory. Then when the printer was asked to print the alternate font it would pull it from its memory and use the bit pattern to fire the individual pins in the printhead. There were some limitations, such as you could not fire the same pin twice in a row as it needed time to reset itself as the printhead moved across the page, and the character could only be as large as a typical character (as I recall it was 9 bits high and 11 bits wide), but otherwise you had free rein to program the firing of the individual pins in the printhead.

I looked in an encyclopedia for the shape of the full Greek and Hebrew characters, then built a file with a corresponding set of pin firings for each character (essentially a text file with a bunch of X’s corresponding to the firing of each pin on a separate line and a column for successive firings). I then constructed a program in BASIC that would read this text file of X’s and build the bit patterns that would be sent to the printer. I thought it was a pretty elegant solution.

When you selected the “alternate font” in Volkswriter (kind of like a modified shift key), it would put the font on the screen in color. The correspondence was that a lower case “a” (which would show on the screen in red background) was going to be transliterated into a Greek alpha, but an upper case “A” was going to be transliterated into a Hebrew alef. For Dick, this was going to be pretty easy, he would just shift into alternate font mode and type the equivalent Latin characters for each Greek character (alpha, beta, gamma, delta, etc.) or the upper-case equivalents for Hebrew characters (Alef, Bet, Gimel, etc.) Since Greek and Hebrew do not have lower/upper cases there were no conflicts. I printed out a full alphabet for Dick and he made a few corrections to my character shapes based on how he wrote each character and I simply adjusted the pattern of X’s in my text file and reprocessed it until I satisfied his criteria.

This was a real good test of my computer skills – learning the capabilities of my printer, designing a solution that included a readable input (patterns of Xs) and building a program to translate that readable input into the bit patterns that the printer required.

Finishing the dissertation

Dick is a very serious writer. The finished work was over 600 single-spaced pages which he took to CA with him for his dissertation defense. The committee he met with had a number of changes that they wanted in it, which mostly involved cutting out some portions. But the finished project needed to be printed and also needed things like a table of contents, and an index. Dick returned the marked-up copy to me (via insured mail), together with rubber-banded strips of paper that contained all the things that he wanted to appear in the index. And by strips of paper I mean little strips – basically one line high with a word/phrase and page number on each strip!

I had some major work to do in order to produce the finished product. I first typed up all the strips of paper into a document, then sorted the lines of the document by page number. I made all the textual changes from the marked-up document. I then printed the main body of the dissertation (I’ll call it a book, because it was going to be one before it was done). This meant a continuous print job that lasted nearly 24 hours. I built an overall document that did an “include” of each of the documents that were part of the overall book). I was sufficiently skilled that I could go from floppy to floppy as each chapter finished (as I recall it took 7 floppies to store it all). I was also able to periodically pause the printer and put in a new ribbon (so that the final print quality would not show any fading as the pages advanced). But once that 24 hours of printing was done, I had more work to do.

First, I had to look up each of the index entries to find out what page number the reference had moved to (remember that if there are significant deletions, then the page numbers are all going to change)! I then sorted the index document by reference word/phrase to get it in alphabetical order. When the same word was indexed in two or more places, I manually combined the lines into one with multiple page numbers listed. I then printed the index (starting the page number of the index on the page after the last chapter. Finally, with all the page numbers known, I could insert the page numbers into the table of contents – the last piece of the puzzle to be printed.

It took several days to complete the project – but I was thoroughly invested in the finished work. I mailed it back to Dick in CA (again by insured mail). He had copies made and bound. As a token of thanks, he presented me with a copy of the finished work – my sole pay for my contribution in both time and expertise to his dissertation. But, unlike many dissertations, this one did not just sit on a shelf gathering dust. It became the basis for three books that he later published, some of which are still being used now some 35 years later. I’m happy that I was able to be a part of this project!


Notes: