Results 1 ... 38 for 'o(1)'...

asciilifeform: btw verisimilitude , you can already 'dispatch in hardware in o(1) by port number' given as ethernet is a bus. set n boxes (1 per port) to sit on same switch, all set to same 'mac', but each only processing packets having its respective port.

verisimilitude: I've seen many discussions in which they clearly need a linked list, but then the ``experienced Googler'' says those are bad, and a vector has ``amortized O(1)'' insertion or such drivel. They get haughty over using just a few data structures.

verisimilitude: Elision is based around O(1) time operations.

asciilifeform: going from hash to item in o(1) is a solved problem.

dulapbot: Logged on 2020-05-03 17:37:59 asciilifeform: trinque: i've been sawing at the 'get rid of bdb, have o(1) indexer in ada instead' thing for 2y+ nao, on&off. principal headache is the obscene impedance mismatch b/w the cpp liquishit and anyffin sane. the 'glue' threatens to be 10x larger than the original coad.

asciilifeform: whaack: 'fixing' bdb is imho outta the question tho, one needs a dedicated item w/ o(1) retrieval of arbitrary blox/tx

asciilifeform: the pill of course aint cement (which is imho necessary but not sufficient) but o(1) db. cement simply removes the time burned on 1) verifying blox which you already know 'aint it' 2) 'waiting with open mouth'

dulapbot: Logged on 2021-11-12 12:48:05 asciilifeform: replacing the db with proper o(1) nqb+cryostat would fix this, bdb is monstrously slow

dulapbot: Logged on 2020-10-01 15:00:29 asciilifeform: gregorynyssa: there's not a thing that'd rise to the level of 'plan'. asciilifeform in particular wrote 3 things: 'nqb', a largely-complete coder/decoder for the formats used in trb; ffa, with which possible to perform the cryptonumerics; and 'cryostat', to implement a o(1) db .

asciilifeform: mats: best of all'd be a o(1) lookup ~in own trb noad~ db

mats: an o(1) lookup would be great

dulapbot: Logged on 2020-10-01 15:00:29 asciilifeform: gregorynyssa: there's not a thing that'd rise to the level of 'plan'. asciilifeform in particular wrote 3 things: 'nqb', a largely-complete coder/decoder for the formats used in trb; ffa, with which possible to perform the cryptonumerics; and 'cryostat', to implement a o(1) db .

asciilifeform: replacing the db with proper o(1) nqb+cryostat would fix this, bdb is monstrously slow

asciilifeform: cgra: indeed asciilifeform proposed a max realistic reorg for nqb, but strictly for allowing readonly o(1) blox db

dulapbot: Logged on 2020-10-01 15:00:29 asciilifeform: gregorynyssa: there's not a thing that'd rise to the level of 'plan'. asciilifeform in particular wrote 3 things: 'nqb', a largely-complete coder/decoder for the formats used in trb; ffa, with which possible to perform the cryptonumerics; and 'cryostat', to implement a o(1) db .

dulapbot: Logged on 2021-10-26 10:32:39 asciilifeform: 'nqb' was actually about this -- attempt to represent traditional tx/blox in a maximally, as possible, 'trbi'-like form, for O(1) storage/retrieval.

asciilifeform: 'nqb' was actually about this -- attempt to represent traditional tx/blox in a maximally, as possible, 'trbi'-like form, for O(1) storage/retrieval.

dulapbot: Logged on 2021-10-03 22:35:27 asciilifeform: not fond of multipacket answers to a 1-packet question, for the simple reason where 'am i expecting this packet?' gotta be O(1) resolvable

asciilifeform not fond of multipacket answers to a 1-packet question, for the simple reason where 'am i expecting this packet?' gotta be O(1) resolvable

dulapbot: Logged on 2020-10-01 15:00:29 asciilifeform: gregorynyssa: there's not a thing that'd rise to the level of 'plan'. asciilifeform in particular wrote 3 things: 'nqb', a largely-complete coder/decoder for the formats used in trb; ffa, with which possible to perform the cryptonumerics; and 'cryostat', to implement a o(1) db .

asciilifeform: gregory4: asciilifeform has a o(1) indexator , but not had time to finish it..

asciilifeform: bonechewer: this also discussed (if not easy to find in O(1)..) -- you authenticate message before acting on it

asciilifeform: o(1) but rather fat constant

whaack: I'm pretty sure I have all the insert operations at O(1), there's just a lot of rows...

gregorynyssa: although nano(1) and links(1) are halfway decent (at the cost of the horrid "ncurses" dependency).

asciilifeform: would run in o(1), too.

snsabot: Logged on 2020-10-01 15:00:29 asciilifeform: gregorynyssa: there's not a thing that'd rise to the level of 'plan'. asciilifeform in particular wrote 3 things: 'nqb', a largely-complete coder/decoder for the formats used in trb; ffa, with which possible to perform the cryptonumerics; and 'cryostat', to implement a o(1) db .

asciilifeform: gregorynyssa: there's not a thing that'd rise to the level of 'plan'. asciilifeform in particular wrote 3 things: 'nqb', a largely-complete coder/decoder for the formats used in trb; ffa, with which possible to perform the cryptonumerics; and 'cryostat', to implement a o(1) db .

snsabot: (therealbitcoin) 2020-05-15 asciilifeform: guaranteed o(1) access.

whaack: Does trb keep a separate index for O(1) lookups of txn's by hash? And you're saying that the hash table becomes corrupted, but perhaps there is another location where the txn / block data is being stored?

asciilifeform finds it odd that (afaik) to date no one implemented proper storage of blox/tx, such that could ask in o(1) 'is this unspent addr', 'how much'

asciilifeform: the metric units which ~did~ catch on, let you answer practical q's in o(1), e.g. how many kalash rounds it'd take to boil a swimming pool w/ N litres, etc. but there's less clear use from 'how far did light travel from the sun in the time since caesar bit it'

asciilifeform: trinque: i've been sawing at the 'get rid of bdb, have o(1) indexer in ada instead' thing for 2y+ nao, on&off. principal headache is the obscene impedance mismatch b/w the cpp liquishit and anyffin sane. the 'glue' threatens to be 10x larger than the original coad.

asciilifeform: cuz if you do, you will 1) have to write one 2) put up with the fact that it can't allocate in O(1) or alternatively 3) can't deallocate in O(1)

asciilifeform: current-day trb aint esp. well tailored for this type of use, either (no support for o(1) querying of outputs)