Vassil Nikolov wrote:
>> Is there some efficient method for comparing hash tables, if
>> these are allowed to have other hash tables as keys?
> EQUAL is the same as EQL for hash tables, therefore it has limited
> usability as the hash table test if the keys can also be hash tables.
I choose hash tables with :test 'equal, because for elements this
seems to be the best comparison. But for sets of sets this produces
multiple instance in the hash tables.
> Now EQUALP does descend hash tables recursively, so it might (or
> might not) be suitable for your purposes.
I did not try equalp, because strings and other types of elements
are not compared well.
> Why not define the set equality test in terms of the test for subset,
> the latter being easily done by a `single pass' of MAPHASH
If I understand you well, a single level of comparisons should not
suffice. This is also so in set theory: By definition two sets A and B
are "equal" if they have the same elements. But this means
that every element x of A has to be "equal" to some element y of B and
viceversa, and if x and y are both sets, one has to apply again the
definition of "equal", which becomes therefore recursive.
It appears to be complicated. The algorithm I proposed seems to work
however. Maybe it is slow, but these are difficult and abstract
constructions, so I'm wondering why one discusses here whether Lisp
is dying. A language in which one can write so powerful operations
in a few lines can only die by bad marketing, confusion of
implementations or resistance by those who don't want to learn it
(or don't believe to be able to learn it).
I'm rather new to the language and live far away from software
business, so my opinions are naive. The winning strategy is probably
not to distillate a core Lisp, if this means to eliminate the higher
features, but to reorganize what in Lisp exists. On the one hand there
are many old names, difficult to remember. Why not "put" instead of
"setf", "case" instead of "cond", at least "first" and "rest" also in
the system's response, or macro characters for them, why not "op"
instead of "lambda" (someone knows how to do this?), why not ^ instead
of #' (I made this already, it is much easier to write especially when
preparing a function by hand)? A good collection of system modules as
in Python would be useful. With little modifications Lisp also from the
aesthetical point of view would be superior to every other language I
know.
Perhaps it has shifted too much to the computer science side, and
a renewed emphasis on its incredible mathematical content could
be good. Some big programmers think that the main value of Lisp is
in the big programs. But I believe that it is also a wonderful
language for doing small things, a companion for developing
reasonings and algorithms, where I can write (with the usual
non-standard parts)
(reduce ^+ (mapcar ^1/xx [1 n :if-not ^evenp]))
after (def 1/xx (x) (/ (* x x))) or
(defconstant +i (complex 0 1))
(defconstant -i (complex 0 -1)).
Josef Eschgfaeller
Dipartimento Matematico
Universita' di Ferrara
http://felix.unife.it/ Mathematical BBS
On Mon, 02 Aug 1999 03:10:31 +0000,
Josef Eschgfaeller <···@felix.unife.it> wrote:
>Vassil Nikolov wrote:
>
>It appears to be complicated. The algorithm I proposed seems to work
>however. Maybe it is slow, but these are difficult and abstract
>constructions, so I'm wondering why one discusses here whether Lisp
>is dying. A language in which one can write so powerful operations
>in a few lines can only die by bad marketing, confusion of
>implementations or resistance by those who don't want to learn it
>(or don't believe to be able to learn it).
>
>I'm rather new to the language and live far away from software
>business, so my opinions are naive. The winning strategy is probably
>not to distillate a core Lisp, if this means to eliminate the higher
>features, but to reorganize what in Lisp exists. On the one hand there
>are many old names, difficult to remember. Why not "put" instead of
I do wish that the standard would allow the user to specify a hashing
function. Hash tables would be even more useful.
As far as the core lisp goes.... I think this is called scheme :-)
--
Kenneth P. Turvey <·······@SprocketShop.com>
----------------- http://www.tranquility.net/~kturvey
We all enter this world in the same way: naked; screaming; soaked in
blood. But if you live your life right, that kind of thing doesn't
have to stop there. -- Dana Gould
In article <·················@felix.unife.it>,
Josef Eschgfaeller <···@felix.unife.it> wrote:
>
>> Now EQUALP does descend hash tables recursively, so it might (or
>> might not) be suitable for your purposes.
>
>I did not try equalp, because strings and other types of elements
>are not compared well.
>
What kind of base-level elements comprise your sets such that
EQUALP is not suitable? Maybe case-distinction in strings is
significant?
Additionally, using modifyable structures as hash-table keys
can be dangerous: if the structure is modified, its hash-code
might change as well.
Bernhard
--
--------------------------------------------------------------------------
Bernhard Pfahringer
Austrian Research Institute for http://www.ai.univie.ac.at/~bernhard/
Artificial Intelligence ········@ai.univie.ac.at
Josef Eschgfaeller wrote: [1999-08-02 03:10 +0000]
> Vassil Nikolov wrote:
>
> >> Is there some efficient method for comparing hash tables, if
> >> these are allowed to have other hash tables as keys?
>
> > EQUAL is the same as EQL for hash tables, therefore it has limited
> > usability as the hash table test if the keys can also be hash tables.
>
> I choose hash tables with :test 'equal, because for elements this
> seems to be the best comparison. But for sets of sets this produces
> multiple instance in the hash tables.
Of course, precisely because it is nothing more than EQL for hash tables.
> > Now EQUALP does descend hash tables recursively, so it might (or
> > might not) be suitable for your purposes.
>
> I did not try equalp, because strings and other types of elements
> are not compared well.
Yes, this is yet another proof of the fact that there can't be a
universal equality test.
> > Why not define the set equality test in terms of the test for subset,
> > the latter being easily done by a `single pass' of MAPHASH
>
> If I understand you well, a single level of comparisons should not
> suffice. This is also so in set theory: By definition two sets A and B
> are "equal" if they have the same elements. But this means
> that every element x of A has to be "equal" to some element y of B and
> viceversa, and if x and y are both sets, one has to apply again the
> definition of "equal", which becomes therefore recursive.
What I meant was that if one implements (SET-EQUAL A B) as
(AND (SUBSETP A B) (SUBSETP B A)), one produces a more elegant
implementation which does not require copying one of the sets
just to delete its elements one by one. (Of course this has to
be applied recursively to any elements which are sets themselves.)
In any case, there is something inconsistent here. If you are not
concerned with performance (i.e. with speed), why not use simpler
data structures for the sets (e.g. there is already Lisp support for
sets represented as lists). If you are concerned with performance
(which seems to be indicated by the use of hash tables), then you
might be better off doing your set abstractions on top of
special-purpose hash tables that you implement yourself, as Common
Lisp's general-purpose hash-tables are not very good when the
keys can also be hash-tables.
[...]
> On the one hand there
> are many old names, difficult to remember. Why not "put" instead of
> "setf", "case" instead of "cond", at least "first" and "rest" also in
> the system's response, or macro characters for them, why not "op"
> instead of "lambda" (someone knows how to do this?), why not ^ instead
> of #' (I made this already, it is much easier to write especially when
> preparing a function by hand)?
One can't just go around and change names. Regarding the examples
you mention:
* SETF is named so for a very good reason---it is a generalisation
of SET[Q] for places, i.e. for arbitrary `holders' of data including
components of data structures (the name comes from `SET Field'
since such components are often called fields). Besides, PUT
already has a meaning in Lisp (though it is no longer a standard
function in Common Lisp) as the function that changes an entry
on the property list of a symbol, as the companion of GET; in
Common Lisp, instead of (PUT symbol indicator value), one
does (SETF (GET symbol indicator) value).
* CASE exists in Common Lisp and serves the same purpose as
case in Pascal or switch in C, something which is quite different
from COND (which is an if-elseif-elseif...else construct).
* I don't understand what you mean by `FIRST and REST also in the
system's response'; as to macro characters for them, one can't
possibly have macro characters for everything.
* If LAMBDA would be changed, the really appropriate name would
be ANONYMOUS-FUNCTION, *not* OP, but any change is pointless
because of the enormous amounts of existing code that use LAMBDA.
Besides, what is really wrong with LAMBDA (as a name)? As soon
as one knows at least a little about lambda-calculus, one should
see that LAMBDA is a perfectly good name.
* There is at least one reason why one should stick to #' and not
change it to ^ or whatever, and that is communication with others.
Let me quote Feynman:
While I was doing all this trigonometry, I didn't like the
symbols for sine, cosine, tangent, and so on. [...] So I invented
[other symbols].
[...]
I thought my symbols were just as good, if not better, than
the regular symbols---it doesn't make any difference _what_
symbols you use---but I discovered later that it _does_ make
a difference. Once when I was explaining something to another
kid in high school, without thinking I started to make these
symbols, and he said, ``What the hell are those?'' I realized
then that if I'm going to talk to anybody else, I'll have to use
the standard symbols, so I eventually gave up my own symbols.
(Richard P. Feynman, _``Surely You're Joking, Mr. Feynman!''_.
W. W. Norton & Company, New York - London, 1997, p. 24.
ISBN 0-393-31604-1)
[...]
> With little modifications Lisp also from the
> aesthetical point of view would be superior to every other language I
> know.
It is not trivial to do modifications while at the same time
preserving the language's stability and not spoiling a miriad of
other things. But a lot has already been said on this issue, e.g. by
Kent Pitman.
> Perhaps it has shifted too much to the computer science side, and
> a renewed emphasis on its incredible mathematical content could
> be good. Some big programmers think that the main value of Lisp is
> in the big programs. But I believe that it is also a wonderful
> language for doing small things, a companion for developing
> reasonings and algorithms
[...]
Oh yes, definitely.
Vassil Nikolov
Permanent forwarding e-mail: ········@poboxes.com
For more: http://www.poboxes.com/vnikolov
Abaci lignei --- programmatici ferrei.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.