The first AI universe sim is fast and accurate—and its creators don't know how it works Computer Science

---

• The first AI universe sim is fast and accurate—and its creators don't know how it works
• A different way to look at factoring
• How E-Commerce Sites Manipulate You Into Buying Things You May Not Want
• Good Algorithms Make Good Neighbors
• Facebook Model Pretrained on Billions of Instagram Hashtags Achieves SOTA Results on Top-1 ImageNet - Medium
• concurrency computational models vs. concurrency patterns?
• Intensive mentoring in programming, feedback on code and answers on your questions

The first AI universe sim is fast and accurate—and its creators don't know how it works Posted: 26 Jun 2019 08:18 PM PDT submitted by /u/saiteja13427 [link] [comments]

A different way to look at factoring Posted: 26 Jun 2019 12:16 PM PDT Over the last few weeks, I spent a lot of time trying to think about different ways to factor integers. This method I found stuck out to me as unique, and I have not seen something similar to it. It's probably still much worse than the General Number Field Sieve though. I'm posting about it, because it made the problem seem so simple to me, and I thought others might think the same thing. Before explaining why/how it looks different, I first need to explain some simple math related to squares. (they're used a lot in other factoring algorithms too) The difference of two squares can be factored easily using operations from the Binomial Theorem x2 - y2 = (x + y)(x - y) So for example, 42 - 22 = (4 - 2)(4 + 2) = (2)(6) = 12 Which should easily show how squares can be very useful when attempting to factor an integer. (common knowledge) One of the first things I was able to find/discover myself is that there's actually a very simple way to convert any integer to this form. xy = ((x + y)/2)2 - ((x - y)/2)2 Some more examples (because this really is amazing to me) (15)(1) = ((15 + 1)/2)2 - ((15 - 1)/2)2 = (16 / 2)2 - (14 / 2)2 = 82 - 72 = 15 and (7)(3) = ((7+3) / 2)2 - ((7 - 3) / 2)2 = (10 / 2)2 - (4 / 2)2 = 52 - 22 = 21 After going over that... The factors that can be obtained from squares are always the same as the ones that created it. For example: (15)(1) = 82 - 72 = (8 - 7)(8 + 7) = (1)(15) But from above, it can be observed that factors of an integer have their squares appear before the most trivial squares. So the only thing that needs to happen is to reduce the squares. There is the Pell Equation that does something kind of like this, but it's complicated and in the wrong form... However, there actually is a really simple way to reduce squares too. For example 15 = 82 - 72 82 product 72 product 82 + 16(0) 0 72 + 14(0) 0 72 + 15(1) 15 62 + 13(1) 13 62 + 14(2) 28 52 + 12(2) 24 52 + 13(3) 39 42 + 11(3) 33 42 + 12(4) 48 32 + 10(4) 40 32 + 11(5) 55 22 + 9(5) 45 22 + 10(6) 60 12 + 8(6) 48 12 + 9(7) 63 02 + 7(7) 49 02 + 8(8) 64 Using that information we now have 42 - 12 = (4 - 1)(4 + 1) = (3)(5) = 15 And we have obtained the factorization. But even with knowing this, it's probably not going to significantly impact the speed for factoring integers, as it's still required to check a large amount of numbers before finding a correct match. Though, when it's written like this it does kind of remind me of subset sum/knapsack problem. Only a little easier... If you look closely at the table above from the bottom to top, it's easy to notice that each number is decreasing by the odd integers. 82 product 72 product 15 0 13 0 13 15 11 13 11 28 9 24 9 39 7 33 7 48 5 40 5 55 3 45 3 60 1 48 1 63 0 49 0 64 This really stuck out to me, and was actually why I titled the post the way it is. When it's written like this, it seems like a much easier problem to solve to me. Instead of finding a factor in huge set of numbers, the problem is just how much do two numbers need to decrease by so that they are equal. If only the required math existed for something like this. To anyone unfamiliar with math related to sums, there is a really easy way to get sums up to a certain number, but I haven't seen something that could solve a problem like this. If it is possible, then I would think that this problem would solvable in close to constant time. It's also easy to rewrite the odd sums as squares in relation to the squares at the bottom. This really doesn't change the original problem by much, besides provide a sort of bound that is visible. When looking at the math involved, it's still basically the same problem... just presented differently. Though, I didn't give up here either. I noticed a few more things: Products for all numbers that are equal are divisible by 16. (it's easy to remove odd numbers, harder to remove products that are divisible by a certain number.) The factors appear before going halfway up the list. The distance between the two matching columns equals the smallest factor of that number. The total distance up to the two matching values is a factor. There's actually an easy algorithm I found for skipping huge chunks of numbers. And I made a program for the last one. It does seem to be converging to something really fast... But estimating the complexity (or even time required) on this sounds miserable. (lookups are logarithmic, but the top of the search area can be estimated, and the bottom decreases. In the clip, I have it doing full lookups, so if it was changed, it would be faster. It's hard to accurately predict how much searches will jump) I'm highly doubtful it will perform better than something like the General Number Field Sieve. Anyway, I hope you found this interesting even if it doesn't improve on what is currently possible. submitted by /u/World177 [link] [comments]

How E-Commerce Sites Manipulate You Into Buying Things You May Not Want Posted: 26 Jun 2019 08:43 AM PDT submitted by /u/l_hazlewoods [link] [comments]

Good Algorithms Make Good Neighbors Posted: 27 Jun 2019 04:32 AM PDT submitted by /u/alexeyr [link] [comments]

Facebook Model Pretrained on Billions of Instagram Hashtags Achieves SOTA Results on Top-1 ImageNet - Medium Posted: 26 Jun 2019 08:34 AM PDT submitted by /u/Yuqing7 [link] [comments]

concurrency computational models vs. concurrency patterns? Posted: 26 Jun 2019 04:12 AM PDT Concurrent computational models includes actor model, CSP, Petri nets, etc. Concurrency patterns includes active objects, barrier, reactor, monitor, scheduler, etc What are the differences (and also maybe relations) between concurrency computational models and concurrency patterns? It is interesting to notice that wikipedia's Design Patterns patterns template lists "Actor model" under concurrency patterns. That makes me even more unsure about the question I asked above. I don't have much exposure to them, but concurrency models seem to be mentioned more often than concurrency patterns. Do concurrency patterns fall out of favor? Can different concurrency patterns and different concurrency models be used in a mix and match way, or are some concurrency patterns only used with some concurrency models? Could you recommend literature (book or articles) that can clarify the differences and relations between the various kinds of computational models and/or patterns for concurrency? Thanks. submitted by /u/timlee126 [link] [comments]

Intensive mentoring in programming, feedback on code and answers on your questions Posted: 26 Jun 2019 06:02 AM PDT I have setup a community a few weeks ago for people to find studybuddies, request exercises - and get feedback, get long-term mentoring, ask questions and hangout. This is for almost all languages. If there's a language missing, just hit me up! If you are interested, you're welcome. If you're not, well.. Sorry for this post then, hope you don't find it annoying it's all free! The link: https://discord.gg/bhSwuDS submitted by /u/ratataprogrammers [link] [comments]

You are subscribed to email updates from Computer Science: Theory and Application. To stop receiving these emails, you may unsubscribe now.	Email delivery powered by Google
Google, 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States