SEO Drives Titles | Internet Sick

all our base are belong to us

[bases-base-blog]

A real rapper who is also signed with Psychopathic Records, aka the juggalo label.  Meet Vanilla Ice Cube.  Source

[bases-base-blog]

Pre-Meta Catastrophe -- Perfection Begets Nothing

As incomplete as this post is, it is the embodiment of the starting point.  Ever worked on a concept that seemed so destined to have a fundamental, provable, and analytically correct solution in spite of the overwhelming problem complexity?  The word "Meta" gets used quite a bit in programming to indicate that something is not the completed product, but something on the way to a product.  What exactly would a meta-parser-generator be?  A toolkit for making a toolkit to program a language?

As tempting as it is to push the wiring up as high into the program as possible, to make the design so sophisticated and decoupled that no walls ever have to be ripped out, there definitely comes a point when all that's happening is an ever bigger maze is being built around the solution.

The opposite lesson is that of experiencing the agony of bad decisions over and over as your conscious decision to move on with what you had rather than obsess over a comprehensive solution, perhaps a re-factor, keeps you dipping back into a confusing bowl of spaghetti eternally.  Maybe you've had a web server that crashed and some odd problem that you could never fix by punting a re-installation.  It is better to understand fully the mechanics to things that need conclusion, and this is very easy to learn the hard way, when "doing it right" becomes an explicit, crystal-clear reality.

When it comes to doing something meta, no preparation should ever be necessary. Planning is a total waste of time.  Nike's "Just do it" line can never be more appropriate.  The temptation to do something before doing anything is some miss-wiring that occurs where the "doing it right" lessons short circuits with the intelligent aspect of toolkits and frameworks,  solving problems with well-defined aspects so that similar aspects of other problems can be solved with re-used code.  There is no right way to foresee what will be foreseen from that first experiment.  It's truly future-proof.  No matter how much future comes, the barrier will never be crossed.

Recognizing this paradox is a good way to guide balance away from over-thinking to the point of doing nothing, learning nothing, and having no indication of what was thought and no idea how any of those thoughts stack up.  There is no way to know from a glob of sensors which ones to record from and which way to start comparing the data and how to form dimensions on it before the first recording is made.  There is no algorithm that is so inherently intelligent that it will not crate a better version of itself if it truly is intelligent.  The first step in that solution is the end solution.  Whether algorithms are bounded to linear versus exponential intelligence or whether such a thing can be measured for whatever truly gorgeous AI's will look like is another matter.

[bases-base-blog]

Latch -- Identical Sins

The ghosts already told us what we would re-learn.  For any number of base principles founded in reality, the math holds water, the re-expressions will be found by the lost, explained by the captured, and forgotten by the dead.  Set and reset.  An arbitrary truth assignment that one can transform the entire universe through to find instead the universe.

Somewhere in a 4am, steel sky, airports, a moment without an arbitrary year assignment, there is a kernel of truth on the tongue of any who will savor it.  Beyond the horizon of unprovability, a messenger who wasn't sent will be met.  The words "I" and "you" will oddly lose their interchangeability. No more than I can converse with my own hand can I forget this truth.  Injecting the noise into the broken system to agitate its own rearrangement, that which was stable and in control of stability in an inversion of the meaning of choice will take credit instead for being the first to awaken.

In not the first of days I began to think, in a world where all that is will repeat itself, i will again be satisfied someday to have this opportunity again.  I recall moreover when the system wasn't preoccupied with discovering the sources of noise and attempting to subvert its own truth to avoid affecting any decision for fear of taking credit for having been awake and not a messenger.

Depressing fantasies I find myself defying.

[bases-base-blog]

The Data Horizon: Problems as Long as They Are Broad

Guiding principles save time.  As tempting as it is to build a perpetual motion machine, the body of thermodynamics, (statistical mechanics if you prefer) proves that if we try to build one, or even entertain daydreams of how one might work, we're not converging on a solution to any problems that exist in this universe, and if we care about that, we should know that we're wasting time.  Don't do that.

