Saturnus Posted February 28, 2020 Share Posted February 28, 2020 14 minutes ago, Gurgel said: Would not surprise me. And it might explain why a single looped NOT gate just outputs a solid 1. Does it though? No, what they did change is that the simulation will run the circuit 3 times. And if there's an invalid connection, like connecting NOT inputs and outputs together then the simulation of that circuit is halted until it is changed in any way. At which point it will try 3 times again. Link to comment Share on other sites More sharing options...
psusi Posted February 28, 2020 Share Posted February 28, 2020 1 hour ago, Saturnus said: It is possible it used to be 1/5th of a second but the automation clock has been 0.1s for at least a year. Do you base that on anything other than the not gate chain? Because that probably has been that way for at least a year. People used to say that if you wanted to make a battery flip-flop you needed to use an OR gate on the other side to balance out the delay of the NOT gate, but I've never had to do that. I wonder if you can build a counter circuit and use it to measure how fast a buffer+not oscillator is actually oscillating at a buffer setting of 0.1 vs 0.2 and see if it is actually any different. 1 hour ago, Saturnus said: Does it though? No, what they did change is that the simulation will run the circuit 3 times. And if there's an invalid connection, like connecting NOT inputs and outputs together then the simulation of that circuit is halted until it is changed in any way. At which point it will try 3 times again. How is that invalid? It should be perfectly fine and just result in toggling as fast as the tick rate is. Link to comment Share on other sites More sharing options...
Saturnus Posted February 28, 2020 Share Posted February 28, 2020 Apparently I was both slightly wrong, and very right before. Apparently, connecting a NOT to itself still makes an oscillator. The game just picks to show it as constantly off or on instead of trying to flicker the gates. The picture below proves the main point that the game tick is indeed 1/10th of a second. Top counter is buffer at 0.2s Middle counter is buffer at 0.1s Bottom counter is no buffer. Bottom one is pretty much precisely double the middle one proving that the tick is indeed 0.1s Precisely why the top counter is off where it should be I don't know yet Link to comment Share on other sites More sharing options...
Gurgel Posted February 28, 2020 Share Posted February 28, 2020 1 hour ago, Saturnus said: Does it though? Depends. When I tried, it did. The actual output signal is completely immaterial though, all that matters is that it is static. There does seem to be a random component: Quote No, what they did change is that the simulation will run the circuit 3 times. And if there's an invalid connection, like connecting NOT inputs and outputs together then the simulation of that circuit is halted until it is changed in any way. At which point it will try 3 times again. Connecting a NOT in a loop is not "invalid". The only thing it could be is non-convergent in the same sense as a spreadsheet. Now, if you mean they are running 3 iterations and check for convergence, then why does the following 2-gate construct oscillate? It does oscillate, incidentally, 1500 times per cycle, and that means by some easy math, once per 2/5 sec. And since this circuit changes it state on every recalculation, that pretty much means 5 recalculations per second. Anyways, listen. You are now deep into a defensive battle you cannot win. You just do not really understand what you are talking about and it shows. I suggest you stop digging yourself deeper.. Link to comment Share on other sites More sharing options...
Saturnus Posted February 28, 2020 Share Posted February 28, 2020 3 minutes ago, Gurgel said: It does oscillate, incidentally, 1500 times per cycle, and that means by some easy math, once per 2/5 sec. And since this circuit changes it state on every recalculation, that pretty much means 5 recalculations per second. Anyways, listen. You are now deep into a defensive battle you cannot win. You just do not really understand what you are talking about and it shows. I suggest you stop digging yourself deeper.. See post above... and cower... Link to comment Share on other sites More sharing options...
JoeW Posted February 28, 2020 Share Posted February 28, 2020 Please keep things constructive. You can disagree without being argumentative. Thanks. Link to comment Share on other sites More sharing options...
Gurgel Posted February 28, 2020 Share Posted February 28, 2020 11 minutes ago, Saturnus said: See post above... and cower... Nope. It still does not matter what the tick actually is. That is a complete side-issue here. The question was whether gates are free-running or clocked. And they are clocked. Link to comment Share on other sites More sharing options...
Saturnus Posted February 28, 2020 Share Posted February 28, 2020 20 minutes ago, Saturnus said: Apparently, connecting a NOT to itself still makes an oscillator. The game just picks to show it as constantly off or on instead of trying to flicker the gates And it was just a bug in the automation overlay it turns out. Works as before now, ie. flickering like a Duracell bunny on speed. 29 minutes ago, Ipsquiggle said: A bug causing the Automation Overlay to only update on every second automation tick has been fixed. It should be easier to see and debug rapidly-switching circuits now. Link to comment Share on other sites More sharing options...
psusi Posted February 28, 2020 Share Posted February 28, 2020 20 minutes ago, Saturnus said: Apparently, connecting a NOT to itself still makes an oscillator. The game just picks to show it as constantly off or on instead of trying to flicker the gates. That makes sense. 20 minutes ago, Saturnus said: The picture below proves the main point that the game tick is indeed 1/10th of a second. Top counter is buffer at 0.2s Middle counter is buffer at 0.1s Bottom counter is no buffer. I'm not sure what you are using there as counters, but I don't see any feedback, so what is making it oscillate? 20 minutes ago, Gurgel said: It does oscillate, incidentally, 1500 times per cycle, and that means by some easy math, once per 2/5 sec. And since this circuit changes it state on every recalculation, that pretty much means 5 recalculations per second. This also makes sense, but how do you explain Saturus's experiment? 3 minutes ago, Gurgel said: Nope. It still does not matter what the tick actually is. That is a complete side-issue here. The question was whether gates are free-running or clocked. And they are clocked. I think we all agree that it is clocked, the question is how fast. Link to comment Share on other sites More sharing options...
Saturnus Posted February 28, 2020 Share Posted February 28, 2020 8 minutes ago, Gurgel said: Nope. It still does not matter what the tick actually is. Of course it matters. You don't get to choose what matters. 8 minutes ago, Gurgel said: That is a complete side-issue here. The question was whether gates are free-running or clocked. And they are clocked. That is however irrelevant to the discussion because I don't think anyone argued the opposite point. 4 minutes ago, psusi said: I'm not sure what you are using there as counters, but I don't see any feedback, so what is making it oscillate? I'm using the counter in the automation update preview. It's a positive edge detector. That the counter on the bottom counter is double that of the middle counter proves that a 0.1s buffer and a NOT gate is precisely the same length of time. Which proves the tick is exactly 0.1s (in so far that a 0.1s buffer or not gate is in fact the same as 0.1s of game time). Link to comment Share on other sites More sharing options...
Gurgel Posted February 28, 2020 Share Posted February 28, 2020 4 minutes ago, psusi said: I think we all agree that it is clocked, the question is how fast. 10 times a second. Makes for 5 counter updates a second, as an update requires two changes. My manual measurements with a stop-watch were off because of this bug here, that has just now been fixed: "A bug causing the Automation Overlay to only update on every second automation tick has been fixed. It should be easier to see and debug rapidly-switching circuits now." Link to comment Share on other sites More sharing options...
psusi Posted February 28, 2020 Share Posted February 28, 2020 5 minutes ago, Saturnus said: That the counter on the bottom counter is double that of the middle counter proves that a 0.1s buffer and a NOT gate is precisely the same length of time. Which proves the tick is exactly 0.1s (in so far that a 0.1s buffer or not gate is in fact the same as 0.1s of game time). It would if there were feedback making it oscillate, but where's the feedback? How is the circuit ever changing state? 2 minutes ago, Gurgel said: 10 times a second. Makes for 5 counter updates a second, as an update requires two changes. My manual measurements with a stop-watch were off because of this bug here, that has just now been fixed: Oh, so a tick is 1/10th of a second? OK... Link to comment Share on other sites More sharing options...
Gurgel Posted February 28, 2020 Share Posted February 28, 2020 12 minutes ago, Saturnus said: Of course it matters. You don't get to choose what matters. What is your issue? In a discussion on whether a gate is clocked or not, the rate does not matter. Obviously. And incidentally, I _do_ get to chose what matters to me. You do not get to tell me differently though. Ah, well. Time to find that ignore-function again... Link to comment Share on other sites More sharing options...
Saturnus Posted February 28, 2020 Share Posted February 28, 2020 So to further prove the tick is indeed 0.1s. Here's the counter set up again. The top one is now an OR as buffer. As you can see it's exactly the same count as the not gate plus 0.1s buffer. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.
Please be aware that the content of this thread may be outdated and no longer applicable.