2025-02-10 13:54:14 <xentrac     > lisbeths: Forth, Inc., used to sell a database management package, but I don't know what capabilities it provided or how they were implemented.  On a multi-gigahertz processor you can get pretty far with nested loops over parallel arrays though
2025-02-10 13:54:40 <lisbeths    > what are parallel arrays?
2025-02-10 13:56:32 <xentrac     > KipIngram: Sam's work is sufficiently high resolution to build processors for sure; remember that computers predated ICs by 20 years (roughly 01948 to 01968) and predated ICs at the resolution of Sam's chips by 35 years (01948 to 01983)
2025-02-10 13:56:49 <lisbeths    > I'm really looking for a simple datastructure
2025-02-10 13:56:53 <lisbeths    > or a simple algorithm
2025-02-10 13:57:39 <xentrac     > the hardware equivalent of open-source software is when you can find an antifeature in your CPU design's source code, comment it out, and recompile your CPU without the backdoor/bug/limitation/dependency/adware
2025-02-10 13:59:21 <xentrac     > that depends on making the recompilation step easy and autonomous
2025-02-10 14:00:21 <xentrac     > oh, I see veltas answered the database question with the Forth, Inc., manual, which I didn't know about
2025-02-10 14:01:43 <xentrac     > neauoire: that's awesome!  Victoria, BC?  is the Playdate game related to McCulloch–Pitts neurons?
2025-02-10 14:03:28 <xentrac     > Shark8: a directed graph is straightforwardly a relation: create table digraph (src integer, dest integer);
2025-02-10 14:04:58 <xentrac     > though most graph databases have labels on the arcs or nodes; for example, create table unql (src integer, label text, dest ingeger);
2025-02-10 14:05:25 <xentrac     > lf94: congratulations!
2025-02-10 14:08:52 <xentrac     > lisbeths: parallel arrays are where you represent tables with one array per column, with corresponding indices in different arrays representing different attributes of the same object.  So in my examples above you might have a 53-item array named src and another 53-item array named dest.  This was a common way to program in Fortran or BASIC which didn't have structs.  The best explanation I've found of
2025-02-10 14:08:58 <xentrac     > this approach to programming is by Adam N. Rosenberg: http://www.the-adam.com/adam/rantrave/st02.pdf
2025-02-10 14:12:53 <xentrac     > the biggest disadvantage is lifetime management.  You can't create a temporary object as a local variable on the stack, for example, and if you want to delete some objects you need some way to keep track of which ones you've deleted
2025-02-10 14:13:55 <veltas      > xentrac: I linked PolyForth other day, which was written by Forth Inc.  I don't know if they did another database package
2025-02-10 14:13:59 <veltas      > Maybe
2025-02-10 14:14:25 <veltas      > It's described in full in that manual
2025-02-10 14:14:52 <veltas      > Although GeDaMo spotted a mistake
2025-02-10 14:27:58 <xentrac     > I appreciate it!
2025-02-10 14:29:26 <xentrac     > haha: > For example, one company sells a data base system which uses the polyFORTH Data Base Support option to handle 300 Mbytes of data and support 64 simultaneous users with under one-second response time even at peak load, on a single 68000 microprocessor.
2025-02-10 14:30:54 <xentrac     > this manual hasn't been updated lately I think
2025-02-10 14:32:35 <user51      > looks like standard fare when you take into account we're talking about forth  :)
2025-02-10 14:38:57 <xentrac     > if you have 300 Mbytes of data nowadays, or 3000, you should just keep them in RAM
2025-02-10 14:43:47 <xentrac     > I don't think it's accurate to describe PolyForth's system as a "pre-relational" database.  It doesn't support hierarchical nesting, repeated fields, or any of that non-relational nonsense.  Its "files" are relations and its "records" are tuples of a relation.
2025-02-10 14:44:17 <xentrac     > that is, it can only handle data in Codd's "first normal form".
2025-02-10 14:50:00 <xentrac     > the indexing facility described is very primitive.  It uses binary search rather than B-trees, so you need a lot of disk seeks to do a lookup, and insertions require rewriting the whole file, and it doesn't update the index automatically.
2025-02-10 14:53:02 <xentrac     > I guess maybe "pre-relational" is fair in the sense that the main objective of the relational model was decoupling application logic from the physical layout of data on disk, so you could change the layout independently of the logic, and this completely fails to do that.
2025-02-10 15:07:03 <xentrac     > I want to point out that if you want to get chips fabricated, the 130nm Skywater PDK is freely available, and if your design is under a free license, Google will foot the cost for fabbing some prototypes and sending them to you
2025-02-10 15:07:46 <xentrac     > and although the Tiny Tapeout program (using the Skywater PDK) is not actually *free* it's very cheap
2025-02-10 15:08:59 <xentrac     > Skywater supports Magic
2025-02-10 15:09:32 <xentrac     > mostly Skywater is aimed at digital logic, which is kind of a dubious proposition when you can just use an FPGA for that and probably get better performance
2025-02-10 15:09:55 <xentrac     > but it also has some analog standard cells, and 130nm is a lot more tempting for analog than for digital
2025-02-10 15:16:33 <veltas      > Yeah that's roughly what I meant by pre-relational
2025-02-10 15:17:03 <veltas      > I mean it just feels like dbase before SQL, so really I mean pre-SQL, but that was billed as making it 'relational' at the time
2025-02-10 15:22:04 <xentrac     > Oracle started selling SQL in 01979, the same year Ashton-Tate started selling dBase, but Chamberlin and Boyce published their SEQUEL paper in 01974: https://web.archive.org/web/20070926212100/http://www.almaden.ibm.com/cs/people/chamberlin/sequel-1974.pdf
2025-02-10 15:23:17 <xentrac     > with queries like SELECT NAME FROM EMP WHERE DEPT = 'TOY' and SELECT ITEM FROM SALES WHERE DEPT = SELECT DEPT FROM LOC WHERE FLOOR = '2'
2025-02-10 15:24:39 <xentrac     > the difference from current SQL is that you need parens around the nested select now
2025-02-10 15:24:47 <xentrac     > SELECT ITEM FROM SALES WHERE DEPT = (SELECT DEPT FROM LOC WHERE FLOOR = '2')
2025-02-10 15:25:48 <xentrac     > (there are some other significant differences, just not in that query)
2025-02-10 15:39:06 <xentrac     > It's probably worth mentioning that if you build a CPU the way people built CPUs in the 60s and 70s (when they couldn't use microprocessors), by building it up out of discrete logic, it will be enormously cheaper today.  JLCPCB will sell you a 74HC164 shift register for 9.04¢ plus 7¢ in soldering costs
2025-02-10 15:51:16 <xentrac     > that plus a CD4051 (15.01¢ plus soldering) gives you a three-bit LUT
2025-02-10 15:54:30 <xentrac     > (you shift the truth table into the shift register at startup and then use the CD4051 to select one of the bits)
2025-02-10 16:52:15 <veltas      > Any plans to do something like that?
2025-02-10 17:17:11 <xentrac     > I've thought about it but Argentine import restrictions make it impractical for me at the moment
2025-02-10 17:26:51 <xentrac     > here's an example from just now (in Python) of what I was saying about queries by looping over data in RAM: len({m['sym'] for m in k.manifests.values() if 'expiry' not in m})
2025-02-10 17:28:43 <xentrac     > if you don't speak Python, that loops over the key-value dictionary k.manifests, and for each value dictionary in it, checks to see if the key 'expiry' is present in that dictionary; if so, it adds the value associated with the key 'sym' to a set of unique stock symbols, and then at the end it finally reports the size of that set
2025-02-10 17:30:56 <xentrac     > on the cloud server I'm running it on, it takes 53 milliseconds to run over 37830 key-value pairs, which is adequate for my interactive exploration purpose
2025-02-10 17:32:24 <neauoire    > xentrac: the game is not related to neural nets no, it's an illustrated puzzle page
2025-02-10 17:32:29 <neauoire    > puzzle game*
2025-02-10 17:32:49 <neauoire    > I've been trying to replace makefile with a little system of my own running on NNs
2025-02-10 17:33:19 <neauoire    > since it's so easy to implement on small systems, I find it was a bit more realistic than implementning make on uxn
2025-02-10 17:33:19 <thrig       > 
ACTION gets headache from trying to read python and decides (again) to stick with perl