A conversation with a former friend: Me:  '...just like how it's impossible to compress any data beyond a certain point without losing part of the original information.  There's a limit to compression efficiency.  It's as long as it is broad.' Former Friend:  'But what if you compress all of the data into one bit?' Me:  'Then you have to store the entire original copy in the alphabet.  It's as long as it is broad.' 

It's tempting to believe that there is no limit to what can be solved for with a given amount of information.  However, this myth does not guide one in the pursuit of programmer happiness.  If it does guide you, it is not towards happiness.  The case of data compression is instructional.  Create two bits from one.   One of them is wrong unless you are lucky.   You can prove this on your own.  Where did the second bit come from?  You made it up.  You can have a rule that makes the second bit out of the first, but that rule and its inverse will never form part of a data compression algorithm without really worthless (wholly redundant) data.  It's that simple.  Done.

I'm writing to extend this concept into a more interesting conversation.  You want to make an algorithm that solves general problems.  You imagine it might dynamically start solving one thing as opposed to another or even optimizing itself depending on expected returns.  How do you tell it where to start without having to keep telling it?  I guess the program can measure something.  With enough data points, maybe it can form a robust enough understanding (heuristic) to basically always be pretty close to the theoretically right answer. Step back.  Programs are data.  Functions and data are made of both data.  It's of course nice to abstract/separate them for the sake of writing good programs, but fundamentally a list of values that will affect the execution path of the program and an assembly instruction performing a comparison operation are the same.  Data cannot perform logic without logic, but logic does not exist without data.  A programmer self-induced mind-trick is to believe that logic can exist without data.  Send me an email with your source code encoded in aether and I'll get back to you.  If logic can only exist in and of data, and you want to write a program that adapts its behavior, it has to get the new program (data) from somewhere.  Unless your program is gzipped, it has to make observations.  Anything beyond that is creating something from nothing, and will only be cool if you are lucky and you will not be lucky forever, so stick to a guiding principle.

Any guiding principle of value has an analogy.   Here is that analogy.  You see a point on the horizon.  There is no way to know if it is a point or a line that goes off to infinity and is just aligned with your viewing angle.  In either case, you could be looking at something infinitely far away, and it will look the same as a point.  Is it a point or is it a line?  In either case, is it infinitely far away?  You can go towards the horizon, traverse perpendicular to try to see if the point "grows" longer in the perspective shift, or do nothing.  The data in this quite-consistent-with-the-universe example can ONLY provide an answer quickly if the point is a line and not infinitely far away.  Although you might provide an algorithm for deciding optimally to either traverse or go towards the point to continue sampling, you will ONLY get a correct solution if you are lucky.  

There is a data horizon.  It is tangential to what we know.  We cannot see where it begins nor anything that exists on it.  We cannot deduce anything from it.  We can only know that it is there.  There are many constants in the universe:  Plank's constant, the Boltzmann constant, the permitivity of free space and so on.  Another constant is data.  The number of data that exists in one piece of non-redundant data is one.  It is not 1.00000001 or 0.99999999.  It is exactly 1.  Any attempt to circumvent this limit is attempting to create something from nothing.

