Re: geometrical algorithm design

Thanks for an interesting objection
and yes I disagree and I suspect it is I who
have not been entirely clear in elucidating this idea.

Let us take, for an obvious example, the Simplex algorithm - a known
method of optimizing situations involving thousands of variables.
It is known that there are geometrical interpretations of this algorithm
(and I am not referring to Karamkar's breakthrough, this was done
long before that) and that in the geometrical interpretation, the
optimizations can be seen as paths accross some surface.
It so happens, because this is the realm of mathematics,
that this kind of correspondence occurs. No big deal then.

Now, imagine a mechanical engineer/bridge designer
designing a bridge, he could call up perhaps a finite element program
or a program that simulated wind loading and other stresses and would
probably have already drawn the bridge in some sort of CAD/CAM
program which would might interact with the other softwares.
A plethora of visual tools are at his disposal.

But, the poor software engineer does not have a tool that would
allow him to express his desired algorithm in anything other than
symbols. He might be a sophisticated designer and use the method of least
preconditions
of the renowned E. Dykstra in a modified Boolean logic is used to develop
some algorithm
but it would still be entirely operations on abstract symbologies.
And all he would have is stuff like the pathetically named "Visual
Development IDE Environments"
of the present whoose only "visual" aspect is that you can drag and drop
some stupid icons and forms and windows and when you type in some
class name it will do some rudimentary class or variable completion for you.
In some cases, when you create a window or button by dragging and dropping
icons, it will create some preliminary outline code for you - well that is
a step in the right direction anyway.

The question I have wondered about for some time is - could this process
be improved by some sort of real geometrical visualization??
At first I naively thought perhaps something like modified Platonic solids
might do the trick
but they are far too limiting.

Eventually I came to suspect (without any theory and not at all being a
researcher)
that the answer might lie in fractals and, sure enough, Gerard Langlet seems
to have
been going in this direction at the time of his untimely death.

So, the software engineer of the future, if he had such a tool as I am
envisioning,
and indeed if it is even possible, might switch from a fractalic to a
symbolic
view of the same algorithm or code. And, if one were to load the shape
into a 3d kind of paint program and operate on in some fashion, perhaps
replicating
some portion of the curves, and then return to the symbolic view, the code
would have
addtitional functions automatically generated by the shape interpreter.
Likewise, if the code were altered by the addition or deletion of functions
or lines, the symbolic shape representing the algorithm would be changed
by the symbol interpreter.

A pipe dream then? Perhaps.

But I am sure of one thing even from what little Lisp I know already.

C++ would fall over and die trying to do such a thing
but Lisp - that is the language which might do it.

Thanks.
Tak (Jim Pannozzi)

P.S. Re: Algorithm tolerance adjustment idea you mentioned -
It's already been done and is called Fuzzy Logic.


"Adrian Kubala" <adrian-news@xxxxxxxxxxxxxxxxxx> wrote in message
news:slrnd5lmad.na9.adrian-news@xxxxxxxxxxxxxxxxxxxxx
> Takuon Soho <Tak@xxxxxxxxxxxx> schrieb:
>> There is a secret hiding out there amongst thousands of developers, a
>> dream of tools and a software development environment to rival the
>> simulation and design tools that architects and engineers have now.
>>
>> For me, ultimate expression of that dream is to elucidate some sort of
>> correspondence between geometrical shapes and abstract algorithm
>> design and then have an environment which embodies it.
>
> I think this is a pipe dream because the very things that make algorithm
> design different from physical design are what make it more useful. For
> example, it would be nice to have something like physical "tolerances"
> where a small difference here or there didn't break an algorithm, but at
> the same time the fact that small local code changes can completely
> change the global behaviour of a program are what make programs
> maintainable and extensible. Not to mention that physical machines (or
> geometric approximations thereof) have little capability for
> abstraction. Babbage invented the Difference Engine precisely because
> programming it was better than building special-purpose machines for
> everything it could do. Your notion of physicalizing algorithms is going
> the wrong direction. Can you explain why you disagree, or have I
> completely misunderstood you?


.