Building fasttext with Visual Studio

While working on classifying knowledge management documents needed word embedding, and this required me to build fasttext on windows using visual studio, as cmake was not available.

Here’s a visual summary of the steps with few things I faced while building fasttext with visual studio 2013.

 

 

 

 

 

 

 

 

 

 

 

Error    4    error C2146: syntax error : missing ‘;’ before identifier ‘size’    d:\project\fasttext-master\fasttext-master\src\utils.h    19    1    fasttext

Error    5    error C4430: missing type specifier – int assumed. Note: C++ does not support default-int    d:\project\fasttext-master\fasttext-master\src\utils.h    19    1    fasttext

Error    6    error C2061: syntax error : identifier ‘int64_t’    d:\project\fasttext-master\fasttext-master\src\utils.h    20    1    fasttext

Error    7    error C2146: syntax error : missing ‘;’ before identifier ‘size’    d:\project\fasttext-master\fasttext-master\src\utils.cc    18    1    fasttext

Error    8    error C4430: missing type specifier – int assumed. Note: C++ does not support default-int    d:\project\fasttext-master\fasttext-master\src\utils.cc    18    1    fasttext

Error    9    error C2086: ‘int fasttext::utils::int64_t’ : redefinition    d:\project\fasttext-master\fasttext-master\src\utils.cc    18    1    fasttext

 

Error    11    error C2061: syntax error : identifier ‘int64_t’    d:\project\fasttext-master\fasttext-master\src\utils.cc    23    1    fasttext

Error    12    error C2065: ‘pos’ : undeclared identifier    d:\project\fasttext-master\fasttext-master\src\utils.cc    25    1    fasttext

Error    24    error C2039: ‘iota’ : is not a member of ‘std’    d:\project\fasttext-master\fasttext-master\src\productquantizer.cc    115    1    fasttext

Error    25    error C3861: ‘iota’: identifier not found    d:\project\fasttext-master\fasttext-master\src\productquantizer.cc    115    1    fasttext

Error    26    error C2039: ‘iota’ : is not a member of ‘std’    d:\project\fasttext-master\fasttext-master\src\productquantizer.cc    134    1    fasttext

Error    27    error C3861: ‘iota’: identifier not found    d:\project\fasttext-master\fasttext-master\src\productquantizer.cc    134    1    fasttext

Error    55    error C2039: ‘iota’ : is not a member of ‘std’    d:\project\fasttext-master\fasttext-master\src\fasttext.cc    207    1    fasttext

Error    56    error C3861: ‘iota’: identifier not found    d:\project\fasttext-master\fasttext-master\src\fasttext.cc    207    1    fasttext

 

 

 

 

 

 

 

Advertisements

Patran Neutral Mesh File Writer updated

A recent comment from a blog reader made me relook at the patran neutral mesh file writer routine that I had on this blog.

Since the code was pasted on this blog, it lacked proper update and ability to have a test case or example file.

So spent this weekend, creating an example file and have uploaded the code and the example on github.

The entire writer is now availabe at https://github.com/sukhbinder/PatranMeshWriter

Hope to add and update the code more often. 🙂

 

Intersection Of two curves in Pure Numpy

Faced the following problem a few months back: Have two sets of curves in Cartesian coordinates, want to find if they intersect and where?

No straight forward solution was available, could find various solution using functions but none available with x, y coordinates.

Solution, found a matlab implementation that did just that, ported it to python. This is a pure python numpy implementation of interaction of two curves.

 

Example Usage:

Produces the picture at the start of this post. As always the entire code freely available at this github repo.

 

 

 

 

 

 

Leap

If I had an hour to solve a problem and my life depended on the solution, I would spend the first fifty five minutes determining the proper question to ask,for once I know the proper question, I could solve the problem in less than five minutes.—ALBERT EINSTEIN

But we leap.

Algorithm

For many people, the word “algorithm” evokes the arcane and inscrutable machinations of big data, big government, and big business: increasingly part of the infrastructure of the modern world, but hardly a source of practical wisdom or guidance for human affairs. But an algorithm is just a finite sequence of steps used to solve a problem, and algorithms are much broader—and older by far—than the computer. Long before algorithms were ever used by machines, they were used by people.

The word “algorithm” comes from the name of Persian mathematician al-Khwārizmī, author of a ninth-century book of techniques for doing mathematics by hand. (His book was called al-Jabr wa’l-Muqābala—and the “al-jabr” of the title in turn provides the source of our word “algebra.”) The earliest known mathematical algorithms, however, predate even al-Khwārizmī’s work: a four-thousand-year-old Sumerian clay tablet found near Baghdad describes a scheme for long division.

But algorithms are not confined to mathematics alone. When you cook bread from a recipe, you’re following an algorithm. When you knit a sweater from a pattern, you’re following an algorithm. When you put a sharp edge on a piece of flint by executing a precise sequence of strikes with the end of an antler—a key step in making fine stone tools—you’re following an algorithm. Algorithms have been a part of human technology ever since the Stone Age.

From the book Algorithms to live by Brain Christian and Tom Grifiths

The Best Debugging Tool of All

Rob Pike (one of the authors of the Go language) has this to say on debugging…..:

A year or two after I’d joined the Labs, I was pair programming with Ken Thompson on an on-the-fly compiler for a little interactive graphics language designed by Gerard Holzmann. I was the faster typist, so I was at the keyboard and Ken was standing behind me as we programmed. We were working fast, and things broke, often visibly—it was a graphics language, after all. When something went wrong, I’d reflexively start to dig in to the problem, examining stack traces, sticking in print statements, invoking a debugger, and so on. But Ken would just stand and think, ignoring me and the code we’d just written. After a while I noticed a pattern: Ken would often understand the problem before I would, and would suddenly announce, “I know what’s wrong.” He was usually correct. I realized that Ken was building a mental model of the code and when something broke it was an error in the model. By thinking about *how* that problem could happen, he’d intuit where the model was wrong or where our code must not be satisfying the model.

Ken taught me that thinking before debugging is extremely important. If you dive into the bug, you tend to fix the local issue in the code, but if you think about the bug first, how the bug came to be, you often find and correct a higher-level problem in the code that will improve the design and prevent further bugs.

I recognize this is largely a matter of style. Some people insist on line-by-line tool-driven debugging for everything. But I now believe that thinking—without looking at the code—is the best debugging tool of all, because it leads to better software.

Updated Binary STL File Reader

A recent comment on the post titled binary stl file reader in numpy prompted me to revisit the code and while I was looking at it , I updated the same for code to view the loaded stl file.

The above picture shows the result.

The code as usual available on github from here

from binarySTLreader import BinarySTL,ShowSTLFile
h,p,n,v1,v2,v3=BinarySTL('bent_plate.stl')
ShowSTLFile(v1,v2,v3)