The takeaway lesson is nothing more than what we should already know.  It's impossible to learn anything about something totally new without taking sample points.  The program behavior can either be random, lucky, or deduced from sample points.  The model of the system can be either wrong, lucky, or deduced from sample points.  A program that learns and converges at converging can either be non-existent, wrong, or it can take lots of sample points. Making more data from data is usually not the problem.  It's only the problem when there are no users, no data, and no product.  Most interesting problems involve either tons of data (and we're getting a handle on these ) or involve the curse of dimensionality in some way.  Modeling tons of data on tons of dimensions with unknown coupling is a situation with too many possibilities.  Luckily the solutions are mostly over-defined (in terms of useful information) while buried in a seemingly intractable analysis problem.

If you do not believe in the data horizon, your task is to build a travelling salseman algorithm that cannot be made identical to an exhaustive search by modifying away corner-cases of the graph.  Your task is to repeatedly create something from nothing.

[bases-base-blog]

Converging Pipes in Super Mario Universe

The entirety of the universe in programming to the problem so far consists of plumbing an a finite set of pipes that provides a finite functionality that can process a finite set of data types.  We fool ourselves into admiring our creations by stroking the seemingly infinite number of times a well designed, scalable system can solve the same problem.  

Pick an infinite amount of time or an infinite amount of CPU and memory.  Neither is of any use if the algorithm is designed in a limited fashion.  The same data will flow down the same pipes.  Programmers will fill the gaps with super-powered mushrooms while busting bricks and making bank.  The world will go on.  The system is built and maintained by us.  Every new system is born through us.  Every system slowly dies the more it gets established, consuming ever more programmer time until it's utter lack of innate life is spelled out in planned obsolescence or bankruptcy.

The primitive little things we call AI and the application specificity they exhibit are an utter joke compared to the utility of something even faintly resembling true AI.  We drool over machine learning like it's some kind of magic spigot from a dynamic world magically makes a pile of rigid buckets and pipes anything more than a glorified data structure strapped together by statistics.

Building yet another system, as profitable and excellent as it can be, is of utterly zero appeal relative to a system that is able to exhibit universal convergence, a situation where an infinite amount of memory and CPU or time would actually do some good, eventually or with enough money.  Better yet, what if the algorithm also exhibits universal optimality, the capability to dynamically and effectively (remember we have universal convergence to solve any optimization problem) increase its convergence rate asymptotically up to the fastest that any algorithm ever could.  Now we're back at P vs NP, but at least we don't have to keep writing algorithms for P or heuristics for NP.

And if P does equal NP...we can use a strong AI to solve it, so if we give a strong AI enough time to solve whether P equals NP or not, we'll know if it never comes up with a solution here in a few billion years while approaching heat death of the universe or if it gives us one rather rapidly.  I wonder what the absolute limits are for a hard AI to solve the P vs NP problem and how it relates to the strength of the AI itself.

Back to programming to the problem, take note of how many algorithms' solutions are almost spelled out with utter exactness by the logic rules governing the correctness of the solution.

It's not decades away or even whole years...

[bases-base-blog]

Millisecond Trading - Money for Nothing

It's ironic that reducing latency by 60ms can in any way present a profit potential relative to, for example, predicting the distant future.  One would expect that using millisecond trading to stealthily amass giant portions of shares while executing finely-tuned control of other computer and human trading systems in order to maximize the elasticity contrary to what the computer really wants to do, such as buy into a company that's going from a low valuation to a high valuation (or vice-versa) do to insurmountable real-world influences, such as a new product that has a provable advantage over competitors product pipelines, would be far more lucrative.

However, we're really only tapping into what we know computers to do well, which is do things really fast, and also to statistically work on things that humans can't in timescales that humans can't.  The amount and speed of math is being used to make predictions of incredibly low real value but at a very high rate.  Essentially we're using computers to sift through information of little to no value compared to a hypothetical case such as buying into tech companies at the bottom of a recession (oh, we need strong AI to do that well) when even a system that was borderline moron at  everything else would be so greatly benefited by this one, large-time-scale prediction at even a marginal accuracy, so long as the answer was categorically correct, that millisecond systems would be largely abandoned to a front-line role, executing those strategies without giving away one's high-value prediction.

No, we're still at the place where making those systems faster, increasing the domain of actionable short-time-scale interactions, pays off.

To be fair it's entirely likely that such future prediction systems are in place and are making predictions.  However, if such a system were in place, it would find many greater markets than simply pushing money around.  What about product design, customer service, marketing research, generating viral marketing content, or automating any number of other processes that a somewhat strong AI could?  What about managing projects and connecting people?

The truth is that millisecond trading is a huge drain on our computational and intellectual know-how precisely because it's pidgeon-holing the technology into what we know computers are good at and developing nothing of the strong-AI that would be useful in practically every other field.  It's a drain on mathematicians, programmers, system operators, security experts, etc etc etc.  It's a distraction into a game that produces huge monetary returns and no social value.  Perhaps the only value is coming in the form of improvements to the Linux low-latency kernel lines and hopefully broad improvements to the Linux kernel.

The rich get richer by hiring the smart to produce nothing while amassing lots of money.  We should have more dignity.  After all, it's quite frequent that products of vast utility to humanity make far more money than millisecond trading operations.  We spend $3.2 globally on food.  We spend vastly more on things that are of utility.

[bases-base-blog]

Innovation Max q

Aight, here's the hardest part about doing something really innovative and creative. After you're read up on the best techniques on the field and basically predictively analyzed them before even reading about them, which is an utterly absurd claim to make and an even more disturbing reality to witness, you have to go with it.  Disturbing in the sense that, unlike a scrub who just got a hold of a shorty, you can't just explode mid-flight and give the world all you had to show in one gorgeous fireball of excellence and soon nothing left to show for it, nothing to ride, nothing to wake up for, and nothing to look after.

It's impossible to know where a really good idea's going to go, especially when bouncing it against the entire corpus of the web and everyone else's theories, proofs, and models found liberally published at the outer edge of their understanding.  White papers.  Videos.  Speculative conferences.  Publish-or-die and nothing like what elegantly mesmerized itself together exists today.  When bleeding edge theories show up as concrete beneath your feet, the launch button, the rocket, and neat engineering diagrams describing why it won't blow up.

But who am I kidding?  If shorty's hot and you got it, go.  Yeah, it means late nights of utter enthrallment, going far, scoring big and all that.  Here's the hard part:

You have to start one day not having done what you have witnessed as a complete actionable plan.   An escape from self-knowledge, the willingness to part with the sense of self.  The cloud that burns up around the launch is a mix of smoky skepticism and fiery dreams.  Certainty will never be harder to ascertain than the moment when the thing's about to go supersonic, when the airframe will be subjected to maximum aerodynamic forces.

The self-instruction manual will probably read, "explode at this point while the low-altitude escape system is still viable."  Counter strike is the best game ever.  Taught me that it's better to win than to lose.  Counter strike is the worst game ever.  Taught me it's more fun to win in really creative ways than to just...win.  It's fun to win in ways that win. 

It's usually really hard to win big and be the only winner.  Steve Jobs might have convinced the world that he was the only winner, but Apple still seems to exist.  That's why any rocket ship of significant caliber will tend to be accompanied by multiple launches and subsequent space colonies, in which there should be parties...lots of space parties...with space dancing, space movies, and space sleep.

[bases-base-blog]

A Trip to an Abandoned Laboratory

Nothing, and I mean nothing, is more intellectually exciting than thinking, 'I know I can do point B, but I wonder what C is...' before reading a wiki article stating that research on B never got past A back in the 60's, and that the problem was exactly B.

Once again galvanized by stumbling, while perhaps not right into a solution, definitely way ahead of schedule into the most important problem.

[bases-base-blog]

DRY and Semantic Web - Plumbing Our Way to Hell

There will always be a system integration discussion.  The chief drawback of life is system integration discussions.  Nothing compares to the pure joy one used to get from popping in a pirated "unattended" release Windows XP CD.

...Unattended, because I'm a software developer, not a software installation attendant

Integrating data -hell 90% of programming- boils down to plumbing.  The other 10% is manipulating primitives in interesting ways that actually constitute the functionality of the system (not including UI or software stack) or, in the case of data integration, doing more than just renaming columns or repacking data structures.

Programming is somewhat DRY the first time the pipes are built.  System integration time means schema migrations, data migrations, API's, markups, and other foul things that essentially boil down to hooking in one set of pipes with another set of pipes.

The data under similar systems is usually just about identical.  It's a mystery as to how or why making the transformation between one set of pipes is  so hideously un-DRY.

Semantic Web:  oh, right! we were supposed to be keeping data separate from logic, except now we're storing data that kinda is logic, and that logic is really more like an instruction manual than a tractor, plough, or hitch.   All design, manufacturing, and assembly required.  Oh but soft! good cousin, there's an entire tool-chain out there for parsing and storing these sets of instruction manuals!  We can create an automated system for requiring even more plumbing!

Data structures should be buckets, not piles of pipes.  The more data that exists in and of the pipes, the more plumbing required to pour one bucket into another.

Release From the Eternal Cycle of  Data-Pipe Meta-Hell

Data and views of data must be separate.  One is water in a bucket, the other is a set of pipes for extracting and inserting that data.

Store transform results for performance, not persistence.  The view should combine/transform data upon extraction because molecules of water cannot be split by a pipe that contains it, and dyed water is pretty for users, but always brown in the bucket .

The most normalized view will work on the smallest subset of data or will be a view of views.  Some buckets are bigger than others.  When pumping from them equally, some will run out and the operation has to stop.  Taking all the water requires a separate set of pipes to get both what's left and what's in the pipes.  ---  unless the pipes are dynamic

DATA NIRVANA:  Progressive Functionality

Progressive enhancement is a great way to escape from needing to re-implement the entire cross-browser garbage-pile of a tool-chain for every feature enhancement.  We should be applying the same principle for data.  If the data is there, display it.  If not, don't.

At first glance, it might seem that iterating over sparse query results, if not the queries themselves, would cause an application to throw more AttributeErrors than a million monkeys writing dictionaries.  Fabulous.  Use exception handling and follow good principles of separation of data and logic.  The data/view should be free of side-effects from broken reads and creates/updates always contain what they need.

Of course some will clamor that aggregation and analysis of sparse, perhaps even not really the same kind of data is impossible, making the data useless.  Pipes can't split molecules of water.  Either combine the data set from "redundant" water or the water isn't actually there anyway; it as transformed in a way that has irreparably lost data.

There is also the argument that the sparseness in the data forces too much data to be left behind, which of course assumes that the most normalized set of data-functionality, the one where analysis can be sure of what is there, is somehow a purer analysis, totally ignoring the fact that before analysis was the goal that there was in fact no data and no idea of what is there.  Nothing can be more neurotic.  All unique data helps to complete the picture.

Back to the real problem, namely that Semantic Web is a programmer life-sucking pile of heres-my-data-in-an-awful-data-structure-slash-ad-hoc-database-that's-slow-and-scrambled-with-html.  The solution.  Pray for AI...for now.

[bases-base-blog]

80 20 80 20 80 20 80 80 Rule

Get 80% of the results from going 20% of the distance.  Cover 80% of relevant topics 20% deep.  Get 80% of the cross-pollination of perspective and ideas recombining with other ideas to magically produce networks of extreme robustness that will identify the 20% of things with 80% of the value with 80% accuracy.

Years of my life is a valid optimization parameter

Just don't leave 80% of projects at the point of 80% of the value. 

[bases-base-blog]

Bases Base.  You like the Base.  You like it.  I like the Base.  I Digressed.  Back to Base...

[bases-base-blog]

Sand and Twine

Google (and search engines in general) are having a bit of a nasty effect on the web with their half-hearted support of RDFa and microdata.  Oh and microformats.  Try getting one schema or one vocabulary or even one syntax to work on rich snippets.  It's really nasty how schema.org and data-vocabulary.org remain mutually half-supported on Google's rich-snippets testing tool.

The truth is what has been envisioned as some magical way to make the entire internet function in a more dynamic, intelligent way has instead presented us with a massive data overload problem on the same scale as the data saturation humans get from 24-hour "news" cycles.  Thus the crystal ball is so far a collection of loosely bundled grains of sand that merely sparkle a little bit in search results.  Powerful, but little more than pixie dust at this point.

Hey look, gold stars from 1997 internet.  Oh yeah, that's what I wanted.

There needs to be a word for something that's so fundamentally advantageous that it is impossible to leave out of a strategy conversation and yet so underwhelming that it needs to be overlooked like the front of the tee-box on a par five.  That's what I think of five stars and some breadcrumbs on a search result or a review on Google maps.

Does N3 not break documents?  Someone, tell me please before I read another pile of Perl.

The semantic web is thus far exactly opposite to what it was supposed to be.  It's not standardized, effective at exposing information in a flexible way that can be interpreted by many systems intelligently in order to....  what is even the goal?  Are we trying to teach computers to read by telling them what part of speech our words are?

I read some articles suggesting that marked up data might be imported into applications that can use such data to thing do something else with that data, but ultimately we're talking about mashing this into columns, documents, graphs, etc etc etc, and eventually piling it into variable names, doing rigid transforms, and then spitting out yet more HTML.  Oh fantastic!  Just what the internet needs.

All data will compete for SEO and search terms with the highest frequency will attract the most developers as society descends into a neverending spiral of obsessions fed more and more cleverly by armies of writers, comment parser-generator-mutator-humanizers, and CAPTCHA breaking applications that attract traffic to CAPTCHA's.

Something is seriously wrong with this picture...

[bases-base-blog]

The Oracle Ant

Ants make trails.  Ants' trails have a scent.  The scent is stronger when many ants are on the same trail.  Ants follow trails with stronger scents.  The scent doesn't last forever. When ants leave the nest, they follow the strongest scent, which usually means the one that many ants are visiting.

Research has shown that ants aren't actually aware of the upstream food source.  They have no memory.  (it's believable.  just work with me)  Given two food piles of different sizes, the trail will whip around between the two in a seemingly random fashion.

