On Sat, 2013-01-19 at 11:39 -0800, Ben Wolfson wrote:
> You couldn't observe the breakage, but it would still the case that
> for many elements of the domain no finite subsequence of the seq
> contains those elements.
Indeed, it would merely be observably correct, not actually correct.
What do you return for count, though?
> There are other ways to make trouble anyway: it's perfectly possible
> to define infinite sets that support conjoining, disjoining, union,
> intersection, difference, etc., whether in forms that also support
> seq-ing, e.g. sets of multiples of a given integer, or not (or not
> obviously to me), in terms of an arbitrary characteristic
> function---these not necessarily being infinite, I suppose.
Such sets couldn't support forward domain transformation, though,
because membership testing could then fail to terminate.
> I don't really understand this. Surely you can, in fact, transform the
> domain of an associative the same way you transform the domain of a
> function? You could support the associative interface via a function
> from newdomain -> olddomain + the old associative.
But you couldn't transform that result's domain with a newdomain ->
newhotnessdomain; it would thus no longer be an associative under the
qualification I'm positing.
It would be no different from converting to a function, with a
peculiarly shaped codomain that modeled domain membership testing, then
transforming the domain in the usual way for functions.
> (And if you can go function -> associative
But you can't.
> If the domain transformation function is injective and the associative
> maps everything to the same value, then transforming the domain
> forward is a no-op: there can't be something in the new domain that
> wasn't in the old domain at all, since everything was in the old
> domain. All we could do is shuffle elements in the domain around with
> respect to what they're associated with. But they're all associated
> with the same thing. You don't need to enumerate anything in this
> case.
Yes; this is the case I described as follows:
The only way you can apply both transformations is if your
domain is vacuous: that is, constant functions like yours are
the only ones that permit domain transform in either direction.
> If the domain transformation function is not injective, then I get
> very nervous about transforming the domain at all.
I would absolutely agree that only injective forward domain
transformations are well-defined.
> But in the end my more fundamental question is: what makes it the case
> that associatives can transform their domains forward? AFAICT the
> answer is "the enumerability of associatives".
My previous email argued that the former implied the latter, rather than
vice versa. Forward domain transformation via injection seems more
fundamental than enumerability, to me.
> So, in fact, it has not helped me to look at the relation between
> enumerability and forward domain transformability, because I no more
> see why the latter is something that belongs with associating elements
> of a domain with elements of a codomain than I do the former.
Because that definition of associative, "associating elements of a
domain with elements of a codomain", is entirely characterized by the
codomain of the associative -> function isomorphism. Such functions
support containsKey, entryAt, assoc, and both valAts.
Because such an isomorphism exists, the only reason to use this
not-a-function is to exploit the extra operations and guarantees by law
we get, and allowing domain transformation this way is a stronger claim
than the ability to override particular mappings.
--
Stephen Compall
^aCollection allSatisfy: [:each|aCondition]: less is better
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
