A semantic space-dimension for the Web

[ "A space-dimension to the Web: a combinatorial optimisation problem"
  
  Published at: http://architectando.blogspot.com
                /2009/07/space-dimension-to-web-combinatorial.html
  Discussed at: http://groups.google.co.uk
                /group/sci.math/browse_frm/thread/2cd2380c0bd245eb
  
  How to give a *sensible* space-dimension to the Web.
  Solutions, corrections, suggestions, etc. all very welcome.
  This is an open project. Contributions will be acknowledged.
  
  -LV
]
[
 
=== Setting:
 
Let G be a weighted, directed graph.
 
Let S be a lattice space for G.
 
Let M be a physical model for G.
 
Let U be (the absolute value of) the potential energy (in M over S, given G)
 
=== Problems:
 
Problem 1 (optional): Express U.
 
Problem 2 (optional): Minimize U.
 
Problem 3: Express and minimize U, given the following constraints:
 
- Constraint 3.CG1: Weights in G have positive rational values.
 
- Constraint 3.CG2: Graph G is sparse.
 
- Constraint 3.CG3: Graph G is dynamic, i.e. nodes and edges change (appear, desappear, change their weight). The dynamic is by discrete singular events, changes are smooth.
 
- Constraint 3.CS1: S is a diophantine circle where positions start from zero along the circumference, and the distance function 'x' is:
 
    let c be the circumference (i.e. number of nodes in G)
    let x' = x1 - x2 (absolute distance, integer >= 0)
    
    x := x'      , if x' <= c/2
         c - x'  , otherwise
    (i.e. distance along the shortest arc, integer >= 0)
 
- Constraint 3.CM1: Within model M, the force 'F' is:
 
    let i,j be non-negative integers indexing nodes in G
    
    f_ij = k_ij * x_ij , if exists in G edge i->j with weight k_ij
           0             , otherwise
    (i.e. absolute elastic force, rational >= 0)
    
    F = sum_i sum_j f_ij
    (total force, rational >= 0)
 
- Constraint 3.CU1: Given that graph G is dynamic (see CG3), we want to minimise U and keep it minimised!
 
=== Solutions:
 
My solution to Problem 3 at the moment consists in a "local approach". I build a graph that is near-to-optimal (by inserting any new node at a location so to minimise total energy change), plus have a process that keeps iterating the solution space for local improvements (by swap of adjacent nodes). The idea is that such process should be able to keep up with changes (that are smooth, see 3.CG3 and 3.CU1), and this together with said strategy of insertion should be enough to keep the system at a near-to-optimal minimum (if not global! I guess this depends on practical timing considerations... and complicated calculations. Anyway, if needed, some simulated annealing might also be implemented).
 
Incidentally, in the setting of Problem 3 there is no role for node weights. This is a choice, not a simplification, related to semantic considerations. It might be surely discussed: we are after a *sensible* way to give a space-dimension to the Web.
 
]

Software craftsmanship

"Crafting the details" to me evokes hours spent filling in the little gaps and cleaning up, while rethinking the whole thing over and over again. Hours when few lines of code get written, yet the overall quality and understanding improve dramatically. I was thinking how much I value and do it...

Software craftsmanship is when we spend at least 20% of the project-time crafting the details.

Posted to the software craftsmanship user group:
http://groups.google.co.uk/group/
/software_craftsmanship/msg/9d5194756e327110

I am a software professional

[ Draft manifesto. Partly in response to the craftsmanship manifesto. ]

I am a software professional:

1) I build software that solves my customers' needs, explicit and implicit.

That is the only software I will qualify as "working".

2) The software I build not only works, it keeps working.

Always around the optimal balance between minimality and continuous improvement.

3) I build software with honesty, responsibility, vision, and passion.

My customer is king and I will tell him when he is wrong: no excuse, rather quit.

4) I believe in professional integrity and real competence.

This is no place for unscrupulous marketers and incompetent wannabies.

I am a software professional, and I am damn proud of it.

Artificial Intelligence

THE AVERAGE MAN IS
THE NEXT GENERATION AI

(There is intelligence and intelligence.)

Why is the Software Industry sucking more and more

With inflation and pollution come ignorance and even more confusion.

To begin with, the A in the ABC of software production:

It is not about doing it right, it is about:

doing the right thing!!

Software is about the conceptual side and only marginally about the technicalities. About using your mind, sensibility and intelligence to provide a concrete and competitive service to people.

This is certainly clear to customers: information technology is a wonderful instrument, yet an enabler and never a driver. This is too seldom clear to present day software professionals, who should realise the matter in question remains predominantly conceptual even at the lowest levels.

The rest is the usual gadgets for grown-up kids. Post the 90's, software engineering is dead, killed by the invasion of incompetence in a huge market of marketers. For instance, most of the late generation of professionals in this field have never ever encountered Analysis: and, no Analysis equals no quality, period. While most of the managers, as well as the divulgators, opinion leaders, and overall the big companies, not only do not have a clue, they actually make every effort so that this, and in fact all that may be related to any process of intelligence and learning, will never happen. The whole situation is simply and deeply compromised. Just as everything else nowadays -- everything coming from this side of the planet, that is. Corruption has broken down empires across history, sometimes rigidity, but noone ever guessed an empire of sacred mass stupidity devoted to self-destruction could be near to unbeatable. In fact, just everything is sucking more and more.

Yet another argument: against test-driven

Mr Jason Gorman, in his post "Test-driven Enterprise Architecture" (September 16, 2008) [*], writes:

I've discovered that the most effective way to align business goals with the software and systems we deliver is through heirachies of tests, not through pretty pictures and dotted lines.

I have to disagree, in the essence. It is surely true that most of those dotted lines get drawn without criterion, which is indeed what makes the difference between an Analysis and a bunch of dotted lines. Still, the problem domain and the solution domain do not coincide, rather the latter is a subset/subproduct of the former. In practice, as information engineering tells, the solution domain emerges from the opportunities for automation that come from the process and data models at the business level. Here is a gap, or rather, a "distinction", just like the distinction between syntax and semantics, that must not be neglected, otherwise not only the understanding, but the very quality we are after is gone, with all that in fact counts.

[*] http://parlezuml.com/blog/?sectionid=20

If I jump into a Ferrari and... run away?

Ok, let's suppose somehow I get around the boxes of an F1 circuit at the time of a race: difficult surely, but if you take into account a bit of luck, pretty doable.

Let's then suppose somehow I manage to find an F1 car in the proper conditions, that is as much ready to start as needed: so difficult that, again, with a bit of luck, it is definitely possible.

Let's finally suppose I manage to start and go: not so difficult, above all if I have *trained* hundreds of hours in a proper simulator...

...broooOOEBY*&CROXZYQNRX8-7pVWOaei72)D9####F[---

Wow... let's assume I wake up from a crash at the very first bench after the start. Hmm, what is gone wrong?