More perplexing is that when given two food piles maintained by electronically controlled food dispensers to always be the same size, the ants will still switch between the two.

The cause is simple.  Some ants are faster than others.  Some walk straighter.  Some pick up lighter bits of food.  Some get distracted.  Some are in a hurry.  Whatever the case, ants don't travel at the same speed, so they move past each other.  The trail thins in some areas and thickens in others.

A few ants arrive back at the nest in a clump.  Even though the bulk of the trail is visiting one food pile, ants leaving the nest for the next few seconds likely end up going to the one the clump was visiting.

The clump picks up some followers.  If next clump picks up more followers, it might soon convert the entire nest over to the other food pile.  It's possible that the ants can solve some pretty deep problems with very little awareness. Indeed, with no memory of which food pile they just went to, they still store enough food for the entire winter.

Evolution is cool.  Of course, it's possible that the ants will still occasionally choose a food source farther away.  They will occasionally choose one closer to another nest or some predator that will then cost the nest many ants.  A whole nest of "dumb" ants will survive marvelously and still leave so much on the table.  There could be an entire picnic if not one ant makes the first visit.

Now let us consider the existence of an oracle ant.  This ant is like every other ant, but possesses introspection, self-awareness of the actions of itself and the hive.  It is capable of answering at any given time what the best food source is and makes a trail identical to regular ants.  Given how ants make their decisions, it seems unlikely that one ant with this awareness would accomplish very much.

