By now, it is rather obvious that the Fed is determined to promote growth at the risk of having a runaway inflation.
Is it a sound policy?
I am never impressed by this obsession with growth. For example, Wall street expects the listed companies to grow continuously, ignoring the fact that there exists business cycle. Have you studied the “Constant Growth Model”? It is still a part of orthodox, formal financial education curriculum.
In order to fullfill this expectation, GE has to manipulate their accounting in order to smooth out their earning growth to satisfy the Wall Street analysts.
In making a choice between Growth Promotion and Inflation Control, it also highlights whom the Government and the Fed are serving.
Inflation control is in a way a self-imposed constraint of the Government and the Fed such that they will not impose tax implicitly on the public at large by printing money. Usually a low inflation rate is preferred because it allows the monetary base to grow with GDP without eroding the purchasing power of existing currency holder significantly.
However if the policy makers focus on keeping the momentum of growth of G.D.P., it is not clear who will ultimately reap the benefit out of this at the end. For example, employers, over the years, have mastered the art of boosting company profit at the expense of the worker by the means of layoff, or, the mere threat of doing so, to suppress the wage growth. General public does not get to share the fruit of the GDP growth.
Policy markers used to justify their pro-Growth decisions by saying that “A bigger pie feeds more people”. But as modern technology has dramatically improved the productivity, a growth in G.D.P does not necessarily translate to increase of payroll positions.
I think I can see quite clearly who are going to lose out in next few years as a result of this series of rate-cut by the Fed — the public.
Erlang Mailing List - String as List 3
This is the last installment of the digest of the topic of “String as List”.
Hasan Veldstra opined that lack of library support make string operation difficult. He was working on an Erlang Unicode string library based on ICU (http://www.icu-project.org/) for the past week, and expected to release an alpha version soon.
Zvi suggested that in the case of 64 bit implementation of Erlang, a “String as list” representation is wasteful.
Richard A. O’Keefe seems to be annoyed by this suggestion (and other comment on Lisp machine), and advocated that if space is a concern, the programmer can use an alternative representation such as binary.
Robert Virding clarify the leex (function token/2 and token/3) is re-entrant. However, yecc is not and must be fed with a completed list of token.
Dmitrii ‘Mamut’ Dimandt gave an example of why “string as list” is bad idea, because:
“This is only true for ASCII text. Non-ASCII gets screwed up badly.
lists:reverse(“text”) %% gives you “text”
lists:reverse(“текст”) %% Russian for text becomes [130,209,129,209,186,208,181,208,130,209] which is clearly not I wanted”
“This is what you should have in your list:
1> Text = [16#442, 16#435, 16#43a, 16#441, 16#442].
[1090,1077,1082,1089,1090]
You can convert it to utf8 for output
2> xmerl_ucs:to_utf8(Text).
[209,130,208,181,208,186,209,129,209,130]
And you can reverse it and convert that to utf8.
3> xmerl_ucs:to_utf8(lists:reverse(Text)).
[209,130,209,129,208,186,208,181,209,130]”
A positive message from Bjorn Gustavsson. He confirmed that is possible to use lists of Unicode characters easily. In Wings 3D, he have implemented a limited support for Unicode.
Joe Armstrong weighted in on 19 Feb. He suggested “One problem with strings unicode, regexps etc. is how you input the string.”. He proposed several new syntax to capture regex or xml string.
Basically from this point onward the thread has shifted gear into forward looking mood. The discussion now focused on the best way to represent a string in Erlang.
Erlang Mailing List - String as List 2
Zvi responded to Christian S’s “recommended large text mass handling modules”. He said, if for efficiency we represent a string as binary, the code will become too verbose. For example,
- <<“ABC”>>, instead of “ABC”
- <
< S1 / bytes, S2 / bytes>> instead of S1++S2 - using file:delete(binary_to_list(Filename)) instead of file:delete(Filename)
- xmerl and erlsom parse into lists and not binaries
Dustin Whitney concurred the verboseness, and recommend a new string type.
Bjorn Gustavsson responded to eariler Kevin Scaldeferri’s opinion on list inefficiency. He suggested, in the case of appending:
Christian S suggested an alternative to one of Zvi’s string-as-binary example (“ << S1 / bytes, S2 / bytes >> instead of S1++S2”):
Then focus of discussion shifted to a tool called Leex for a while.
Richard A. O’Keefe weighted in and expressed his opinion on a number of issues.
First of all, the String as list should not be dismissed as “historical reason” only:
Masklinn pointed out later that Java benchmark is off because the example is not using StringBuffer.
End of Part 2
Bjorn Gustavsson responded to eariler Kevin Scaldeferri’s opinion on list inefficiency. He suggested, in the case of appending:
“You can append by building a deep list and only flatten it at the end.
NewString = [AListOfChars|AnotherListOfChars]
or
NewString = [AListOfChars,ACharacter]
Or you can simply do a recursion (not tail-recursion) and use
the ‘++’ operator. That will be efficient, because the recursion will
ensure that the ‘++’ operators are executed in a right-to-left order.”
Christian S suggested an alternative to one of Zvi’s string-as-binary example (“ <
“[S1,S2] and then do iolist_to_binary/1 if you need it flat.”
Then focus of discussion shifted to a tool called Leex for a while.
Richard A. O’Keefe weighted in and expressed his opinion on a number of issues.
First of all, the String as list should not be dismissed as “historical reason” only:
He suggested the following rule of thumb for text handling
“it is simplicity (the preferred
sequence type in Erlang is lists, and strings are just sequences of
characters), power (because any time someone defines a function on
lists you get to use it on strings, and there are lots of useful
list functions), and processing efficiency (because working down
one character at a time doesn’t require allocating any new storage,
not even for slices).”
and some myth-busting on appending string performance issue:
“The guiding rule is
– if you just want to hold onto a string for a while, use a binary
– if you want to build or process a string, use a list (possibly in
Erlang a deep list).
– if you want to represent something that has structure, and you want
your program to be aware of that structure, turn it into a
structured
data value and work with it in that form.”
“Right, this is not efficient. But it is spectacularly
inefficient in programming languages with more conventional
representations.
It is O(n**2). For example,
x = ”“
for (i = 1; i <= 100000; i++) x = x “a” just took 30.5 seconds in awk on my machine, 62.2 seconds in Perl, and a massive 631 seconds in Java. That was using gcj; I lost patience with the Sun SDK and killed it. (AWK faster than Java? Yes, it often is.) Building the same string in Erlang using loop(100000, “”) where loop(0, S) –> lists:reverse(S);
loop(N, S) –> loop(N-1, “a”++S).
takes 0.15 second on the same machine.“
Masklinn pointed out later that Java benchmark is off because the example is not using StringBuffer.
End of Part 2
Erlang Mailing List - String as List 1
A discussion named “String as List” has been running, at the time of writing, for 6 days and 56 posts already. A lot of interesting idea and insight into Erlang were poured into this discussion. I simply want to write down some interesting technical points in this blog as a digest, as a reference.
It all started with a question from tsuraan:“Why does erlang internally represent strings as lists?”
First response from Masklinn, and actually many other contributors share the same idea:
“A lot of functional languages represent strings as lists rather than
arrays because lists are their basic collection datatype, and this allows the use of all the list-related functions on strings.”
Christian S put it in a shorter phrase: “historical reason”. As he pointed out, “internal” is not right word in the question because string was not a special type or abstraction built on top of list. A string is a list.
He then suggested the following module for handling large text:“– binaries (features representation that is 1:1 with the character
Then Kevin Scaldeferri throws in a different point: list is not a good representation because
encoding itself, now also (R12B) with efficient scanning and
tail-construction)
– iolists (features cheap concatenation of large texts)
– list of words and a word-dictionary (features quicker scanning of words, efficient storage too)”“First off, I append to strings a lot more than I prepend to them. Yeah, I
could work with reversed strings, but that’s a hack to deal with using the
wrong data type. Plus, I probably prefix match more often than suffix matching
(although this is less lopsided than append vs. prepend) …”
Now we have a diversion, Lev Walkin responded to earlier Robert’s post about that list is an ideal string representation because it can easily accommodate UTF-16 and UTF-32.“Small correction: UTF-16 and UTF-32 are practically dead, you certainly
Now we are going to have several threads going on under the same thread subject. Let’s get to it in my next blog. But for now I will ignore UTF-8 vs UTF16/32 discussions in order to focus on Erlang features.
need to think in terms of UTF-8 nowadays.”
End of Part 1
It is about summarization, so quote will be edited liberally for clarity, rather than reproduced word for word.
Oversocialnetworkisation
When I write this blog, I fully expect this information, given the exponential growing digital archive storage, will be kept for prosperity eternally.
As long as we can capture all these information in digital form of which, I can assure you, this tiny article is already in, then you, my dear reader, will always be capable of reaching this article, as long as you are so determined to know something about me.
The problem is: now since we remember so well, we are losing the ability to forgive and forget.
For example, some people made mistakes. Some people made mistakes occasionally, some people made mistakes all too often. We probably do not want to give forgiveness to perpetual liers, but we also should not dwell on one’s bad move, which could be a result of poor judgment or simply circumstantial.
But today, every records are digitized. We can crosschecked records in A against records in B. Past stories no longer faded into oblivion with time.
As if they are trapped in a perpetual time capsule whose accessibility, paradoxically, is just a mouse click away.
A new generation of offenders now are the all-reaching social networks. It expands, it keeps tracks, it feeds on your personal information. Your misdeeds, once made public, by your own hands or not, will be instantly available to the World, and can never be retracted.
Your friend and your acquaintance will never forget too.
Those who watched will remember, those who had not will attempt to find out, those forgot can search to refresh the memory.
How will this impact human collective EQ is yet to be seen.
But I am glad this gives me a legitimate excuse to create a new word: Oversocialnetworkisation.
(The only worry is: the above “manifesto” makes me sound a bit like the Unibomder…)