|
They are using Molten Salt Reactors? Neat. I can understand now why they want some hardware now because that poo poo is vital infra for the baseload needed to operate all the large scale equipment on a whim. No offense to solar but steam turbines are still the king of electric generation. Besides, thorium fuel cycle suits the place if you gents have a breeder reactor too.
|
#
?
May 16, 2019 15:17
|
|
|
|
| # ? May 3, 2024 00:22 |
|
|
I remember reading a plan awhile back that would allow for carbon capture on a geo-engineering scale. It required ocean access for the chemistry (and for somewhere to drop the captured carbon which would just sink), and lots of power. Maybe we're finally going to undo some of the environmental damage of the last century.
|
|
#
?
May 16, 2019 23:00
|
|
|
A liquid salt reactor, at least the one I'm familiar with, runs at about 2,000 degrees Celsius. Fortunately, you have a lot of ocean to put heat exchangers in, but it still seems mildly inadvisable.
|
|
#
?
May 17, 2019 19:42
|
|
|
Blast From the Past Guess who wrote in today - Carl, from Shenzhen! I'd been so busy I'd almost forgotten about Longteng... it's embarassing to say that, honestly.  This feels like a mix of familiar - and very, very odd. I get Lili taking over CEO position of the company. She was kind of doing that already (if I remember rightly, I only got the one email from Mr. Yonghong when I started, and that was all I heard from him). But Joe in her position?! And he's not screwing it up?! I'm impressed, in a sort of ungodly drat-he-really-has-changed way. I hope David is wowing the folks back in California with his commitment to Chinese culture. It might actually sway a few people on the North American continent...! Seriously, though, best wishes to him and Xiaomei. I strongly suspect that Jie is going to remain the head of the engineering department at Longteng up until the day he dies. Looking forward to playing his daughter's best work (again) one of these days. And, well... it's good to hear that the company and Carl are all right. I'm going to email Carl back telling him what I've been working on (he'll be interested to hear the kelp harvester story, especially once I tell him how the faux cheese is), and also giving him a link to this blog. It's good to catch up, and this way he can follow along.
|
|
#
?
May 27, 2019 01:32
|
|
|
Interface Today, I'm going to talk about weaknesses in organizational structures. The fact that Avalon City expects you to self-organize is a great benefit, as it prevents a feeling of overwork and allows for a great deal of flexibility. As a drawback, however, you can sometimes get almost (but not quite) press-ganged into helping with a project. It really depends on how the person asking makes the offer. (Asking politely can get you anywhere, but them being rude makes it feel... less fun.) I guess what I'm really saying is that one of the drawbacks of the Avalon City organizational structure is one Mr. Kamran Farzan:  I said yes to the job, but yeah... I hope Mr. Farzan's not as brusque as that in person! The NETHUNS project is one of Avalon's many, many research projects - its focus is on new ways of bridging the gap between human thought and computing. The only really notable thing about it is that this particular project is Sun-sponsored - it hews a little bit more multidisciplinary than some projects, though the team is arguably about as diverse (field-wise) as the Ocean's Bounty project was. The actual project is part of a brain-computer interface - specifically, I think it's supposed to be part of a translation apparatus that converts nerve signals into data.    If I had to guess, once this component sends data to its output, the job of whatever-it's-attached-to will be to interpret the nerve pulses in some way. Design-wise, there's a few obvious places to start. Those six inputs just scream 'add input expanders'. Past that, there's three major design problems: 1. Counting how many pulses are active in a given time unit. From the test cases, it looks like a nerve pulse will never last two time units, so I don't have to worry about double-counting a pulse from the previous time unit. 2. Remembering how many pulses (and which pulses) were active in the previous time unit. If the device is reporting two time units' worth of pulses, the ones from the previous time unit will have to be saved so they can be reported. 3. Converting from three-digit (input expander) values to the 0-1-2-3-4-5 output values the interpreter (or whatever's on the other side of that output) expects. Once I've figured out all those problems - well, that'll be the design! [ ~ ] Here's my first stab at it.         All three of the design problems are mentioned are solved. 1. The device uses a RAM chip to turn the value from each input expander into a count of the number of '1's in the value. This works because each possible value from the input expander, when divided by 14, points to a separate location on the RAM chip: '000' = address 0 '001' = address 1 '010' = address 10 '011' = address 11 '100' = address 2 (100 / 14 gives 2 left over) '101' = address 3 '110' = address 12 '111' = address 13 So, if you put [0,1,1,2] in the first four cells of a RAM chip, and [1,2,2,3] in the last four cells, feeding the input expander value to the RAM chip as an address will let you read the correct count as data. The reason the device uses a RAM chip for this, as opposed to a non-writable memory chip, is that the RAM chip is also used for storing the last time unit's input values. More details when I discuss Design Problem No. 2, below. The fact that the design uses RAM means that I have to spend some chip space and instructions when the device is turned on to set up the eight values in memory. The far left MC6000 (the one connected to the input expanders) and the bottom left MC4000 are both responsible for this. The MC6000 on the left also passes on the input to be processed, and stores it in the RAM chip if need be - but the bottom left MC4000 is only used for setup. 2. The same RAM chip is used to store the values of the input expanders from the previous time unit. In addition, the device keeps track of the count of 1's in the previous input - in the dat register of the MC6000 directly above the RAM chip. This counter MC6000 is responsible for getting the 1's count each time unit. It'll add the saved count back in the next time unit, using add dat. 3. The two MCs on the far right are used to format the paired three-digit values into 0-1-2-3-4-5 output packets. The large formatter MC gets the data for the past two time units, amalgamates it by adding it together, and then sends each digit (one at a time) to the small MC. The small formatter MC checks if the digit it receives is a '1' or not, while keeping track of how many digits were sent previously in its acc. If a '1' is received, the small MC outputs its acc to the output pin. If it's a '0', it doesn't. Either way, it adds 1 to its acc, resetting it to 0 if it's over 5. Effectively, the small MC goes through the numbers 0 through 5 in acc, sending those numbers to output if it received '1's, and not sending them if it received '0's. The pattern of 0s and 1s it receives determines what's output. Here's how the device works from start to finish: • At startup only, the input MC6000 and the bottom left MC4000 store the hardcoded values into the RAM chip. • Each time unit, the input MC6000 on the left sends the input expanders' values to the counter MC6000 in the center. The counter MC counts how many 1's are in the input, adds the count from the previous time unit (which was stored in its dat), and sends that number back to the input MC. The counter MC also resets the address pointer of the RAM chip so that other MCs can use it. • If the input MC sees '2' or more, it will re-send the input to the counter MC so that the counter MC can pass it on to the formatter MCs. Otherwise, it will send the input to the RAM chip to store it for next time unit. • The counter MC also checked whether the count was '2' or more - this is how it knows whether to expect more input or not. If the count is 2+, it sends this input on to the large formatter MC in the bottom right. Otherwise, the counter MC stores that in its dat to be added next time unit. • When the large formatter MC gets input, it adds the previous time unit's input, which was stored in the RAM chip. Then, it sends each digit of the combined input to the small formatter MC, one at a time. • The small formatter MC converts the digits to the output format the device expects, sends the output, and the cycle begins again with the input MC. This design is ¥25, and uses 2112 average power per run, but... well, all the explaining I did when writing this up left me unsatisfied. Why do I need a RAM chip to store two values total, when I could use a ROM chip to store the translation table, put the last time unit's input in two registers, and save a MC? I'm going to rebuild the design, aiming to make it a lot more efficient. Here goes. [ ~ ~ ]       As promised, the updated design is a lot more streamlined. The input MC6000 still sends the values from the input expanders to the counter MC (now a MC4000 in the top center), and receives a count of 1's in return. However, if the returned count is less than 2, the input MC will store the current time unit's values in its acc and dat, instead of in the RAM chip (which was removed; the 1's count table was moved to the ROM chip, attached to the counter MC.) If the count is 2 or more, the input MC will add the previous time unit's values to the current input values before sending them to the large formatter MC (the bottom center MC6000) - previously, the formatter MC did this itself. I realized that the counter MC doesn't need to keep track of how many 1s were counted in the previous time unit, because of the threshold of two 1's for sending data to the output. If no 1s were counted at all last time unit, or the device sent data to the output last time unit, then the counter doesn't have to add anything to the value. The only situation where the counter MC has to fiddle with the value is if there was exactly one '1' last time unit - and that data can be stored using conditional flags instead of dat. Because of this, I was able to cut the counter MC down to a MC4000. Finally, the large formatter MC doesn't need to access the memory chip either, as the input MC does the addition of the previous time unit's input for it. Its script is slightly shorter for this reason, while the small formatter MC (the MC4000 in the bottom right corner) is exactly the same. Here's the updated version of how the device works: • Each time unit, the input MC6000 on the left sends the input expanders' values to the counter MC4000 in the center. The counter MC counts how many 1's are in the input; if it counted a single '1' last time unit, it'll add an extra one to the count now. It then sends the total count back to the input MC. • If the input MC sees '2' or more, it will add the current input and the previous time unit's input (which was stored in its acc and dat) and pass the result on to the formatter MCs. Otherwise, it will store the input in its acc and dat for the next time unit. If the input MC sent data to the formatter, it will clear its acc and dat so that values from before aren't double-counted. • The counter MC checks if it counted exactly one '1'. If so, its conditional flag sets up the add 1 next time unit. If the conditional flag was already set going into this time unit, a line of code* will trigger, instead, that makes sure that the test fails. This clears the flag (because if we had only one 1 on the last time unit, the device will either send output this time unit, or it didn't receive any input this time unit - the flag needs to be reset either way). *It's the + mov 0 acc. • When the large formatter MC gets input, it sends each digit of the combined input to the small formatter MC, one at a time. It uses the dst 0 dat trick to save a line of code - copying the three-digit input value to its acc and isolating the ones digit in the same line. • The small formatter MC converts the digits to the output format the device expects, sends the output, and the cycle begins again with the input MC. (This is unchanged from before.) This version clocks in at ¥20, and power usage is also much improved - 1894 average per run! I'm happy with it, and I'll send it off. I wonder what Kamran and co. will think?  As terse as ever. Figures. Interpersonal commentary aside, I'm sure I'll enjoy working on the NETHUNS project! It looks like it'll have intriguing challenges - and being back in research, on the forefront of something, feels good. I'm looking forward to whatever they have for me next....
|
|
#
?
May 27, 2019 01:32
|
|
|
They're trying to digitize brains? Aww, hell naw. That is never a good thing. I've read enough bad sci-fi novels and cheap 70's horror flicks to know that this sorta thing always goes bad.
|
|
#
?
May 27, 2019 01:56
|
|
|
I'll say it again: if they start talking about rewriting human DNA with stuff they got off of sea slugs, run the gently caress away. Heck, might as well do that now as digitizing brains is either going to lead to SHODAN or SOMA.
|
|
#
?
May 27, 2019 08:48
|
|
|
Junpei posted:They're trying to digitize brains? Aww, hell naw. That is never a good thing. I've read enough bad sci-fi novels and cheap 70's horror flicks to know that this sorta thing always goes bad. To quote a classic old game: quote:“I think, and my thoughts cross the barrier into the synapses of the machine, just as the good doctor intended. But what I cannot shake, and what hints at things to come, is that thoughts cross back. In my dreams, the sensibility of the machine invades the periphery of my consciousness: dark, rigid, cold, alien. Evolution is at work here, but just what is evolving remains to be seen.” More seriously, though, this sounds more like an advanced version of those headbands that you can use as an analogue stick replacement. As long as it stays a pure input device, I can't really see anything to worry about.
|
|
#
?
May 27, 2019 09:54
|
|
|
Yeah, I'm fine with a mind-machine interface that goes from mind to machine, with the only feedback being through conventional senses. That's a fairly straightforward variation on, say, a keyboard or a mouse. It's when the machine starts twiddling your neurons directly that I get worried. I don't trust software to not be exploited, and if you thought advertisements and malware were bad when all they could do is show you things and steal the data you'd recorded, imagine what they're like when they can make you experience anything and steal your thoughts.
|
|
#
?
May 27, 2019 16:52
|
|
|
TooMuchAbstraction posted:Yeah, I'm fine with a mind-machine interface that goes from mind to machine, with the only feedback being through conventional senses. That's a fairly straightforward variation on, say, a keyboard or a mouse. It's when the machine starts twiddling your neurons directly that I get worried. I don't trust software to not be exploited, and if you thought advertisements and malware were bad when all they could do is show you things and steal the data you'd recorded, imagine what they're like when they can make you experience anything and steal your thoughts. Professor Helper here, ready to help!
|
|
#
?
May 27, 2019 18:55
|
|
|
The Diamond Age posted:You could get a phantascopic system planted directly on your retinas, just as Bud’s sound system lived in his eardrums. You could even get telaesthetics patched into your spinal column at various key vertebrae. But this was said to have its drawbacks: some concerns about long-term nerve damage, plus it was rumoured that hackers for big companies had figured out a way to get through the defenses that were built into such systems, and run junk advertisements in your peripheral vision (or even spang in the loving middle) all the time – even when your eyes were closed. Bud knew a guy like that who’d somehow gotten infected with a meme that ran advertisements for roach motels, in Hindi, superimposed on the bottom right-hand corner of his visual field, twenty-four hours a day, until the guy whacked himself.
|
|
#
?
May 28, 2019 14:09
|
|
|
Scaffold Printer It turns out that joining the NETHUNS project was the relative end of silence in my inbox. I've been getting a lot of chatter regarding interfaces this, neural computing that, and so on. And today, a new project showed up.       As far as I can tell, this design appears to be at the forefront of neural network research: not computing with the AI constructs known as "neural networks", but with actual networks of neurons (or something that looks a lot like them - maybe mock neurons). The project itself looks interesting, and the design looks pretty simple. Or, well, it did. Then I took a close look at the specification. If there were just the 9 patterns listed in the article, I'd probably be able to do something clever and make it so that each pattern requested had a different code path. But that would require the scaffold printer's "print head" to always move from left to right. It doesn't. In the spec, you can see that it prints the first row left to right, then reverses direction and prints the second row right to left, then the third left-to-right, the fourth right-to-left again, and so on. In short: the device has to not only store the 9 patterns listed, but also what they look like when printed in reverse order. Patterns 0-2 are the same backwards and forwards, but the rest aren't - once you count all the reversed variants, there's some 15 unique patterns to distinguish from, counting the blank one (Pattern 0). The amount of information that needs to be stored is probably going to force any and all ideas for clever plans out the window... and I'm honestly not sure where to start. I'll try taking a stab at things and see where I end up. [ ~ ]    This is my earliest attempt, and while the MCs attached to the motor outputs are a good start, the PGA33X6 was officially a mistake. I had assumed that with the PGA, I'd be able to separate the patterns into chunks, then use the PGA as a sort of translation table, maybe in concert with some logic gates. The problem with that: the PGA only has eight conceivable input states, so I'd have to do a LOT of preprocessing to get the input to a set of 8 state-chunks - and not only can I not see any obvious way to turns the required patterns into something that the PGA would be able to use, but by the time I'd done that much preprocessing, the PGA itself would be useless. I have, however, gotten a start on the motor MCs. The upper one handles horizontal movement of the print head; each time it's triggered, it pulses motor-x for six time units, moving the head all the way right (or left). It uses its acc to keep track of the direction it should move, and so will move in opposite direction each time it runs. The lower motor MC is set up to handle vertical print head movement, but it's pretty crude for the moment. If it's notified with a positive number, it moves the print head up by pulsing motor-x to 100 for one time unit. If the MC receives a negative number instead, it moves the print head down by pulsing motor-y to 0 for a time unit. There's no functionality for resetting the print head to the lowest position yet, but that'll come soon. With the PGA approach fallen through, I'll have to come up with another approach. I'll try to see if there's any similarities among the patterns that I can use to the design's advantage - but it'll be tough. More soon. [ ~ ~ ] I've made a little more progress - though my 'second approach' to decoding the patterns also fell through.     I had planned to break the patterns into three-time-unit chunks, and control the what valve was to be turned on, and whether a valve was to be turned on, separately. This was initially based on my observation that Patterns 4, 5, and 6 are the same pattern - except Pattern 5 has blanks instead of Ψ (Y), and Pattern 6 has blanks instead of α (A). Here's how I had it mapped out: I had a total of seven valve-value chunks: AAA, BBB, ABA, BAB, YAA, AYA, and AAY. I also had a total of eight valve-activation chunks: 111 (all on), 000 (all off), 100, 101, 001, 011, 110, 010. From there, it was just a matter of coding patterns to pairs of value-power chunks: 0: [any]-000, [any]-000 (same in reverse) 1: AAA-111, AAA-111 (same in reverse) 2: BBB-111, BBB-111 (same in reverse) 3: ABA-111, BAB-111 (reverse: BAB-111, ABA-111) 4: YAA-111, AYA-111 (reverse: AYA-111, AAY-111) 5: [YAA or AAA]-011, [AYA/ABA/AAA]-101 (reverse: [AYA/ABA/AAA]-101, [AAY or AAA]-110) 6: YAA-100, AYA-010 (reverse: AYA-010, AAY-001) 7: [AAA/BAB/YAA/AAY]-010, any-000 (reverse: [any]-000, [AAA/BAB/YAA/AAY]-010) 8: [any]-000, [BBB or ABA]-010 (reverse: [BBB or ABA]-010, [any]-000) This is where the grand idea fell apart. I could see a few shortcuts - like being able to use any of AAA, BAB, YAA, or AAY as a value chunk in Pattern 7 - but I couldn't figure out a good way to code this all into a translation table. So, instead, in this section, I'll tell you about the new MC I added, which handles input. The new MC checks if the input is a line (0+) or a reset packet (-1). If the input is for a line, it copies the value out to x0 and x2, which will go to the MCs that will determine what patterns to output. (These MCs have yet to be installed and coded.) In either case, it will also send the value to the main motor MC (the MC6000 on the top right). The main motor MC has been upgraded slightly. Not only does it pulse for 5 time units, instead of 6 (I had the timing wrong before), it will now save the input it gets and pass it on to the secondary motor MC on the far right. If the input was a reset (-1) packet, it will also notify the input MC once the print head is done resetting; the input MC pauses when it receives a reset packet, so the pulse from the motor MC lets it know that it can start reading input again. The secondary motor MC now tracks the height of the print head in its acc. If it receives a reset packet, it will now lower the print head to the lowest level in one movement. So, as I predicted above: clever solutions have failed. Even only slightly clever ones. It's time for me to go the simple way, and use the ROM chips I put in for the translation table to hardcode the expected output. It's an ignoble way to build the device, but it'll work, and it might even be efficient in the bargain. We'll have to see. There's no way forward but to build it! [ ~ ~ ~ ] Here it is! It got a lot more complex-looking, but it's the same device at heart.            When the input MC gets data now, it turns it into a memory address by multiplying by three. Then, it sends the address to one of the two pattern-reader MC4000s attached to ROM chips (in the top and bottom left). Those MCs will use that memory address to get the correct pattern of valve outputs. Backwards patterns are also handled by the input MC. The main motor MC uses its p0 simple output to let the input MC know whether it's a normal or reversed line. If it's a reversed line, the input MC will add 1 to the memory address before it sends it off to the pattern-reader MCs. This works because each of the patterns in the article has a second half that is the same in reverse. So, in the memory chip, each pattern is stored in three memory cells, in this order: (first half of pattern) (second half of pattern) (reversed first half). The pattern-reading MCs attached to each ROM chip will output two values out of those three. If it's the normal pattern, it reads the first and second cells. If it's the reversed pattern, it's the second and third cells. The pattern reader MCs' output lines are connected to the primary decoder MC, which is the MC6000 on the lower center-right. This MC functions a lot like the decoder MC from the brain-computer interface: it takes a three-digit value and turns it into three single digits. The digits are fed to the secondary decoder MC (bottom right) one at a time, which toggles the correct valves with the output expander. The motor MCs are mostly the same as last design, with just a few slight tweaks: • The big motor MC now reports on its p0 whether it's a reversed line or not. The input MC reads this to determine which pattern to use, as mentioned above. • The small motor MC turns off the valves after each line has been successfully printed. (There was no space for the instruction in the other MCs.) And that's the design! It's actually more efficient than I expected, clocking in at ¥32 and 636 average power per run. I'm pretty sure Lisa is going to be happy with it.  I wonder how many of these they're planning to make? Is this going to be more research lab equipment or production equipment? I'll have to ask next time we're in the same room.  Overall, this project was kind of weird. It wasn't hard in the end - it was only difficult when I was trying to be clever about it. Once I just bit the bullet and hardcoded the patterns, it became really straightforward. I guess there's some kind of moral to be had there, but I'm not sure what it is - but for now, I'm going to take a break. A group of people ended up following in the footsteps of the Sushirobo concept and made a Mexican restaurant! And I'm about to go see it. Avalon City is becoming more intriguing, challenging, and comfortable every day...
|
|
#
?
Jun 10, 2019 11:52
|
|
|
Turbocharge Your Brain! ♩It's one weird trick discovered by a mom ♫ One weird trick discovered by a mom ♪ ♫ And you can own a house in Panmunjom And you can own Your Name dot com ♬ ♪ And you can own Your Name dot net: ♫ It's one weird trick I wish I could forget. ♩
|
|
#
?
Jun 10, 2019 11:52
|
|
|
The_White_Crane posted:Diamond Age Of all the creepy stuff in that book (and there is a LOT of creepy stuff), the "ad permanently embedded in your vision" is definitely one of the worst.
|
|
#
?
Jun 10, 2019 15:05
|
|
|
Quackles posted:Overall, this project was kind of weird. It wasn't hard in the end - it was only difficult when I was trying to be clever about it. Once I just bit the bullet and hardcoded the patterns, it became really straightforward. This is a lesson I had to learn the hard way several times early in my career. I kept thinking "I write software, the computer does the drudge work for me" and would spend hours automating a task that would've taken me five minutes to do by hand the one time that it was required. Sometimes it really is better to do the work for the computer (or the MC, in your case), instead of the other way around.
|
|
#
?
Jun 10, 2019 15:49
|
|
|
I'm not sure if "premature optimization is the root of all evil" really applies when the "unoptimized" approach is just different? This sort of programming under very hard constraints is also an exception in general, since the optimization is less "premature" and more "fundamentally required"... I guess "try the straightforward solution before you get fancy" remains a good idea, but you've been very sensible about that so far.
|
|
#
?
Jun 11, 2019 08:56
|
|
|
Between the vast resources of Sun Haotian, the geometric fixation of Avalon City's layout, and the recent forays into the cybersingularity, I can't help but feel there is a cautionary tale in our cultural mythos
|
|
#
?
Jun 14, 2019 04:36
|
|
|
I have a question about the layout of Avalon. If the need for more space is required, will another "pizza" be built over the current one?
|
|
#
?
Jun 15, 2019 03:21
|
|
|
Recommendation: Existence Within Sun's recommendations are getting progressively more cosmic. I wonder what he's had on his mind lately? Danny Glands posted:I have a question about the layout of Avalon. If the need for more space is required, will another "pizza" be built over the current one? No, the city can just add more plates and expand out horizontally. Or even pull the current plates apart (they're modular!) and add interstitial ones in between.
|
|
#
?
Jun 19, 2019 11:28
|
|
|
Logic Board NETHUNS is almost complete, and I've been able to puzzle together what the goal of it all is. We're making a sort of... I guess you could call it a hybrid biological and machine-based 'cortex'. The intent is to create a distributed system with sufficient complexity to provide a means of emulating the kind of networks found in the brain, with the intent to model emergent properties of consciousness. In plain English: we're making a machine capable of true thought.  Which means I have one more job on my hands before all this is complete.     This board is a little different than pretty much every other design I've worked on so far. Those neural processors in the middle of the board are fixed components. Not only are they not movable, I can't route wires under them, either. Given that the pump motor inputs are on the opposite side to the LOGOS and TELOS neural processor outputs, and there's only a one-wire gap to get from point A to point B, I have a small problem on my hands. (By the way: 'logos' is Greek for 'reason', and 'telos' is Greek for 'purpose'.) My first order of business is definitely going to be to get something reading the output of the neural processors and passing a go/no-go signal to the pump inputs. Because either processor can output a thought packet at any point, the MCs that handle the pumps will have to be notified whether or not to flush the flow of... whatever's in those tubes... every time unit. I'll try and get as far as that, because those long-rear end packets are staring me in the face, dauntingly. 25-unit thought packets are big enough that I don't know what I'll do to handle storing them - because I WILL have to store them while I process the checksum. Otherwise, I risk sending on a corrupted packet. For now, let's work on pumping some cool neural goo. [ ~ ]        Here's my first stab at it. The MC6000 on the left side checks both of the neural processors for values that aren't -999. (It's kind of like dealing with a radio input, really.) If it finds a value that's part of a thought packet, it'll send that value (and the rest of the packet) out on x0 to... I don't know what yet. The MC will also send the first value it gets from each processor in a time unit, along the wire that leads to the pump MCs. It'll do it in the following sequence: Logos's value, then Telos's value. The reason for this is that the pump MCs are designed to respond in a staggered order. The pump MCs themselves are pretty simple. Each pump MC reads a single value from the input-processing MC each time unit - but the lower (Telos) pump has an extra slx that will make it always lose the race to get the first value. This ensures that the Logos pump MC gets Logos's value, and the Telos pump gets Telos's value. In both cases, if a pump MC sees a value that's not -999, it cycles the pump immediately and resets its countdown, which is stored in acc. Otherwise, it will subtract from its countdown as normal, and cycle the pump when it hits 0. At this point, the next step is to actually store and checksum the packets. This is tricky - I don't see an obvious way forward just yet - but I'll play around with the design. With luck, I'll be able to make some headway soon. [ ~ ~ ]       This design took longer to piece together than you'd think. At one point, I went off chasing a variant design that had each MC6000 attached to one (and only one) neural processor, and both of those MCs would do the checksum for their neural processor's output in-chip. I abandoned that design for a few reasons, the biggest being that I couldn't get things to synchronize properly. This version is a step forward from the previous one I blogged about. The input-handling MC's code has been finalized; Kamran was helpful enough to inform me that LOGOS and TELOS should never both generate a thought packet on the same time unit, so the input MC will send off any not-minus-999 input to the new MC6000 above it, then pass along a single -999 to indicate that it's done. The new MC6000 does checksumming. If it gets a -999 value at the start of the time unit, it concludes no thought packet is present and goes to sleep. Otherwise, it moves the input into its acc (as well as passing a copy of the input out on its x0 to be stored and processed in an as-yet-undefined way), then performs the checksum on the rest of the input as it arrives, continuing to pass copies of the input values along. This continues until the checksummer MC gets (and passes along) a -999, signaling the end of the input. After this happens, the MC will output its acc (the completed checksum) forward on x0, which the storage MC (to be designed) will interpret as a 'go' or 'no go' signal depending on whether the result is 0 or not. There's one other change to this design: it turns out I had the wrong initial timing on the pump MCs. It turns out their acc counters need to be set to 5 at the start, not 4, to get the desired behavior. So far, so good. But I'm on to the hardest challenge of all. I need to store that thought packet while it's being checksummed, and read it out afterwards - and I've got to do it in an area of board space the approximate size of a postage stamp. (Maybe smaller, after fabrication.) One possibility is putting everything in a single memory chip - packet contents, except for the checksum, appear to be single digits, so this could work if the 24 non-checksum values double up and share two digits to a memory cell. But I'm not sure if it'll work - and, once again, I'll have to play around with the design before I can get something that behaves properly. So: once more to work. And once I crack this, we should have a finished design, and the final piece to possibly the biggest advancement in computing the world's ever seen. [ ~ ~ ~ ] Here it is. It turns out that sometimes, the simple solutions are the best ones.          This is definitely the final design. I haven't changed anything about the input-handling, checksumming, or pump MCs (except for commenting out the slp 1 on the TELOS pump MC, as it doesn't need it with the slx it has at the top). The big, obvious change from the last version is - the storage mechanism is complete. I went with two memory chips, instead of one, because it was easier to do. The storage MC alternates between the two RAM chips, storing each value it receives, first to one, then the other. This includes the -999 the checksummer MC sends along to indicate 'end of input'. Once the -999 is stored, the storage MC will make sure that the checksum it receives from the checksummer is 0. (If it's not, it will stop and start over, waiting for the next packet to store.) Once the checksum is confirmed, the final step starts: reading out the stored packet. Once the packet, the checksum, and the -999 to mark end-of-input have been stored in the RAM chips, the input has taken up a total of 26 memory slots, 13 in each RAM chip. This is exactly enough that I can use a single command, mov x1 x2, to reset the RAM chips' memory pointers to the the start of their portions of the packet. (It works because the pointers will be pointing to the one slot that's not used for anything in each memory chip, so the instruction makes the pointers wrap around to the beginning.) From there, the storage MC can read out the values from the RAM chips and output them to mesh-data, stopping once it reads a -999. Then, the packet output is complete and the device can wait for the next thought packet. In total: ¥25, and 2979 average power per run. And I've made a contribution to the annals of experimental computing.  Past this point, my part of the NETHUNS project is done, but I'll keep you updated for the grand finale: putting everything all together. Expect another post in a few days. Talk to you then?
|
|
#
?
Jun 19, 2019 11:28
|
|
|
Can anyone* confirm that Sun Haotian is a human and not an AI? *(natural organic human being)
|
|
#
?
Jun 19, 2019 12:20
|
|
|
Maybe someone can email Sun a CAPTCHA 
|
|
#
?
Jun 19, 2019 15:03
|
|
|
My solution did double up the data so I only used one RAM chip. I also only used one MC6000 to do all the pumping, so you can save ¥1 by figuring that out yourself. Yet my best solution was ¥26. There's a newly released free game/pdf thing for Zach games if anyone didn't know about it. https://store.steampowered.com/app/1098840/
|
|
#
?
Jun 20, 2019 01:02
|
|
|
The Final Step So, it turns out there was one thing I missed about NETHUNS when I gave you the run-down last post. The 'brain' we've made doesn't... we're not trying to create a new intelligence in it. Instead, the plan is to transfer a human consciousness into the NETHUNS biomechanical computing engine. It'll be a new kind of mind. Perhaps this is a bit cliché, but— it's... For Science. Of course, that just leaves the question: who would be so visionary/reckless to do such a thing of their own free will? Well...  Yeah. Sun Haotian is going transhuman. And I have to sign off on it.  Maybe I've got an imperfect grasp of group psychology, but making it a group decision like this feels like it made it that much harder for any one person to back out. I certainly wasn't going to say no. I'd have to explain myself to... pretty much the rest of everyone in the project. It's a big project. And besides... I'm curious what will happen next. Will history remember this as a pivotal moment? Or a terrible moment? Or will this just be forgotten? [ ~ ~ ~ ~ ~ ]  I watched the video they took of the upload process, or most of it. It was straightforward at first: there was an operating theater, with white paneling and what looked like a bank of computers at one end. Sun entered, followed by three other people: a neurosurgeon, an anesthesiologist, and Kamran. Without much ado, Sun lay down on the operating table, and the anesthesiologist put him under. Then, the neurosurgeon sat down by Sun, using a robot arm with several cutting tools to open the top of Sun's skull. Here's the part I wasn't expecting: once Sun's head was held in place, and the neurosurgeon opened the top of it, the anesthesiologist eased off. After a bit, Sun opened his eyes, and Kamran began talking to him, asking questions to see if he was coherent. Sun answered all of them with an incredible degree of calm for someone whose head was currently open at the top. (Apparently, the idea was: if Sun isn't conscious when he goes into the NETHUNS system, he might not be able to resume consciousness once he's inside.) After this, the camera view changed to show Sun's brain, from the top. I've always been a little squeamish, so I skipped ahead a few minutes. By the end of the segment, the neurosurgeon had attached thin wires directly to points of Sun's brain, running to the bank of computers at the other end of the room. Finally, the actual upload began (the camera changed back to an overhead view, thankfully). It was kind of boring compared to the previous part. Sun just lay on the table, blinking occasionally. Once or twice, Kamran held a card in front of Sun, asking him to read the contents. This continued for a little over an hour. (I did skip ahead in the video again.) And then.... Sun closed his eyes. That was it. The anesthesiologist checked Sun's pulse to make sure everything was OK, and nodded. Kamran began disconnecting the cables at the computer end. After a second, someone switched off the camera. At this point, we're all waiting to see if the experiment was a success. [ ~ ~ ~ ~ ~ ] It's been several hours, and, well...  So is Sun in the NETHUNS system, or not? We just can't know, at least not yet. [ ~ ~ ~ ~ ~ ] We're currently at the 24-hour mark, and... nothing. And on top of that... Sun Haotian (the human version) hasn't woken up. It looks like he's in some sort of coma as a side effect of the process. (Or maybe this was supposed to happen. I really don't know.) Did we screw up?  Soooo... yeah. It looks like NETHUNS, which was supposed to be not so much the cutting edge or bleeding edge as the pre-emptive edge of biomechanical computation technology, may be a complete bust. And, with Mr. Haotian in a coma, we have no way of trying again if the NETHUNS apparatus turns out to be a high-technical garbage can. Yeah. I'm going take a nice, long walk around the city, then find a project that feels like it could have a meaningful impact on the world. Apparently there's a group trying to make a free-roaming robot that cleans up loose plastic in the ocean. I might be able to help with that, somehow. I'll update this blog once I have something interesting to talk about.
|
|
#
?
Jun 28, 2019 21:50
|
|
|
I hate to sound callous, but, well it wouldn't be the first time a rich and powerful man killed themselves persuing immortality.
|
|
#
?
Jun 28, 2019 22:20
|
|
|
Check your spam folder. All of Suns AI brain emails are going there maybe.
|
|
#
?
Jun 28, 2019 22:25
|
|
|
Wonder what our friends back in Shenzhen would have thought of this brain transfer thingy...
|
|
#
?
Jun 29, 2019 00:00
|
|
|
Man, I hope the simulation brief they gave to you was accurate enough. If this all happened just because they didn't account for something I'd be very dissapointed in them.
|
|
#
?
Jun 29, 2019 00:18
|
|
|
GuavaMoment posted:My solution did double up the data so I only used one RAM chip. I also only used one MC6000 to do all the pumping, so you can save ¥1 by figuring that out yourself. Yet my best solution was ¥26. The... prototype games and stuff won't work on Linux it seems, but I grabbed the 400 page PDF and am reading through it. It's very fascinating. I didn't know Zach did a lot of stuff trying to design physical games, or, more like, the intersection of physical and video games. Did you know that he once designed a laser tag game (but it never left the design phase) that he called AWESOMEPLEX? Sound familiar? Yeah, apparently he likes to refer to old ideas in new games.
|
|
#
?
Jun 29, 2019 13:38
|
|
|
<NO SUBJECT> I have just received a very strange message.  I'm not alone in this. Lisa got one of these. So did Kamran, and Derrick. The people they've spoken to also had one, too. I think Mr. Sun Haotian 2.0 emailed the entirety of Avalon City. On one hand... we did it. We managed to create a whole new form of hybrid human-machine intelligence!  On the other hand... that. That message. Clearly Sun has something in mind, with his stated plans to monkey about with human [development / desire / whatever]. I get the feeling that maybe I should be worried, but... well, he did say: next message in 6.038 * 10^10 seconds. We've got about 1,914 years to prepare for whatever's coming. I'm not sure where the future is going to take me, or any of us, at this point; but, I can still try and help the people around me with my engineering skill. Will Sun's plans save the world? Or doom it? Or will entropy end up turning NETHUNS and Avalon into high-tech ruins long before that second message is ever sent? I guess we'll have to wait and find out. See you in 1,900 years.
|
|
#
?
Jun 30, 2019 11:55
|
|
|
Well done. You just turned Chinese Elon Musk into the Borg Queen. God help us all.
|
|
#
?
Jun 30, 2019 14:15
|
|
|
I'm pretty sure that's just a Internet explorer type estimate and will probably speed up when Sun's rearanged his mind bits around. Will probably only take 100 years, tops.
|
|
#
?
Jun 30, 2019 14:19
|
|
|
I would wonder why AIs always go skynet, but considering the kind of megalomaniac idiot* that became this AI this was the only possible outcome, wasn't it? *being one of the smartest men alive does not mean one cannot also be a complete idiot
|
|
#
?
Jun 30, 2019 14:45
|
|
|
Tombot posted:I'm pretty sure that's just a Internet explorer type estimate and will probably speed up when Sun's rearanged his mind bits around. Will probably only take 100 years, tops. Or it'll get to 99% / 1 second and stay there for a million years. We need to assume that the text glitches are proof that the basic structure of the NETHUNS system is faulty and needs to be taken down. Nuke it from orbit, just to be sure.
|
|
#
?
Jun 30, 2019 14:46
|
|
|
Here ends the Let's Play. We did it! We made a bunch of cool stuff and/or junk in Shenzhen, then moved to a futuristic city and helped upload a man to the cloud. Alas, we may never know what becomes of our friend the Engineer, as they work towards a brighter future(?). Sun's message is the conclusion of the bonus campaign, so we've seen everything there is to see. Thank you all for reading. (( Music: Outro )) Now that the Let's Play is over, I'll now answer questions out of character if anyone's got 'em. First off, here are some answers and fun facts: • There's only one gameplay path Sadly, there is no branching storyline if you decide to stay in Shenzhen (or, alternately, not sign off on NETHUNS). The game just has the button there and it will wait patiently forever for you to come back to the in-game email program and click on it. • The I Ching reading The I Ching reading I did for Assignment #20 was real, with 50 very much real pencils, and I didn't alter the results in any way. Thinking back on it, the reading was dead right, too— the Engineer saw a great man (Sun Haotian), then moved to Avalon City (represented by the two 'water' trigrams in the second hexagram). • Sun's delayed message and the Engineer's Tablet The '<NO SUBJECT>' message appears in your in-game inbox three IRL days after you perform the sign-off. Once you read it, the game's start-up screen gets... a little different. • Bonus puzzles! The 'Puzzle Archive' feature in the options menu lets you enter codes to access a total of three bonus puzzles: the tough version of the Personal Sandwich Assembler (2241), the tough version of the Kelp Harvester (3113) - argh! - and the SHENZHEN I/O trailer device, which was featured in the trailer (0451). They're out there if you ever want a challenge. If one or more of the codes doesn't work, you may need to update your version of the game. Quackles fucked around with this message at 21:11 on Jul 7, 2019 |
|
#
?
Jun 30, 2019 21:39
|
|
|
Thank you for this LP, it was quite the ride, and very fun with your "we're actually in Shenzhen in the near future" shtick. Excuse me for tuning out during some of the more complicated puzzle explanations though. Also once again kudos for this project of yours than ran completely out-of-hand: https://www.youtube.com/watch?v=dZVrbpQoqg0
|
|
#
?
Jun 30, 2019 22:08
|
|
|
This was a great LP, thank you very much for writing it!
|
|
#
?
Jun 30, 2019 22:30
|
|
|
Carbon dioxide posted:Thank you for this LP, it was quite the ride, and very fun with your "we're actually in Shenzhen in the near future" shtick. You're very welcome! I did my best to try and make the puzzle explanations as accessible as possible to people without much programming experience, but I'm aware that I didn't pull it off completely. I'm writing it off to 'perils of the genre'. Carbon dioxide posted:Also once again kudos for this project of yours than ran completely out-of-hand:
|
|
#
?
Jun 30, 2019 22:30
|
|
|
There's one other change as you beat the game - the loading screen when you first boot up the game gets a little glitchy, I guess implying Sun's influence over computers now or something? Thanks for the LP! This is the part when people want you to move onto EXAPUNKS now, because an LPers job is never done. I am those people. 
|
|
#
?
Jun 30, 2019 23:24
|
|
|
|
| # ? May 3, 2024 00:22 |
|
|
GuavaMoment posted:There's one other change as you beat the game - the loading screen when you first boot up the game gets a little glitchy, I guess implying Sun's influence over computers now or something? Yep! It looks like this:  I get the feeling the Engineer's tablet may be part of NETHUNS now.  quote:Thanks for the LP! This is the part when people want you to move onto EXAPUNKS now, because an LPers job is never done. Maaaaaaaaybe.  EXAPUNKS is a full-size project by itself! I might do it someday, though. It'd certainly be fun.
|
|
#
?
Jul 1, 2019 00:37
|
|