--------------------------- 1056a eek! yikes! ----- thinking a little of code parts, unsure the attempt to learn the [self-referential algebra godel thing] was fun 1112a we're thinking of the number 1, and assuming it is useful for something. [the existence of 0 is implied] but i'm a little confused, maybe this isn't quite what i'm trying to think of? i think i might actually -- 1113a 1114a --- often when i encounter a software challenge nowadays i have severe difficulty forming information in my mind that relates between useful parts of the challenge i then cope by forming strong habits that can work on just little tiny bits sometimes maybe this useful-part-nearness could be a reasonable practice. software challenge idea one of the first software challenges i learned was that of making a sandwich ... but maybe let's go more toward actual algorithm design. ooh! i've spammed this before! probably totally differently, maybe better. ok umm design algorithm to [do sometihng, maybe make sandwiches] but: rather than planning/making it, write the parts needed to do so ... maybe, unsure. let's not do fibonacci numbers, language models everywhere have done that one maybe could though ... ok how about this: generally we are challenged with finding the answer when we do not know it. how would we find it more rotely? if we didn't know it? and then maybe could practice these parts or such? --- 1116a ummmmmmmmmmmmmmmmmmmmmmmm uhhhhhhhhhh a really simple algorithm ok lets square every element of an array let's first do it simply and then try to improve. so when programming it's very similar to a collectible card game or a runaway ai you have a bunch of things (instructions, design patterns, libraries & library functions, etc) that you can use each of these tihngs does something different and you want to combine them in ways that move toward what you're trying to do. this might mean imagining a lot of different combinations of them. you develop familiarity with them and learn ot only combine them with some things. so if we're squaring an array, i know that iteration is a very simple first step. if you're not sure if you can do something, O(n) approaches are a reasonable thing to have available to make it clear it is possible to do. iteration means going through every item. so like (for each item in list: do thing with item) we can summarize this as "O(n) iteration" and various synonyms. 1119 then we have operators. when i think of the challenge of "squaring every item in a list", i guess i tried to combine my available tools, and shoehorn them into the sentence, seeing how each part of the sentence could be fulfilled. "every item in a list" can be met with iteration. "squaring" could be met with the multiplication operator (because squaring is defined by multiplication), or a squaring function from a library. it could also be met with a summation operator (because multiplication is defined by summation) and with bit fiddling tricks (because the computer is based on bit fiddling). so this basic concept of goal meeting: 1. what kind of thing might meet the goal 2. do i have it will enough to meet the goal? yes: use it no: consider calling 1 with goal=what i need to make the thing meet it pretty simply! you could explore that with a priority queue and maybe make any software program! i think it would work! you might need to rewind from #2 and pick no instead of yes as information develops, sometimes. assuming we can use that approach, the problem then simplifies into cognitive triggers, inhibitions, etc that respond to concepts and behaviors rather than the general task shape. feeling it out, it seems like topical inhibitions could shift to the general goal meeting reasonable readily, so it could be something to practice. it's also very similar to [todo list] which are heavily inhibited for me, one of my very biggest inhibitions :S executive functioning conflict in brainmind, maybe. 1123a