## Why Code Hero will save the American economy, and so should you

You are going to die.

Few try to change the world during their brief tenure, fewer still try to change it for the better. Few step into the arena and spend themselves for a worthy cause. From the moment you come kicking and screaming into this world, you’re dying. By the time you’re “educated” with a college degree, you’re already 1/4 of the way out the door. What side of human progress are you?

It’s inspiring to know people like Alex Peake. We’re all capable of being catalysts of change in our environments; what have you done to change the world this month?

## we are going to die

We are going to die, and that makes us the lucky ones. Most people are never going to die because they are never going to be born. The potential people who could have been here in my place but who will in fact never see the light of day outnumber the sand grains of Arabia. Certainly those unborn ghosts include greater poets than Keats, scientists greater than Newton. We know this because the set of possible people allowed by our DNA so massively exceeds the set of actual people. In the teeth of these stupefying odds it is you and I, in our ordinariness, that are here. We privileged few, who won the lottery of birth against all odds, how dare we whine at our inevitable return to that prior state, from which the vast majority have never stirred.
—Richard Dawkins

## Bjarne Stroustrup Talk at UMich Notes

Bjarne Stroustrop
2011年 11月 09日 星期三 17:18:36 EST
-------------------------------------------------------------------------------

Light-weight abstraction
- software infrastructure
- resource constrained

No one size fits all
- 1st to market
- If program fails, pepole die
- 50% overhead implies the need for another \$50M server farm

What we want
-------------------------------------------------------------------------------
Easy to understand

- Modularity
- No resource leaks
- Efficient
- Portable

Ghastly style

ugly -> cin>>val

Bad style is the #1 problem in real-world C++ code
- Many are self-taught

Mars lander
-------------------------------------------------------------------------------

Using *UNITS*

Speed sp1 = 100m / 9.8s // very fast for a human
...
Acell acc
...

Using operator ""s, operator ""m, operator ""kg -- Elegant!

Keep interfaces strongly typed
- avoid very general types
- int, double, ...
- Object....

Checking of trivial types finds trivial errors

void f(const char* p) {
f = fopen(p, "r");
....
fclose(f);
}

(*The number of bugs you have in your problem is proportional to the amount and
complexity of the code you have got.*)

RAII - resource acquisiion is initializiation

~File_handle() { fclose(p) } // destructor

RAII lowers the time you use resources compared to other strategy
- manually
- finalizer
- garbage collection, etc...

Not all resources are scoped

Most uses of scoped resource allocation is no exception-proof

std::shared_ptr releases its object at when the last shared_ptr is destroyed
std::unique-ptr is the same

Gadget g {n}; // No naked 'new' s!

-------------------------------------------------------------------------------
Range-checks on containers, no more overflows

Resource handles and pointers "smart pointers" address most memory leak
problems
-------------------------------------------------------------------------------
Use data types that integrate this into their behavior:

Moving large objets out of a function

Move the Matrix out
"steal the representation"

Use the Move Constructor in X11
class Matrix {
//
..
}

New X11
Not array -- because array is a chunk of memory

- no naked pointers
- no naked new or delete
- keep arrays out of interfaces (prefer containers)
- pointers are implementation-level details
- use unique_ptr and shared_pointer
- return objects "by-value" (using move rather than copy)

Vector vs List
To anwer this---
Know:
- complexity theory
- data structs.
- machine architecture
- *ran out of memory before list's advantage could show itself*
- Amount of memory used differ dramatically
- Memory access is relatively slow
- Implications

We *NEVER* hit the asymtote!

* Compactness
* Generic Code

Algorithms vs."Code"

Need to get to a more algorithmic version of code
-> gather example

A.K.A. C++ is becoming more like python

Low-level != efficient
-------------------------------------------------------------------------------

Don't lower your level of abstractionwithout good reason
Low-level implies
more code
more bugs
harder to understand and maintain

Inheritance
- When the domain concepts are hierarchical
- When there is a need for run-time selection among hierarchically ordered
alternatives

Type-Safe Concurrency

auto --> gets type of initializer

async() - pass arguments and return result
auto res1 = async(f, some_fec);
cout << res1.get();
get return value when you want it

-------------------------------------------------------------------------------
tldr;
C++ Style
Practice type-rich programming
- focus on interfaces
- simple classes are cheap - use lots
- avoid over-genral interfaces
Use compact data structures
- by default, use std;:vector
Have a general strategy for error handling
- By default, us exceptions and RAII
Prefer algorithms to "random code"
Rely on type-safe concurrency
Build and use libraries

Q&A
- What languages do you feel have features you would like to see in C++?
- Threads & Concurrency now in ISO std C++
- shipped in MS/GNU/CLANG compilers
"Not a science fiction tour -- all shipped"

## Leonardo DaVinci Quotes on Humility

