HN user
Nop, the article is false about this. The optimal algorithm is O(n) as you can make a simple regular expression that is the Kleene star of an or of all the words in your dictionary to match the input. This is allowed as you can choose how to implement the dictionary, it don’t take more space than a trie and match in linear time as it can be compiled to an NFA or a DFA.
It works the other way, the shooter position is fixed as well as your position. Your are allowed to place a finite amount of blockers to make your position safe. The video comment say that it is always possible to make your place safe with at most 16 blockers. There is a link to the actual code used.
There is nothing here close to sign language translation. Hand gesture are a very small and quite easy part of sign language who involve all the upper part of the body and face and use a lot of context and placement in space.
But I'm in their target market and I don't want a replaceable battery. I just want the battery to be serviceable when it wear.
For a given phone size, a replaceable battery require some additional space which means it will be smaller than a non-replaceable one.
I don't want to buy one or two additional battery to carry with me when I can get a battery that last a bit longer and that I can charge with any power bank. (mine or the one of a friend as there is no compatibility problems)
Users who want replaceable battery are niche in the niche.
Then, how do you explain that the last update improved performance a lot on older devices ? Last time I've checked there was no hardware upgrades in the downloaded update...
Your data are sold by the second party. The first party give them for free most of the time...
This si full FUD and I don’t known the author objective. Those satellite will be in low orbit where one of there big problem will be to keep theire orbit. Their end of Life depend on how much fuel they have, and when they have no more fuel they decay. Or takes only some months (or at most a des years for the ones in higher orbit) to burn in the athmospher.
The only problem Witness so much satelite in low orbit si tracking them during their life which us easy for thoses as they require precise tracking for being operational.
But this device doesn't need a way for the user to enter the pincode. So, all the sensitive part of the terminal is probably completely isolated from the android part.
I don't know this device internal and the PED/PTS exact requirement but it seems plausible for me.
You have something like a physical compartment who include the NFC and everything needed to process it like in a classical terminal. This compartment is highly secured as requested by the specification with just a very simple interface for the android part to send the amount to bill.
I've seen a lot of each-machine running on windows. Doesn't they work like this with the windows machine just managing the display buttons to select the amount and sending this information to the secure part who handle card interaction, pincode and delivery of the money ?
This only accept contact-less payment who doesn't require pincode.
There is a lot of reason why you can prefer a linked-list over an array, even with the hardware changing they are still a lot more efficient in some cases :
* In multi-threaded context insertion and deletion can be done lock-free which is not the case for arrays ;
* For intrusive list, insertion and deletion can't fail due to memory allocation ;
* If you do only insertion at the tail and removal at the head these operation need only a pointer change which is more efficient than an array ;
* Merging two list is only one pointer operation ;
* Intrusive list have better memory allocation properties ;
* ...
The problem is that, on new hardware, linked list should be used in less cases that in the past and some people have generalized this to linked-list should never be used. This is false, if you care about performances you should keep thinking and testing what is the best data-structure in different cases. If you don't care about performances, you should use an abstraction who implement what you need and don't car about the underlying data-structure.
Or just browse the article with a mobile user-agent. Big site like this cannot cut themselves from big market like iOS or Android, so there is always a non-flash version available.
My nexus 9 have changed a lot the way I work. As a professor, my time is split between teaching and research. I still use my computer to prepare my lectures and a big part of my coding but, giving lecture, reading papers and taking notes are all done on it.
The combination of termux and SSH means than I can do some dev on it if I have the Bluetooth keyboard with me, it's not ideal but enough to not justify taking my computer with me for one our of coding in the day. The interactivity of being able to move through the classroom and ask students to write answers on a virtual whiteboard keeping the results and going back later to this is invaluable. For a lot of things I do with it, there seems to be only half finished poorly written applications and still it's a big improvement in my work
I truly wait for the day were we have good PDF library app with a reader that can take notes, a good whiteboard app that allow you to have an infinite canvas, ... but even now it changed my way to work for the better.
Thanks, it works perfectly now.
Do you plan to also make a version for 64bit ARM ? This one works perfectly on my Nexus 9 but I would love to be able to develop for ARM64 directly on it.
Thank you for your work, From what I see on the play store, you plan to make money with the extensions ? I will probably buy at least the theme one soon.
I've tryed it on a very simple makefile and after some testing found what trigger the message. It is simply a line with an "echo" command. It seems that make try to run it with "/bin/sh".
Very good ! Thanks.
There is still some problems, on my nexus 9 "make" complain that it doesn't find "/bin/sh" which is normal, is it possible to change this so it can find the provided shell ? And "ld" from binutils require gcc so it seems that it is not possible to work only with clang ?
Thanks a lot, it is the best solution to develop on my Nexus 9, it really shine again !
But "temporary" is a thing who exists only in theory. In practice its always never or (almost) forever. As soon as a few applications start using this "new" form of UTF-8, some of them may have to keep supporting it forever.
Why not directly going for the pre-2003 UTF-8 encoding ? It would even put a bit of pressure for restoring them and would show that this is the good way. It is also the only way I think to convince people to start implementing it.
This is the most stupid way to extend UTF-8 I've seen. The only acceptable solution is to remove the restriction of using only four byte per sequence which would allow to encode these easily keeping all the advantages of UTF-8.
Doing it like they does add an additional layer of encoding and so a lot of complexity a room for bugs.
It was probably made for compatibility but a lot of software will do bad thing with these new "surrogate" pairs so this solution is not really more compatible in practice. And updating software to handle UTF-8 sequence longer than 4 bytes is a lot more easier than updating them to handle such encoding.
You're the one who don't get it. This watch is very nice and non-blind people also wear it. For people like me with small wrist, this watch is very big and its a "shame".
We don't think its a shame that this watch is too big for all people, we just hope that a smaller model exist even if it is less readable for blind people.
Its your turn to think about what you wrote. You seem to think that this watch is reserved for blind people. Don't you think that non-blind may think this watch is beautiful and want one ? Do you really think that having a smaller model make impossible to also have the big one ?
But even if you don't install new apps, phones still call the play store regularly at least to ask for updates of the OS and the installed apps so they should be counted in the stats.
The original link I wanted to post is : http://tools.android.com/recent/androidstudio10released
But this is already posted here : https://news.ycombinator.com/item?id=8718353
But marked as dead so it will never be seen by a lot of people... Is there a proper way to handle this ?
Its probably for testing purpose. Its a big file of natural text so you can easily checks a lot of things with it and its a lot less boring than pages of lorem ipsum...
But, its funny that it is more than half of the full content in the git clone...
The improvement is only theoretical. The Fürer algorithm is quicker than Schönhage-Strassen only for impractical numbers and no arbitrary precision toolkit use it as far as I know.
The Fürer algorithm change the loglog term of the complexity to 2^log* which doesn't change anything in practice for workable numbers but it also add a lot to the constant term which is not counted by the big O notation but is very important in practice.
It is very easy to perform "123 * 456" but when each numbers have millions of digits it is a lot more complex. The naive algorithm require N^2 operation to multiply two numbers with N digits. This algorithm reduce this complexity.
The most simple "fast" algorithm is the karatsuba multiplication. If you want to do "12 * 34" using the classical algorithm you will compute "12 * 3" and add "12 * 4 * 10". This need 4 single digit multiplications. (the * 10 is a simple shift) Karatsuba algorithm say that you can do "13100 + (1-2)(3-4)10 + 2*4" and get the same result. This imply only 3 single digit multiplications. (again the multiplications by power of 10 are simple shifts)
Here the saving is small but if both of your numbers are N digits, you need 3 multiplication of N/2 digits that can be done recursively with the same algorithm for a final complexity around N^1.585 instead of N^2.
Instead of splitting each number in two, you can split them in more pieces and reduce further the complexity. For big but not so big numbers you use the Karatsuba algorithm or the various Toom-Cook splitting, but with very big number you switch to the Schönhage-Strassen algorithm who use the FFT. All these algorithms works by transforming the numbers in polynoms, compute their convolution and convert back to integer.
The Fürer algorithm is most efficient algorithm known for now but only theoretically, for pratical numbers we stick with Schönhage-Strassen. This paper introduce a new proof of the complexity of the Fürer algorithm as well as a few tricks to slightly improve it.
I fully agree with you but just want to add that you can do it in "pure" Lua :
for file in io.popen("ls "..dir):lines() do ... end
This should never be used in real applications and a proper filesystem module should be used instead. But, I find it very useful for quick one-shot scripts I write for batch processing some files.
There is some interesting things in this post but the main problem is not using Judy or something else, or talking about memory or complexity. The main problem I see here is using the wrong tool.
Replace the token matcher with a simple classifier (a maxent will work very well here) with n-gram of characters features through a hash-kernel and you get a very accurate, fast and low memory system.
I've build one two-years ago who accurately classified a bit over 100 different languages with only 64k features in the end. (So requiring only 8*64ko of memory) And this was without using file extensions as they weren't available in our case.
Before any hard optimizations, first check the methods used, and next the algorithm, anything else should go after.
You're joking, this was a wonderful machine. Especially the CDP1802 processor with its ability to use any register as a PC. I've very nice memory with this chip.
You clearly have no idea how big a problem DRM are for customers. I have no sympathy for anyone who use it.
Especially in this case where the DRM have totally screwed up the game, where EA have explicitly said people to ask for a refund, and denied it in the end.
Is it just me or is making a video for this is also ridiculous ?
On a webpage with this static image and text below I would probably have read all the text but here I stop after about 30s.
Please also think about non native speakers. If I read english without a problems, its very different when I hear it. I think this is quite common at least in computer science.
The important step I think here is that the developer not used the initial HTML prototype as a template when building the application. He just looked at it and produced code that output code who have a similar visual appearance but probably with different HTML structure who work well with the code.
If the code was written just to fill some holes in the original prototype, basically replacing some hard-coded strings, the developer would have less liberty on how to code lending to something less efficient and less elegant.
Just one request: please accept delivery to Europe (at least France) even with some shipping cost and I will join immediately.