Jon Tingvold

Hydrological modeling with a simple LSTM network of 30 units

2019-11-01T00:00:00+00:00

Abstract

Are neural networks the future of hydrological modeling? Maybe. This simple LSTM is in many ways a poor model; yet, it performs remarkably well. On the small 15-year dataset included, it archives a Nash–Sutcliffe efficiency/R2 of 0.74 on the 3-year validation part (where 0.00 is the trivial mean prediction and 1.00 is perfect prediction). On the same validation set, my own HBV implementation, SwiftHBV, archives 0.78. It still much left to beat HBV, especially its robustness. However, LSTM was never designed for numerical predictions. Its range contrained units and non-conserved water flow, makes it unnecessary hard to learn hydrological behavior. A special designed RNN architecture might perform a lot better.

1 Introduction

There have been some papers out there that have tried to model rainfall-runoff and sometimes snow storage with LSTM neural networks. For instance Kratzert et al. (2018)¹ who archives a median Nash–Sutcliffe efficiency/R2 of 0.65 on 250 catchments in the US, -0.03 less than a traditional SAC-SMA+SNOW17 model. The results seem good, but not jet as good as old fashion models, like SAC-SMA+SNOW17 or HBV, which also are more robust.

This was a quick model I through together to see for myself how good these models perform compare to HBV. In difference to HBV, this model has no catchment parameters and generally no assumptions about the world. It should, therefore, be harder to fit than HBV—especially for small datasets, like the one I used. On the other hand, are they not constrained by HBV’s simplistic model of the world.

A poor model

I many ways are LSTM networks a poor model for hydrology. LSTM was created to model more fuzzy binary problems like natural language processing. While the memory cells can have arbitrary values, the inputs/outputs to/from them are constrained to the [-1, 1] domain with tanh activation functions. To be able to handle rare floods, hydrological models should not constraint large inputs or outputs.

The second problem is that LSTM has forget gates and add/subtract gates. Generally, we would like to have models where water is passed around from input, to different internal (storage) cells, between (storage) cells and then to output, without water being created or lost, except for the correction of precipitation at the input and a separate evaporation output that could be monitored.

These problems do not make LSTM inherently unusable. LSTMs are general computation machines that should theoretically be able to compute anything, given enough units. The problem is just that they might be unnecessary hard to train.

2 Method

2.1 Model

The model is a simple LSTM with one layer and 30 units, plus one output layer with ReLU activation.

2.2 Code

Code and data can be found on Github.

2.3 Optimization

Adam is used for optimization with a learning rate of 0.00001
The sequence length is 30 time steps (days) and batch size 1. Thus the error is back propagated 30 time steps and parameters are updated without batching.
The internal state is reset every epoch (12 years). It can therefore learn dependencies longer than 30 days.
The loss function is mean squared error on the discharge. There is no explicit optimization of the accumulated discharge.

2.4 Dataset

I used a short 15-years dataset from Hagabru, a discharge station in the Gaula river system, south of Trondheim (Norway). This catchment has a big area of 3059,5 km2 and no lakes to dampen responses. The first 12-years are used as training set, the last 3 years as validation set.

3 Results

3.1 Training experience

Normalize inputs and outputs between 0.0–1.0 seems to have a big effect on how fast optimization converges, but not prediction performance. Since the LSTM layers outputs are between -1 to +1, the dense layer has to increase their weights. It seems to take a lot of time before these weights are fully learned.
Increasing the number of LSTM-units seems to have a modest effect on performance after 30 neurons on the small dataset.
Two LSTM-layers gave the same fit on the training set and slightly worse on the validation set. It might increase a bit with a bigger dataset, but I don’t think it is very beneficial with many layers for hydrological models.
Normal SGD Nesterov with momentum seems to converge extremely poorly compared with Adam. I have no explanation for why.
I tried to put accumulated discharge in the loss/objective/cost function, but this just led to models that cap peaks and smoothens the discharge rate. R2 was reduced to 0.54 on the validation set.
I tried ReLU as activation function, but convergence failed and outputs produced NaNs. Not sure why, but ReLUs are uncommon for LSTM, so it might be that ReLUs make values explode and convergence unstable.

3.2 R2/Nash-Sutcliffe efficiency

R2/Nash-Sutcliffe efficiency
Dataset	LSTM	HBV
Traning set	0.82	0.78
Validation set	0.74	0.78
Here 0.0 is the trivial mean prediction and 1.0 is perfect prediction

The LSTM network is generally not much behind the HBV model. It performs four percentage points, or 20% worse than the HBV model. However, the LSTM model is less robust. HBV performs equally well on the validation set as the training set, while the LSTM model performs 8 percentage points worse.

3.3 Training set

3.4 Validation set

Rainfall events

It seems to estimate the peak size after rainfall events quite well, perhaps slightly better than HBV.
The discharge falls a bit weird. It seems to fall linearly with lots of breaks. It should fall like exponential decay, where the decay is larger for/after big rainfall events.
It seems like the model has a maximal discharge rate. Large peaks are underestimated and simulated peaks have ca. the same value.

