4 ms·

Clicking through to the relevant github: https://github.com/udexon/5CSM/tree/master/SMOCL?fbclid=IwAR2-1oq_y-d3SeHVbLMr1WHqjuj_t9armmTcLOU4bINBJPwmZa91WbpfddE

Clicking through to the relevant github: https://github.com/udexon/5CSM/tree/master/SMOCL?fbclid=IwAR2-1oq_y-d3SeHVbLMr1WHqjuj_t9armmTcLOU4bINBJPwmZa91WbpfddE https://github.com/udexon/5CSM/tree/master/SMOCL?fbclid=IwAR... This is gibberish. > I also coined the name Inverse Shunting Yard Algorithm (ISYA) to describe the operations of [the system]...In my not so humble opinion, ISYA might be the most significant algorithm since [the Shunting Yard algorithm] -- as it can potentially "unify" ALL programming languages: Programmers need only to write programs in Forth-like reverse Polish notation; using nSM, the program written in RPN is translated into the host programming language and executed. This has immense implications on beginners learning programming languages, as well as large teams, as using RPN helps to consolidate codes written in multiple programming languages. This just in: it's possible to represent a syntax tree in different ways. > The main motivation lies in mobile GPU cryptocurrency mining. By rejecting OpenCL, Google has caused a huge unfortunate side effect -- tens of millions if not hundred of millions of Android mobile phone with GPU effectively become underutilized...[This project will]...utilize the hundred of millions of GPU in Android phones, especially for cryptocurrency mining. [It] will provide the much needed Forth-like interactive development enviroment to develop cryptocurrency mining programs ON THE MOBILE DEVICE ITSELF, as well as potential novel optimization schemes, as described below. Ah, yes, that's just what the world needs -- a way to make sure your phone is so hot and power-hungry at all times that you can fry an egg on it. > Forth code optimization is a manual process, while C code optimization is a black box, automated process based on algorithms written by compiler developers...[This project] can make C code optimization a manual process like Forth, opening up the black art of code optimization to a wider audience. Don't you just hate it when your compiler makes the right choices for you? Wouldn't you rather have to manually allocate registers every time you build your binary?

heavenlyblue 8y ago
A few years ago I had an encounter with a guy on Quora who was claiming to have invented a way to reverse SHA-256 used in Bitcoin because you can use a SAT solver to do so. He claimed to having done so. I was not entirely sure if he had a condition or if he was just trolling. He was technical enough to put the arguments in a way that essentially looks absolutely plausible for someone who is not familiar with the problem. He's still a puzzle to me.
- TomMarius 8y ago
  There is a similarly crazy person who's moderately famous in my country - he claims he has "a much better instant search algorithm way faster than Google", but sadly because of the mafia and the Illuminati and probably also the Jew-freemasons no one wants to give him capital. He is also smart enough to seem to know what he's talking about, knows hard facts about common search algorithms and actually can code. I wonder how does that happen - he is not even trying to foul investors.
  - DiabloD3 8y ago
    I think I've heard of this guy, but theres probably more than one. They describe how to search faster, not produce results faster. Whats really silly is, its already as fast as it needs to be: Google has long since admitted their bottleneck isn't reading all the websites and parsing them (they could point their entire Death Star-esque amount of raw network and disk bandwidth and DDoS the entire Internet at once, every single indexable webserver)... Its actually storing them coherently in their database(s). They have to store them before they can process them (thus reading them back while other storing is happening), and then reading their OTHER database of searchable metadata. Databases Are Hard(tm). Next gen databases like Spanner and BigTable didn't get invented because reading websites was hard (where "better search algos" fits in), but because coherently handling a large database of said fetched results was hard. Actually, it isn't even Databases Are Hard(tm), its the Laws Of Physics Are Hard(tm). 90% of whacko claims I can dismiss because either that, or I'm reasonably sure P != NP.
    - deleted 8y ago
      [deleted]

heavenlyblue 8y ago

A few years ago I had an encounter with a guy on Quora who was claiming to have invented a way to reverse SHA-256 used in Bitcoin because you can use a SAT solver to do so. He claimed to having done so. I was not entirely sure if he had a condition or if he was just trolling. He was technical enough to put the arguments in a way that essentially looks absolutely plausible for someone who is not familiar with the problem. He's still a puzzle to me.

TomMarius 8y ago
There is a similarly crazy person who's moderately famous in my country - he claims he has "a much better instant search algorithm way faster than Google", but sadly because of the mafia and the Illuminati and probably also the Jew-freemasons no one wants to give him capital. He is also smart enough to seem to know what he's talking about, knows hard facts about common search algorithms and actually can code. I wonder how does that happen - he is not even trying to foul investors.
- DiabloD3 8y ago
  I think I've heard of this guy, but theres probably more than one. They describe how to search faster, not produce results faster. Whats really silly is, its already as fast as it needs to be: Google has long since admitted their bottleneck isn't reading all the websites and parsing them (they could point their entire Death Star-esque amount of raw network and disk bandwidth and DDoS the entire Internet at once, every single indexable webserver)... Its actually storing them coherently in their database(s). They have to store them before they can process them (thus reading them back while other storing is happening), and then reading their OTHER database of searchable metadata. Databases Are Hard(tm). Next gen databases like Spanner and BigTable didn't get invented because reading websites was hard (where "better search algos" fits in), but because coherently handling a large database of said fetched results was hard. Actually, it isn't even Databases Are Hard(tm), its the Laws Of Physics Are Hard(tm). 90% of whacko claims I can dismiss because either that, or I'm reasonably sure P != NP.
  - deleted 8y ago
    [deleted]