Re: If you were inventing CoBOL...
From: Robert Wagner (robert_at_wagner.net.yourmammaharvests)
Date: 09/12/04
- Next message: Robert Wagner: "Re: If you were inventing CoBOL..."
- Previous message: Robert Wagner: "Re: If you were inventing CoBOL..."
- In reply to: Richard: "Re: If you were inventing CoBOL..."
- Next in thread: Richard: "Re: If you were inventing CoBOL..."
- Reply: Richard: "Re: If you were inventing CoBOL..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 11 Sep 2004 23:37:28 GMT
On 10 Sep 2004 19:58:58 -0700, riplin@Azonic.co.nz (Richard) wrote:
>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
>
>> >Nor can one in a file such as a data file as used by CISAM, the well
>> >known Informix underlying file system.
>>
>> The underlying file system is irrelevant.
>
>It was you that started arguing that there was a relevant similarity
>between a table and a database table. Now its all hand waving on your
>part.
If they replaced CISAM with Btrieve, you wouldn't be able to tell the
difference. The database would work exactly the same. That's why the
file system is irrelevant.
>> In database view, one can not only insert a row in the middle,
>
>You cannot insert a record into the middle of a phyical file (without
>moving all the data beyond that point), a logical insert puts it at
>the end.
I care about the logical view, not physical details. They could store
the inserted record on paper tape for all I care. So long as it comes
up in the right place when I say NEXT, I'm happy.
>If there actually is a requirement to keep a path through records
>without a physical insert it is easy enough to have 'next' and 'prior'
>subscripts in the table, of course this then defeats the SEARCH ALL.
Imagine that, a linked list. Since we've lost the ability to find
entries with SEARCH ALL, let's build an index over it. Let's call it a
tree.
There is an alternative -- one used by nearly every spelling checker.
Leave the original intact and put recent additions in an unordered
set. You look in the main list first. If not found there, you do a
serial search through the supplement. When the supplement becomes too
big, you 'reorganize' it into the main list.
>> it can even have a duplicate key.
>> Try creating duplicate subscripts in a Cobol table.
>
>Subscripts are not 'keys' they are equivalent to a record number. Try
>having a file with two records with the same number.
You said "Tables can be directly accessed by a calculated index
number." What about two entries that calculate the same index number?
>> Most compilers already do. It's generically called a collection class,
>> specifically a dictionary. J4 appears to be standardizing the class.
>
>If you were promoting the use of collection classes this would be a
>different discussion. You weren't, you were promoting hand coding low
>level address fiddling as done by C in the 70s.
My low-level fiddling is the code that belongs inside a *competent*
collection class method. I measured and posted here the speed of
methods developed under other philosophies. Their performance was
terrible -- 50 times slower than the worst of the legacy solutions.
I didn't make this stuff up nor bias the outcome. I measured the speed
of code distributed by a mainstream company.
>> Informix temp tables reside in memory and are automagically defined.
>> They offer the benefit of database logic without the overhead of disk
>> access, separate definition and security issues. When the job ends,
>> they disappear in puff of smoke.
>
>Exactly, I don't have to care how it does this, I just throw the data
>at it and ask for it back as I want it. This is far more valuble than
>how to fiddle non-standard memory addresses. They can read that in
>'Computer Science' if they care.
What do you think lies in the heart of databases? It's bit-fiddling
that isn't embarrassed by the appellation.
>> Everyone's not a dumb consumer. Someone has to write those easy-to-use
>> tools. I was talking to the tool makers and anyone curious about the
>> subject.
>
>How many 'tool makers' do you think visit clc ? Your code and example
>was directly aimed at applications programmers, ie those who visit
>here.
I think there are more aspiring tool makers than you do. At age 18-20,
everyone is idealistic. Somewhere along the line, most lose their
innocence. Ever see the movie Pleasantville? Most people think it's
about pragmatism; I think it's about giving up ideals.
>> >Do you do this by dividing the pointer by 2 ?
>>
>> By using SEARCH ALL. In the demo, tree nodes lived in a table.
>
>Well bang goes the only advantage of lists and trees, the freedom from
>a limit imposed by having a table. Presumably you have to sort the
>table so that SEARCH ALL can work.
>
>You seem to have gone full circle and just picked up a huge baggage on
>the way.
I sorted by rotating the tree until all left-pointers were null. I
don't recall whether I physically rearranged them with MOVE or XOR.
- Next message: Robert Wagner: "Re: If you were inventing CoBOL..."
- Previous message: Robert Wagner: "Re: If you were inventing CoBOL..."
- In reply to: Richard: "Re: If you were inventing CoBOL..."
- Next in thread: Richard: "Re: If you were inventing CoBOL..."
- Reply: Richard: "Re: If you were inventing CoBOL..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
