Halfdan Rasmussen - Stilheden

Jeg er stilheden. Jer er den lyttende grav.
Den talende død, som tålmodigt og uden krav
byder dit øre at lytte, dit øje at se.
Jeg er stilheden. Jeg er det lydløse tog
af tøvende ord, som tegn i et renere sprog
end det dine læber har talt. Jeg er ordenes sne.

Jeg er en tåge af vigende tegn i det blik
som ydmyg bevæger dit hjerte og lader musik
tone i det som er fjernt og alligevel nær.
Jeg er den ordløse fabel lagt ind i et tegn:
Spirende frøkorn. En stjerne. Syrener i regn.
Alt hvad du bare kan dele med en du har kær.
Træernes løv er min mund når det drivende rum
ånder i fuglenes vinger og havenes skum.
Gravenes stilnede hjerte blev stilhed i mit.
Blind er jeg født. Men jeg ser med hvert øje der ser.
Døv var jeg altid. Men lydhør når skumringen sner
over de usagte ord og de tøvende skridt.

Søger du mig så du søge mig nænsomt og tyst
nær ved den vuggende ild i menneskets bryst.
Jager du mig går du vild i de vejløse skove.
Ingen har strejfet mit hjerte med skygger af ord.
Kun døden har kendt mig. Og trygt skal de hjemfaldne sove. Ingen
har fulgt mig herud hvor det tidløse bor.

Suppose you’re in the middle of nowhere (or at least anywhere in Greenland) and need to know the coming weather conditions. The typical five day forecast is not gonna cut it.

METAR (METeorological Airport Report) describe the current conditions as observed by the weather tower at an airport. These are reliable, updated frequently, although incredibly terse. Similarly, TAF (Terminal Aerodrome Forecast) report the coming conditions including trends and temporary changes typically for the next twelve to twenty-four hours. The format takes a little getting used.

I’ve compiled a number of reports for a select few cities in the north Atlantic and compressed them into a format the plays nicely with mobile telephones. For the benefit of humans, I’ve prepended the Metar decoded. Let’s check out the balmy Kangerlussuaq (Søndre Strømfjord):

Metar


BGSF 071750Z 04005KT 5000 -SN OVC035 M11/M12 Q1008


BGSF is the airport code (ICAO) followed by the time of the report at UTC. The first two digits represent the day of the month (in this case the seventh) while the next four are the hour (24-hour) and minute (Z refers to Zulu or UTC), thus 17:50.

The next three digits refer to the wind direction (the direction from which the wind comes) over 360 degrees, where 0 is north, 90 is from the east. The next two digits is the wind speed in knots (hence KT). Two knots is roughly one m/s. So 04005KT is roughly 2.5 m/s wind from the northeast. Sometimes you’ll see a G which refers to gusts, so 27020G30KT means 10 m/s gusting to 15 m/s from the west.

The next four digits refer to visibility in meters. 5000 means 5 km visibility. 9999 is typically used for visibility unlimited or at least 10 km.

Then there is the weather type, precipitation, etc. A minus (-) means light while plus is heavy. There are a huge number of codes. Just a few, SH showers, SN snow, FG fog, DZ drizzle, TS thunderstorms, BR mist, RA rain, and many more.

The next zero to many describe the layers of clouds. Scattered, broken, overcast, etc followed by the number of hundreds of feet. Why we mix metric with imperial, I have only guesses. OVC035 means overcast layer of clouds at 3500 feet.

The next numbers refer to the the temperature. The M means minus (below freezing). After the slash is the dew point, the temperature at which precipitation should be expected, or at least 100% relative humidity.

The number with a Q is the barometric pressure in millibar (mbs).

I present an alternate theory as to the cause of the Icelandic financial crisis. Specifically, the negation and diversion of sub-zeros from database aggregate product calculations.

Just kidding. But, every once in a while there is a hack so circuitous it keeps one up at night. Literally. This is one of them. This hack has found itself in production code in banks around the world with no problems for several years. Until now.

When calculating sliding averages, adjusted duration, volatility, and other performance graphs, it is often necessary to multiply huge sets of values from a database. For example, the product of the daily change in the closing price of a stock over the past ten years. This is known as an aggregate product.

So, you would think that the leading database, Oracle, would handle an aggregate product. Some common aggregate functions include SUM, AVG, COUNT, MAX, MIN, etc. Oracle allows us to add, average, count, even calculate logarithms, but we can not simply multiply the rows in a table. Here’s a simplified solution at one bank, now going the way of the polar bear:

   select
      exp(sum(ln(abs(decode(COLUMN,0,1,COLUMN)))))*
      decode(mod(count(decode(sign(COLUMN),-1,1,null)),2),1,-1,1)*
      nvl(max(decode(COLUMN,0,0,null)),1)

Let’s reconstruct this. Put simply, we add up all the natural logs of each value and reapplying the exponential to the sum. The first line, exp(sum(ln(…))) relies on the fact that:

   e^(ln(x1) + ln(x2) + ... + ln(xn))
      == x1 * x2 * ... * xn, for all x >= 0

But this is only true for positive non-zero numbers. The abs(decode(…)) of the first line, reverses all negatives and ignores all zeros. The next two lines, handle negatives and zeros respectively.

   select
      e^(sum(ln(abs( [ ignore zeros ] ))))*
      ( count( negative numbers ) == even ? 1 : -1 )*
      ( have any zero at all ? 0 : 1 )

The second line multiplies the entire result by negative one if there are an odd number of negative numbers. The third and final line multiplies the entire result by zero if there is any zero.