Snowmelt

The model struggles with spring melt when the temperature is near zero, for instance in March and April 2014, and March 2012. When the temperature is high, like in June 2012, the estimates are good. Snowmelt around zero is something all hydrological models struggle with because snowmelt is affected not only by temperature, but also wind, humidity and in-/outgoing radiation (e.g. clear nights). It still performs worse than HBV, but the HBV is configured with the elevation distribution of the catchment and the estimated temperature on different elevations, while the LSTM-network needs to learn it, so it should perform worse.
It seems to be able to learn to store snow, but it is hard to know how accurately it records and store snow levels. The model seems to output more water after winters with more precipitation, and it looks like the accumulated discharge is neither severely over- or underestimated during spring melt the two first years in the validation set. However, in 2014 the discharge is way too high over time.

4 Discussion

The performance looks quite good compared to the simple, poor model and short time series. It is quite amazing how well it behaves from being trained on only 4380 time steps and that it learns quite well to store snow over long periods.
The reason it underestimates peaks is probably because of the tanh activation functions. It is not the biggest problem, but it probably makes LSTM unusable to estimate (rare) flood events. A different RNN architecture could perhaps solve this.
It is hard to know how accurate the model store snow levels. However, it is probably far away from HBV. The model would likely benefit from a more constraint model when it comes to adding and subtracting water from memory cells.
The problem that discharge rates do not smoothly decay after rainfall events, might be an artifact by how LSTM networks work. LSTM networks should be able to model exponential decay. However it requires that the cell units have values around 0.5 (so they neither are limited the tanh activation functions, or they are close to zero and produce small outputs), the activation layer needs produce outputs near 0, so the sigmoids produce output near 0.5 and decent decaying factors, and the outputs should into the forget gates on the next time step and remove the same amount of water from the cell states that was outputted. It is a lot to demand that LSTM networks should learn this accurately, and the fact that it does not look like it does might mean that LSTM networks are poor at accurately modeling snow levels, and get proper decaying outputting from storage cells.
Even if LSTM model had performed similarly as HBV, the HBV model would be preferred. It is, of course, a lot more robust, and performs almost equally well on the validation set as the training set.

5 Conclusion

This dataset is too small to get a decent overview of LSTM s performance. However, on this dataset it performs quite well. It is not too much behind HBV, although its predictions are a lot less robust and trustwordy compare to HBV. The LSTM model fails at some places which might indicate that the architecture is not the best, like that the decaying after rainfall events are not very smooth and constrained peaks. It would be interesting to look at other RNN architectures that are more suitable for hydrological modeling.

Is it possible to create a better model?

For hydrology, we probably want an RNN network with ReLU gates and where water not lost or created. However, designing new RNN architectures is not the easiest task in the world. LSTM (and the similar GRU) has been the default architecture because it is difficult to create RNN models. LSTM was carefully designed to make training stable and avoid the vanishing gradient problem and be able to propagate errors over long time frames. I have tried to think of a better model, but probably need to think a bit more seriously, if I should have a chance.

It would also be interesting to implement HBV, or something similar, in Tensorflow and train it with gradient descent like a neural network. As far as I can see is the only strictly undifferentiable parts in HBV min/max functions, and they are differentiable in practice.

However, a pure HBV trained with gradient descent might be stuck in local minimas. Local minimas are usually not a problem for neural networks because they have lots of parameters. The chance that all second derivates are all positive is therefore small. HBV has only 16 parameters and is, therefore, more likely to be stuck in local minimas if it’s not trained by algorithms that tackle local minimas.

The ideal model might be therefore something between HBV and LSTM—a network based on HBV’s tank model, but with more parameters, more freedom, and less linearity. The error in storage cells should also be able to flow freely back in time without degradation to be able to train long term dependencies like snow storage over the winter.

References

Kratzert, Frederik, Daniel Klotz, Claire Brenner, Karsten Schulz, and Mathew Herrnegger. “Rainfall–Runoff Modelling Using Long Short-Term Memory (LSTM) Networks.” Hydrology and Earth System Sciences 22, no. 11 (November 22, 2018): 6005–22. https://doi.org/10.5194/hess-22-6005-2018. ↩

Regulate tech and set markets free

2018-06-24T00:00:00+00:00

The market economy is supposed to set us free. Not only is it supposed to get firms to innovate and lower their prices through a Darwinistic process. It’s supposed to give us the freedom to choose our own products, who to trust and let businesses have alternatives when their partner bullies them. However, all of this only works when there is competition.

Instead, tech firms are creating monopolies in almost every industry. Amazon controls 50% of US online shopping, Google gets 95% of online searches, Uber wants to control taxi markets—Airbnb private lodging, Google and Apple (and Microsoft and Apple) have duopolies in mobile (and desktop) operating systems, and messaging and social media is impossible without using Facebook’s systems.

