Re: Demo: Modelling Cost of Travel Paths Between Towns

> Some tools (like Windows) are based on OO concepts.
> Others (like SQL) are not.

I would say nearly all tools have object-like orientation but to different degrees including SQL.

> Why don't you do it? All 64 towns. WIth a minimum of 4096 possibilities.

It would be more fun to compare the methodology of several solutions. Would any RM, OO, C++, Haskel proponent like to join? I woundn't start with 64 towns though. The permutation of paths among 64 towns is likely to be much bigger than 4096 :)

> I have no interest in attempting to solve this problem, just in pointing out
> that your "solution" is not a solution, and is bound to send anyone who
> tries it to the doctor.

You are correct, the solution only represented things and does not provide algorithms to process those things. I didn't know I was under that obligation. I titled the thread Modelling... not Computing...

> > > Here is some SQL for Neo to learn:
> > > INSERT INTO neo VALUES 'common sense', 'integrity', 'honesty';
> > > UPDATE neo SET pocketbook = pocketbook - 1000;
> >
> > Please teach Neo the common sense meaning of integrity and honesty by
> > showing that Hugo's RM Solution #1 and #2 aren't nearly twice as slow
> > as XDb1's even when XDb1 is executed on a 5.6X slower machine.
>
> I don't have to. It's been done. Repeatedly.

Then how difficult could it be for you to do it again. Please post the execution time of XDb1 vs Hugo's on your machine for the small report. And please show how to represent case 1 or 2 without NULLs or redundant data. Received on Tue Nov 09 2004 - 05:10:23 CET