Welcome, Guest |
Welcome to Makestation! We are a creative arts/indie discussion community — Your center for creative arts discussion, unleashed!
Please note that you must log in to participate in discussions on the forum. If you do not have an account, you can create one here. We hope you enjoy the forum!
|
|
the forum is being flooded with spammers!
|
|
the forum is being flooded with spammers!
|
|
the forum is being flooded with spammers!
|
|
the forum is being flooded with spammers!
|
|
the forum is being flooded with spammers!
|
View all updates
|
Online Users |
There are currently 403 online users. » 0 Member(s) | 401 Guest(s) Baidu, Google
|
|
|
Projects |
Posted by: Juneberry - February 11th, 2020 at 1:46 AM - Forum: Community Related
- Replies (2)
|
|
I'm a bit confused after looking at the Makestation Awards. How do we create a project to be even thought of for this award/in general?
|
|
|
Project Euler and Software Optimization (Problem 4 & Palindromes) |
Posted by: Darth-Apple - February 6th, 2020 at 11:16 PM - Forum: Software
- Replies (4)
|
|
I play around with Project Euler from time to time. These are programming problems that are designed to be difficult to solve, but not unsolvable with a modest computer hardware and a good algorithm. The trick is to come up with a good algorithm to do the job. Therein lies the problem. Algorithms are hard to design, especially if they are highly efficient.
I usually do these in Python. I also do very easy problems, and try to optimize them as much as possible. Python, unfortunately, is an interpreted language. It does not compile to machine code. As a result, average Python code is at least 10x slower than equivalent C code, and often slower.
That being said, my challenge to myself was to make this problem run as quickly as possible, and to make it run with relatively large numbers. This problem is based on Problem 4, but I've expanded it somewhat. Instead of using two three digit numbers to find a palindrome, it uses two numbers of arbitrary length. I've tested it with as many as 10 digits, and found that it runs in fairly reasonable time constraints.
My python code: https://www.dropbox.com/s/hoekt73ioovwq0...me.py?dl=0
This is technically an O (10^n)^n algorithm, so it is, quite literally, doubly exponential in runtime. As the number of digits increases, the runtime increases quite severely. I have yet to find a better algorithm to do the job, so I tried to optimize the one I had as best I could. I've asked as many math majors as I could. I've looked all over the internet for better ways of approaching it. I have yet to crack the problem. It seems like trial and error is the only way to really attack it, as least as of so far.
What this does to run faster: - I multithreaded this. The trick to doing this is to use processes instead of threads. This gets around the GIL lock that ordinarily prevents this, and allowed Python to properly use all available cores.
- The algorithm starts by checking the largest numbers first, as it only wants the largest palindrome possible. Generally, the factors of the largest possible palindrome are very easy to find at the top of the possible number range. By starting at the top, runtime is improved significantly.
- As it turns out, every single even-digit palindrome has a factor of 11. This algorithm only ever needs to check every 11th number, making it run ~11 times faster.
- It runs as a loop within a loop (hence the doubly exponential time). However, it assumes that the first factor will always be the larger of the two factors, since 997 x 993 == 993 x 997. Thus, if it checks a combination of numbers, it doesn't check the reverse of this combination, which would have the same result.
- If it finds a palindrome at 993 x 990, it cannot necessarily stop evaluating lower numbers. If, for example, 992 x 995 was a palindrome, it would be a higher palindrome than the first one would be. However, it has a heuristic to detect if there is possibly any higher palindrome than the highest one it has found yet, using only numbers it hasn't checked. As soon as it detects that no higher palindrome could be possible, it stops evaluating. This massively improved performance compared to the unoptimized code.
- It "guesses" on possible values to find the first palindrome. The highest palindrome is almost always made up of two factors that are very near the top of the number range that is given. As a result, it does not attempt to calculate 999 * (any number from 999 to 1). It stops at 999 * (some number around 900-990, depending on settings), and then moves on to 998 * (similar range as previous iteration).
- By "guessing" in the most likely range first, it almost always finds palindromes much more quickly. If "guessing" fails to find palindromes, it falls back to checking the full range. It rarely does this. There's almost always a palindrome near the top of the range.
- Once it's finds the first palindrome, it can check a smaller range of numbers, since it only needs to check combinations that, when multiplied, are higher than the previous highest palindrome. As a result, this algorithm goes much faster once the first palindrome was found. (This is the reason that "cheating" and guessing on palindromes increases performance so drastically. )
Someone else did another deep dive into this very same problem, and posted their findings and code. I implemented very similar optimizations in my own code, with a few differences. His runs much faster than mine. He is doing it in a much better programming language for performance, and it shows.
As much as I spent some time diving into this one, I have yet to find a faster algorithm. If anyone well-versed in math has a better solution, please give me a shout out. I'd be interested in taking suggestions and learning further ways to optimize it!
In the meantime, happy programming. If anyone wants to see how to multithread python, take a look at my code. It really is that easy.
|
|
|
Ask the Berry! |
Posted by: Juneberry - February 4th, 2020 at 5:48 PM - Forum: AMA Zone
- Replies (24)
|
|
Hihi. This is my AMA thread. Feel free to ask anything that comes to mind- just know I may refuse to answer if they're too personally identifying and such.
|
|
|
Makestation Awards 2019 |
Posted by: Guardian - February 4th, 2020 at 3:29 AM - Forum: Announcements
- Replies (17)
|
|
Makestation Annual Awards
We are currently taking nominations for Makestation Annual Awards for the year 2019. The following are the official categories.
- 2019 Member of the Year
- 2019 Newcomer of the Year
- 2019 Project of the Year
To nominate a member for these awards, please submit your nominations here. All qualifying nominations must be received by 11 February to be considered. Voting will begin as soon as I can possibly get one established, but no earlier than 12 February.
|
|
|
Ultimate Joystick Interface |
Posted by: SpookyZalost - February 1st, 2020 at 6:25 AM - Forum: Technology & Hardware
- Replies (7)
|
|
So I thought I'd post a thread about this because hey, it's nifty and pretty useful.
what you see here is the UJI or Ultimate Joystick interface.
It's a programmable logic controller that's specifically designed to take analog and digital inputs (which you set via resistors)>
up to 10 of them, and convert them into a generic joystick which works via USB.
originally designed to convert old hardware to new standards this wonderful little device can actually be used to design your own interface setups for stuff like custom flight cockpits, DIY joysticks, and other wonderful things, on the cheap no less.
you can get it here: https://backofficeshow.com/shop/ultimate...-interface
now while I haven't messed with one of these personally I've done similar work using Arduinos, raspberry pi's, and other hardware and can confirm that yeah this is a pretty great little device, just wish it had more inputs but what makes this one really special is that it's designed to reduce input lag by running at 40hz and responding faster than you can.
honestly I'm thinking about picking a few up to see how they work for some custom control interface panel upgrades.
just remember, the chip is write once so once you get it setup it's meant to stay, and you'll have to save a config file but once you do that you're good to go.
confirmed to work with most software that supports generic joystick inputs like elite dangerous, various racing games, emulators, etc.
hats off to those brilliant madmen across the pond, they once again lead the charge in making DIY more accessible.
|
|
|
Verilog HDL - Designing a CPU... |
Posted by: Darth-Apple - January 11th, 2020 at 11:03 PM - Forum: Technology & Hardware
- No Replies
|
|
You might think that designing CPUs involves literally drawing out each transistor by hand. This, as it turns out, has not been the case for several decades. Rather, something called HDL (hardware description language) does this instead. For the designer, they merely design the chip at (roughly) the gate level, creating modules that perform functionality that can be re-used and tied together to form a CPU. This is harder than assembly language, but far easier than designing it by hand.
In other words, there is literally a language that people use to design circuits. We haven't needed to do these by hand in a long, long time.
Last year, I used something called Nand2Tetris (an educational tool designed to teach CPU fundamentals) to "design" (read: followed the instructions) a CPU from scratch. It was incredibly educational in a lot of ways. The tool has its own form of HDL that allows you to design an extremely simple 16 bit CPU from the ground up, literally gate-by-gate. The instructions are simple enough that someone with no experience could easily complete it within about two days or so.
Now, I'm taking on the next challenge, and giving myself a year to do it. I'm going to redesign the same CPU in 8-bit form using real, industry standard languages: Verilog. This is what Intel and AMD and all of the other large companies use.
Ideally, I would like to use 7400 series ICs (mostly adders, chips with NAND gates, and flip flop circuits) to actually implement the design on a real circuit board. This is probably biting off more than I can chew, so at the time, I'm just going to design it in software. This could be either very simple, or I could get carried away with it. Either way, it will be good experience, and I'll be posting progress here as I make new additions to the design.
Has anyone attempted this before? If so, did you manage to translate the HDL implementation to a real hardware implementation?
|
|
|
|