These platforms and their terms are hard to escape. Consumers can’t choose their messaging app of choice or who to trust with their data, Uber’s contractors can’t negotiate, youtubers must self-censor to appease YouTube’s monetization rules, iOS-developers are banned from making competing products, and developers can’t fight the 30% cut Google, Apple and Amazon take of Google Play, App Store, and Alexa purchases.

They also bar technology progress. Most of us have an NFC-chip which can emulate contactless «chip cards» in our phones, the same technology used in most wireless credit cards, access cards, public transportation cards, wireless keys, and biometric passports. Powered by induction it even works without battery. Yet, we still have wallets because Google and Apple refuse 3rd parties (and other payment providers) to use our NFC-chips.

Innovating?

Many think tech is innovating, but these innovations are usually results of a desperate fear of not controlling the next platform. What happens when the power struggles are settled?

In many areas tech is hardly moving. After internets 30 years bank transfers still take days. Most online banks are a mess. We still use paper receipts and there is no international standard for e-invoices with makes bookkeeping tedious and tax control difficult. Email has not had an update for decades and is so insecure and unreliable (because of spam) that governmental organizations and banks refuse to use them for important documents.

Designers cry inside when they see documents from common word processors like Word and Google Docs. They use second class fonts which are harder to read and show little beauty. And they lack even basic typographic improvements which have been standard in all books for a century like proper justification of text and preventing orphans. The state of the web is not much better. It even lacks multi-columns which could have better filled today’s wide screens. Most documents worth reading are still published in PDFs because there is no widely supported document standard that can adapt to the small screens of laptops, tablets, and phones.

For over 20 years tech-people have dreamed of a world with personal digital certificates. Fully supported this could have solved many of the problems we see today like electronic signing of documents, reliably verify who people are in email and eBay, and get rid of the security mess of having hundreds of accounts on the internet with the same password and usernames you can’t remember. Yet, we still print out documents, sign and scan them.

So why does the problems of tech seem to pile up? Why does not competitors enter to improve the tech giants mediocre products? The problems are many: From networking effects and governments absence at setting standards, but the biggest, and least talked about, is perhaps the problem of zero marginal costs.

The tragedy of zero marginal costs

As Joseph Bertrand stated in 1883, prices tend to converge down to near marginal cost in competitive markets. For digital goods, the marginal cost is next to nothing. So for tech, economic forces push the price down to zero—where it is hard to make money. Wired’s then editor-in-chief Chris Anderson called it «the law of gravity online». As a result, most apps are free but have rather lousy quality. While you can spend hours finding a physical notepad with the right paper texture, it is hard to find even a good note taking app that can export notes.

While it might be true that you would spend a few dollars more for quality, it’s easier to get customers to spend $5 more if the alternative cost $30 than if it’s zero. So most users end up with the free version, pushing prices up for the quality version, possibly in an endless death spiral. In my home country Norway, an English–Norwegian dictionary used to cost affordably $30 (for life), now the digital version costs $50 per year because so many use meager alternatives like Google Translate.

The effect of zero marginal costs can be seen on all digitalized goods from books, maps, travel guides, dictionaries, fonts, scientific journals, and newspapers—all have seen a plunge in revenue and quality. While American newspapers had $67 billion in revenues in 2000, their digital part brings in only $4 billion today—weakening democracies in the process.

Since its hard to make money on software directly, software is used to gain power and firms find other revenue streams. Google made Android free to gain control of smartphones and protect its advertisement business. Apple sells hardware by beautiful software (at least in the Steve Jobs era) which locks consumers into its platform. Google gives email, docs, and spreadsheets away for free to gather information for advertisers. Facebook does the same with social apps. These strategies are hard to copy.

In the related hardware industry, which have significant marginal costs, we see little of the same problems. There is an endless variation of phones, cameras, and routers to fit every need. Competitors are often working together for standardization, and standards like 5G are evolving quickly. When Apple surprised everyone with its iPhone in 2007, competitors quickly caught up to prevent market control. This is markets working at their best.

There is an important lesson here: While market economies are usually self-regulating, zero marginal economies, like tech, are not efficient without regulation.

The remedies

The remedies should be clear. As social platforms and public marketplaces like Uber, Airbnb, app stores, ad exchanges—and to a certain degree Amazon—will never have real competitors, they should be regulated as public utilities: run by governmental companies, tendered to the most innovating firm with lowest prices or heavily regulated. After all, it’s how we ended up regulating other natural monopolies like railways, public transit and electric grids a century ago.

Software makers should be required to open their formats and protocols and let competing firms create alternative software. As a start, we should let people have their messaging app of choice—no matter what their friends are using. Only then can we drive innovating and let people choose which provider to trust their data.

Governments should take an active role in developing standards and force all everyone to adopt them. Only then can we improve email and banking where firms have no incentives to collaborate.

