Endless arguing

[Tim Rentsch]

I think he makes way more than five a day. But yes, he does tend to end up
with more responses than his original posts. And yes, I would agree that
at this point, "challenging" the noisemakers isn't doing anything.

Step 1: Killfile Nilges.
Step 2: Encourage other people to do so.
Step 3: Try to keep responses to anything in his threads strictly topical.
Step 4: ???
Step 5: Profit!

Step 4: Refrain from making any kind of ad hominem remark,
against anyone, in any posting. Assuming the choice has
been made to write a response/followup, write about what
was written, not about the person who wrote it. Calling
someone a "troll" (or any other such appellation) is just
as much part of the problem as whatever it was the "troll"
did in the first place.

 

[Seebs]

Step 4: Refrain from making any kind of ad hominem remark,
against anyone, in any posting. Assuming the choice has
been made to write a response/followup, write about what
was written, not about the person who wrote it. Calling
someone a "troll" (or any other such appellation) is just
as much part of the problem as whatever it was the "troll"
did in the first place.

I'm not convinced of that. Overall, DNFTT seems to rely to
some extent on convincing people that a given person is, in
fact, a troll. People who don't believe that are unlikely to
participate in avoiding/ignoring the troll.

Sometimes, it really *does* matter what you think of the person,
not just what you think of the post. As an example, look at
Bill Cunningham's endless series of combinations of newbie
questions. A reasonable response to those from someone who has
never seen one before is *very* different from a resaonable response
to them from someone who's seen his last decade or so of asking
questions and then ignoring the answers, or "learning" something
only to have no idea even what the words used to describe it are
a few months later.

-s

 

[Seebs]

But you only replied to one, so the debate never got going.

I'm pretty sure he's killfiled me, which turns out to remove about
half of the responses to his container library posts and discussion.
(At least, I don't recall having received any acknowledgement of or
response to any of my questions, comments, suggestions, or other feedback
about it in recent months.)

-s

 

[Eric Sosman]

[...]
An obvious issue suggests itself. One of the most useful containers is
the "hash" -- that's sort of a perlism as a name, but basically, an
associative array in which each member has a key, but keys are not necessarily
a numerically-ordered list.

So, if I call GetFirst() on such a thing, how/where do I find out what key
is associated with the first item?

For what it's worth, Java deals with this issue in three ways.
First, you can iterate over the "key set" of the hash table, getting
each key once and once only and using it (if you like) to look up the
associated value. Second, you can iterate over the "values," getting
each value exactly as many times as it appears but learning nothing
about the keys (unless the values themselves refer to their own keys,
which is an extra-container mechanism). Finally, you can iterate over
the "mapping," getting each key/value pair exactly once. In all three
styles, the order in which keys/values/pairs are visited is whatever
the hash table feels like.

 

[Ersek, Laszlo]

Ersek, Laszlo a écrit :

If I ever intended to unify iterator interfaces at all, that was about the
end of it. As soon as I wanted to bolt something "really useful" on an
iterator interface, it was immediately shown to be container specific. I
took it as proof that my pursuit is futile.

[...]

I solved your problem. Now, it would be nice if you worked with me and
we could develop this together. I can't do everything alone.

Thanks for your contribution

You made me laugh (in the best sense of the word); great style, thanks
I'll respond to the meat of your posting by piggybacking Seebs' answer.

Cheers,
lacos

 

[Ersek, Laszlo]

Hmm.

Oh yes, "Hmm" it is! Why not GetLast() too? forward iterator, backward
iterator, bidirectional iterator; one kind to return non-const pointers
(to nodes or to objects, see next point), one kind to return const
pointers. It may not be a simple matter of casting, as the iterator is
stateful, and const and non-const iterators may react differently to
whole-structure modifications. Or something like that.

Okay.

Hmm, nope. I wish to be able to store null pointers in the structure.

Seems reasonable.

