Et matematisk problem, lad os kalde det "Pubcrawl Paradokset"...

For lang tid siden, var jeg med til at planlægge en pubcrawl, og vi løb ind i et planlægningsproblem, jeg ikke har kunnet finde en løsning på endnu, og umiddelbart har ingen af dem jeg lige har spurgt, kunne give mig et hint af, i hvilken retning svaret måtte ligge. Så nu smider jeg det op på internettet, og håber at der sidder nogle kloge hoveder derude, der kan hjælpe lidt.

For en god ordens skyld, så skal det siges at jeg er ved at lave en brute-force løser, der tester alle mulige permutationer, men inden den bliver færdig for de rigtigt store tilfælde, kunne det være fedt hvis nogen havde en ordentlig grund til, hvorfor man ikke kan planlægge det. 

Jeg sætter i øvrigt en flaske vin på højkant. Måske 2. Og også et kram! Nå - her begynder vi:

  • Pubcrawlen involverer et antal aktiviteter, svarende til antallet af steder der skal besøges. Dette antal er m.
  • Pubcrawlen har n deltagende hold.
  • På hvert sted, skal to hold kæmpe imod hinanden, så n = 2m. Om man møder alle hold, er ikke vigtigt.
  • Hvert hold må kun prøve hver aktivitet én gang.
  • Holdene må ikke kæmpe mod hinanden mere end én gang.
  • Og slutteligt, grundet fysikkens love, kan man ikke være på 2 pubs på én gang.

Så langt jeg har fundet frem til, så kan problemet ikke løses hvis antallet af aktiviteter (m), er lige. Men for et ulige antal, kan man bare drible ned gennem et skema, og så passer pengene. Er der nogen der kan hjælpe? Gerne, eventuelt med noget litteratur på emnet, samt et navn på det matematiske aspekt af det. Jeg er sådan set ligeglad med om det kan løses eller ej, jeg vil bare gerne vide hvorfor. På billedet nedenfor har jeg vist et eksempel, med 3 steder, og 6 hold. Og den kan godt løses (med mindre jeg har overset noget).

pubcrawlParadox

 

Og skulle det resultere i at vi er nød til at opfinde noget matematik for at få det løst, jamen så gør vi det gerne! Jeg håber at måtte blive medforfatter på en eventuel publikation.

Jeg skal nok give lyd når jeg nærmer mig et resultat... Og ja, jeg løser også mine sudoku med kuglepen, jeg lever et hårdt liv!
/Rasmus

Hvad kan jeg bruge "Itô Diffusions Processer" til?

Så skete det, mig og min vejleder fik et gennembrud, i form af hvordan vi skal gribe hele min Ph.D. an. Siden jeg startede, har vi egentlig gerne ville to forskellige ting, og vi har ikke rigtigt kunnet finde kombinationen af dem - men den åbenbarede sig igår! Så nu kan der virkelig ske fremskridt. Du tænker måske, "ja ja, Rasmus, det er alt sammen meget godt - men hvad laver du egentlig?". Jo - det jeg forsøger at udvikle, kva min Ph.D. er en metode til at detektere fejl i kølesystemer. Kølesystemerne har, efterhånden, fået en del sensorudstyr monteret, og man kan derfor måle en masse forskellige ting. Det kan være temperaturen af den luft man blæser ind i køleskabet, temperaturen af den luft der er i kølesystemet eller temperaturen af den kølevæske man bruger til at flytte varmen.

Alt sammen, har de det til fælles, at vi har en masse målinger, og forsøger at finde hoved og hale i dem. Over det sidste halvandet år, har jeg så arbejdet på 2 (lidt) forskellige metoder, hvor den ene drejer sig om bare at kigge på målingerne, og se om man kan sige noget fornuftigt ud fra hvad de måler. Den anden metoder består i at bruge en computer model af systemet, til at bestemme om det faktiske system fejler.

Begge metoder har sine styrker og svagheder - og vi har nu endelig fundet en måde at kombinere dem på, så vi potentielt set tager styrkerne fra begge metoder, og slipper for svaghederne (tror vi....). Det vi arbejder på, er at anvende såkaldte stokastiske differential ligninger, til at lave en computer model af hvordan kølesystemet burde arbejde. Og dem kan vi så sammenligne med de andre målinger fra den tidligere computer model - og vi får så en ret god idé om der skulle være en fejl. At noget er stokastisk, betyder i øvrigt at man ikke ved hvordan det præcist opfører sig. Dog kan man oftest sætte nogle øvre (og nedre) grænser på hvordan det vil opføre sig. På "matematisk" hedder det jeg er ved, at Parameter Estimere en Itô Diffusions Process. I første omgang, antager vi at systemet er lineært, så kan vi se om det er forkert, på et senere tidspunkt.

Jeg skal i øvrigt lige have lagt nogle små flag på overskriften, så man kan se hvilket sprog posten er på - men det må blive på et senere tidspunkt! Tilbage til arbejdet.

Kalman Filtering and "Cause and Effect" - my first blog post..

I've chosen to start this blog, just to vent my thoughts, and keep some sort of diary! Furthermore, i'll use it when I go to USA, so family and friends can follow what i'm doing. The contents of the blog, will be a mixture of tech and phd related news, mixed with societal issues at hand - it'll be mixed up, like Jeremy Clarkson does it, in his car reviews.

But, here goes!

The goal of my PhD, is to develop a method that can detect, isolate and determine errors on a refrigeration container, you know, one of those that ensure that the fruit you buy at the store is ripe. To the companies who own the containers, it is really important to know the integrity of the system, as they can prepare maintenance accordingly. A system that malfunctions, destroys the cargo, and trust me on this, a container packed with luke-warm, rotten meat, does not smell good.

There are several methods that can be applied to solve such a problem, where most of them, apply some sort of model-based approach. For you, non-mathematicians, a model is a way to express how an input, influences an output. One of these model-based approaches, is to apply, what is known as a Kalman Filter to the measurements. This have several benefits, firstly, it filters the sensor measurements, and provides the end-user with a better idea of the different temperatures in the system.

When its working properly, you also gain the benefit if being able to remove sensors from your system, and keep the system running! The latter is a huge benefit, given the problem described above.

The tuning of the filter, however, is really a pain in the ass! As a small adjustment one place, can lead to huge changes in other places, cause and effect. Today, i've spent several hours trying to tune it, and as soon as I saw some progress, the next iteration, went two steps back. I weren't able to determine what caused which changes, but i'll get back to that tomorrow, and hopefully be able to go to weekend, with a functioning prototype.

Thats it for now!
/R