Lastly—and this is probably most controversial—governments should probably regulate prices of software. If we want quality, privacy and diversity we need to solve the race to the bottom and forgo free apps. The price does not need to be high—a minimum price of $1 from 1 billion people, or $1000 from 1 million businesses, will not be noticeable in anyone’s pockets. Yet, better software will boost economic growth.

Most importantly, we should embrace regulation. If we value personal liberty we should acknowledge that zero marginal markets, like tech, won’t thrive without it.

Three formulas

2017-01-01T00:00:00+00:00

A responsive multi-column feasibility study

2015-10-01T00:00:00+00:00

This was a small personal research project I did in 2015, which was updated in 2016, 2018 and 2019. The aim was to create a prototype of a responsive multi-column layout and see if the technology was production-ready.

Demo

https://jontingvold.github.io/responsive-multicolumn-layout/

Abstract

Multi-columns are a distinct part of every newspaper. However, on the web, where multi-columns could have helped fill desktop’s wide screens, they have so far been absent. While there have been multiple efforts to get proper multi-column support in CSS, today’s implementation is flawed. Multi-column javascript libraries have their own challenges: FTColumnflow, the best, is complex and lack responsive layouts. This study, and the included proof-of-concept, shows that it is probably possible to solve these problems and use multi-column layouts in production. After the first version in 2015 browsers have become faster and CSS Scroll Snap has improved the user experience considerably. However, multi-columns are still risky. The complex layout engines necessary are prone to bugs and changing browser behavior.

Introduction

Why multi-column layouts?

I like reading print. You can see big parts of the page at once. It is easy to scan pages. You can look at headlines and pictures, and go a bit back and forth, and try to figure out what the page is about, without too much commitment. It is easier to examine the connection between the text and picture, introduction and conclusion. This non-linear reading is also a bit relaxing. It makes you stop reading. And think.

I think one of the reasons print feels so superior to the web, is multi-columns. In today’s world where most desktops have wide low screens, website’s single-column layouts lead to large empty parts, and just a small part of the document is visible at the same time. The whole experience feels a bit like reading documents through a tiny straw. That is problematic because the less you see of a document at the same time, the more of the article you have to hold in your internal memory. And it gets harder to get a holistic view of the article.

The other problem is that there are no natural breaks. There are no column breaks or page breaks. Just an endless stream of text pointing downwards. I notice it when I read: I forget to take breaks. I look less on images. And I stop less to think about what I am reading.

I also look less on ads. When I read print, my eyes often wander over the page and sometimes stops at the ad in the corner. When I read on the web, I just want to continue with the article I am reading.

It would have been interesting to research if what I am thinking is true.

My unproved thesis is that multi-columns have the following advantages:

More beautiful and more relaxing
Scanning is easier
Images and headlines get more attention
Ads get more attention
Articles generally communicate better

But if multi-columns are so good, why aren’t web designers using it?

Doesn’t CSS support multi-columns?

Multi-columns was proposed as a web standard as early as 1999 (W3C) and have been supported by browsers since at least 2005 (caniuse.com).

However, this standard misses so many vital features that it essentially is useless. The problems are many, but the most important are that:

It does not support pagination (except for print). So if you have longer text pieces than one screen size, you either have to get very long pages, where the user have to scroll back and worth. Or, you can expand the page vertically, which is problematic because many users lack mouses with support for vertical scrolling.
column-span is still not supported by Firefox (caniuse.com), so images, tables, and other fixed elements can’t be larger than the column width.
There are no controls to float/bound images to the bottom of a column, the last column (on a page) or the page corner

I guess part of the reason multi-column have not seen more traction is that is difficult to implement. It also joins a long list of missing design features in HTML/CSS, so it might also be because W3C and browser makers consist mostly of engineers, and not designers, and are concerned about improving the web as a programming platform, than a document standard.

Without native support, the only way to make multi-column layouts is to create a layout engine in javascript, calculate where each paragraph and image should be displayed, and use absolute positioning. That requires lots of engineering.

Implementation and technical challenges

The project is built on FTColumnflow, a library for creating multi-column layout build by George Crawford for the Financial Times (FT). In many years it was used in Financial times’ and The Economist’s iPad web apps, back in the days when companies created web apps to avoid Apple’s 30 percent revenue cut. And, as far as I know, no other multi-column libraries come close to being as good as it.

FTColumnflow’s design

FTColumnflow is based on fixed page size, you have to specify when FTColumnflow renders the page. The library also differs between two types of content: fixed content, like images, that are assigned a specific page and column, and flowed content, like the rest of the article, that are flowed (automatically) around the fixed content to fill the pages and columns. Fixed content can be positioned using CSS classes to specify a page number, vertical/horizontal anchoring, column span, and span direction.

FTColumnflow renders first fixed elements, like images, to determine their size. It then sets up the pages using absolute positioning and calculates where the fixed content inside a page should be places and positions it—also with absolute positioning. Finally, it calculates how large each column can be and fills the columns with content.

