2023-09-12 05:46:20 <xelxebar    > KipIngram: Ah, yes. The classic example of a second-order phase transition model. Trying to model the Curie temperature transition of ferromagnets is, surprising, still a really active area of research, AFAIU.
2023-09-12 05:46:35 <xelxebar    > How the heck did you end up there from Galton boards? :P
2023-09-12 05:47:06 <xelxebar    > Regarding diamond, if I understand you correctly, then no. APL expressions are always executed line-by-line or expression-by-expression.
2023-09-12 05:47:28 <xelxebar    > I guess I see what you mean about LF having semantics.
2023-09-12 09:55:23 <KipIngram   > Yes, I didn't mean to "overstate" the line semantic thing - I don't really see it as any kind of "show stopper."  Just a small amount of "dissonance" between the two ecosystems.
2023-09-12 09:55:54 <KipIngram   > I think it will be easy enough to work around - I don't see any reason why APL expressoins couldn't come along and happily manipulate arrays living in the Forth system's data environment.
2023-09-12 09:56:23 <KipIngram   > It's really just a "toolkit" for doing sophisticated manipulations to sophisticated data structures.
2023-09-12 10:02:05 <KipIngram   > Apparently there was a big controversy some time back about the "computer aided" proof of the four color theorem.  That's the notion that with just four colors you can color in any map such that no two adjacent regions share a color.
2023-09-12 10:02:21 <KipIngram   > Lot of math guys thought that the computer proof gave no "insight."
2023-09-12 10:02:30 <KipIngram   > But I think that's picking nits.
2023-09-12 10:02:58 <KipIngram   > If you just start drawing graph nodes, you can put down one node.  Then a second, connected to the first.  Then a third connected to the other two.  You now have a triangle.
2023-09-12 10:03:33 <KipIngram   > You can add a fourth node and connect it to all three of the others (no crossed lines allowed), but in order to do so you have to "envelop" one of the first three.
2023-09-12 10:03:44 <KipIngram   > So you can't then add a fifth and connect it to all of the other four.
2023-09-12 10:04:21 <KipIngram   > So, I think that's the "insight" right there.  It's a little sad that's not a complete proof, but I think the fact that the remainder of the proof gives no insight is just because we already got the insight in those first few steps.
2023-09-12 10:04:56 <KipIngram   > The fact that that last arc added for the fifth node "encloses" a node - that's the insight right there.
2023-09-12 10:05:27 <KipIngram   > That whole mountain of stuff they did with the computer was really just "shoring up" that first fundamental insight.
2023-09-12 11:07:02 <KipIngram   > The logistic map is fascinating.
2023-09-12 11:42:49 <thrig       > math types generally hated on computers (until the chaos stuff came around)
2023-09-12 12:20:55 <KipIngram   > I have no trouble accepting that such a thing can be a "proof" in the strict sense yet still not be as desirable as a  "intuition building" proof.
2023-09-12 12:21:07 <KipIngram   > so, perhaps not the "best" proof, but a proof nonetheless.
2023-09-12 12:57:05 <rendar      > in your Forth implementations how do you manage output? is that a buffer that you write into when "." is encountered, and the the buffer is displayed onto the screen?
2023-09-12 13:27:13 <crc         > I just write to some output device (mostly /dev/stdout on unix; serial on embedded targets)
2023-09-12 13:29:04 <crc         > the output gets routed through a single word `c:put`, which can be altered to redirect or capture output to a buffer
2023-09-12 13:29:23 <crc         > (see an example of this at https://retroforth.org/examples/capture-output.retro.html )
2023-09-12 13:50:30 <rendar      > i see
2023-09-12 13:51:07 <rendar      > crc, is that your own version of Forth?
2023-09-12 13:51:26 <crc         > yes
2023-09-12 13:51:49 <rendar      > that's interesting, its : used for namespaces?
2023-09-12 13:53:05 <crc         > I use a <namespace>:<name> convention for word names
2023-09-12 13:54:00 <rendar      > i see
2023-09-12 13:56:27 <rendar      > another thing, let's say i have in the stack something, that maybe an integer, or even a more complex object like a rectangle. Usually in Forth, let's say you want to calc a property of this data, e.g. counting zeros for the integer, or area of the rectangle, you usually pop off the old object, and push into the stack the result, or just leave the original object and push the result?
2023-09-12 13:57:54 <thrig       > usually old goes away and result remains. but this can vary.
2023-09-12 14:01:01 <rendar      > thrig, ok i'm interested exactly on that 'vary', can you elaborate more?
2023-09-12 14:01:14 <rendar      > e.g. giving some example when the old doesn't go away
2023-09-12 14:02:17 <crc         > It'd depend. If I need to do something else with the item on the stack, I'd leave it on the stack (or write the words that operate on them leave it).
2023-09-12 14:05:15 <crc         > I normally write words to consume values though; I can easily `dup` or similar if I need to keep a value on the stack afterwards
2023-09-12 14:07:09 <KipIngram   > rendar: Yes, I suspect the most common approach is to just write to a device.  I am wanting to try to have some kind of 'i/o stream' model in my upcoming one, though.
2023-09-12 14:07:44 <KipIngram   > At the application level, the code will just read from our write to a buffer, and threads running under the hood will know how to maintain those buffers.
2023-09-12 14:08:13 <KipIngram   > Sort of a "device" model.  At the app level I'll just have something like stdin, stdout, stderr, or "other devices."
2023-09-12 14:08:34 <KipIngram   > The code that actually reads the keyboard / writes the screen might even be on a different system.
2023-09-12 14:09:02 <KipIngram   > So on the target a background thread would take the content from the device buffer and send it over some comm channel to my host.
2023-09-12 14:09:10 <KipIngram   > Or receive it from the host and place it in the buffer.
2023-09-12 14:09:16 <KipIngram   > Many details left to be worked out.
2023-09-12 14:10:04 <KipIngram   > There's a paper out there from way back, where Rob Pike talks about "communicating synchronous processes."  I think those ideas come into play here.
2023-09-12 14:10:22 <KipIngram   > But all of this is well beyond where Forth normally "goes."
2023-09-12 14:11:50 <KipIngram   > rendar: In your rectangle example it would normally be that your application code totally kept up with that.  You could code a word so that it took all of the parameters describing a rectangle from the stack and left the area.
2023-09-12 14:12:03 <KipIngram   > Or you might have on the stack a pointer to your rectangle.
2023-09-12 14:12:06 <KipIngram   > It's totally up to you.
2023-09-12 14:13:47 <KipIngram   > In this APL supporting effort, I plan to have the actual data - the arrays themselves - somewhere in RAM, and the stack will hold a pointer to the data.  For all of this "typed" stuff that will be the approach.  So I can use the pointer on the stack to find the data and one way or another also learn the type of the object.
2023-09-12 14:14:11 <KipIngram   > But those pointers will manipulate just like integers, so words like SWAP, OVER, DUP, etc. will be entirely standard.
2023-09-12 14:14:26 <KipIngram   > I've been referring to those as "agnostic" instructions.
2023-09-12 14:15:18 <KipIngram   > One possible rub there will be if I start trying to do reference counts; DUP would in theory increase your reference count, DROP would decrease it, etc.
2023-09-12 14:57:09 <veltas      > rendar: Yes . is usually done via a buffer, standard calls it the "pictured numeric output buffer" which is an awful nmae
2023-09-12 14:57:12 <veltas      > name*
2023-09-12 14:57:30 <veltas      > rendar: Look up standard words <# # #S HOLD #>
2023-09-12 14:57:44 <veltas      > Which are used for numerical output and formatted numbers in standard and most classic forths
2023-09-12 14:57:58 <thrig       > it's FORMAT but not as we know it!
2023-09-12 14:58:20 <veltas      > Simply because it's much easier to build a number in reverse, dividing/modding by BASE each step
2023-09-12 15:27:11 <veltas      > When was FORMAT invented anyway?
2023-09-12 15:28:36 <thrig       > ancient, lisp took it from fortran or maybe something even older
2023-09-12 16:00:20 <KipIngram   > I know FORTRAN had it.
2023-09-12 16:05:06 <KipIngram   > What did COBOL use?  I know it was heavily about reporting.  Did they have PICTURE or PIC or something like that?
2023-09-12 16:19:03 <rendar      > KipIngram, maybe you refer to Pike's Newsqueak paper?
2023-09-12 16:20:55 <KipIngram   > I don't think it was that one.  I guess he had a bunch of papers.
2023-09-12 16:21:09 <KipIngram   > He may have mentioned it, though.  it's been a while since I read it.
2023-09-12 16:22:16 <rendar      > yeah, interesting
2023-09-12 16:22:31 <rendar      > so, every words chooses if it want to 'consume' the last stack value or not..
2023-09-12 16:22:56 <KipIngram   > I was looking into plan9 around that time.
2023-09-12 16:22:57 <rendar      > and consumers and producers words will live together nicely
2023-09-12 16:23:10 <KipIngram   > And Acme.
2023-09-12 16:25:00 <KipIngram   > I can't seen to turn it up right now.
2023-09-12 16:25:46 <rendar      > for instance, what about counting integer one and zeros bits? do you think it would be better to consume the integer itself?
2023-09-12 16:28:11 <KipIngram   > I see references to the paper in our logs, but can't find a link.
2023-09-12 16:28:29 <KipIngram   > I generally think inputs should be consumed.
2023-09-12 16:28:39 <KipIngram   > But it really depends on whether you're going to need it again or not.
2023-09-12 16:28:54 <KipIngram   > If you "occasionally" need it you can always DUP before running your consuming word.
2023-09-12 16:29:19 <thrig       > or have a DOES> that, uh, does fancy things
2023-09-12 16:29:39 <veltas      > KipIngram: If it was called PICTURE or PIC then that explains where "pictured numeric output" terminology in standard forth comes from
2023-09-12 16:29:41 <KipIngram   > But I think of Forth as generally removing inputs and loading up outputs.
2023-09-12 16:30:03 <veltas      > I suspect a few things in Forth come from COBOL
2023-09-12 16:30:06 <KipIngram   > Yeah.  I think Cobol may have used # patterns too.
2023-09-12 16:30:21 <veltas      > Not surprising
2023-09-12 16:30:35 <KipIngram   > Not as individual things like in Forth, but rather, you'd just draw a picture of your number:  #,###.##
2023-09-12 16:30:47 <veltas      > Yeah that looks familiar
2023-09-12 16:31:35 <rendar      > yes i see
2023-09-12 16:33:04 <KipIngram   > rendar: If you don't remove inputs, then they'll be in the way when you need to generate several intermediate solutions.  Generally you'd like to be able to say
2023-09-12 16:33:47 <KipIngram   > (input1 input1 <owrd> output1) (input 2 <word> output 2) (input 3 input 3 <word> output 3)
2023-09-12 16:34:04 <KipIngram   > and have it ready for (output 1 output 2 output3 <final word> final_output)
2023-09-12 16:34:05 <rendar      > i see
2023-09-12 16:34:08 <KipIngram   > If that makes sense.
2023-09-12 16:34:16 <rendar      > yeah i guess so
2023-09-12 16:38:59 <veltas      > thrig: 1956 https://web.archive.org/web/20220704193549/http://archive.computerhistory.org/resources/text/Fortran/102649787.05.01.acc.pdf
2023-09-12 16:39:07 <veltas      > So yeah I suppose it is pretty ancient
2023-09-12 16:40:16 <veltas      > Just think, 1956 is closer to 1890 than 2023
2023-09-12 16:40:26 <KipIngram   > Wow.
2023-09-12 16:40:52 <KipIngram   > I just watched a bunch OF Magnum PI episodes a week or two back - and it hit me one night... "This stuff is FORTY years old."
2023-09-12 16:41:16 <KipIngram   > Feels like yesterday when it premiered.
2023-09-12 16:41:35 <KipIngram   > I remember my 11th grade teacher gushing over it the next day.
2023-09-12 16:41:48 <KipIngram   > Day after the pilot ep, that is.
2023-09-12 16:42:13 <thrig       > we didn't really get TV where I grew up
2023-09-12 16:42:33 <KipIngram   > we got fuzzy TV.  If we got the antenna pointed the right way.
2023-09-12 16:42:41 <KipIngram   > Had to go out and twist the pole when we changed channels.
2023-09-12 16:42:56 <KipIngram   > No TV stations in my town - they were all 50-ish miles away in various directions.
2023-09-12 21:48:45 <KipIngram   > Ok, sometimes is the simple little things that are satisfying.  Watching a Wildberger video.  Simple stuff; he's introducing the basic principles for later.  So, I've always known that if you have two lines ax+by=c and dx+ey=f, you can go through a bit of a rigamarole and find their point of intersection.  Little system of equations, solve it, etc.
2023-09-12 21:49:01 <KipIngram   > But what he just demonstrated is that you can place your lines in what's called the "projective form":
2023-09-12 21:49:25 <KipIngram   > (-c, a, b) and (-f, d, e).
2023-09-12 21:50:01 <KipIngram   > You can put points in projective form too; the point x, y gets written as [1, x, y].  Note the [] for points and () for lines.
2023-09-12 21:50:31 <KipIngram   > Anyway, now the components of the point of intersection of your two lines is just the components of the cross product of the two projective lines.
2023-09-12 21:50:35 <KipIngram   > Bam bam and done.
2023-09-12 21:50:49 <KipIngram   > I know it's ultimately the same arithmetic, but it's PACKAGED in a much more conceptually simple way.
2023-09-12 21:51:21 <KipIngram   > And, what's even cooler, is that there's a duality.  If you have two POINTS and want the LINE that they form, the components of that are exactly the same thing: the components of the cross product of the two projective points.
2023-09-12 21:51:26 <KipIngram   > now that is just quite cool.
2023-09-12 21:51:52 <KipIngram   > So the cross product arithmetic just flips you back and forth between the two "meanings."
2023-09-12 23:47:27 <KipIngram   > xelbar: I think something like foo←4 4⍴0 will give me a dictionary entry foo which will behave as a Forth variable - executing it will leave it's address on the stack.  And of course it's initialized a 4x4 integer array.
2023-09-12 23:48:00 <KipIngram   > Now, I DON'T know if that's going to create a standad Forth header.  The namespaces may not mingle exactly that way.
2023-09-12 23:48:37 <KipIngram   > I haven't thought yet about how to make Forth aware of APL symbols, or vice versa.