HN user

putterson

47 karma
Posts0
Comments14
View on HN
No posts found.

I think the challenge with making such small screws would be mostly around

- Making your own or acquiring cutting tools that fit in such spaces, e.g. able to thread up to a shoulder at that scale.

- Measuring your progress. I'm really not sure how you'd measure pitch diameter for such a small screw without exotic measuring tools. Perhaps you would just cut it to fit the mating part, which on it's own would still be difficult to check due to the subtlety of the feel of such a small screw going in.

- Cutting internal threads. I imagine making your own M0.6 tap would be quite tricky as you'd have to grind very small reliefs after making an M0.6 screw.

Definitely not using coolant on parts this small; small amounts of lubricant if anything. Supporting the part shouldn't be much of a challenge as you would be taking requisitely small cuts with very small forces. I'm sure tweezers and loupes/microscopes are your friend when making watch parts.

I found it striking how similar the system that I have settled into is to yours, and also the similarity of the benefits that you ascribed to it. I love having my /home/name/tmp folder and being able to delete everything in it without worry when I find it becoming a bit crowded. I find that it takes care of most things I don't need but there are a lot of small projects and downloaded libraries that sit in my programming projects directory that are more difficult to delete. All in all I find the organization very relaxing and passive. Roughly the buckets I have are: - Downloads - Documents - workspace (programming projects) - tmp

I applied a technique for quickly finding exact k nearest neighbors or nearest neighbors in a specific hamming distance using research[0] which includes a library + source code. The largest dataset that I tested was 10M 256 bit codes but the technique scales well with larger datasets. You can look at the performance figures I achieved in my paper at [1]. [0] http://www.cs.toronto.edu/~norouzi/research/mih/ [1] https://github.com/putterson/undergrad-thesis/raw/master/mai...

This makes me wonder what those two holes in the shroud of USB A style connectors are for. After a bit of googling it looks as if they are to provide a bit of tension against removal. I'm sure you could repurpose them to lock the usb drive into a USB port.

I wrote a MCTS Ultimate tic-tac-toe engine[0] over the last little while, and likewise don't know how to play the game well. Once thing I have been mulling over in my mind but haven't really explored is training an NN on the game tree produced by long searches and somehow extracting strategies a la DeepDream. I don't have much experience with NNs though so no idea if it even possible or what the extracts would look like.

If anyone would find this interesting work to collaborate on feel free to contact me. The MCTS part is done.

0. https://github.com/putterson/uxobot

I agree with you that these particles should be studied for their potential health and environmental impact, but combustion has been around much longer than humanity. I think that not all these particles are made equal and that being said I don't think that the nanotubes found in this study are much like what we are trying to create for technological purposes. They are probably very short/small and the article mentioned "[these] nanotubes are unlikely to have the cancer-causing potential of asbestos fibres, which are much larger and can get trapped in the lining of the lung." I believe their impact should be studied but there are also many other combustion products that probably have a larger negative impact.

Yes, it would be, but interestingly I didn't interpret it that way. I'm not sure what the author intended but while reading I imagined malware using this technique for obfuscation, and the inability to run this code in virtual machines would also hinder the analysis of such malware. Goes both ways I suppose.

Well this datastructure lets us find the k nearest neighbors in Hamming space (think binary vectors in binary vector space) quickly. If we can map features (for simplicity lets think of images) to points in hamming space such that similar features have a small hamming distance then we have a fast way of finding similar images. That is the problem that this paper proposes to help with, but I could easily see this also applying to sound clips or other media, though my imagination is not that great. When I used this code I applied it to the problem of image matching using binary codes generated by a feature detector [1]. The benefit of using binary codes over traditional floating point vectors is they are much faster to compare. [1] http://docs.opencv.org/modules/features2d/doc/feature_detect...)

I used this paper and associated code in my undergraduate thesis. After decoupling the C++ code from MATLAB I was able to make it into a library and use it to search binary features instead of the floating point features hashed with Locality Sensitive Hashing, giving an exact k-NN instead of approximate. The code was fast but the benefits really manifest with large numbers of codes (pretty much what we want). Contact me if you would like to see the performance of this code for various m and image corpuses, or the rest of my paper.

EDIT: also it's probably best to link to the homepage for the paper: http://www.cs.toronto.edu/~norouzi/research/mih/ and the code: https://github.com/norouzi/mih/

Actually, I really enjoy using Groovy as a Java REPL, when having to use Java. Your code is run in a Script class

Most java code is valid Groovy code and it has some nice dynamic features, syntax sugar and has closures. I am currently using it to hack together a small DSL to easily configure a transformation from XML -> CSV

Here's an example of a Groovy session (From my instance of IntelliJ IDEA through Tools -> Groovy Console)

  > P = "Hello world!"
  Hello world!
  > sub = P.substring(5)
  world!
  > sub ==~ / wo.+/ ? println("World") : {}()
  World