During the Euler stuff I came upon this following sub-problem.
It is elementary enough to be in a library somewhere.
An area giving as (addr_start, addr_end) contains items
of length ``len''. I want to get of the duplicates.

Sorting the items is pretty easy, qsort can handle that.
Now eliminating the duplicates, we need only compare one
item to the next.
Something along compact (start, end, len -- end' )
The new end should be returned, of course.

Even using variables/locals, I find this difficult.
(More difficult then e.g. making a table for the number of
dividers of N, which sounds much less trivial.)

On May 24, 3:05 pm, Albert van der Horst
wrote:

It's not difficult if you have a library of sequence operations:

http://factor-language.blogspot.com/2008/05/removing-duplicates-from-sequence.ht...

Slava

Slava Pestov wrote:

Nice filter, but doing that in-place is not difficult, either.

I give you a solution for characters in a string, and Albert can generalize
it. It is supposed that the string is sorted, so it will only remove
sequenes of the same character:

: uniquify ( addr u -- addr u' )
over >r bounds dup dup c@ 2swap 1+ ?DO
I c@ tuck <> IF swap 1+ 2dup c! swap THEN LOOP
drop r> swap over - ;

On May 24, 4:36 pm, Bernd Paysan wrote:

This is why stack-based languages have a reputation of unreadability.

Slava

On May 24, 6:23 pm, Slava Pestov jedit.org> wrote:

``uniquify'' ... I dunno, that word looks pretty readable to me.

Its *definition* is underfactored, of course, and underfactored
definitions are always hard to read, but

uniquify ( addr u

On May 24, 1:05 pm, Albert van der Horst
wrote:

Bruce McFarling netscape.net> wrote:

So, could you try your hand at a properly factored definition. This is
a good example of the kind of thing I never code cleanly in Forth.

Thanks,
Andy Valencia

Slava Pestov wrote:

I both agree and disagree with you in this case. It is not the kind of
code I would normally write, especially if in a hurry to get the job
done. Of course I could spend the time to pick it apart and see exactly
what is going. But why bother? The word works. Some people, like
Bernd, can probably glance at code like this and easily/quickly see
exactly what makes it tick. I am not one of those people, even though I
like and use Forth.

I will hang on to 'uniquify' because I can see where it could be useful
to me in the future. (Thanks Bernd!).

-Doug

On May 24, 9:18 pm, Doug Hoffman wrote:

Albert van der Horst wrote:

What if the original ordering must be preserved? By sorting, you've
destroyed that ordering. You would now have to annotate each item so
that you could later sort again. So the computational cost of this now
requires an annotation pass and two sorts... if the original ordering
must be preserved.

A less general way to deal with this would be to construct a parallel
data structure that recorded the values. In the case where each item
was relatively small (say, a 16-bit integer or a 8-bit character), then
a bitmap is an obvious data structure. As you move through the list of
items, check first if the item is set in the bitmap. If it is, then
it's a duplicate. If it isn't, then mark the bitmap. No sorting is
necessary and duplicate detection occurs in a single pass.