The Jokes thread

Tonyr1084

Joined Sep 24, 2015
9,744
The cops just knocked on my door.
"Who IS it?"
"The cops!"
"What do you want?"
"We just want to talk."
"How many of you are there?"
"Just the two of us."
"So talk to each other!"
 

Tonyr1084

Joined Sep 24, 2015
9,744
While this is "The Jokes Thread", this is no joke. Met a guy from California. Californian's are paying 4¢ per mile tax. They have to show mileage. Now, I don't know this, but I think it sounds like an EV tax. Gas taxes go to pay for road maintenance. EV's don't use gas, so they're essentially riding around on the streets for free, charging the battery not withstanding. EV's, of course, have no emissions. But they're not free and clear from emissions. Power companies have to burn fossil fuels to generate the electricity the EV's use.

Bottom line, Death and Taxes are the only two unavoidable things I can think of off hand.
 

nsaspook

Joined Aug 27, 2009
16,330
A Spanish captain of a Navy ship in the 1800s was on Duty as they sailed a scout yells up to the Captain "I see 2 enemy ships on the horizon" The Captain yells out "Bring me my red shirt" his 1st mate asked "Why a red Shirt" The Captain responds "I wear a red Shirt because if I am wounded in battle the men won't see the blood and continue fighting" A week goes by and the Scout yells up to the Captain "I see 20 enemy ships on the horizon" The Captain looks around frantically and yells "BRING ME MY BROWN PANTS"
 

joeyd999

Joined Jun 6, 2011
6,323

ApacheKid

Joined Jan 12, 2015
1,762
When NASA Lost a Spacecraft Due to a Metric Math Mistake
The initial error was made by contractor Lockheed Martin Astronautics in Colorado, which, like the rest of the U.S. launch industry, used English measurements. The contractor, by agreement, was supposed to convert its measurements to metrics. The systems engineering function within the project, whose responsibility was to track and double-check all interconnected aspects of the mission, was not robust enough.
 

WBahn

Joined Mar 31, 2012
32,890
I know someone one that was on the inside of this debacle and he and I have had some spirited discussions over this. He says that there were underlying issues, mostly management issues, that played a huge role in the failure of the mission. That may well be, but my contention is that that at least this particular aspect of the failure -- the units mismatch issue -- would likely not have happened if our engineering education emphasized the proper tracking of units throughout the work as being expected and demanded in order to earn an engineering degree. If that were the case, it is my contention, the mistake probably would not have been made and almost certainly would not have gone uncaught because all it required was one person in each of the steps to be a units fanatic to spot that something was wrong. There were several points at which this almost certainly would have happened, despite the subtleness of the chain of events that resulting in computations from one piece of software, being done in one set of units, from being ported over to another piece of software that assumed a different set of units. If nothing else, had a units-aware culture been in place, the variables in both of the programs would have incorporated the units into the variable names and the people taking data from one program to another would have been in the habit of verifying that the units were compatible before proceeding.
 

nsaspook

Joined Aug 27, 2009
16,330
I know someone one that was on the inside of this debacle and he and I have had some spirited discussions over this. He says that there were underlying issues, mostly management issues, that played a huge role in the failure of the mission. That may well be, but my contention is that that at least this particular aspect of the failure -- the units mismatch issue -- would likely not have happened if our engineering education emphasized the proper tracking of units throughout the work as being expected and demanded in order to earn an engineering degree. If that were the case, it is my contention, the mistake probably would not have been made and almost certainly would not have gone uncaught because all it required was one person in each of the steps to be a units fanatic to spot that something was wrong. There were several points at which this almost certainly would have happened, despite the subtleness of the chain of events that resulting in computations from one piece of software, being done in one set of units, from being ported over to another piece of software that assumed a different set of units. If nothing else, had a units-aware culture been in place, the variables in both of the programs would have incorporated the units into the variable names and the people taking data from one program to another would have been in the habit of verifying that the units were compatible before proceeding.
+1 and it doesn't need to be a oddball metric conversion error.