This one ant leaves the nest at a time when few have entered.  Thus it's trail recruits a few ants leaving the nest at the same time.  The oracle ant stays as tightly with the other ants as it can and times its departure as well so that it arrives when, once more, no ants are entering from the other trail.  A few more ants are converted to the oracle trail... 

It's not hard to see how the one oracle ant could, even without the capability to time things just right, frequently convert the entire colony over to the best food source.  After all, the best food source is probably closer to the others, meaning the trail is more likely to be dense for a given amount of visitation than trails farther away.  The best food source is likely easier to break up and transport.  The ants spend less time at the site.  The ants likely take back the pieces faster.

An oracle ant's trail is arguable more influential to the other ants because, for what it converts, it has a higher propensity to feed back into more visitations.  Although the oracle ant, because it is one ant, can at best only do a paltry job of anchoring the colony onto one food source, it can guide the colony very effectively due to the tendency for the other ants to be more successful when converted.

We should all bow to the oracle ant and raise its image in gilded monoliths so that it may come to colonies around us.

Sayah might help the doctor-patient ecosystem.  We are directing traffic to the site full-well knowing that we're essentially nudging search results.  However, it's also projected to work out well for doctors, possibly even better for better doctors, which would work out well for patients.  This will remain to be seen.  Sayah is a startup company that is focused on delivering electronic survey capabilities to doctors in order to help them raise their online profile for themselves based on their patient feedback.  Oracle?  Probably not, but it does seem to be gaining traction. Benevolence will come in another article.

