I was reading a book on the life of the italian Jesuit priest Matteo Ricci in China (1582–1610). During that period, he taught the chinese about the Art of Memory used in Europe and contributed some of the images from his memory palace for a book about the teachings of christianity in chinese.
A curious fact is the time that was necessary for a letter from China to arrive in Europe by means of the Portuguese and Spanish trade routes—seven years. Given that my e-mails can arrive practically instantly, I was baffled at the thought of waiting that long to get a response.
The Jesuits in China knew enough of the sea’s dangers to send each of their letters to Europe in two copies—one via Mexico on the Spanish galleons out of Manila, and one via Goa on the Portuguese carracks leaving Macao. Ricci’s superior Valignano may have been startled that one of his letters to Rome took seventeen years in transit from Macao, but Ricci accepted six to seven years as the norm for receiving an answer to a given letter.
This paper talks about how most introductory physics textbooks are awful and provide unrealistic approximations, with no comments on their applicability.
The observant student knows—from exploring the world—that golf drives rise quickly and almost straight and drop parabolically only near the end. This student learns that the world described by her physics textbook is not the real world and that careful observation is irrelevant to physics.
Contrast the experience of the curious student with that of a student who parrots equations and regurgitates textbook paragraphs. This student is untroubled by the golf problem or its variants listed in Table I because he knows the easily memorized ‘fact’ that all trajectories are parabolae. […]
If you ever took a physics class, I’m quite sure you recognize that teaching style. The following figure shows the trajectory of a gold ball considering air resistance, in case you’re interested:
Following my first post on books between the first quadrimester (Jan-Apr), here’s the list for May-Aug. There’s also a post on the books I read read during 2014.
I didn’t read as much as I wanted… but being able to measure how much I’m reading is nice, and I’m coming up with ways to improve on that, e.g. don’t read a book on Haskell and a treatise on Memory written by a historian in parallel.
(I’ve recently discovered that quadrimester is sometimes used as a synonym for quarter in english. Well. In 2016 I might try breaking it into Q1, Q2, Q3, and Q4.)
tl;dr: building features manually is inefficient and extracting them automatically is possible and, in a sense, better.
I’m not writing a lot here these days, so let me summarize: I left my job recently to start working on my Masters at Universidade of São Paulo (USP). I’m studying an area of Machine Learning called Deep Learning (or Representation Learning, the term I prefer) for my research. This post is an overview of what I’ve read so far about the subject.
(By the way, it is practically impossible to enter a PhD program in Brazil without a MSc.)
To engineer is human (see in Amazon or in Goodreads) is a 1992 book about how knowledge of past design failures is useful in current projects, strongly biased to civil engineering. Some examples are repetitive and not studied in depth, thus making the book a bit dull at times. Even then I found some very interesting reflections and quotes that I wanted to comment on or simply organize for later reviewing.
UPDATE: According to the comments of HellRazor, it is possible to play Rising Lands successfully with DOSbox. I added a new section explaining the method.
After reading the StarCraft II novels Heaven’s Devils and Flashpoint, I got back to playing StarCraft 2. I’m an awful player, but remembering the original StarCraft (and its expansion set, Brood War) made me think about games that impressed me when I was young. One of them was Rising Lands, a RTS set in a post-apocalyptic future in which Earth was devastated by a meteor collision and most technological knowledge was lost. (yes, cheesy, but trust me on this – it is good)
Na semana passada participei do RuPy Campinas. Há anos que não ia em algum evento de programação e foi divertido rever algumas pessoas e conhecer outras. :)
Deixarei aqui links para as apresentações que assisti.
I came across some curious Haskell tweets lately and decided to group them in a unique place.
These made me remember about a curious fact: did you know that there are other types of spaces in Unicode, like U+00A0, the no-break space? What about using it in Ruby? (please don’t)
Whenever I see someone talking about non-ASCII characters in programming languages, I always get back to APL, an old language that used extremely concise notation similar to mathematics itself. Due to most keyboards being horrible, it never caught on. :-(
(Mental note: having some kind of LaTeX math symbols embedded into a language for scientific computing would be… interesting.)
I work for a mobile games company as a data scientist. I use Ruby for data wrangling and some sorts of analysis, Python for more specific things (essentially scikit-learn) and bash scripts for gluing everything together.
The developers use Corona for creating our games, which uses Lua. I decided to give that language a try.
- Lua is tiny. As someone accostumed to Python and Ruby, it is shocking to see such a small standard library. For example, this is the manual – there are only 158 Lua functions listed there.
- The syntax is incredibly simple. Take a look at these diagrams; if you understand the Extended Backus-Naur Form, you can read Lua’s syntax quite easily. For comparison, Ruby’s syntax is complex enough that there are lots (and lots and lots) of small corner cases that I probably never heard about, even after years using it. Ah! And Ruby’s parse.y has 11.3k lines.
- Lua was built with embedding in mind; it is used for interface customization in World of Warcraft, for example.
- It is a Brazilian programming language! :-) Lua was created in 1993 in Rio de Janeiro, according to Wikipedia.
At my last job, I worked with data from the Brazilian educational system in several situations. The details aren’t the important part, but the format – a giant denormalized CSV with an accompanying PDF detailing its fields. It is very nice after you work with it for some time, but there are some things that could be better.
In that format, enumerations (fields with a fixed, finite set of values) are encoded as some arbitrary integer range, boolean values as 0 or 1, and other implementation details that are explained in the PDF. Thus far we have a cute CSV with documented fields. Nice, right?
Programming languages are possibly one of the simplest parts of software engineering. You can know your language from the inside-out and still have problems in a project — knowing the tool doesn’t imply knowing the craft. But learning a new language is really a lot of fun.
Inspired by Avdi Grimm’s roadmap for learning new languages, I decided to give it a try and put my current interests in writing.
- Julia – http://julialang.org/
I have experience writing code in MATLAB, Octave, Python (with Numpy, Scipy and Pandas) and a bit of R, and still I’m excited with Julia.There are at least 3 features of Julia that are powerful and make me wish to work with it: its Just-In-Time compiler, parallel for and the awesome metaprogramming inherited from LISP.
The drawback is… is… well, I didn’t have time to really use it and get comfortable writing Julia programs. Yet.
- Haskell – https://www.haskell.org/
I already tried learning Haskell a couple of times. Maybe 3 or 4 or 5 times. I wrote programs based on mathematics and some simple scripts, most of the syntax isn’t strange anymore, even monads make sense now; however, I still feel a bit stiff when writing Haskell. I don’t know.
Two books I recently bought might help with that – Real World Haskell and Parallel and Concurrent Programming in Haskell. I probably need to motivate myself to write something useful with it.
- Rust – http://www.rust-lang.org/
There is a quote in Rust’s website that sums my expectations of it:
Rust is a systems programming language that runs blazingly fast, prevents nearly all segfaults, and guarantees thread safety.
I know how to read C/C++ and even write a bit of it, but it’s messy and takes more time than I usually have for side projects. Writing code that is safe & fast shouldn’t be so hard. ;)
All-in-all, this is a very brief list. However, I don’t think I should focus on more languages right now. To be honest, I think that my next learning targets are in applied mathematics. I need a stronger foundation in Partial Differential Equations and Probability Theory. There are several topics in optimization that I should take the time to study. Calculus of variations also seems quite cool.
(good thing that I have friends in pure math to help me find references!)
Another year with SciRuby accepted as a mentoring organization in Google Summer of Code (GSoC)! The Community Bonding Period ended yesterday; the coding period officially begins today.
I’m really happy with the projects chosen this year; various different subjects and some would be really useful for me, i.e. Alexej’s LMM gem, Sameer’s Daru and Will’s changes to NMatrix.
That’s all. After the next GSoC meeting, I should write about how each of the projects are going.
Searching for your tools when you need to use them is bad organization.
Having a standard set of tools is a good thing. I have two toolboxes in my house, one for electronics and another for “hard” tools.
A voltimeter, a Raspberry Pi and an arduino.
Time and time again I forget that
Object#clone in Ruby is a shallow clone and end up biting myself and spending 30 seconds looking at myself asking what the hell happened. The only difference today is that I decided to finally post about it in my blog – let’s hope this time is the last.