<div dir="ltr"><div style="font-family:monospace" class="gmail_default">Hello,<br><br>Thank you for your response!<br><br>> While I can't comment about Frontend, and the paths<br>> finding case is clearly correct<br><br>While STD's were built with path-finding in mind, I have to say that front end code is where STD's truly shine imo. Frontend code struggles greatly from separating business logic from rendering logic from data transmission logic. Having a STD allows you to group all of your decision making into a set of paths, and STD's compose so you can latch one on to the other like a train cart, put a few inside of a larger one, nest them like Russian nesting dolls, etc.<br><br>> but from my experience in NLP, having a "frozen<br>> repository" of lookup map is more convenient.<br>> <br>> Specifically, the ability to copy the repository in an<br>> efficient way (as it is just a fixed number of maps) is<br>> very useful for hot-commits ("frozen repo" is active,<br>> while there is a non-frozen repo in the background,<br>> changing all the time, every X amount of time/changes I<br>> copy the non-frozen repo into a frozen repo and replace<br>> the old active with the new frozen repo)<br><br>Lol, that hot swapping is really clever!<br><br>I've actually been working on a path-finding problem using dynamic programming. I have a map that is oriented almost exactly like you put it, but I update on the fly, and that always carries overhead that I wasn't really sure how to shake. I'm going to try that myself. Thank you very much!<br><br><br>But to address your point (which flows nicely from the previous sentence), I don't think one or the other is necessarily the best option at all times. Ultimately, there are times when a lookup map is definitely the best solution forward. A perfect example is when you have a massive, unknown number of transitions from each state. In situations like that, you COULD try and do the direct approach, but that degrades fast. There's a threshold, decided strictly by the number of branches, where directness becomes a poor fit. I've only hit that boundary once before though, and even then, it only meant uprooting one of my STD's, not all of them.<br><br>> You can also do it using cyclic GADT but I don't see how<br>> you both enable fast copying and fast freezing.<br><br>Lol, you don't.<br><br>Long story short, that hasn't really been a need for me. Most of my NLP is working within the grammar, parsing, discoverability side of things. Take a raw english sentence, determine the language parts from it (verb? noun? adjective?), then use that information to quantify, negate, or compare to a known set of entities that are pulled at startup. Then, I use all of that info to answer the users questions. My algorithm starts fresh on each session, as opposed to accumulating data to be used for the next request.<br><br>I'm sure once I get further along, I'll run into the problem that you are describing (persisting the results to be loaded later).<br><br>> You can also sidestep these problems adding util method to add nodes/edges (as in, create new graph with the extra nodes/edges), but this becomes very hard to reason without a reference to every node (or without identifiers, the Poor's-man-ref), in which case you basically have a backing repository with "get frozen copy" method that return your GADT<br><br>I see what you mean. When I get the chance, I am going to try this out and see how it turns out. Not sure how I would approach it.<br><br>Thank you for your time and help!<br>David Alayachew</div><div style="font-family:monospace" class="gmail_default"></div><div dir="ltr"><div class="gmail_default" style="font-family:monospace"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 5, 2023 at 5:09 PM Holo The Sage Wolf <<a href="mailto:holo3146@gmail.com">holo3146@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">While I can't comment about Frontend, and the paths finding case is clearly correct, but from my experience in NLP, having a "frozen repository" of lookup map is more convenient.<div dir="auto"><br></div><div dir="auto">Specifically, the ability to copy the repository in an efficient way (as it is just a fixed number of maps) is very useful for hot-commits ("frozen repo" is active, while there is a non-frozen repo in the background, changing all the time, every X amount of time/changes I copy the non-frozen repo into a frozen repo and replace the old active with the new frozen repo)</div><div dir="auto"><br></div><div dir="auto">You can also do it using cyclic GADT but I don't see how you both enable fast copying and fast freezing. You can also sidestep these problems adding util method to add nodes/edges (as in, create new graph with the extra nodes/edges), but this becomes very hard to reason without a reference to every node (or without identifiers, the Poor's-man-ref), in which case you basically have a backing repository with "get frozen copy" method that return your GADT</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 4, 2023, 22:06 David Alayachew <<a href="mailto:davidalayachew@gmail.com" target="_blank">davidalayachew@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:monospace">Hello Ron,<br><br>Thank you for your response!<br><br>I have to run for holiday festivities, so this will be my last response for several hours. I'll address any future points tomorrow when I get back.<br><br>> Cyclic is in fact possible<br><br>Since I conceded that cyclic is in fact possible (regardless of the trouble I have to go through to get it), there's not much I have to say other than that you are correct, cyclic is in fact possible.<br><br>> BIG problem<br><br>I spend a lot of my time writing front end code, path finding algorithms, and natural language processing. These are basically the 3 realms I spend 90% of my time in. All 3 of these treat State Transition Diagrams as the holy grail for representing control flow and decision making. Literally ALL of the business logic I write for these initiatives involves me emulating a state transition diagram directly into Java code.<br><br>For front end code, after I click a button, knowing what the next buttons should be activated or deactivated is an ideal use case for a state transition diagram. If I write a calculator, pressing the start button should activate the number buttons and the operator buttons, but not the negation button or the clear buttons. By using a state transition diagrams, you clearly define all possible path in control flow execution, which is GOLDEN for eliminating bugs in front end code.<br><br>For path finding algorithms, I don't think that requires any explanation lol. State transition diagrams were literally built for path finding algorithms lol. You need a very good reason to NOT use a state transition diagram.<br><br>And for natural language processing, you follow almost the exact same logic as the front end code example above. By entering a word, you have filtered the domain of possible follow up words considerably, depending on the type of the word. It is this control flow wrangling that allows something as prohibitively expansive as the English language to be effectively wrangled down to Earth with State Transition Diagrams and Pattern matching. It's no secret that the first thing I ever used Amber for was natural language processing ()<br><br>All of that is to say this. This is a problem that I pay a tax for several times a day, every day. So in my eyes, this is a very large thorn in my side.<br>I treat it similarly to how we treated enums. Sure, they were representable as static final fields, but introducing them as an enum opened up an entire world of possibilities that I could use them for. Enums are my literal favorite feature in all of Java because, like pattern-matching and state transition diagrams, it allows you to be able to wrestle a prohibitively complex domain (serialization and deserialization of a small set of values) into an ergonomic feature that's easy to wield.<br><br>I'll respond to any further questions when I get back.<br><br>Thank you for your time and help!<br>David Alayachew<br></div><br></div>
</blockquote></div>
</blockquote></div></div>