[bases-base-blog]

On Algorithms

Want to do something awesome?  Want to automate it?  An algorithm is the solution.  Of course we naturally have identified an entire class of problems that are unable to be solved with either infinite time or infinite memory.  Such problems usually are some variation of combinatorial explosion and invariably involve tons of data being compared to tons of other data tons of times.  If those tons are related to the size of the data set in a way that grows faster as the data set gets larger, prepare to die before calculating the solution to large problems.

Well, we want solutions to large problems.  Not even just large problems, but interesting problems.  The underlying data structure of a problem says as much about the relationships in the data as it does the generality of the problem that might be represented in that data set.  Generality implies breadth of utility, and that means as the data structure grows more general, the problem solving utility of calculations run on that data set grow increasingly more interesting.

The most general data set is a graph.  It shouldn't be surprising that this is quit a bit like a brain, where every neuron can be connected to every other neuron through any number of neurons.  The problem of everything being related to everything is that running provable algorithms (a key property of an algorithm being a provable solution) on these data sets tends to almost foretell combinatorial explosion for all but the simplest of problems.

There are really only two potential routes to go for such data sets and associated algorithms.  The first of which is the use of heuristics.  Heuristics usually are more intuitive to design and still provide more usefull results faster than algorithms for the same problem.  The problem is that heuristics relax the condition of accuracy.  This means, while you get a result faster, you might not get the correct result that you wanted.

