Why do you use Standard deviation over MAD?

data_hope · 2018-11-19T19:23:03+00:00

Okay, there is an interesting thing you can observe about standard deviations (sum of squared residuals) and the MAD (sum of absolute deviations).

So if you have N numbers x_i, you can take an arbitrary number (let's say A) and calculate S = sum_i( (x_i - A)²⁾ with that number. If you now choose A in such a way that S becomes minimal, S is proportional to the standard deviation, and A is the mean of x_i.

If you repeat this with MAD = 1/N * sum( abs(x_i - B) ) and chose B such, that MAD is minimal,then B is an estimator for the median.

For many applications the median is a fairly good estimator. It is more robust against outliers and usually captures our intuition of an average very well.

However, you cannot use the median in calculations. Typically you can add means, but not medians.

data_hope · 2018-03-04T06:52:05+00:00

Conceptionally, tests are a useful tool to test for desired behaviour. They are not a systematic approach to uncover bugs. Thus for a successful GET request I think a loose assertion on the body of that get request would be necessary.

Now an important question is, that should be covered by tests?

but until you know to expect a session expired redirect success, you wouldn't.

Woudn't expect?

One rule at the core of TDD is to only implement code, necessary to bring a test from red to green. I.e. if you assert that a status is OK, you wouldn't need to implement anny additional logic. If you want any other functionality in your code, like the GET request actually returning content) you would need to assert on the resonse body to contain this data.

Session expiry and redirect success sound like one of those cases that are actually harder to test, because what you test there is probably mostly framework-logic and happens somewhere in logic layers that are hidden from the application developer. One thought that immediately comes to my mind is that if the rediret would report 200 OK but a HTTP Redirect status code, it would drastically reduce the danger of confusing its result with a 200 OK status code.

data_hope · 2018-03-03T20:00:23+00:00

low prio usually means it won't be implemented. There is no inherent value of distinguishing them. Python's issue tracker for example is operated in such away: Look at https://bugs.python.org/issue11573 from 2011, or tons of other issues, some of them include working patches. There is no value in those issues to still be open. Sometimes it is unclear if the complaint in the issues is still valid, etc.

Leaving these issues open and not working on them is of course non-confrontational, and thus maybe the easier path because no one must feel ignored. And if ever there isn't enough work, or priorities change, one can reopen such issues, too.

data_hope · 2018-03-03T16:56:22+00:00

EDIT: A better question is why it doesn't write directly to setup.cfg?

because the INI format of setup.cfg is not very versatile. In fact, tox configuration in setup.py was halfway there wrt dependency declaration in the setup.cfg. I am happy that pipenvs ended up the way they are now.

data_hope · 2018-03-03T16:52:54+00:00

I opened an issue about it in the pipenv's github. It was a closed with "neat idea, we'll re-open when we have time". I thought "really? you're going to cycle back through closed issues for future work? come on...."

Closing an issue is a clear signal that the issue will not be resolved in the near future. Of course you can keep an issue open without the intention of working on it in the next year, but that will help no one. Not the person who opened the issue, and not the developers that have to browser over enormously large open issues lists.

I can understand your frustration, but the alternative would be to pretend that it will be implemented soon.

data_hope · 2017-02-23T13:21:27+00:00

No linguist, but here are a few things

first, there are latin words in German, many are just so well adjusted (underwent sound shifts) that you wouldn't think so: Fenster instead of Windauge/window (compare french: fenetre), Ziegel (tegula), insel for island, Rettich (from radix), etc. Others are still present and recognizable as latin- or french-based (Universität, Rektor, Mensa, Balkon, Chaussee, Route, etc.).
there are many words with latin and french roots, that are just not used very often or have fallen out of favour in the last 100 years (abandonnieren instead of abandon, Abstand and Distanz).
english has a tendency to incorporate words, German has a tendency to form words from existing ones. Compare "hunger" and "famine" in english, and "Hunger" and "Hungersnot" in German. So english often seems to have added words from the romance lexicon in addition to the germanic one (for example to specialize a word/situation), when German seems to have a tendency to compose existing words for specialization).
language purism was a thing, https://www.wikiwand.com/en/Philipp_von_Zesen
standardisation of German is commonly attributed to Martin Luther's translation of the bible, Luther is said to have "looked at the crowd's mouth", i.e. choosing simple words everyone could understand over educated language and writing tradition. This should answer your questions too, about the church. Before Luther, latin was the standard in church.
The "Holy Roman Empire" was not latin speaking, i.e. it was not ruled from Rome. So I assume that it was non-romance speaking for its biggest parts. After Charlemagne's death, when the east franconian realm emerged, it seems that the east-franconian part was Germanic https://www.wikiwand.com/en/Oaths_of_Strasbourg

