Unsignad Less

[main sand]

Clean, although not perfect

[fluid garnet]

That's pretty gate efficient 👍.
Now time to make a delay optimised version.

[main sand]

don't ask me why this works (signed less)

[main sand]

why thank you. I'm not good at optimizing though (only routing/optics)

[fluid garnet]

There is a much better way to do this:
||You can just swap the sign bit between the 2 inputs,
to make the unsigned version work for signed numbers & vice-versa.||

[main sand]

you found that out rather quickly, but it makes sense

[fluid garnet]

If I'm not mistaken, then your Unsigned lesssollution is 68gates & 16 delay.
I on the other hand have a 112 gates & 5 delay solution.
It requires some trickery though.

brb

[main sand]

it doesn't fit in my head entirely, it's too complicated

[fluid garnet]

Sorry, it took a while, but here's my solution.
RSH by 1 CCs perform a constant/static logical right shift &
the remaining ones are just the legacy 1 bit switch replacement CCs:

[main sand]

I'm not even gonna pretend to understand how this wiorks or how you came up with this

[crystal musk]

It's the inductive method. A[n..] < B[n..] = A[n] < B[n] or (A[n] = B[n] and A[(n - 1)..] < B[(n - 1)..])

||The OR gates in the top-left calculates X | Y' aka X >= Y. The XOR calculates X ^ Y aka X != Y.