To an extent, yes. But this is a quite featureless iterator; the
"inflexible" case in my previous post. We didn't talk about what happens
to existing iterators when I delete (a currently pointed-to, or a
completely unrelated) element. Can I assign iterators? Can I fork
iterations? We'll need a bunch of iterator characteristics, organize them
into characteristics-sets, and build a hierarchy of them with the
subset-of operator.

An obvious issue suggests itself. One of the most useful containers is
the "hash" -- that's sort of a perlism as a name, but basically, an
associative array in which each member has a key, but keys are not necessarily
a numerically-ordered list.

So, if I call GetFirst() on such a thing, how/where do I find out what key
is associated with the first item?

Another thing to consider: Trees. Do you want to have something like
Iterator *it = GetIterator(tree, ITERATE_DEPTH_FIRST);
or what? (It is not necessarily an attribute of the tree itself whether
you want to iterate over it depth-first or breadth-first!)

There, you've said it.

Perhaps we should make the GetIterator() "factory" function to take a
variable argument list. Or we could make concrete containers with concrete
iterators, and allow the programmer to create *ad-hoc* wrappers, like
GetFirst(), GetNext(), GetPrevious(), for containers and iterators he
knows for sure he'll use.

(I'm not necessarily agreeing with myself on this, but it is an
interesting standpoint to explore, I find.)

Cheers,
lacos

 

[Ersek, Laszlo]

In all three styles, the order in which keys/values/pairs are visited is
whatever the hash table feels like.

Yes, this is the correct wording, "unspecified order". Not "random order",
because then some poor bloke will start to rely on GetNext() jumping among
values, and then somebody will implement the interface with a red-black
tree.

lacos

 

[Ersek, Laszlo]

I'm pretty sure he's killfiled me, which turns out to remove about
half of the responses to his container library posts and discussion.
(At least, I don't recall having received any acknowledgement of or
response to any of my questions, comments, suggestions, or other feedback
about it in recent months.)

Willfully ignoring the actual question of Seebs being present in jacob's
killfile or not, this is *exactly* my problem. I planned to follow up on
Richard Heathfield's posting, but now I'm drawn to do it here instead:

Do you honestly think the S/N ratio will improve if the noisemakers go
unchallenged?

Yes, I do. I have a simplistic view which seems to work:

- noisemakers tend to make noise wherever they go:

killfile entry -> From: noisemaker, Subject: *

- others tend to contribute to the noise only if they follow-up on noisy
threads:

killfile entry -> From: non-noisemaker, Subject: noise

The first type of entry has a long TTL and the *group* of those entries as
a whole rarely needs editing. The second type has a short TTL and the
group of those entries needs incessant editing. It also bears the risk of
losing occasional pearls posted to noisy threads by contributors I esteem
highly. So I'm forced to cherry pick until I conclude the thread has
regressed beyond repair. This is very tiresome. If we could eliminate the
second group, it would be great.

How this relates to Seebs potentially being killfiled by jacob; IOW, why
I'm following up on Richard's question here: I can imagine a scenario
where jacob grew tired of Seebs' noise posted *only* to noisy threads
(second category), and instead of constantly updating his subject-based
kill filter, he modified his other filter (first category), permanently
making the risk of losing those pearls I talked about above actually
manifest with probability 1.

My From:-based killfile works great across subjects and even different
groups. The Subject:-based one produces both false positives (if I add a
thread, I may lose valuable contributions) and false negatives (I don't
add a whole thread but cherry-pick postings based on From:, and to my
dismay, I find noise nonetheless).

Cheers,
lacos

 

[Alan Curry]

|
|Do you honestly think the S/N ratio will improve if the noisemakers go
|unchallenged?

As much as I'm about to hate myself for posting to a meta thread:

Yes!

Yes, yes, and more yes.

 

[jacob navia]

Seebs a écrit :

An obvious issue suggests itself. One of the most useful containers is
the "hash" -- that's sort of a perlism as a name, but basically, an
associative array in which each member has a key, but keys are not necessarily
a numerically-ordered list.