Filling the pages with flowed content is the most complex process. Most javascript libraries that have tried to implement multi-columns, fill each column with elements and paragraphs until a word is placed outside the page. They then cut the paragraph in half, creates a new p-element with the remaining text and places it inside the next column. New elements are then placed in the next column until a paragraph, or other text element, overflows the page again.

FTColumnflow found the last operation, of splitting the text, so slow that it became a performance problem. Instead, they found it was less expensive to just hide the excess paragraph behind overflow: hidden, calculate the pixel height of the visible paragraph part, and create a new copy of the whole paragraph that could be placed in the next column. If 50 pixel-heights of the paragraph was visible on the previous column, the new paragraph element was offset with top: 50px, so the paragraph seemed to flow consistently from one column to the next.

FTColumnflow’s new method is faster, but it creates its own problems. If the page height is not a multiple of the line-height, a part of the excess paragraph line will become visible. The same problem happens if not all lines have the same line-height or a multiple of it. All headers, leads, paragraphs, images, captions, and the page itself, must, therefore, have a height that is a multiple of the standard line-height, even if the elements have different font-sizes. That requires careful configuration of the CSS file. FTColumnflow tries to automatically correct for this, but this feature sometimes fails.

FTColumnflow’s two problems

There are two major problems with the way FTColumnflow is designed.

Few content management systems (CMS) can be configured so it is possible to specify which page and columns images should be placed on. Some CMS systems allow you to set custom classes on images, so you might set up many configuration classes, like one for each page, one for each possible column, one per columns the image can span, and for different floats, but this quickly becomes a mess, and is far from user-friendly.

The other big problem is that is FTColumnflow is based on a fixed page size and does not support responsive layouts. While you can query the browsers viewport size and set FTColumnflow’s page size to the same size as the browser window, it creates other problems. Since some screen sizes generate six pages—some only two, and some screens can hold up to four images—some only one, it is hard to know which page images should be placed on, without getting cramped pages with overlapping pictures on some screens. Or getting large empty pages on others, because the text only fills three pages, while you specified that the image should be placed on page 5.

Making FTColumnflow responsive

To solve, or at least limit, the responsive layout problem, I tried to limit the maximum and minimal screen area of each page.

In the demoed version I wrote some javascript code that sets the maximum page width to 1300 pixels, and the minimum page width to the width of the screen. Then I defined a maximal and minimum screen areal. If the screen size is less than the min areal, the page scroll snap is turned off and the page height is set bigger than the screen height, and so tall that the height and width have an area equal to the min areal. If the screen size is larger than the max areal, the page scroll snap is also turned off, and the page height is set smaller than the screen height and so short, that the height and width (or 1300 px) have an area equal to the max areal. This reduces the chance that images will cramp together, or that there is not enough text to fill all the pages that images have been placed on.

This is by far an ideal solution but avoids the problem enough, as long as you are a bit careful with how you position images.

The ideal solution would have been to rewrite FTColumnflow so it can handle normal HTML documents where images are placed in the middle of the content without special formatting or extensive class names, except some predefined image sizes. Large images could then span two columns, and small images only one.

The images could then be positioned so that the first image always appeared on the first page in the lower right. Then some predefined areas could be defined, e.g. top right and bottom left. The layout engine could then calculate how large each image would be and make sure that there were never so many images on each page that it would overlap. Then it could try to place the images evenly across the pages, and as close as possible to the text where they were defined. As long as the images are only very loosely bound to the text they appeared along, this would not be too difficult to calculate.

Such a solution would require considerable coding efforts, but it seems possible without major complications.

Findings

The good

As the proof-of-concept shows, it is possible to create fairly good multi-column layouts today. They can be beautiful, work quite smoothly, and work pretty well on most screen sizes.

Since 2015, when I made the first version, swiping between pages have become a lot slicker. Back in 2015, I had to use fullPage.js to swipe between pages. The old javascript page swiper libraries animated the page flip after registering a full swipe. Thus, they reacted a bit late. In addition, they did not adjust the animation time to how fast users where swiping. The result was a second class user experience. After most browsers implemented CSS Scroll Snap, swiping is now smooth and multi-column have become a first-class layout experience.

The bad

The layout engine is a bit slow. It takes 1000 ms to render a page—2000 ms if the page is long. This issue is complicated by the fact that Chrome does not use bfcache (back-and-forward cache) on pages with javascript that manipulate the DOM; the whole page needs to be re-rendered if a user clicks on a link and return back to the page. However, the rendering speed have improve noticeably since 2015 as browsers just-in-time compilers have become ever faster. The Chrome problem is common among web pages, and the page load time is still faster than many news sites. Ideally, I think it too slow, but since the rest of the web community think it’s an acceptable rendering time, I guess it is ok.

The potentially problematic

There are some potentially problematic sides under the hood