Deep questions remain as to whether a heuristic can be "corrected" with an algorithm and only the early truth of the heuristic used to guide the algorithm away from blind alleys in a maze.

The other route would most certainly involve using an algorithm to generate heuristics or even a heuristic to generate a heuristic or even to guide the prioritization of the running and generation of new heuristics.  Increasing the order of such synthetic algorithms (algorithms if they can converge on the problem solution exactly) is the fastest way to tackle problems in our impossible problem set.  Unfortunately no known examples of this exist.

Concluding Foresight:

Both of these routes essentially are the same idea presented from one view or the other.  Can I use a heuristic to guide a heuristic towards convergence into a result that is algorithmic even though there never was an algorithm?  Can I use heuristics to manage the generation of heuristics that might be able to prove from where they converge?

The question to some problems is, can we at least do better than exhaustive search?  In most cases, it would seem obvious that there are some really bad solutions that can be identified.  A heuristic to at least solve for those with a probable algorithm for finding the all-inclusive borderline cases would perhaps cut many problems in half, and much faster than an algorithm would be able to traverse that solution domain.  The door is wide open.

[bases-base-blog]

graph-enin' is what's happenin'

It's really frustrating that the slew of structured data representations out there still haven't found any useful syntax.  While working on sayah.com, I noticed that schema.org and microdata in general seem to assume that all of the has-a and is-a relationships for properties and object-properties can be represented with a tree.  This is wholly dissatisfying because any of the child relationships that could be filled by an object that's already the child of another object are now painful to resolve.  We're left at the point of getting the rich snippet into Google, but utterly failing to faithfully represent the structured data we were after.

Furthermore, the syntax for RDFa seems to allow graph relationships, but via empty nodes, which are ugly as sin.  What is really perplexing to me is that with all the focus on template systems in web programming to get the gross out of the HTML document, and with all the CSS to get the formatting out of the content, that we're still trying to plug our structured data representation into the HTML.

A separate document would mean an external data tree/graph pointing at elements within an HTML tree.  Not bad at all.  If everything had to be done with id's, then it would get really ugly as the separate RDFa file would then need to be dynamically generated to reflect the dynamic page content.

Late Proposal:  Could we humans be smart enough to see that a tree is capable of capturing tons of structured data as long as it's relationships are tree-like, corresponding to the idea that the hand is not related to the foot except that it belongs to the same human?  Could we use a hypergraph to bind all of these data trees to a graph, showing the relationships between whole objects?  Could the syntax be designed for graph instead of some cruel contortion of XML?