[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Two maybebugs and two proposals
This page is part of the web mail archives of SRFI 67 from before July 7th, 2015. The new archives for SRFI 67 contain all messages, not just those from before July 7th, 2015.
Hello Amir,
Thank you for the remarks.
> Actually, it would work iff thereone exactly
one class.
You are right; we'll correct it.
> Also, in an impure language such is Scheme, a
comparison function
> can be defined from equality  but not in O(1)
operations.
We state that already by saying there
are no "sublinear worstcase" data structures
for this. I'll rewrite the remark to
make it clearer and given an implementation explicitly;
it might prove useful to somebody someday.
> The specification of the chain functions (#node_idx_90)
states clearly
> that when exactly one value is given, the comparison function should
> still be invoked. The purpose of this is not clear, since the only
> difference between this comparison and a noop is typechecking. IMO,
> there is no use for this kind of uniformity here (to me it doesn't
seem
> uniform at all).
The purpose of calling the compare procedure
for the only element
of a chain of length one is indeed
typechecking: I am not sure what
you mean by "uniformity" here,
but after calling
(apply
chain<? compareinteger xs)
you may assume that xs is a list of
objects satisfying integer?,
irrespectively of the length of xs or
the outcome of the test.
(We'll add a clarifying remark in the
specification.)
In my experience, most people will assume
that xs is a list of
integers anyhow, no matter what is actually
specified for chain<?.
(And we try to minimize the "gotcha
potential.")
> I would like the <? family of functions to
take only one parameter, the
> comparison function, so that they will transform from comparison
> functions to predicates. This is also doable with srfi26 as (cut
<? <>
> <>), but for many uses, including the second proposal, the shorter
form
> is nicer.
>
> Another proposal is to drop the `chain' functions. There is one basic
> higher order list function, (chain pred . elts) that applies the elts
in
> consecutive pairs. If the previous proposal is also accepted, all
that
> would be required from uses is typing (chain (<? comp) ...) instead
of
> (chain<? comp ...). It would also allow nonsrfi67 uses of this
list
> function, and using defaultcompare: (chain <? ...) works as (chain<?
> defaultcompare ...) does in the document.
Incidentally, we had this design in
an earlier (before release) version
of the SRFI and we switched to the current
design later.
However, we switched before we had invented
IF<? and friends, which
were conceived when I caught myself
avoiding (if ((<? compare) x y) ..) in
the reference implementation for minor
efficiency concerns and lying to
myself about efficiency in the spirit
of "but in the application I will use it."
Now may be the time to revise the earlier
decision, as you propose.
The alternatives are: Parametric tests
(<? compare x y) vs. higherorder
procedures (<? compare) => predicate.
I would like to think about this first,
and come back to it later.
For the chain tests: The five tests
currently specified make sense and are
clearly defined and efficient. (chain?
(not=? compare) x ...) is very dangerous,
and the need for nonSRFI67 use of
chain testing is hardly an issue. So,
at least I am pretty happy with chain<?
and friends and pairwisenot=?.
Sebastian.
P.S. Sorry for copying you email once
again below, but Philips uses Lotus Notes....

Dr. Sebastian Egner
Senior Scientist Channel Coding & Modulation
Philips Research Laboratories
Prof. Holstlaan 4 (WDC 1051, 1st floor, room 51)
5656 AA Eindhoven
The Netherlands
tel: +31 40 2743166 *** SINCE 10Feb2005
***
fax: +31 40 2744004
email: sebastian.egner@xxxxxxxxxxx

srfi67request@xxxxxxxxxxxxxxxxx
14042005 13:57

To:
srfi67@xxxxxxxxxxxxxxxxx
cc:
(bcc: Sebastian Egner/EHV/RESEARCH/PHILIPS)
Subject:
Two maybebugs and two proposals
Classification:

In the question about deriving ordering from equality
(#node_toc_node_sec_Temp_25), it is claimed that the definition doesn't
work if there is more than one element. Actually, it would work iff
thereone exactly one class. Also, in an impure language such is Scheme,
a comparison function can be defined from equality  but not in O(1)
operations.
The specification of the chain functions (#node_idx_90) states clearly
that when exactly one value is given, the comparison function should
still be invoked. The purpose of this is not clear, since the only
difference between this comparison and a noop is typechecking. IMO,
there is no use for this kind of uniformity here (to me it doesn't seem
uniform at all).
I would like the <? family of functions to take only one parameter,
the
comparison function, so that they will transform from comparison
functions to predicates. This is also doable with srfi26 as (cut <?
<>
<>), but for many uses, including the second proposal, the shorter
form
is nicer.
Another proposal is to drop the `chain' functions. There is one basic
higher order list function, (chain pred . elts) that applies the elts in
consecutive pairs. If the previous proposal is also accepted, all that
would be required from uses is typing (chain (<? comp) ...) instead
of
(chain<? comp ...). It would also allow nonsrfi67 uses of this list
function, and using defaultcompare: (chain <? ...) works as (chain<?
defaultcompare ...) does in the document.