The FTColumnflow requirement that all element heights have to be a multiple of the line-height, makes it prone to bugs. It demands a lot from designers, especially when you expect FTColumnflow to correct for it. Small inconsistencies between browsers, like how heigh elements are rendered, can have dramatic consequences. Occasionally, I have seen FTColumnflow jump over a line on column breaks. I suspect this an artifact of overflow, and how FTColumnflow handles column and page breaks.

The complex layout can sometimes be problematic. In Safari the graphic card sometimes flickers the screen on page swipes; it seems it can’t handle the complex layout. Generally, I have also seen more a lot more strange behavior and inconstancies between browsers, than in normal projects. Sometimes it feels like I am pushing the limits of browser technology a bit too much.

None of these problems seems unfixable, but they indicate that multi-columns can be a bit risky to implement.

Conclusion

So is it possible to create responsive multi-column layouts?

The proof-of-concept shows that it at least can be done.

The biggest problems in my solution, such as that FTColumnflow is incompatible with most CMS systems, or that the responsive design is not perfect, can probably be solved, although it requires some engineering.

The worrisome news is that the complicated layout and inconsistencies between browsers are more prone to bugs. It’s not discouraging levels, but it makes it risky to use multi-columns, and you have to live with the fact that they probably need extra maintenance.

Følelsen av pudder

2010-02-01T00:00:00+00:00

De sier det er øyeblikkene. Men øyeblikkene kan bare legge seg. Det er følelsen! Følelsen av ski som gynger mot underlaget. Følelsen av mykhet. Følelsen av å presse snøen sammen i en sving, sprette opp og la overkroppen gynge fra side til side. Den ene skien fram, så den andre. Følelsen av flyt.

Egentlig burde jeg stoppet opp og nytt synet. Under meg ligger fjorden. Blå og klar. Et skip tusler av gårde innover. Rundt meg ligger fjellene. Spisse alpine fjell dekt i hvitt, med blå bakgrunn. Men øynene har mest lyst til å være lukket. Ikke får å kjenne sola som varmer mot øyenlokkene. Men for enda litt sterkere kunne nyte følelsen av pudder.

Jon Tingvold, februar 2010

Elvepadling

2009-10-01T00:00:00+00:00

Et rop om hjelp

Rolig, rolig, bli rolig! Kroppen vrir seg. Lungene vil ha luft. Kan ikke få panikk. Kan ikke få panikk. Panikken spiser mye oksygen. Jeg vet det. Oksygen er dyrbart nå. Må bli rolig. Har noen sett meg? Kroppen har lyst til å dra seg ut. Jeg prøver å trosse ubehaget. Alternativet er verre. Sakte kjenner jeg kroppen aksepterer sin tilstand. Jeg løfter armene. Et rop om hjelp. Kan ikke vite om noen svarer. Slår hendene mot kajakken. En gang. Ikke mer. Kan ikke bruke for mye luft. Var det noen i nærheten? Jeg husker ikke. Kanskje bør jeg bare gi opp. La kroppen trekke seg ut. Akseptere å bli gjennomvåt og at padledagen er over. Kroppen vil det. Venter. Vannet er kaldt. Kanskje 10 grader. Jeg kan kjenne det sildre inn i våtdrakten. Lungene er nesten tomme for luft. Venter. Hvor lang tid har gått? Prøver å se for meg verden der oppe. Det brusende vannet. Valsene. Her nede er alt så stille. Kanskje kjemper en eller annen seg i strykene mot meg. Jeg liker den tanken. Lungene er tomme nå. Er det noen der? Det må minst ha gått et halvt minutt. Føles sånn. Venter litt til. Munnen vil gape. Om enn bare for å trekke vann. Kommer det noen? Kanskje piner jeg meg selv for ingen nytte. Gir de fem sekunder til. Hvor er de? Hendene vil ned til spruttrekket. Kroppen prøver å redde seg selv. Men jeg kjemper imot. Lungene er over overtid. Tre sekunder til. To. Neonprenhanskene kjenner noe. En hard kant. Hvem har kommet? Finner ikke helt taket. Men så, jo! Drar meg opp. Endelig!

Jon Tingvold, oktober 2009

The burden of free money

1970-01-01T00:00:00+00:00

The role of interest rates is to balance production and consumption.

Overskrift og ingressalternativer

Todays modern monitary policy is the wrong way to save for retirement
While quantitative easing don’t cause inflation now, it will cause problems for future generations

The burden of free money
The solution to the global saving glut is neither quantitative easing, nor negative interest rates. Instead, central banks should be given the power to increase property and wealth tax rates.

The problem with quantitative easing
If most people want to save, interest rates should be negative.

Kickers

Modern monetary policy
The problem with quantitative easing

Heads