2025-02-10 17:33:30 <xentrac     > oh, is that what the McCulloch–Pitts thing is about?
2025-02-10 17:33:39 <neauoire    > yup!
2025-02-10 17:33:48 <neauoire    > it's the ideal declarative language
2025-02-10 17:34:00 <xentrac     > I think implementing make on uxn is totally plausible.  make was originally implemented on a PDP-11 which also had a 64KiB address space
2025-02-10 17:34:01 <neauoire    > it parallelizes really well, whereas rewriting typically doesn't
2025-02-10 17:34:22 <neauoire    > It is, it's just a pain
2025-02-10 17:34:39 <neauoire    > whereas I've already got NNs on uxn
2025-02-10 17:34:40 <neauoire    > https://git.sr.ht/~rabbits/neur/tree/master/item/src/neur.tal
2025-02-10 17:36:07 <xentrac     > thrig: in Perl that would be something like () = @{[keys %{{map {$_->{sym} => 1} grep {!exists $_->{expiry}} keys %{$k->{manifests}}}}]}
2025-02-10 17:36:14 <xentrac     > does that help?
2025-02-10 17:37:10 <thrig       > what's the () = for
2025-02-10 17:37:24 <xentrac     > to count the number of items in the ARRAY
2025-02-10 17:37:39 <xentrac     > but maybe I'm remembering that wrong and you should just say scalar
2025-02-10 17:37:46 <thrig       > scalar can do that well enough, or just scalar context my $count =
2025-02-10 17:37:53 <xentrac     > neauoire: I suggest not calling them "neural networks" because they're almost completely unrelated to both actual networks of neurons and what people call "neural networks" today
2025-02-10 17:38:10 <neauoire    > dunno how to call them
2025-02-10 17:38:24 <xentrac     > McCulloch–Pitts networks?
2025-02-10 17:38:35 <neauoire    > that sounds like some sort of disease
2025-02-10 17:38:38 <xentrac     > haha
2025-02-10 17:38:42 <xentrac     > poor Pitts
2025-02-10 17:38:56 <xentrac     > he'd be so sad
2025-02-10 17:39:08 <neauoire    > being sad, that was like his thing
2025-02-10 17:40:46 <neauoire    > I've started chipping away at replacing this as my build system these past few days
2025-02-10 17:40:49 <neauoire    > it's coming along
2025-02-10 17:41:09 <xentrac     > it kind of was: "Pitts died in 1969 of bleeding esophageal varices, a condition usually associated with cirrhosis and alcoholism."
2025-02-10 17:41:20 <neauoire    > yeah, his story is super sad
2025-02-10 17:42:01 <xentrac     > you could call it "Walter"
2025-02-10 17:42:34 <xentrac     > thrig: anyway, did that convey the idea?
2025-02-10 17:43:19 <neauoire    > it gives it a kind of Alfred vibe
2025-02-10 18:42:21 <amirouche   > according to kiwix.org, en.wikipedia.org without images is less than 8G
2025-02-10 18:44:39 <amirouche   > and you do not need to load it to ram to scan the pages looking for something
2025-02-10 18:45:28 <amirouche   > re database, I also wonder what is polyforth database
2025-02-10 18:47:59 <amirouche   > I am going through the chapter 8.0 ie. DATA BASE SUPPORT, and it sounds good
2025-02-10 19:27:57 <amirouche   > I will try to go scan thhrough with aho-corasick en.wikipedia.org json dump I have around and see how much time it takes for my own culture, but also adding an argument for why there is an interest in having a database, and in particular indices
2025-02-10 19:28:48 <amirouche   > on a related note, anyone has a version of jonesforth that run on alpine?