If you expand the inductive method expression I gave for n = 7, you'll end up with (A[7] < B[7]) or (A[7] = B[7] and A[6] < B[6]) or (A[7] = B[7] and A[6] = B[6] and A[5] < B[5]) ...; the long "and" chains are equivalent to "nor" chains with the operands inverted, because of de Morgan's law. Switches give you "or" for free, and the operands are already inverted (the OR and XOR are calculating >= and != instead of < and ==.||

[crystal musk]

(BTW you can get 62/5 if you use a different inductive method)

[fluid garnet]

Is that using switches or is it switch-less?
(I might want to figure out this other way myself so minimal spoilers please).

[crystal musk]

Switches

[valid lily]

my solution, ||just uses XOR gates to get the different bits then selectors to either keep the existing result or change it starting from least to most significant||

signed less ||is just the same with a not gate for the last bit||

[dense pulsar]

The problem with this answer is that it outputs either 1 or Z instead of 1 or 0.

Your bottom 8-input OR needs to be replaced with true OR gates with a total delay of 3 instead of 1.

You've a similar problem with the other switch network.

Best possible result is 9 instead of 5 while using proper OR gates (and having no Z state)

[fluid garnet]

This is not a problem for the game's scoring & this won't likely change ever,
because of the simulation performance implications,
so this solution is perfectly valid in my eyes.

Anyways, while not exactly intended, this is perfectly acceptable & the reason
(or at least one of them) why the [save_breaker] alpha's scoring was changed the way it was,
was because switches in the [stable] release were OP in every possible usecase (that you could use them in),
now you have to actually think how to obtain the best score & not just spam switches everywhere.

If you don't want to take advantage of the Hi-Z -> 0 coercion of input pins, then just don't use it.

[dense pulsar]

"If you don't want to take advantage of the Hi-Z -> 0 coercion of input pins, then just don't use it."

In today's version of alpha, the XOR with 2 NOT and 2 Switches explicitely refuse Hi-Z (which appears as grey) as 0 (which appears as red). So exploiting it is quite unsafe and IMHO, should be avoided as the said coercion is not a given.

[fluid garnet]

That is only a level restriction issue, and in practise (most other levels) could just be bypassed by adding a splitter before the output: #development-branch-feedback message

[dense pulsar]

You just voided the Delay=2 of the 3-port OR decided by the developpers...

[fluid garnet]

In practice the use of that gate is very sub-optimal,
as it disables you from using the intermediary OR gate,
so it is always more optimal to implement it using 2 x 2 input OR gates,
especially if you need the intermediary signal or have the space for it.
Similarly with the 3 input AND gate.

And besides, it is usually beneficial to use normal gates instead of switches,
but as long as they aren't influencing the critical path of the circuit,
as they're always better gate-wise.

[dense pulsar]

Well, depends on the use. For a 8-input AND/OR, chaining 2-input AND/OR would lead to a delay of 3 instead of 4 while using 3x3-input + 1x2-input.

The intermediary signals are not always needed.

Using proper OR would only add 4 to the delay of your solution (which would still be the best atteignable delay without using unsafe hacks which could stop working at a later time and are definitively not "export to verilog" friendly)

[fluid garnet]

I'll never export to verilog, and the hack is not unsafe at all.
This functionality won't go away untill there is going to be significant overhaul of the game,
as it is impractical to fix from the simulation performance point of view as it is.

Besides, you could just pretend that the game uses a pull-down resistor,
for all of the wires and don't think about it.

[quartz moat]

If this isn't export to verilog safe, that is a bug in the exporting functionality. I say that as the person who implemented it.

Using switches for this is fully indented functionality. This might get disabled once/if we get the transistor-based mode, but even then it will stay available in the main game

[dense pulsar]

There are still differences made by TC between Hi-Z and 0. You may test it easily by feeding 0 and 1 through parallel switches, it'll generate an error while if you only feed the 1 (and feed an Hi-Z from the other switch) there are no error.

so I don't think that it'd impact the functionnality that much

[fluid garnet]

I'll be down for implementing circuits using transistors. Even entire circuits 👍.

[dense pulsar]

It could be quite fun... at least for people used to electronics... But for the "basic player" (if any), it could end-up being a real nightmare

(remind me University where I had to create a 8x8 bit pipelined multiplier on Compass)

[quartz moat]

Which is why it will never be the baseline experience

[fluid garnet]

In such cases, you just need to work-around this by eiteher
using more switches or using the existing switches in a different way,
look no further than these messages for an example
(partial spoilers for sub-optimal very fast solutions for Adding Bytes):
#highscore-hunting message
#highscore-hunting message

[dense pulsar]

I don't need "work arounds" for that, it's a bad design... It was more a way to test if there was a difference made between 0 and Hi-Z in the simulation 😉 And there is so flagging an Hi-Z on an input as an error is a trivial change that could happen (not saying that it will happen)

We could even end up with a behaviour like "Hi-Z on input means keep the previous value" (like it would with MOSFET thanks to the gate capacitance)...

[quartz moat]

It will not happen.

The current behavior is the result of 3 years of experimentation.

Something dramatic has to happen for this to be changed.

[dense pulsar]

Like version 3.0

[quartz moat]

Version 2.0 didn't actually change much with regard to how switches behave

Output components just gained the ability to distinguish between Z and 0, which makes them quite unique

[dense pulsar]

[by the way, is it possible to split the discussion and move it to some other (more adequate) channel ?]

Version 2.0 is still not "out of the box" 😉 Who knows what changes may come for the version 3.0 😉

DRAM-like behaviour may add the use for an actual clock signal... which in turn would help in situation like pipelined processing.

[fluid garnet]

While this would be more likely to happen than erroring the circuit on Hi-Z
(as it would be as simple as to initialize a variable to what was on the wire in the previous tick),
but it would likely introduce even worse switch cheese in different situations.

And the only way that you could get the former behavior,
is when we'd get the front-end to perform very complex static analysis of the circuit,
to essentially allow it to test if there could be no or too many signal sources on a wire active at one time,
and then it would throw you some form of circuit compile-time error.
But that's not something that's likely to happen at this point, or ever TBH
(which was my impression of the way Stuffe & Megalng felt about this in other discussions).

[quiet crag]

my terrible solution

clean at least

(and easy to convert to signed)

[abstract scroll]

I think with that exact design you could save at least 15 gates now that I see it

I've found a solution that is 41/16

pretty proud of that, although I know people have done better and I dont know how to improve it xd

[main sand]

I'm terrible at hardware optimization lol. I don't know yall do it. I just barely find out a solution that works. What's your secret?

[abstract scroll]

Its nothing really that hard, you just have to know some tricks, at least to get you started.
First, you usually want to avoid using components, unless in some specific scenario.
Here is what I know:
After you replace the components with their logic gates, you can first see that in 7 of the 8 components of the output "A > B" is followed by a NOT. This means that in those cases you can remove the not gate and replace the AND gate with a NAND gate.
Then you can also see that the output "A = B" in the component is never used, so the NOR that is used there is a waste.
This one is a bit more tricky, but instead of using a NOT gate for both of the inputs in the component, you can NAND both inputs, and use the output for both AND gates you have rn. (This makes you save 7 + 8 + 8 gates)

[main sand]

So leave components away to deobfuscate whats happening on the gate level and with some boolean skills it becomes more visible that the logic is bloated and how to fix it