Instead of quantitative easing or negative interest rates, central banks should raise property taxes and subsidize lending
The problem with quantitative easing
Why interest rates should be negative
The problem with unceasing quantitative easing
The displeasing about quantitative easing
The problem with modern monetary policy
The problem with modern monetary theory
Money and dept—two sides of the same coin
Printing money and raising dept—two sides of the same coin
The burden of free money
The cost of free money
Why we should stop saving for retirement
Let the young pay: The burden of free money

Leads

Printing money and raising dept is two sides of the same coin. If most people want to save, interest rates should be negative.
Quantitate easing is a tax on future generations. If most people want to save, interest rates should be negative.
The solution to the global saving glut is neither quantitative easing, nor negative interest rates. Instead central banks should be given the power to increase property taxes.

Openings

Interest rates is the price to move production and consumption in time.
The role of interest rates is to balance production and consumption.
A requirement for the economy to work smoothly is that production and consumption is always in balance.
It is hard to save money.

Illustrations

En ung person tunget av byrden å bære en stabel full av penger. Evt. med eldre mennesker festende på toppen.

Intro historie

A Financial Fable” (also known as “The Cyclone Money Crib”) is a Donald Duck comic book story written and illustrated by Carl Barks in September 1950. As with many other Barks stories, it was originally untitled. The story deals with what will happen if everyone in a community becomes a millionaire.

Historien har mange likheter med Milton Friedmans teori om “helicopter money”, publisert i boken The Optimal Quantity of Money (1969), som han vant nobelprisen for i 1976.

Men hva hadde skjedd hvis innbyggerne ikke hadde brukt pengene, men spart dem? Det er nærmere den situasjonen vi har idag.

Velocity of money ofte glemt.

Hva jeg vil si

Trenger et ord for inverse of velocity of money. Jeg kaller det fra nå circulation time eller sirkulasjonstid. Evt. gjenomsnittlig fordringstid eller claim on GDP.

Ikke helt sikker på hva jeg ønsker å si, men jeg tror hovedpoenget er at

Det er farlig å øke sirkulasjonstiden.
Penger og gjeld er to sider av samme sak. Trykker man penger, øker man også gjelden.
Økonomisk teori har lenge basert seg på at sirkulasjonstiden er konstant. Det er den bare når folk bruker penger med en gang.
Sentralbanker bør ikke bare styre etter inflasjonsmål. De trenger også å se på sirkulasjonstid, altså gjeldsvekst.
Sirkulasjonstid er først og fremst farlig fordi det kan gjøre samfunnet ustabilt. Verden forandrer seg. Plutselig vil alle bruke alle pengene de har i banken. Men ressursene finnes jo ikke, så det blir inflasjon. De rike finner ut at de er mindre rike enn de er. De fattige blir tynget av gjeldsbyrden de sitter med, spesielt hvis rentene er flytende og de rike forlanger å kunne bruke pengene de har “spart opp”.
Sentralbanker bør ha to mål: å balansere tilbud og etterspørsel (inflasjonsmål kan være herustikk) og lage korrekt fordring på framtidige generasjoner (i hovedsak stabil sirkulasjonstid, men kan evt. økes ved kortvarige kriser og når det trengs store investeringer og bygges ned ved verdiforringing)
Renten bør gjenspeile kostnaden på å bruke penger nå vs. i fremtiden. Historisk har det alltid vært flere som vil bruke penger enn spare penger, fordi befolkningen har økt og investeringer i teknologi har vært mer lønnsomme enn å spare penger på bok. I fremtiden kan det godt hende det vil være motsatt. Folk trenger å spare penger til pensjon. Bygninger, veinett, strømnett, fabrikkapasitet er stort sett bygget ut. Befolkningen synker. Ønsket om å spare penger vil være større enn å bruke penger idag til forbruk eller investeringer. I så fall bør rentene også være negative.
Negative renter høres feil ut. Men selvsagt bare fordi folk ikke er vant til det. Det er selvfølgelig ingenting som tilsier at det skal være gratis å spare penger til fremtiden.
HVORDAN SKAL ET SAMFUNN KUNNE SPARE TIL PENSJON
Realverdier kan ikke spares. Netto sparing fører til at det er igjen for lite penger i forhold til arbeidskraften som tilbys og det blir deflasjon. Når folk siden skal ta ut sparingen vil for mange penger følge etter for lite arbeidskraft og det blir inflasjon.
Hvis realverdier skal spares må de investeres. Enten bygge veier eller hus. De meste av verdi kan ikke spares. De kan sentralbankene trykke penger med rette, og fordringen kan leve videre inntil behovet for husene har forsvunnet.
Dog er det ikke sikkert det er mulig å investere. Det er ikke sikkert det er behov for flere veier eller hus. Selv om det virker som behovet er der idag kan de hende vi har fått selvkjørende biler og behovet for veier blir borte. Eller arbeidsmarkedene kan ha blitt flyttet til Asia og alle husene vi bygget opp står tomme.
Skal et samfunn

Artikkel: Problemet med å trykke penger når det ikke blir inflasjon

Jeg tror det er dette som er hovedpoenget:

Hvis folk flest vil spare, bør renten være negativ
BNP bør ses på som antall arbeidstimer. Så slipper vi å måle det i penger, en rar størrelse.
Mulig jeg bør bruke omløpstid eller fordringstid, utestående tid, nedbetalingstid, krav på fremtidig verdiskapning,
Problemet med å utvide omløpstiden er at det skaper en illusjon om at det er mulig for et samfunn å spare penger. Det er tull.
På idivid nivå kan vi spare penger. På samfunnsnivå kan vi det i utgangspunktet ikke.
Hvis vi skal spare, må vi gjøre det realøkonomisk ikke finansielt. Kan investere i Afrika og satse på at de betaler tilbake når vi blir gamle. Kan bygge holdbar bygninger, sykehus og veier idag, og så kan vi la være å bygge disse i fremtiden. Utfordringen er at et er vanskelig å anslå hvilke bygninger eller veier vi trenger i fremtiden. Kanskje får vi selvkjørende biler som kan kjøre tettere eller mange små minibusser slik at vi ikke trenger veier med stor kapasitet i fremtiden eller midtdeler på veiene for å unngå møtekollisjoner. Kanskje finner vi en mirakelkur mot kreft og kapasiteten på sykehusene kan halveres. Kanskje burde vi bygget store pumpekraftverk i Norge for å hjelpe Europa og balansere kraftmarkedet i Europa. Kanskje utvikler den politiske situasjonene i Europa seg slik at Europa ønsker å være selvforsynt med energi og ikke kan stole på norsk balansekraft.

Øker byrden på framtidig generasjoner. Selv om M1-penger bare er fordringer på BMP i 3 måneder og M3 fordringer på BMP i 12 måneder, så må vi huske på at penger brukes som leverage. Øker M3 øker også ofte antall obligasjoner. Dobles M3 fra 12 til 24 måneder, øker også antall obligasjoner sin fordring på framtidig BMP fra 5 år til 10 år.

I motsetning til inflasjon, som bare gjør skade her og nå, vil økning av løpetiden gjøre framtidig skade. Mens inflasjon kan skje ubegrenset kan løpetiden økes begrenset. Mens

Økning i løpetiden er et tegn på at noe er galt. Ikke et tegn på

Hva er penger

Vanskelig å finne noen prinsipiell forskjell på penger, gjeld, aksjer, omsettelige verdier.

Notater

How to deal with the zero lower bound problem (ZLB)

Willem Buiter (2009). The wonderful world of negative nominal interest rates, again. Vox EU.

Abolish currency
Tax currency holdings
Decouple the numéraire/unit of account from the currency/medium of exchange/means of payment by introducing a new currency (the rallod) and abolishing the dollar currency. The dollar would remain the numéraire. The authorities would set the exchange rate between the dollar and the rallod. There would no longer be a zero lower bound on dollar nominal interest rates because there is no longer any dollar currency. There would be a zero lower bound on rallod nominal interest rates because of the existence of rallod currency. If the dollar interest rate set by the monetary authority has to be negative (say - 5%) to achieve the objectives of the monetary authority, the rallod interest rate could remain zero, provided the monetary authority announced a credible appreciation of the value of the dollar in terms of the rallod (by 5%).

Det siste har de fleste sentralbanker allerede planer for. IMF diskuterer det i en blogpost i 2019.

Gjeldsvekst

Working age population

Interessante fakta

Financial times hevder Kinas siste folketelling viser at befolkningen synker - The Economist
Retirement age in China er 60 for men og 50 eller 55 for kvinner - The Economist
Retirement age different countries (Wikipedia)

Jon Tingvold

Hydrological modeling with a simple LSTM network of 30 units

Abstract

1 Introduction

A poor model

2 Method

2.1 Model

2.2 Code

2.3 Optimization

2.4 Dataset

3 Results

3.1 Training experience

3.2 R2/Nash-Sutcliffe efficiency

3.3 Training set

3.4 Validation set

Rainfall events

Snowmelt

4 Discussion

5 Conclusion

Is it possible to create a better model?

References

Regulate tech and set markets free

Innovating?

The tragedy of zero marginal costs

The remedies

Three formulas

A responsive multi-column feasibility study

Demo

Abstract

Introduction

Why multi-column layouts?

Doesn’t CSS support multi-columns?

Implementation and technical challenges

FTColumnflow’s design

FTColumnflow’s two problems

Making FTColumnflow responsive

Findings

The good

The bad

The potentially problematic

Conclusion

Følelsen av pudder

Elvepadling

The burden of free money

Overskrift og ingressalternativer

Kickers

Heads

Leads

Openings

Illustrations

Intro historie

Hva jeg vil si

Artikkel: Problemet med å trykke penger når det ikke blir inflasjon

Notater

How to deal with the zero lower bound problem (ZLB)

Gjeldsvekst

Working age population

Interessante fakta

Interessante artikler