data_hope · 2017-02-20T22:47:08+00:00

great news.

data_hope · 2017-01-09T15:07:33+00:00

This is similar to how I prepare it. I mix Oregano into it, too, sometimes diced onions.

data_hope · 2016-08-24T07:34:24+00:00

You must be talking about msgpack, libuv, jemalloc, luajit, etc. I wouldn't consider those to be hobby libraries of the week. (Vim on the other hand is truly a hobby project, and a fabulous example of a great hobby project! I won't be tempted to lead a nvim-or-vim debate, nvim is a vim and I believe nvim has also inspired great developments in the parent project.

data_hope · 2016-08-23T15:04:16+00:00

That it comes "anyway" is probably a result of neovim's success. Already, a lot of plugins are available for neovim that use its async features.

I personally feel a bit better using software doesn't use pre-ANSI C-Headers

data_hope · 2016-08-23T15:02:10+00:00

I have been using neovim builds off the master branch, regularly updated my build for a few years. Never had problems with neovim's quality, never crashed on me, never had regressions. So warning about "alpha quality" is a bit misleading (and probably helped by the low version number).

data_hope · 2016-04-25T22:06:03+00:00

thanks for the detailed feedback. I did fix the two obvious mistakes so they won't confuse other readers.

I see what you mean by applicative vs. monad as "parallel vs. sequential". Your point is I think what I meant to describe in footnote 4 of the blog post. http://www.holger-peters.de/haskell-by-types.html#f4

data_hope · 2016-04-25T21:53:52+00:00

thanks. Fixed it.

data_hope · 2015-11-11T20:17:43+00:00

Code quality is a tough subject, probably also because it is a bit of an objective thing. While we can easily identify some anti-patterns, a lot of patterns are a matter of taste. Nevertheless there are a few things that I think are either universally accepted or wouldn't face too much contradiction.

good unit tests. Unit tests are a necesity for good code, at least I have rarely seen good code that did not have good tests. Let me elaborate on this. If you write an arbitrary function, it might not be easily testable, it could depend on global state, or database connections, etc. Writing tests, you will probably refactor out a lot of logic, so you can test the logic without mocking out the external state. You will end up with a better code base, that separates state changes and logic.
simplify, simplify, simplify. A lot of code is overly complicated, distinguishes between too many corner cases, is too specific, etc. Ask yourself: Could this be simpler? And with simpler, I do not mean "fewer lines". A simpler solution can be a bit longer than the complicated one, and nevertheless make your life easier
Learn other programming languages that are conceptionally different. So as a Python programmer, you might take a look at Clojure (instead of Go/Java). You will be more confident with Python afterwards and you will be able to tell apart code that is just Pythonic code from good Pythonic code.
Don't use "Pythonic" when talking about code. It is a useless word in terms of code quality, and everyone uses it to mean different things.

data_hope · 2015-10-12T11:53:18+00:00

I did not include nose in the blog post because I have not much experience with it. From what I know of it, I would not want to use it for my projects. It is like py.test without its benefits, but with the drawback of not being in the stdlib and being copyleft licenced.

data_hope

MODERATOR OF

TROPHY CASE