Live data from Hacker News

Think in Math, Write in Code

justinmeiners.github.io

251–256 of 256 posts

Re: Think in Math, Write in Code

#251
post #248

Earlier quoted context omitted.

That was the second part of my answer: a graph on paper. Draw nodes of execution and represent the branch as two arrows coming from the node and heading to new nodes. Label the arrows with the predicates of the branch. This is both definitely useful and definitely math.

> That was the second part of my answer: a graph on paper. Draw nodes of execution and represent the branch as two arrows coming from the node and heading to new nodes. Label the arrows with the predicates of the branch. Thanks! You don't happen to have some learning resources for modelling programs as state machines? I can't find anything when I search.

This isn't about modelling rather a programming technique, but check out Idris for its dependent typing. It lets you encode state machines in types, which means your programs literally will not typecheck if you try for example to withdraw money from an unauthorized ATM, or candy from an empty store. You can make verified network protocols and drivers like this.

Re: Think in Math, Write in Code

#252
post #248

Earlier quoted context omitted.

That was the second part of my answer: a graph on paper. Draw nodes of execution and represent the branch as two arrows coming from the node and heading to new nodes. Label the arrows with the predicates of the branch. This is both definitely useful and definitely math.

> That was the second part of my answer: a graph on paper. Draw nodes of execution and represent the branch as two arrows coming from the node and heading to new nodes. Label the arrows with the predicates of the branch. Thanks! You don't happen to have some learning resources for modelling programs as state machines? I can't find anything when I search.

This is more of a practical writeup on state machines than a theoretical one: http://gameprogrammingpatterns.com/state.html

You might also know these as flowcharts when applied to program flow control.

I don't think I answered the original question well. I just wanted to point out that math is more than just equations. Others have done a much better job in this thread.

Re: Think in Math, Write in Code

#253
post #249

Earlier quoted context omitted.

This is a great question. What I really tried to emphasize in the article is that math is not a formal language. Since its just you and coworkers, write out the parts you need as you need them, and ignore details. After all, its an exercise to help you think. If I needed uppercase I would just say: `up(s)` is a function that maps a string s to its uppercase string Writing that down, you and I already have a pretty go…

Thanks for the explanation! An example to check if I understood you correctly. `func1(r, s)` is a function that sends a request `r` to a given server `s`. It returns a status code from the server. How does that sound? It feels more like a spec than "doing math". > I highly recommend that book I linked in the article: "Introduction to Graph Theory" By: Trudeau I'll check it out! Does the book cover all the relevant pa…

Sort of. That would absolutely be "allowed". Now whether that is useful to write out, depends on what problem you are trying to solve.

Here is another example

https://gist.github.com/justinmeiners/0aff3d98a66b4d5f109656...

> Does the book cover all the relevant parts

No, it isn't quite so comprehensive, but it will absolutely help you get started and help you decide if you want to learn more.

https://www.amazon.com/Introduction-Graph-Theory-Dover-Mathe...

Re: Think in Math, Write in Code

#255
post #247

Earlier quoted context omitted.

Some people feel at home with APL (A Programming Language) or its descendants. It was first developed by Ken Iverson as a notation to be used on paper for communicating procedures and algorithms. It was the subject of a book published in 1962, then became a programming language running on IBM mainframes in 1966. The following line of code produces all the prime numbers below the value R. (~T∊T∘.×T)/T←1↓⍳R More histor…

A fairly precise raw Python translation for the interested: T = range(1, R)[1:] # T←1↓ιR u = [[t*u for u in T] for t in T] # T∘.×T v = [t for ei, t in zip([any(t in ui for ui in u) for t in T], T) if not ei] # (~T∈u)/T As the standard poem on the subject by Dave Touretzky and Don Libes says: I wrote some hacks in APL, each on a single line. They're mutually recursive, and run in n-squared time! In this case, of cours…

I realize now that the first line should say range(1, R+1)[1:]. We regret the error.

Re: Think in Math, Write in Code

#256
post #195
post #8

There's an unpopular and somewhat seemingly contradictory opinion that I have regarding this, because this isn't the first time I've seen this topic brought up. Mathematics and programming are not really all that related to each other and I think there's an overemphasis on the importance of math in programming for 99% of applications. Sure, mathematical thinking can be useful, but it's only one type of logical thinki…

I agree with you. There's a popular book they recommend around here for learning linear algebra, which they say its very related to coding. I found it to be not the case. Upon reading the first chapters I started wondering how could this be useful for coding. So I jumped to one of the last chapters where they show you practical applications. Upon reading those I thought: "I can do all this in code just fine without u…

Which books is this? Sounds like something I might want to check out. Thanks!
Post reply on HN