2023-09-03 00:14:58 <KipIngram   > So I'm still kicking around these thoughts from earlier, re: handling high data content objects (fields, etc.) on a calculator or a computer etc.  I'm thinking this is where AI can come into these tools.  It's not really enough for the tool to allow you to construct complex objects, because that puts the human in the loop and that's a bottleneck.  I'm not going to be manually entering a big finite element
2023-09-03 00:15:00 <KipIngram   > grid into a calculator.  But - if the machine can do that heavy lifting for you, and just let the result be another object that you can manipulate and have shown to you on screen and so on?  That makes it something you could actually think about doing.
2023-09-03 00:15:48 <KipIngram   > So it should just figure out what kind of objects your equations imply the existence of, know how to build the data structures required to represent them, know how to do the calculations around them, etc.
2023-09-03 00:17:02 <KipIngram   > And in the end what you actually want from it might wind up being just one or two numbers anyway - maybe you want the total stored energy in some configuration of conductors or something.
2023-09-03 03:15:26 <xelxebar    > : MARKER  CREATE latest @ , DOES> @ (forget) ;
2023-09-03 03:15:49 <xelxebar    > Gah. Unwinding that took some effort.
2023-09-03 03:17:29 <xelxebar    > Looks like MARKER just creates a word that resets the data area to what it looked like before defining the word.
2023-09-03 03:18:18 <xelxebar    > Well, of course, if you manually muck about with words defined before the marker, it doesn't know about that.
2023-09-03 03:23:58 <xelxebar    > So CREATE just makes a word that puts a pointer to it's body on the stack when called.
2023-09-03 03:25:31 <xelxebar    > And DOES> just lets you "append" extra handling code.
2023-09-03 07:52:44 <veltas      > xelxebar: MARKER words are actually meant to restore the search order as well
2023-09-03 07:53:11 <veltas      > But in a Forth that doesn't have the search words you can just do what they've done
2023-09-03 07:53:28 <veltas      > FORGET is much nicer if you don't have search order
2023-09-03 07:54:14 <xelxebar    > Interesting. FORGET literally just updates the Latest pointer in SmithForth, so I guess it doesn't have this search order stuff.
2023-09-03 07:54:26 <veltas      > FORGET doesn't affect search order
2023-09-03 07:54:35 <veltas      > That's why it's deprecated in standard Forth
2023-09-03 07:54:48 <xelxebar    > What's the search order stuff? I've never heard about it.
2023-09-03 07:55:16 <veltas      > Well in a classic Forth there's one linked list through the dictionary with all the names
2023-09-03 07:55:41 <veltas      > In a forth with vocabularies or search orders you can have multiple 'starting points' with different words linked
2023-09-03 07:55:54 <veltas      > And those would be different 'vocabularies' or 'wordlists'
2023-09-03 07:56:31 <veltas      > In the newer standards they're called wordlists, can be created with WORDLIST, and added to the search order using things like ALSO or GET-ORDER/SET-ORDER
2023-09-03 07:57:15 <veltas      > And there's also a 'current' wordlist which is where new definitions go, controlled with DEFINITIONS and GET-CURRENT/SET-CURRENT
2023-09-03 07:57:53 <veltas      > The point of search order is each wordlist in the order is searched, in order, for a word at interpreter or given to FIND
2023-09-03 07:58:37 <veltas      > The oldest Forths with this kind of feature would change the wordlist with words like FORTH EDITOR and CODE
2023-09-03 07:59:17 <veltas      > Wordlists can also be used to make scoped definitions of a sort, like PACKAGE in polyforth
2023-09-03 07:59:26 <xelxebar    > Oh... I see. So there can be multiple linked lists and then some global list lets you "paste" those together in whatever permutations you please.
2023-09-03 07:59:32 <veltas      > Yeah
2023-09-03 07:59:41 <veltas      > And MARKER saves the current state of the search order
2023-09-03 07:59:53 <veltas      > So you can restore it when you 'forget' with the MARKER word
2023-09-03 08:00:17 <veltas      > Most importantly to avoid leaving a forgotten wordlist in the search order
2023-09-03 08:00:47 <xelxebar    > Makes sense.
2023-09-03 08:01:08 <veltas      > FORGET works better without the concept of search orders
2023-09-03 08:01:58 <veltas      > In my design (not implemented) you can use FORGET anyway because I'm going to put a linked list through WORDLIST records, to enumerate all of them
2023-09-03 08:02:13 <veltas      > So I can just remove any wordlists in the search order that have been forgotten when I FORGET
2023-09-03 08:02:31 <xelxebar    > In practice, how do you generally see MARKER and FORGET get used?
2023-09-03 08:02:35 <veltas      > But for some reason that was considered bloated for the standard and they gimped it.....? I don't understand the standard decisions
2023-09-03 08:02:56 <veltas      > To clean up after you've loaded something incorrectly or you've finished working with somethng that's been loaded
2023-09-03 08:03:06 <veltas      > Or cleaning up after defining stuff at the terminal
2023-09-03 08:03:22 <veltas      > Or to reload something after modifying it on disk
2023-09-03 08:06:00 <KipIngram   > How did the standard muck it up?
2023-09-03 08:06:13 <veltas      > They've deprecated and removed FORGET
2023-09-03 08:06:23 <veltas      > On basis that you can't restore search order
2023-09-03 08:06:27 <veltas      > But that's not really true
2023-09-03 08:06:58 <veltas      > So instead we have MARKER which requires knowing what you can't know ... where you want to remove things in advance of wanting to remove them
2023-09-03 08:07:05 <gordonjcp   > veltas: wait, what
2023-09-03 08:07:39 <gordonjcp   > restore what search order?
2023-09-03 08:08:01 <veltas      > IMO they should have made FORGET just remove wordlists that are forgotten from the search order, which is easy to find out
2023-09-03 08:08:20 <veltas      > Because those wordlists are probably just the ones which have a higher address than the forget address
2023-09-03 08:08:27 <KipIngram   > Absolutely agree.  FORGET shouldn't try to work "within a vocabulary."
2023-09-03 08:08:36 <KipIngram   > It should be "dictionary oriented."
2023-09-03 08:09:01 <veltas      > gordonjcp: The search order i.e. the order of wordlists to try when looking up definitions
2023-09-03 08:09:16 <veltas      > In a standard forth with vocabularies / search wordset
2023-09-03 08:09:29 <gordonjcp   > veltas: surely that's just the current vocabulary and then the "default" vocabulary?
2023-09-03 08:09:53 <gordonjcp   > and if FORGET clobbers the vocabulary you're in, reset it to default
2023-09-03 08:10:01 <veltas      > Yeah that's fine too
2023-09-03 08:10:14 <KipIngram   > I would just have FORGET prune back the dictionary and tacitly discard any existing search order beyond FORTH.
2023-09-03 08:10:16 <veltas      > Forth 83 and later standards have multiple vocabs at once
2023-09-03 08:10:28 <veltas      > With ONLY / ALSO / PREVIOUS et al
2023-09-03 08:10:48 <KipIngram   > gordonjcp: There are a lot of ways that can foul you up if you try to be "fancy" about it.
2023-09-03 08:11:00 <gordonjcp   > KipIngram: "fancy" is not the Forth way
2023-09-03 08:11:27 <veltas      > Yeah in typical fasion the standard is overly fancy
2023-09-03 08:11:30 <KipIngram   > I agree.
2023-09-03 08:11:44 <veltas      > And makes bad design concessions that aren't even necessary
2023-09-03 08:13:12 <KipIngram   > I don't really see how MARKER helps remove all those potential problems.
2023-09-03 08:13:32 <veltas      > The idea is with MARKER we can save the current search order
2023-09-03 08:13:43 <veltas      > So when you use a MARKER word it can restore that saved search order
2023-09-03 08:14:27 <KipIngram   > Oh I see.  No attempt to forget "within" a vocabulary - just trying to make things be exactly like they were when MARKER was defined.
2023-09-03 08:14:29 <veltas      > You can't really do that with FORGET... but you can reset the search order (i.e. ONLY FORTH) as gordonjcp suggested or just remove forgotten wordlists from order
2023-09-03 08:14:43 <KipIngram   > Yes - that' sexactly what I'd do.
2023-09-03 08:14:48 <veltas      > So it's sort of an imagined problem
2023-09-03 08:14:50 <KipIngram   > (ONLY FORTH).
2023-09-03 08:14:53 <veltas      > Committees do produce this
2023-09-03 08:15:17 <KipIngram   > The "payoff" seems to small to warrant the complication to me.
2023-09-03 08:15:23 <KipIngram   > too
2023-09-03 08:15:54 <KipIngram   > I do see that it is a "small" benefit.
2023-09-03 08:16:07 <veltas      > Well from my experience I'll say that search order doesn't add much complication to the forth
2023-09-03 08:16:12 <veltas      > But it does make it harder for the user
2023-09-03 08:16:17 <KipIngram   > They want you to be able to immediately repeat a LOAD command or something, without having to recreate your context.
2023-09-03 08:16:32 <veltas      > I don't like using it at all, it feels appropriate only for source code and not interactive use
2023-09-03 08:16:38 <KipIngram   > Oh, I didn't mean that having vocabularies isn't worth it.
2023-09-03 08:16:41 <KipIngram   > They're useful.
2023-09-03 08:18:21 <veltas      > I think one-deep search order i.e. 'vocabs' in classic meaning is fine
2023-09-03 08:18:29 <veltas      > Like EDITOR and CODE etc
2023-09-03 08:19:13 <KipIngram   > I usually do support a list of search vocabs.
2023-09-03 08:26:50 <veltas      > If you think that's bad look up ENVIRONMENT?
2023-09-03 08:27:03 <veltas      > Which is a core word i.e. required on everything from smallest to largest
2023-09-03 09:11:22 <KipIngram   > Yuck.
2023-09-03 09:11:53 <KipIngram   > How on Earth did they decide that should be in CORE?
2023-09-03 09:13:16 <KipIngram   > I haven't given it a LOT of thought, but my kneejerk feeling is that CORE should be limited mostly to words that are very "processor centric."
2023-09-03 09:13:26 <KipIngram   > Or hardware centric.
2023-09-03 09:13:44 <KipIngram   > And not have any dependency on the higher level structure of your "situation."
2023-09-03 09:14:29 <KipIngram   > I mean, sure - MAYBE you're using your Forth in a sort of OS-like way.  But also maybe you're doing nothing more than poking at some peripheral.
2023-09-03 09:14:44 <KipIngram   > In the latter situation you don't want any system-level baggage.
2023-09-03 09:17:30 <KipIngram   > I suppose maybe the argument is that in order for a Forth to bootstrap itself up to the desired level of operation, there needs to be a "standard" way to gather information about what's going on and what you should do.
2023-09-03 09:18:01 <KipIngram   > But I would say that the designer of the system at hand should just KNOW what the system is supposed to do and load the right code.
2023-09-03 09:18:23 <KipIngram   > The idea that your Forth wakes up in a total vacuum and has to be able to figure things out in a fully generic way just seems to be missing the point to me.
2023-09-03 10:01:15 <KipIngram   > It's almost as though the mind-set going on there was that they wanted for an entirely standard Forth to be able to "wake up" and become anything whatsoever, from a simple device driver to a full-fledged operating system, witout having to step outside the standard.
2023-09-03 10:01:39 <KipIngram   > without
2023-09-03 10:02:31 <KipIngram   > Whereas I'd just let the code in my low-numbered block do whatever job needed to be done.
2023-09-03 10:12:06 <KipIngram   > I'm trying to think through how this stuff I was talking about yesterday would work.  Let's say you provide your system with, as an example, the equation of a vibrating string.  That alone is enough to alert the system that you're going to be working with a one-dimensional continuous structure.  Suupposedly at some point you will define boundary conditions - that defines a range of interest in that one
2023-09-03 10:12:08 <KipIngram   > dimension.  That's enough right there for an initial grid to be set up..  Then the grid could be refined dynamically based on the actually solution - you might see the behavior in some part of the solution and that would tell you you needed more resolution there.  Similar to dynamic step size adjustment in simulations.
2023-09-03 10:12:44 <KipIngram   > Let's say instead your equation has two spatial coordinates in it instead of one.  Ok, that means you need a 2D array, and THAT means that your boundary conditions are now 1D instead of points.
2023-09-03 10:14:22 <KipIngram   > A lot of the tech in finite element analysis involves fancy elements (quadratic, etc.).  But for the sort of thing I'm talking about I think maybe you keep that simple.  If you're dealing with a 2D region, you grid it with triangles.  Then to refine a part of that grid you can just drop points in the center of a set of triangles and then each one of those triangles becomes three triangles.
2023-09-03 10:15:04 <KipIngram   > Same idea would work in higher dimension - I think the general term they use for such things is "simplex."  In 3D it's a tetrahedron, etc.
2023-09-03 10:22:57 <KipIngram   > I still haven't figured out how to get the DM-42 solver to give me a quadratic's second root.
2023-09-03 11:30:42 <veltas      > KipIngram: That definition of core being essentially the 'kernel' is what older standards used
2023-09-03 11:31:16 <veltas      > The new one 'core' is just the required words for all standard forths, so words that are absolutely necessary to have a 'forth' standard system
2023-09-03 11:31:35 <veltas      > So basic stack manip, interpreter controlling words, lookup, etc is all in there
2023-09-03 11:32:03 <veltas      > But no block words, file I/O, exceptions, locals, search order stuff, ....
2023-09-03 11:33:57 <veltas      > The ANS committee were nice enough to make block words *mandatory* for any system with mass storage access, i.e. blocks are considered a first-class I/O method
2023-09-03 11:34:23 <veltas      > If you have any mass storage access then you have to implement blocks
2023-09-03 11:45:32 <veltas      > When I say "older standards" I mean like Forth 83 (?) or older
2023-09-03 12:20:32 <KipIngram   > Yes, that makes sense, and I'm also happy about the  block system requirement.  But that ENVIRONMENT thing doesn't seem to fit the "necessary" category to me.
2023-09-03 12:21:02 <KipIngram   > To me the argument for blocks is simple - it's *how the hardware actually works*.
2023-09-03 12:21:36 <KipIngram   > And Forth should always provide "hardware direct access."
2023-09-03 12:21:39 <thrig       > ... so if we extend the meta-block protocol to run on top of Kubernetes ...
2023-09-03 13:32:01 <KipIngram   > I'm not super impressed with the DM-42's solver at least insofar as polynomials go.  It doesn't seem to be able to find complex roots, which seems like a pretty bad shortcoming on a device that purports to support complex arithmetic.
2023-09-03 13:32:26 <KipIngram   > Also, I still haven't figured out how to get "other" roots - it just seems to find one, and that's that.
2023-09-03 13:34:08 <veltas      > Yeah ENVIRONMENT? is really badly designed. It doesn't fit with Forth, yet alone in the core words
2023-09-03 13:34:42 <KipIngram   > I had a program for polynomials I wrote in college for the 41-CV; it would find a roOT (real or complex).  If the found root was real, it would then divide it out of the polynomial.  If it was a complex root, then we know the complex conjugate is also a root, so it would divide out the product of those.  Then I could repeat.  So I could just peel out all of the roots, one by one.
2023-09-03 13:34:57 <veltas      > IMO they should have just given standard words you can expect in a word set, and then used FIND to determine if the word set is present
2023-09-03 13:35:18 <veltas      > And then if you want to check a size then have standard words containing those sizes
2023-09-03 13:35:23 <KipIngram   > veltas: I've thought about having a word that will write out an "environment" record, using blocks to support a stack of those.
2023-09-03 13:35:51 <KipIngram   > That way a word could save the current environment, make any changes it needed to make (to BASE, the search path, whatever), and then pop the old environment back into place when it was done.
2023-09-03 13:38:10 <KipIngram   > Seemed more friendly than having to have programs use ad hoc methods to do such things.
2023-09-03 15:26:17 <KipIngram   > Aiiieeeeeeee.....  One of my daughters just told us she's expecting.
2023-09-03 15:26:30 <KipIngram   > Mid March!
2023-09-03 15:30:45 <veltas      > Congrats man
2023-09-03 15:59:20 <gordonjcp   > KipIngram: woot!
2023-09-03 20:11:05 <KipIngram   > So, now I keep thinking about roots of polynomials.  We can use Newton's method to find a root, and I think that works fine with real or complex roots.  And it's easy enough to divide an (x-root), or an (x^2+root^2) conjugate pair, out of the polynomial.  I'm wondering, though, how feasible would it be to go straight for an (x^2+a*x+b) term, and divide those out?  Then you'd only ever be doing real
2023-09-03 20:11:07 <KipIngram   > arithmetic.  And we have an explicit expression for the roots associated with a term like that.
2023-09-03 20:14:56 <KipIngram   > Newton's method is x(i+1) = x(i) - f(x(i))/f'(x(i)).
2023-09-03 20:16:04 <KipIngram   > So in what I'm thinking about, it's the coefficients a and b that are the independent variables, and the "function" we seek to zero out is the remainder after diving x^+a*x+b out of the original polynomial.  It will have linear and constant terms - call them u and v.
2023-09-03 20:16:46 <KipIngram   > f(a,b) would just be (u,v), and f'(a,b) would, I think, be the Jacobian matrix formed of partial derivatives:
2023-09-03 20:17:03 <KipIngram   > [ du/da  du/db ]
2023-09-03 20:17:12 <KipIngram   > [ dv/da  dv/db ]
2023-09-03 20:17:43 <KipIngram   > Dividing by that matrix would be multiplying by its inverse.
2023-09-03 20:18:39 <KipIngram   > So, [a,b](i+1) = [a,b](i) - [u(a,b) v(a,b)]*inverse(Jacobian)
2023-09-03 20:21:04 <KipIngram   > https://web.mit.edu/18.06/www/Spring17/Multidimensional-Newton.pdf
2023-09-03 20:22:33 <KipIngram   > https://imgur.com/a/fpZfz7v
2023-09-03 23:57:25 <KipIngram   > Wow, that "Spinors for Beginners" video playlist I linked yesterday is just outstanding.  I finished the whole thing just now.
2023-09-03 23:57:54 <KipIngram   > I think there's more to come - he made reference to the "next video" during the last playlist item.  I'll be watching for that one.
2023-09-03 23:58:25 <KipIngram   > This heavily leaned on that "geometric algebra" stuff I've mentioned here before.  That stuff that "isn't really taught" in the mainstream curriculum that I think should be.
2023-09-03 23:58:44 <KipIngram   > It just makes everything so damn streamlined.
2023-09-03 23:59:13 <KipIngram   > It's also sometimes referred to as "Clifford algebras."