A small patch of snow finding itself clinging to the top of a rock which was lying on the topmost height of a very high mountain and being left to its own imaginings, it began to reflect in this way, saying to itself: “Now, shall not I be thought vain and proud for having placed myself—such a small patch of snow—in so lofty a spot, and for allowing that so large a quantity of snow as I have seen here around me, should take a place lower than mine? Certainly my small dimensions by no means merit this elevation. How easily may I, in proof of my insignificance, experience the same fate as that which the sun brought about yesterday to my companions, who were all, in a few hours, destroyed by the sun. And this happened from their having placed themselves higher than became them. I will flee from the wrath of the sun, and humble myself and find a place befitting my small importance.” Thus, flinging itself down, it began to descend, hurrying from its high home on to the other snow; but the more it sought a low place the more its bulk increased, so that when at last its course was ended on a hill, it found itself no less in size than the hill which supported it; and it was the last of the snow which was destroyed that summer by the sun. This is said for those who, humbling themselves, become exalted.

Fables on plants (1275-1279)

My Ninjitsu teacher, Dan Morris said, “The difference between confidence and arrogance is humility”. I try to follow that path.

## Sceptre — My Uncle’s Epic 70s Rock Band

This is a picture of my Uncle Marc that was in the basement of his brother, Kevin.

## Dick Cheney’s new book will have heads exploding all over D.C.

Dick Cheney's new book will have some explosive consequences

## RE: Triangular Numbers – The Triangular Matchstick numbers on OEIS

Last week I made a post about Triangular Numbers. I posted a request for a new integer sequence on OEIS, which eventually got merged with an existing sequence, The Triangular Matchstick Numbers: https://oeis.org/A045943.

I love math.

Here are the Triangular Matchstick Number Formulas:

Recurrence Relation:

 a(0) = 0 a(n) = a(n-1) + 3*n 

Generating Function:
 a(n) = 3*n --------- (1-n)^3 

## Fun with Triangular Numbers + Triangular Corporate Logos

I’ve always been fond of triangular numbers [1] and found the pattern they create beautiful.

                         .
.   .
.   .   .
.   .   .   .
.   .   .   .   .
.   .   .   .   .   .
.   .   .   .   .   .   .
.   .   .   .   .   .   .   .
.   .   .   .   .   .   .   .   .
.   .   .   .   .   .   .   .   .   .
.   .   .   .   .   .   .   .   .   .   .

Embedded within are many a corporate logo:

Mitsubishi, Chase, Star of David, &c.

I wanted to find out the relationships between the dots and the possible lines drawn between them. For example.
If you have T_n, how many dots exist as a recurrence relation? How many lines can one draw between the dots for T_n?

           o
/ \  (T_2 -> n_2 = 3)
o - o

number of dots:
d_i = d_{i-1} + i
number of lines:
n_i = n_{i-1} + 3 * (i – 1)

I wrote some of it up in CLISP to check it out:
 ;; calculates numer of edges in triangular graph (defun nlines (i) (let ((prev (- i 1))) (if (eq i 0) 0 (+ (* 3 prev) (nlines prev)))))

;; returns number of nodes in graph
(defun ndots (i)
(if (eq i 0)
0
(+ (ndots (- i 1)) i)))

Now what if we looked at the triangular numbers with respect to a triangular array like Pascal’s Triangle? [2]
That is, how many operations need to take place in order to calculate the entire triangle?
; calcs number of operations for triangular arrays based on n
; nops = 6, i = 3
; .
; / \
; . . (nops 3) == 6
; / \ / \
; . . .
;
(defun nops (i)
(if (eq i 0)
0
(let ((prev (- i 1)))
(+ (nops prev) (* 2 prev)))))

I brute-forced the limit by just putting large numbers in and found out that the ratio between the number of dots and lines approaches 1/3 as i approaches infinity and the number of dots to the number of operations (in a triangular array) approaches 1/2 as i approaches infinity.

\lim_{i\to\infty} \frac{ndots_I}{nlines_i} = \frac{1}{3}
\lim_{i\to\infty} \frac{ndots_I}{nops_i} = \frac{1}{2}

Sources:

http://en.wikipedia.org/wiki/Triangular_number

http://en.wikipedia.org/wiki/Pascal’s_triangle

## An elegant pythonic solution to – TypeError: is not JSON serializable

So if you ever have to deal with python and JSON at the same time, I’m sure you’ve run into this problem at least once.  With Baybo, the typical example of this is failure for json.dumps to successfully coerce Decimal objects into strings (go figure).  Anyways, the solution to the error above is simply:

dictionary = {"key": "val", "foo": Decimal("8.88")}

dict(map(lambda x: type(x[1]) == "Decimal" and (str(x[0]), str(x[1])) or (str(x[0]), x[1]), dictionary.items()))

Let’s break that down a bit

dictionary.items() => [("key", "val"), ("foo", Decimal("8.88"))]

lambda x: lambda x: type(x[1]) == "Decimal" and (str(x[0]), str(x[1])) or (str(x[0]), x[1]) => ("foo", "8.88")

map turns it all into [("key", "val"), ("foo", "8.88")] if it is in fact a Decimal object, otherwise leaves it alone

which we wrap up with a dict() => {"key": "val", "foo": "8.88"} and dump to json

'{"key": "val", "foo": "8.88"}'

voila! problem solved!

edit (2011-01-04): after looking over this again, I would like to comment that one *might* want to keep integers of type int, list of type list, etc. simply mapping everything to a string is a crufty hack at best. I’ve revised the code to adjust for this. type(x[1]) == "Decimal" and (str(x[0]), str(x[1])) or ... the ever useful and-or logic short-circuting which you may be familiar with if you’ve programmed in C or JavaScript.