I Was Wrong About Being Wrong
In my previous post (here), I concluded that I was heading down the wrong solution path with my Abbreviations* "Xpander" code.
[* = Actually abbreviations plus scripts & url's]
Now I take it back. Well, at least partially.
I was wrong about being wrong. Two wrongs do make a write -- meaning, something to write about. The two oopsies could operate as a double hit on my fragile ego (a.k.a. my Dunning-Kruger based confidence about always being right, about my brain's concocted models of the universe and them being 101% correct despite my lack of full knowledge of the universe).
One reason I was wrong in this particular case (wrong about being totally wrong) is because my initial "thought experiment(s)" did provide useful insights. I now more clearly understand what problems I'm facing in coding up the Xpander project.
link for image source is (here), more of Bob's Banter (here) and also (here) about staying motivated
Some additional insights about admitting that I am / was wrong are here:
QABg ::: Admitting you were wrong
QABg ::: Admitting to and learning from your mistakes
^^-- Learning From Your Mistakes When Coding [= AlgoCademy ] [re Py]
^^-- Accept your coding mistakes and learn from them
QABy ::: Admitting you were wrong
QABy ::: Admitting to and learning from your coding mistakes
^^-- If you're struggling to learn to code, you must watch this [= PP ]
^^--- The Mental Breakdown: Admitting When We Are Wrong
^^--- Our Shrinking Attention Span
^^--- [Quastri] Why Admitting You're Wrong Feels Impossible
^^--- [Why Though?] Why You’d Rather Be Wrong Than Admit You’re Wrong
^^--- DK effect
^^--- How To Overcome Failure & Learn From Your Mistakes - Jordan Peterson
CONTINUING WITH MY MEA CULPA:
My error included not looking at the bigger system picture. Please see the next big image below.
The Xpander can have a number of different sources for its input text, including from a large text file or just a few characters input in real time from a keyboard.
One of the contemplated sources is a real-time typewriter watcher module that parses the incoming data so as to detect continuous sequences of P3/P4's in the input stream as well as to determine when/where the associated sequence ends (e.g. on entry of a white space or a period or another clause/ sentence terminator after the P3/P4 sequence). Here are two examples of possible text streams:
[plain-terminator] [Abv-name] [P3's sequence] [seq-terminator] [post-fix extra] [post-term]
[plain-terminator] [Abv-name] [P4's sequence] [seq-terminator] [post-fix extra] [post-term]
(1) In the first example, the input includes one or a sequence of just P3's. In the second, the input includes one or a sequence of just P4's.
In both cases, we need to parse the incoming data into different buckets. One bucket can simply be for storing non-expandable plain text that will be passed through the pipe as is. That plain text will generally (not always) have an end-of-plain termination indicator (understood to be a terminator only after we detect the first P3 or P4) such as a space, a period plus space, a colon plus space, etc.; after which the name of a to-be-expanded Abbreviation ("Abv") appears. The exception to the general rule is if we have a P3 sequence such as X-prime (x`) which is to be expanded into an "-ing_" ending for a word. P3 only looks at the lone character preceding it. So no need to separate the plain text stream and the immediately following lone character plus P3 or P3's.
(2) Especially for the P4 case, we provide a second bucket for containing the name (e.g., a multi-char name) of what we suspect to be an expandable Abv or a name-based call to a script or a URL or some other dictionary-defined data (where the action to follow depends on what the next two buckets, the Abv name and a possible extenuating circumstances bucket reveal).
(3) A third bucket can contain a detected P3/P4 sequence. This bucket is used to count the number of P3's and/or P4's for determining how to respond (e.g. what index to use for the list of options in a corresponding lookup dictionary).
(4) A fourth bucket can contain the name of a to-be-used parameters list. More specifically in one embodiment, the period (.) will serve as a signal that the called Abv or script has a registered "extension" similar to the method or attribute extensions which can be appended to the name of an OOP object.
Right now, I'm thinking we will need to form at least three "buffers" in the form of mutable Python lists, each of max length = 16 chars.
The incoming "text" has to be converted into list format. This has to be so because strings are not mutable! Then the listed characters have to be fed into what we just called the 'second bucket', but now we are going to call it Buffer number 0. Refer to the image of Buffers 0, 1, 2 shown just below the schematic of the Xpander system.
For sake of visualization, we are going to pretend that Buffer 0 is 16 slots long and is initially filled with nulls (X's here) --an actual Python list will not need to be built like this. For sake of example we could use ASCII code 0 (decimal = null) as such place-holding mere padding in our hypothetical model.
TO BE CONTINUED .. STILL A DRAFT POST ...
Buffer [0] appears before buffer [1].
The characters in each buffer are characterized as one of:
(a) a don't care (X) for our purposes here, this includes right padding nulls
(b) a "spacer" which may become important for Xpander purposes if a P4's
sequence follows. It will also be useful for breaking up the buffer contents
and signaling a "passing through" of the preceding text that does not need
conversion. (Such spacers include a comma-space duo, an
underscore, a hyphen, ...
(c) a "terminator" such as a period that is followed by a SPACE or a CRLF
or ... the detection of a P3 or P4 --which forces the fill process to jump to Buff
number 1 where we will store ad then count the detected sequence of
consecutive P3's or consecutive P4's
With each transfer of text into the pipe, the identities of buffers 0/1 are swapped rather than shifted and only the old 0 gets transferred out to the pipe, The old buff 2 can become the new buff 0 ... TO BE CONTINUED ...
In the below we visualize the concept of parsing the incoming data by using the three buffers (actually Python lists). After parsing, Buff_0 will hold a potential short-name of an Abv or of a script or of a url. Buff_1 will hold a detected P3 and/or P4 sequence. Buff_2 will hold a a potential short-name of an extension
The below code has not been tested yet. It probably has errors,
def buffer_d_input_txt (self, in_txt):
l = len(in_txt)
tub_0 = [ ]; tub_1 = [ ] # create two empty lists for holding long input texts
if l > 1024:
print(f'The input string is too big, Xpander was aborted')
analysis = f'aborted'
exit
elif l > 512:
print(f'The input string is being baloon-wise split too big across tub_0 and tub_1')
tub_0 = list(in_txt[0:49]); tub_1 = list(in_txt[49::]) # copy & convert the first 48 into tub_0
remainder = l-48
analysis = f'48 chars in tub_0, {remainder} remain in tub_1'
if remainder > 0:
tub_1_empty_flag = False
return tub_0, tub_1, analysis, tub_1_empty_flag
elif l < 49:
print(f'The input string is all inside the tub_0 list')
tub_0 = list(in_txt) #convert the input text into a list of 48 or fewer chars
tub_1_empty_flag = True;
analysis = f'{l} chars are inside the tub_0 list'
return tub_0, tub_1, analysis, tub_1_empty_flag
else:
analysis = f'An unexpected error has occurred'
return tub_0, tub_1, analysis, tub_1_empty_flag
The below code includes a sequential state machine and parses the input text data after it has been input via chunking.
def feed_buff_0 (self, tub_0):
list_a = [ ]; list_b = [ ]; list_c = [ ] # create 3 empty lists
buff_0 = list_a; buff_1 = list_b; buff_2 = list_c # assign swap-able names to the lists
if P3 in tub_0 == False and P4 in tub_0 == False:
buff_0 = tub_0 # move all of tub_0 into buff_0
analysis = f'no triggers found in tub_0'
return buff_0, buff_1, buf_2, analysis
# since above conditional failed, we know there is a P3/P4 trigger in tub_0
i=-1 #this is an index into the tub_0 list
state = -1 # this initializes a sequential state machine
while len(tub_0)> 0:
i += 1
if tub_0[i] != P3 and tub_0[i] != P3:
state = 0
buff_0 [i] = tub_0 [i]
elif tub_0[i] == P3 or tub_0[i] == P4:
state = 1
buff_1[i] = tub_0[i] #move the triggers into buff_1
elif state= 1 and tub_0[i] != P3 and tub_0[i] != P4:
state = 2 # non-triggers were found after the P3 and/ P4's
buff_2[i] = tub_0[i] # move the post-fix non-triggers into buff_2
if buff_2[i] in [' ', '.', '!', '?']:
analysis = f'buff_0, buff_1, buff_2 all contain data, name terminator was hit'
return buff_0, buff_1, buff_2, i, state, analysis
else:
analysis = f'tub_0 has been emptied'
return buff_0, buff_1, buff_2, i, state, analysis
MORE TO EXPLORE
QABg ::: Evolutionary basis of the Dunning-Kruger effect--^^^-- Evolution of thought: What changed (DK effect)
[Quora] Why did humans evolve to have the Dunning-Kruger effect?
EverythingProfessor -- Every Type of Intelligence & How To Develop it Explained
^^^-- Every Way to Reprogram Your Brain To Crave Hard Work [avoid dopamine traps]
^^^-- Everyday Habits That Boost Brain Power
Comments
Post a Comment