So, if I call GetFirst() on such a thing, how/where do I find out what key
is associated with the first item?

I use a hash table with collisions handled in linked lists.

Then, GetFirst() goes to the start of the hash table until it finds
a non-empty slot. Then, it returns that object and stores two things
(1) the index of the non-empty slot
(2) the list element within that slot.

The GetNext() routine takes the list pointer and advances it. If NULL,
the it goes on scanning the next non-empty slot.

Easy. The Getlast() routine does the same stuff backwards. (Together with
"GetPreviuos()"

Another thing to consider: Trees. Do you want to have something like
Iterator *it = GetIterator(tree, ITERATE_DEPTH_FIRST);
or what? (It is not necessarily an attribute of the tree itself whether
you want to iterate over it depth-first or breadth-first!)

You can store the way you want the sree scanned in the Flags field
with tree->VTable->GetFlags and tree->VTable->SetFlags

jacob

 

[jacob navia]

Ersek, Laszlo a écrit :

Yes, this is the correct wording, "unspecified order". Not "random
order", because then some poor bloke will start to rely on GetNext()
jumping among values, and then somebody will implement the interface
with a red-black tree.

lacos

Yes: unspecified order.

 

[Seebs]

I use a hash table with collisions handled in linked lists.

Then, GetFirst() goes to the start of the hash table until it finds
a non-empty slot. Then, it returns that object and stores two things
(1) the index of the non-empty slot
(2) the list element within that slot.

Okay. But I'm confused. I want to know, not just the value in the slot,
but the key for it. How do I get that?

You can store the way you want the sree scanned in the Flags field
with tree->VTable->GetFlags and tree->VTable->SetFlags

I don't think that's the right way to do it -- it should be an attribute
of the iterator, not of the tree.

I don't know. I'm still not sure the underlying premise (that there's
measurable utility to C programs in having this kind of shared interface
to things so different that there is no way to swap one in for another
in a well-designed program to begin with) is valid.

-s

 

[jacob navia]

Ersek, Laszlo a écrit :

Hmm, nope. I wish to be able to store null pointers in the structure.

You can store NULL pointers.

You get a POINTER to an object. That object can be anything, but to
access it you have to dereference the pointer you got. When you
dereference it you CAN get NULL pointers OF COURSE...

 

[Seebs]

Yes, this is the correct wording, "unspecified order". Not "random order",
because then some poor bloke will start to rely on GetNext() jumping among
values, and then somebody will implement the interface with a red-black
tree.

Interestingly, the major hash implementations I know of are now all
consistent in order; if you request a walk of the hash, you get the items
in insertion order unless you've sorted them into a different order. Thus,
ordering is separate from keys.

This turns out to be sufficiently useful that it's now standard in at
least Ruby and PHP, and I think modern perl may be doing it too now, or
maybe that was for next release.

Basically, the performance gain of the "we don't specify" turns out to be
dwarfed by the performance costs of forcing users to do the sorting all
the time when they want to sort it.

-s

 

[jacob navia]

Ersek, Laszlo a écrit :

Ersek, Laszlo a écrit :

If I ever intended to unify iterator interfaces at all, that was
about the end of it. As soon as I wanted to bolt something "really
useful" on an iterator interface, it was immediately shown to be
container specific. I took it as proof that my pursuit is futile.

[...]

I solved your problem. Now, it would be nice if you worked with me and
we could develop this together. I can't do everything alone.

Thanks for your contribution

You made me laugh (in the best sense of the word); great style, thanks
I'll respond to the meat of your posting by piggybacking Seebs' answer.

Cheers,
lacos

I am serious. I need help, and it would be nice if many people would
review that code.

jacob

 

[Seebs]

I am serious. I need help, and it would be nice if many people would
review that code.

The problem is, the code started out going in a direction that is, so far
as I can tell, completely contrary to anything I want or need. Imagine
that I was sort of interested in tool design, and someone announced a plan
to work on the hammerscrewdriversaw, a device which is a hammer, a
screwdriver, and a saw. I might be able to point out things like "you
are going to need wildly incompatible material characteristics for these
three tasks", but I can't do much to help. Yes, it's hard. It's extremely
hard. It's also not something I want to begin with, so it's not clear
why I should help.

It might be rewarding to start by looking at how you'd make a really good
interface for each of two or three common container types, and then examining
the resulting interfaces to see whether there is really enough commonality
to justify trying to build a hybrid. My guess is that there simply isn't,
and there's also no reason for one. There simply aren't that many cases
where it would make sense to switch from one to another.

-s

 

[jacob navia]

Seebs a écrit :

Okay. But I'm confused. I want to know, not just the value in the slot,
but the key for it. How do I get that?

I wrote a function GetKeys() that returns a string collection with all
stored keys. Is that what you need?

I don't think that's the right way to do it -- it should be an attribute
of the iterator, not of the tree.

Impossible because that would be container specific (trees) and would
not work with lists.


What is important to remember is basic software design principles.
Information hiding means that the user doesn't NEED to know if the
container is a tree or a list. This is a central point in the design of
the library.

I don't know. I'm still not sure the underlying premise (that there's
measurable utility to C programs in having this kind of shared interface
to things so different that there is no way to swap one in for another
in a well-designed program to begin with) is valid.

The learning curve is MUCH smaller. The surface that the library
uses in your memory is smaller. as you know, we can buy memory
extensions for our computers any time. There is no shop (yet) to buy a
brain memory extension however...

 

[Ersek, Laszlo]

Ersek, Laszlo a écrit :

You can store NULL pointers.

You get a POINTER to an object. That object can be anything, but to
access it you have to dereference the pointer you got. When you dereference
it you CAN get NULL pointers OF COURSE...

Now that you put it this way: sure. Original text was:

This 3 function pointers yield a pointer to each stored object, or NULL
when there are none.

I think I misunderstood the word "stored" in "stored object". The
intrusive/non-intrusive dichotomy, again. You meant non-intrusive, ie.
deep copies. I meant intrusive, ie. links.

lacos

 

[Keith Thompson]

Interestingly, the major hash implementations I know of are now all
consistent in order; if you request a walk of the hash, you get the items
in insertion order unless you've sorted them into a different order. Thus,
ordering is separate from keys.

This turns out to be sufficiently useful that it's now standard in at
least Ruby and PHP, and I think modern perl may be doing it too now, or
maybe that was for next release.

Perl hashes still give you an unspecified (the documentation says
"seemingly random") order. Recent versions of Perl deliberately give
you different orders from one run to the next of the same program.
the older algorithm was susceptible to attacks that could generated
degenerate internal data structures, resulting in very expensive
operations on the resulting hashes. Deliberate randomization was the
solution to that (whether it was the best one is another question).

You can't even determine the order in which the items were inserted
unless you store it yourself.

For the Perl-specific details (which might be illuminating for
designing something similar in C) "perldoc perlsec" and search for
"Algorithmic Complexity Attacks".

Basically, the performance gain of the "we don't specify" turns out to be
dwarfed by the performance costs of forcing users to do the sorting all
the time when they want to sort it.

Another approach is to treat unordered hashes and ordered hashes as
different data structures. Sometimes you need ordering, but when you
don't there's no point in paying the cost to maintain the information.
Whether this justifies the additional complexity of having two
different data structures rather than one is yet another question.

 

[Ian Collins]

Interestingly, the major hash implementations I know of are now all
consistent in order; if you request a walk of the hash, you get the items
in insertion order unless you've sorted them into a different order. Thus,
ordering is separate from keys.

The new C++ unordered containers have unspecified order. At least with
the boost versions, the order depends on the number of items in the
container and the hash bucket size.