Re: If you were inventing CoBOL...
From: Richard (riplin_at_Azonic.co.nz)
Date: 09/12/04
- Next message: Richard: "Re: If you were inventing CoBOL..."
- Previous message: Richard: "Re: Payment systems (was: If you were inventing CoBOL...)"
- In reply to: Robert Wagner: "Re: If you were inventing CoBOL..."
- Next in thread: Robert Wagner: "Re: If you were inventing CoBOL..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 12 Sep 2004 12:40:01 -0700
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
> 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.
Well you _can_ insert a record into a table, you just need to move all
the data at that point up one. That is just an irrelevant physical
implementation detail, the logical result is that the record was
inserted.
> 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.
One can do that, and it doesn't require non-standard address fiddling.
Or just sort and search all.
> 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.
More complexification yet again.
> >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?
Yes, I did say that. In fact that is what SEARCH ALL does. Now hash
tables are useful too, and these can work by calculating an index. As
you say there may be collisions which are dealt with using an overflow
technique (such as adding 1 until an empty slot is found). Hash
tables work quite well when densities are low and a good collision
system is done (the one above may not be good).
You can't do good hash tables with lists.
One can also calculate into a table when it is known that each item is
going to a unique position, which may emulate a multi-dimension table.
For example if I have a range of warehouses of different
configurations but some actual maximum number of slots then, for a
particular warehouse by knowing the max height and number of rows I
can assign a single dimension table entry uniquely by calculating
using the characteristics.
It seems you are rather short of ideas about how these calculations
can be used.
> My low-level fiddling is the code that belongs inside a *competent*
> collection class method.
Hmm, does this mean that it was inside an *incompetent* class, or that
it wasn't inside a class at all ?
> 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.
Having to deal with generics and collections does mean that there is
some unavoidable overhead, yes.
When you have come back with your attempt a collection class that can
deal with generic classes as competently (in terms of actually
working) as MicrFocus's then perhaps a comparison can be made.
In the meantime your code was just 'what C did in the 70s'.
> I didn't make this stuff up nor bias the outcome. I measured the speed
> of code distributed by a mainstream company.
Fine, compare like with like and come back.
> >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.
Just as you said above, I really don't care what it does, something
about papertape, I just throw data at it and get it back (or SORT and
SEARCH ALL). I don't want some non-standard pointer code as you
advocated.
> >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.
The question was ... _visit_here_.
If you want to argue the toss about tree rotation there are groups
that are especially for that where tool builders will visit.
> >> 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.
>
> 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.
It still seem that you have lost the advantage of having no limits by
using a table and also have complexified by mixing table handling and
pointers.
- Next message: Richard: "Re: If you were inventing CoBOL..."
- Previous message: Richard: "Re: Payment systems (was: If you were inventing CoBOL...)"
- In reply to: Robert Wagner: "Re: If you were inventing CoBOL..."
- Next in thread: Robert Wagner: "Re: If you were inventing CoBOL..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
