Mirsad Todorovac wrote:
On Tue, 13 Nov 2001, Frank Heckenbach wrote:
What a coincidence, just yesterday I implemented `WARN' as a test suite flag!
We may be the same Zodiac sign or somethin'? :-)
Libra (though I don't really believe in it ;-).
In the mean time, with your permission, I just might submit a test that gives a WARN if a variable of non-simple type is not initialized on platform?
You mean if it's used without initialization? Sure.
- BTW, I've seen FPC bindist shiping with Mandrake 8.* ... How is the
situation with GPC and Linuxes? I mean with Mandrake 8.1 CD's you get even Haskell functional language HUGS interpreter, which is IMHO far more exotic than GPC compiler. IMHO, with such extensive testsuite that passes without complaint on Solaris box - GPC may be just enough stable to include in official Linux releases?
I don't know about Mandrake. I know it's been included in SuSE for a long time (though often with broken installations)-:, and a Debian package is maintained.
If it's missing in another distribution and you or someone else can make a contact to the responsible people and convince them to include it, go ahead, by all means. (I personally don't have the time for it.)
I was thinking also about the issue - sparsely filled sets of large numbers; and now when I saw then on TODO list I was very excited. I think that they are definitely a good thing, worth implementing (I offer my assistance, as an experienced programmer in C and C++, even worked on great commercial projects for banking software, also knowing PASCAL).
On the other hand, I'd agree with '??' remark in TODO list, because sparse sets bring difficult and vexing algorythmic problems; so I thought of multiple ways of internal representation: from items numbered in a simple list; to multiple ranges of bits representing set items (a very simple extension to current algorythm with MedCards in p/rts/sets.pas) - to some SF features such as something resembling UNIX filesystem internal structure and organization (of course optimized for in-memory operation). Of course, the emphasys would be on speed and conservative memory use - so making all ends meet might be an art!?!
I think so. I've spent some thoughts on the issue and considered various representations ...
Actually, I had in mind a combination of all above, with a number on head representing the version of algorythm used to represent particular set (extra byte or word or long), with also "negative image set" - this would be representation of the complement of the set (used only when this would be opportune - in situation such as "full_set - [one_lement] and like).
OTOH, such a set could quite easily be represented as the union of two intervals. Don't know which is better, though.
A format should definitely support a compact representation of intervals since these are basic elements of set constructors. (Single elements can, of course, be considered as an interval as well.)
This way I think the efficiency would already be linear compared to the number of basic operations ([], +, -, *, ><) needed to construct a set. (Of course, the set of all odd integers, e.g., would be very inefficient to represent this way, but it would also take approx. MaxInt operations to construct it.)
But then, the constant factor is rather high. A set of n non-successive elements would take 64n bits on a 32 bit system while the bitfield representation takes 1 bit per element of the range (so if more than 1 of 64 elements are set, it's smaller). I think something can be done about it -- perhaps some ideas of general compression techniques, perhaps something more specialzed ...
Then again, that would lead to increase in code complexity comparing to elegance shown in p/rts/sets.pas ...
However, SPARSE SETs seem to me like an excellent challenge for a programmer, but they *do* introduce new issues, for example memory allocation problems - since their size can't be computed at compile time since it depends on actual # of set members; and so on and so on ...
Yes, they'd have to be dynamically allocated (behind the scenes). Then they probably should be reference counted with copy-on-write to allow for fast assignments (including parameter passing). Since we plan similar things for (unbounded) strings, that's not a new issue.
Frank