this idea occurred to me. as remarked some prior, there seems to be some pattern in a lot of trajectories in that its basically just an upslope and a downslope, eg within the glide region. how much of a pattern is this? or is it just highly related to all the glide generation algorithms devised so far? what would a trajectory that deviates from it look like?

this code splits the trajectory (glide only) into left and right upslope and downslope sides and then measures the mx value for each separately, trying to maximize it. the code has 3 modes: 1 maximizes left, 2 maximizes right, and 3 maximizes over both, but noticed the last one tends to settle on optimizing left after many iterations. the purple line is the mx value and the green line is the length of the “side” (upslope or downslope). another funky aspect of this code is that it seems to occasionally “paint itself into a corner” and fail to find increasing trends after long runs.

the immediate next step is to look at the trends in particular. was musing what shape is consistent with the measurements. am guessing that this is finding long arcs with high spikes at the end (hitting the maximum of the curve) but not sure. it also seems to indicate the spike is a nearly constant width ie the difference of the trendlines, but a different constant for the left and right sides…? the different scale makes it tricky but it looks like right is about half the left, maybe ~5 and ~10…? definitely some interesting stuff at least that needs further attn/ analysis.

😳 this code was very hard to debug because of a glitch that took hours to isolate. accidentally deleted some db generation code & was without that std code, so rewrote it from scratch as exercise. it didnt find any gradient to exploit in the left/right trajectories, and finally realized that the starting binary shift value was 4 instead of 2 and it led to trajectories with the same mod 4 values and which all terminated glides in 2 iterations. *@#$%&*

elsewhere big drama around here, a windows7 box with SSD crashed (@#%& thought those might be more reliable than harddrives but so far for me they arent!). now running win10 and it took quite awhile to get everything going again. and rats, was working and succeeded with installing a multiple linear regression library in ruby right before it crashed. almost back to square 1 on that one. this is a new version of ruby2.2.4 and gnuplot 5.1 which changed the default plot colors a little.

this new gnuplot also has a very nice feature to save the graph with a gui button instead of awkward gnuplot commands. no longer require extra steps of copying & pasting into windows paint program! (yeah, things are not always so high-tech around here as you might think!)

this next idea is a kind of riff of the last one that seemed plausible but didnt really work out. was hoping for “limited dimensions” somehow. the idea was to recursively decompose a glide somehow. a somewhat natural idea is as follows. find the max point of the glide. if its the leftmost or rightmost point of the glide, simply remove it, and repeat the decomposition. otherwise, split the glide into left and right pieces excluding the maximum glide, put (push) them on the stack to decompose. then measure the complexity of this decomposition basically in breadth (max size of the stack) and depth (number of elements on the stack total). then try to maximize by either breadth (2) or depth (1).

for a fairly orderly glide, this approach will often delete the consecutive monotonic increasing or decreasing points. but for a disorderly or apparently fractal glide, the dimensions will continually/ indefinitely increase.

the graph lines are depth, breadth, glide length, starting value bits. maximizing by depth seems to lead to a nearly flat breadth (1st graph, green line). but maximizing by breadth seems to increase all metrics (2nd graph).

hmmm, 2nd thought, that prior depth was more of an estimate & closer to “total graph decomposition size” (in nodes). this code explicitly keeps track of depth of the recursion and allows maximizing by it also (3rd option) and its plotted as a 5th line but it doesnt seem to chg results much. in the 1st graph it closely tracks the estimated depth. ie/ so the two depths nearly coincide but neither does either bound the other, but later graphs show one bounding the other. anyway there is no particular dimension that seems bounded when optimizing by that dimension, although sometimes (greedy) optimizing by one dimension causes others to nearly flatline. note the starting seed bit width is different/ now the last color (yellow). anyway overall wrt this analysis the decomposition graph seems to have no discernable “shape” or “dimension bias”.

**(7/25)** was musing more on the idea of intrinsic limits and was reminded of this old idea. its fairly natural/ basic to look at the peak glide value versus the starting glide value, eg the relative difference. of course the hard seed generation code has long been looking at “widthdiff” ie the difference in bits in the max glide value versus the starting value, and this leads to a nice hard seed algorithm that doesnt run out of higher metrics in its search.

but what about the ratio, “widthratio”? think maybe did look at this awhile back, need to go thru old blogs. but anyway reworked it into this current idea and a greedy seed search. it looks like the ratio is very noisy and therefore not necessarily a great optimization metric. but it also seems to have a ceiling, or even stronger, this code seems to show a *decrease* for higher seeds! this has a 100 element frontier, 10K advance iterations and the 1st plot is the starting seed bit width versus the widthratio. theres clearly a downward trend, and its repeatable, and it doesnt seem to be due to the “painting into a corner” effect. again that feeling, really should have noticed something this substantial sooner! the 2nd graph is the gradually increasing glide lengths.

**(7/27)** was starting to wonder about what might be called “vertical vs horizontal scaling” on pondering the widthratio which is a measure of vertical scaling. this code also computes horizontal scaling ie length of glide divided by bits in seed. both the vertical and horizontal metrics are somewhat noisy in the sense that new trajectories built from prior ones via (msb) bit setting are not so much correlated. but, still want to find maximal horizontal and vertical scales, so how to do that?

this code does a histogram-like calculation of creating 10×10 bins for the trajectories arranged by horizontal and vertical scales and choosing random trajectories from the bins to advance by bit setting. the idea is that it isnt known *apriori* where new larger scales are found so they are attempted to be found within a “even/ random” distribution of prior scales. more evidence for a ceiling although the decline effect does not seem to be seen here. graph 1 horizontal scales, graph 2 vertical scales, graph 3 bit width of seeds, graph 4 glide length.

it is natural to wonder how the widthdiff metric behaves wrt the 8 hard seed generators and very easy to graph this from the seed database file (14 lines, almost barely deserves saving!) because it was already being calculated. the 7th generator uses it specifically and (again) actually decays somewhat. apparently the 1st generator may actually give some of the highest widthdiffs but nevertheless still seems to decay some. some other methods flatline (2nd, 8th). again, dont recall graphing this before and thats kind of a big oversight.

metrics, metrics everywhere but not a proof to drink. this code greedy searches for large seeds via optimizing the product of the vertical and horizontal scales. the flattening trend is quite noticeable here. vertical scale is in purple and horizontal in green in 1st graph. 2nd graph is the product.

another idea, this optimizes by total memory used in the glide counted in bits. horizontal times vertical scale looks similar.