https://people.computing.clemson.edu/~steve/Spiro/arianesiam.htm

The design of the SRI used in Ariane 5 is almost identical to that of Ariane 4, particularly with regard to the software. Based on the extensive documentation and data made available to the board, the following chain of events was established, starting with the destruction of the launcher and tracing back in time toward the primary cause:

The launcher began to disintegrate at about 39 seconds because of high aerodynamic loads resulting from an angle of attack of more than 20 degrees, which led to separation of the boosters from the main stage, which in turn triggered the self-destruct system of the launcher.

This angle of attack was caused by full nozzle deflections of the solid boosters and the main Vulcain engine.

The nozzle deflections were commanded by the OBC software on the basis of data transmitted by the active SRI (SRI 2). Part of the data for that time did not consist of proper flight data, but rather showed a diagnostic bit pattern of the computer of SRI 2, which was interpreted as flight data.

SRI 2 did not send correct attitude data because the unit had declared a failure due to a software exception.

The OBC could not switch to the back-up SRI (SRI 1) because that unit had already ceased to function during the previous data cycle (72-millisecond period) for the same reason as the SRI 2.

The internal SRI software exception was caused during execution of a data conversion from a 64-bit floating-point number to a 16-bit signed integer value. The value of the floating-point number was greater than what could be represented by a 16-bit signed integer. The result was an operand error. The data conversion instructions (in Ada code) were not protected from causing operand errors, although other conversions of comparable variables in the same place in the code were protected.

The error occurred in a part of the software that controls only the alignment of the strap-down inertial platform. The results computed by this software module are meaningful only before liftoff. After liftoff, this function serves no purpose. The alignment function is operative for 50 seconds after initiation of the flight mode of the SRIs (3 seconds before liftoff for Ariane 5). Consequently, when liftoff occurs, the function continues for approximately 40 seconds of flight. This time sequence is based on a requirement of Ariane 4 that is not shared by Ariane 5.
 

nsaspook

Joined Aug 27, 2009
16,330
In both examples the software was the weak link, how surprising, if it can go wrong, it will.
And the software was written in ADA.
Code:
--- LIRE_DERIVE.ads 000 Tue Jun 04 12:00:00 1996
+++ LIRE_DERIVE.ads Fri Jan 29 13:50:00 2010
@@ -3,10 +3,17 @@
if L_M_BV_32 > 32767 then
     P_M_DERIVE(T_ALG.E_BV) := 16#7FFF#;
elsif L_M_BV_32 < -32768 then
     P_M_DERIVE(T_ALG.E_BV) := 16#8000#;
else
     P_M_DERIVE(T_ALG.E_BV) := UC_16S_EN_16NS(TDB.T_ENTIER_16S(L_M_BV_32));
end if;

-P_M_DERIVE(T_ALG.E_BH) :=
-  UC_16S_EN_16NS (TDB.T_ENTIER_16S ((1.0/C_M_LSB_BH) * G_M_INFO_DERIVE(T_ALG.E_BH)));
+L_M_BH_32 := TBD.T_ENTIER_32S ((1.0/C_M_LSB_BH) * G_M_INFO_DERIVE(T_ALG.E_BH));
+
+if L_M_BH_32 > 32767 then
+    P_M_DERIVE(T_ALG.E_BH) := 16#7FFF#;
+elsif L_M_BH_32 < -32768 then
+    P_M_DERIVE(T_ALG.E_BH) := 16#8000#;
+else
+    P_M_DERIVE(T_ALG.E_BH) := UC_16S_EN_16NS(TDB.T_ENTIER_16S(L_M_BH_32));
+end if;
Insert ADA programming joke.

1719602495955.png
 

ApacheKid

