Ouch, it bites, ehmmm or should I say it bytes ;) Very interesting
stuff, but not for mere mortals like me :)
Really out of my reach. I'll try to play with it, just to try to see how
it works (even if I doubt I'll be able to understand the compiler god's
code :)
Mere RTL god ;)
Marco van de Voort wrote:
I found a png, but can't seem to find the original file (it is in .dia
format), will have to search for it.
http://www.stack.nl/~marcov/decalhier.png
If you can't find the eps - or never had any - I can create one on my own
(using xfig).
Anyway, here is a patch for
Marco van de Voort wrote:
I have a tex version of the decal docs somewhere.
http://www.stack.nl/~marcov/decal.tex (might use some FPC tex docs files)
compiled to
http://www.stack.nl/~marcov/decal.pdf
I am reading this manual now, because I want to familiarize myself with this
lib.
Marco van de Voort wrote:
I have a tex version of the decal docs somewhere.
http://www.stack.nl/~marcov/decal.tex (might use some FPC tex docs files)
compiled to
http://www.stack.nl/~marcov/decal.pdf
I am reading this manual now, because I want to familiarize myself with
Michael Van Canneyt wrote:
What is the performance difference between a hash() and a binary search on
an ordered list ?
IMO perfomance heavily depends on the use of the lists. An ordered list
requires some efforts when entering or removing items, and typically
requires more comparisons than a
Marco van de Voort wrote:
Better finish decal. DeCal is good and comfortable for most cases, and
trying to speed it up will kill the ease of use.
Then we can collect some other set of routines over time for more performance
dependant stuff.
You are right, it will be probably the easier way.
On Tue, 21 Jun 2005, John Briggs wrote:
This is a repost of an earlier response to another thread. I did not recieve
any response so I am posting this in its own thread.
I have several old books (circa 1991), including source code, covering TP6 in
my library.
Perhaps the most interesting one
John Briggs wrote:
This is a repost of an earlier response to another thread. I did not recieve
any response so I am posting this in its own thread.
I have several old books (circa 1991), including source code, covering TP6 in
my library.
I still remember the Algorithms + Data Structures =
Dean Zobec wrote:
As the project looks like a long term one and I think that fpc urgently
needs a optimized hash table I'll also work on a streamlined hash table
with a chaining technique as a collision resolution scheme and a paging
for the allocation of the nodes in the chains, to have an
The generic functions are very powerful and model closely the C++ STL
library (as fpc does not have generics yet a sort of typecast is still
required when fetching the items from the container). The library was
not designed for speed though, from the first test the DArray class is
twice as
Dean Zobec wrote:
As the project looks like a long term one and I think that fpc urgently
needs a optimized hash table I'll also work on a streamlined hash table
with a chaining technique as a collision resolution scheme and a paging
for the allocation of the nodes in the chains, to have
On Tue, 21 Jun 2005, Florian Klaempfl wrote:
Dean Zobec wrote:
As the project looks like a long term one and I think that fpc urgently
needs a optimized hash table I'll also work on a streamlined hash table
with a chaining technique as a collision resolution scheme and a paging
for
Michael Van Canneyt wrote:
On Tue, 21 Jun 2005, Florian Klaempfl wrote:
Dean Zobec wrote:
As the project looks like a long term one and I think that fpc urgently
needs a optimized hash table I'll also work on a streamlined hash table
with a chaining technique as a collision resolution
On Tue, 21 Jun 2005, Florian Klaempfl wrote:
Michael Van Canneyt wrote:
On Tue, 21 Jun 2005, Florian Klaempfl wrote:
Dean Zobec wrote:
As the project looks like a long term one and I think that fpc urgently
needs a optimized hash table I'll also work on a streamlined hash
I would make that the contnrs unit. I think it belongs more together with
objects such as a stack and queue...
What is the performance difference between a hash() and a binary search on
an ordered list ? I've also been working with an 'associative' stringlist,
but
I was using an
Michael Van Canneyt wrote:
Depends how the hash is parametrized. If you've a big hash array and a
good hash function accessing has a complexity of O(1) while for a binary
search it's O(log(n))
But I assume that calculating the hash becomes harder for 'better' hashes ?
Not always, it
Michael Van Canneyt wrote:
What is the performance difference between a hash() and a binary search on
an ordered list ? I've also been working with an 'associative' stringlist, but
I was using an ordered stringlist to keep the data, so a binary search is done.
The TStringList is a very fast
Depends how the hash is parametrized. If you've a big hash array and a
good hash function accessing has a complexity of O(1) while for a binary
search it's O(log(n))
But I assume that calculating the hash becomes harder for 'better' hashes ?
Only for general purpose hashes. Specific
Marco van de Voort wrote:
The generic functions are very powerful and model closely the C++ STL
library (as fpc does not have generics yet a sort of typecast is still
required when fetching the items from the container). The library was
not designed for speed though, from the first test the
Dean Zobec wrote:
I can immagine, the DObject is a TVarRec. The problem with speed and
memory usage are the things that I don't like in Decal and it still
makes me wonder if it would be better to reimplement a containers
library from scratch, if we had generics to add type checking at compile
Marco van de Voort wrote:
Dean Zobec wrote:
As the project looks like a long term one and I think that fpc urgently
needs a optimized hash table I'll also work on a streamlined hash table
with a chaining technique as a collision resolution scheme and a paging
for the allocation of the
Bram Kuijvenhoven wrote:
Besides using TVarRecs, we could also use pointers (as in
classes.TList) or objects.
Pointers like in TList were the things I had in mind.
This would perhaps be a bit like it is in java.util. Then we would
also need container classes for basic types such as
22 matches
Mail list logo