Flash forward, looking TV in London: in a show called "TopGear", a journalist is supposed to have a try at an F1. He has some previous *experience*, so they first let him try an F2 (or similar, don't really remember), so that he can prepare to the F1 experience. He is not that fast but quite comfortable on the F2, but at his first try on the F1, that is, after he has managed to start the car, he is not even able to go as fast as to keep tires in temperature. At his second try, and not before some magic from the mechanics, he does it; funny driving, anyway he is able to complete his 3 or so laps with no more damage than a couple of testa-coda in the smaller benches.

Bottom line: simulation doesn't sum up to competence, and I'd rather go into journalism than try some more training.

Indeed, do not steal a Ferrari, just forget it: ***.

On readability -- Pure induction in action

Radical engineering principle: On readability

Memento:

Engineering principles are true by good convention.

Principle:

Optimal "readability" is readable _optimality_.

Comment:

Never ever optimize. <*>

Do make code readable. <**>

Clean up the dark side. <***>

Readability before all. <****>

The only way to optimal code. <>

Extended:

<*> Includes refactoring, the semantic side of optimization.

<**> Includes restructuring, the semantic side of readability.

<***> Includes comments, the dark side of readability.

<****> Includes the dark side of optimality.

<> Readability dis-including itself.

Hint:

Optimization of a sub-optimal program (algorithm, system, product, procedure, argument) is a pointless hack that leads to solutions at local minima. Improvement of such local-minimal solutions is impractical, given that the underlying landscape is so redundancy-reduced as to result completely chaotic.

In practice, if a sub-optimal program gets optimized (once upon a time there was the blessed post-optimization-upon-need, nowadays we have optimization as an integral programming practice called refactoring and its cousin performance), any required improvement needs stepping back tot iterations until another approach, more basic but broader enough for the extended problem, gets in sight. The more premature the optimizations, the more paralyzing the sub-optimized local-minimal results. And the iteration starts over...

To break the deadly cycle, just stop optimizing in any form, start instead striving for readability. To get a basic idea of readability, we can think of the optimal target as a program code that can be _read as easily_ by a professional in the field as something in between a technical article and a page of mathematics. That is, code needs speak for itself!

[ A side note to the casual reader: please don't get too strict on terminology, I'm using all terms in their _broader_ sense, so that, for instance, should you be a software engineer, where I say "coding", I actually mean any act of production, including all that there is from analysis to delivery. The same holds for other disciplines. The only restriction is maybe in that I try to stay within the bounds of "engineerings" and "applied sciences", although, sooner than later, we'll catch up with "social sciences" as well, and that will be a joyful day for all - until the next. ]

That said, apart from avoiding the inconveniences of optimization (taken in its broadest and weakest sense), readability brings its own distinct advantage, indeed an exclusive property: readability and only readability leads to optimal programs. We still miss a formal proof, but this might be apparent if we think what an _optimal_ program is: on a side, readable entails manageable so much as the latter requires the first; on the other side, every _ideal_ relates to needs that, in any ultimate sense, are "human" and only "human". Indeed, "who" needs _what_?

[ For example, say one is programming and keeps readability in mind. That means:
1) writing code with readability in mind (rather than "writability");
2) designing a system under permanent (re)structuring, down from its very (im)permanent foundations;
3) keeping the whole environment always clean and tidy, as if important guests are to arrive at any moment soon (and that includes documentation; yes, please, if in doubt, just DROP IT ALL!!).
This leaves plenty of room for movement, and the code stays always around the optimal balance between minimality and continuous improvement. ]

We can't predict the future, we make it: we are pure induction in action.

Foundationals

0 = Not

(First learn to say "no"!)

1 = All (is mine)

_____________________________________
Note: This is still work in progress.

A related claim and conjectures is here (please dis-prove):
Claim: The Theory of All Is Equivalent to Inductive Logic
http://mathforum.org/kb/thread.jspa?threadID=1712270

Radical contradiction

Technically speaking,

We have blown up the "root of contradiction" with an _atomic_ bomb.

To the casual philosophers we are, I will show the links below.

To the professional programmer: a crack is not a hack, but a hack is a crack.

Keep up the go(o)d work.

==============================================

Julio Di Egidio
Re: Question about proof by contradiction
Posted: Mar 10, 2008 11:12 AM
http://mathforum.org/kb/message.jspa?messageID=6131405

[...]

BTW, here is an extract from a letter from Wittgenstein to Russel, 1921, which I think sheds some light (I'm

afraid I'll have to traslate, I've got it in Italian):

"I believe our problems track down to _atomic_ propositions. You'll see it if you try to precisely explain

how the Copula is such propositions has meaning. I cannot explain it and I believe that, once an exact answer

is given to this question, the problem of <> and of the apparent variable will be _much_ nearer its

solution, if not solved. Now I think above <> (the good old Socrates!)."

The good old Ludwig!!

Explaining that meaning, by means of the empty set "we" are, is indeed what I have shown (again, until dis-

proved).

Julio

==============================================

Marshall
Re: Question about proof by contradiction
Posted: Mar 10, 2008 5:46 PM
http://mathforum.org/kb/message.jspa?messageID=6131836

> >> Proof by contradiction can be formalized as
>
> >> (P -> (A and not(A))) -> not(P).
[...]
> The proof in question, in fact, does not even use proof by
> contradiction. It has the form
>
> (P -> not(P)) -> not(P).
>
> This is not a proof by contradiction.

[...]

Does anything interesting happen if we transform them somewhat?

(P -> (A and not(A))) -> not(P)
(P -> false) -> not(P).
(not(P) or false) -> not(P)
not(P) -> not(P)

Well, I seem to have destroyed the formula's essential nature
by these manipulations. How did THAT happen? Apparently
truth-value-preserving transformations don't preserve some things
that aren't truth values.


Marshall

==============================================