Joined Jan 12, 2015
1,762
And the software was written in ADA.
Code:
--- LIRE_DERIVE.ads 000 Tue Jun 04 12:00:00 1996
+++ LIRE_DERIVE.ads Fri Jan 29 13:50:00 2010
@@ -3,10 +3,17 @@
if L_M_BV_32 > 32767 then
     P_M_DERIVE(T_ALG.E_BV) := 16#7FFF#;
elsif L_M_BV_32 < -32768 then
     P_M_DERIVE(T_ALG.E_BV) := 16#8000#;
else
     P_M_DERIVE(T_ALG.E_BV) := UC_16S_EN_16NS(TDB.T_ENTIER_16S(L_M_BV_32));
end if;

-P_M_DERIVE(T_ALG.E_BH) :=
-  UC_16S_EN_16NS (TDB.T_ENTIER_16S ((1.0/C_M_LSB_BH) * G_M_INFO_DERIVE(T_ALG.E_BH)));
+L_M_BH_32 := TBD.T_ENTIER_32S ((1.0/C_M_LSB_BH) * G_M_INFO_DERIVE(T_ALG.E_BH));
+
+if L_M_BH_32 > 32767 then
+    P_M_DERIVE(T_ALG.E_BH) := 16#7FFF#;
+elsif L_M_BH_32 < -32768 then
+    P_M_DERIVE(T_ALG.E_BH) := 16#8000#;
+else
+    P_M_DERIVE(T_ALG.E_BH) := UC_16S_EN_16NS(TDB.T_ENTIER_16S(L_M_BH_32));
+end if;
Insert ADA programming joke.

View attachment 325749
GIGO again.
 

joeyd999

Joined Jun 6, 2011
6,323
+1 and it doesn't need to be a oddball metric conversion error.

https://people.computing.clemson.edu/~steve/Spiro/arianesiam.htm

The design of the SRI used in Ariane 5 is almost identical to that of Ariane 4, particularly with regard to the software. Based on the extensive documentation and data made available to the board, the following chain of events was established, starting with the destruction of the launcher and tracing back in time toward the primary cause:

The launcher began to disintegrate at about 39 seconds because of high aerodynamic loads resulting from an angle of attack of more than 20 degrees, which led to separation of the boosters from the main stage, which in turn triggered the self-destruct system of the launcher.

This angle of attack was caused by full nozzle deflections of the solid boosters and the main Vulcain engine.

The nozzle deflections were commanded by the OBC software on the basis of data transmitted by the active SRI (SRI 2). Part of the data for that time did not consist of proper flight data, but rather showed a diagnostic bit pattern of the computer of SRI 2, which was interpreted as flight data.

SRI 2 did not send correct attitude data because the unit had declared a failure due to a software exception.

The OBC could not switch to the back-up SRI (SRI 1) because that unit had already ceased to function during the previous data cycle (72-millisecond period) for the same reason as the SRI 2.

The internal SRI software exception was caused during execution of a data conversion from a 64-bit floating-point number to a 16-bit signed integer value. The value of the floating-point number was greater than what could be represented by a 16-bit signed integer. The result was an operand error. The data conversion instructions (in Ada code) were not protected from causing operand errors, although other conversions of comparable variables in the same place in the code were protected.

The error occurred in a part of the software that controls only the alignment of the strap-down inertial platform. The results computed by this software module are meaningful only before liftoff. After liftoff, this function serves no purpose. The alignment function is operative for 50 seconds after initiation of the flight mode of the SRIs (3 seconds before liftoff for Ariane 5). Consequently, when liftoff occurs, the function continues for approximately 40 seconds of flight. This time sequence is based on a requirement of Ariane 4 that is not shared by Ariane 5.
What's most amazing is that, as late as 1996, they were still using adults in the launch control center.
 
Thread starter Similar threads Forum Replies Date
killivolt Off-Topic 10
KL7AJ Off-Topic 1
Sparky49 Feedback and Suggestions 4
electronis whiz Off-Topic 2
electronis whiz Off-Topic 1
Top