Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #29438 > unrolled thread

passing a set of numbers to a function

Back to article view | Back to comp.lang.javascript

Contents

  passing a set of numbers to a function Matheus Suffi <matheus.suffi40@gmail.com> - 2016-01-25 04:45 -0800
    Re: passing a set of numbers to a function Aleksandro <aleksandro@gmx.com> - 2016-01-25 10:51 -0300
    Re: passing a set of numbers to a function Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-29 03:57 +0100
      Re: passing a set of numbers to a function Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2016-01-28 23:19 -0800
        Re: passing a set of numbers to a function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-29 10:09 +0000
          Re: passing a set of numbers to a function John Harris <niam@jghnorth.org.uk.invalid> - 2016-01-29 10:20 +0000
            Re: passing a set of numbers to a function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-29 12:23 +0000
              Re: passing a set of numbers to a function John Harris <niam@jghnorth.org.uk.invalid> - 2016-01-29 14:50 +0000
                Re: passing a set of numbers to a function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-29 16:11 +0000
                  Re: passing a set of numbers to a function John Harris <niam@jghnorth.org.uk.invalid> - 2016-01-30 10:10 +0000
            Re: passing a set of numbers to a function Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-29 08:35 -0800
              Re: passing a set of numbers to a function John Harris <niam@jghnorth.org.uk.invalid> - 2016-01-30 10:34 +0000
                Re: passing a set of numbers to a function Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-30 18:53 -0800
                  Re: passing a set of numbers to a function John Harris <niam@jghnorth.org.uk.invalid> - 2016-01-31 14:50 +0000
                    Re: passing a set of numbers to a function Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-31 09:56 -0800
                      Re: passing a set of numbers to a function John Harris <niam@jghnorth.org.uk.invalid> - 2016-02-01 11:02 +0000
                        Re: passing a set of numbers to a function Scott Sauyet <scott.sauyet@gmail.com> - 2016-02-01 18:10 -0800
          Re: passing a set of numbers to a function Gene Wirchenko <genew@telus.net> - 2016-01-29 09:38 -0800
            Re: passing a set of numbers to a function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-29 20:17 +0000
          Re: passing a set of numbers to a function Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-29 20:08 +0100
      Re: passing a set of numbers to a function Aleksandro <aleksandro@gmx.com> - 2016-01-29 10:32 -0300
        Re: passing a set of numbers to a function "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-01-29 14:53 +0100
          Re: passing a set of numbers to a function Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-29 06:26 -0800
      Re: passing a set of numbers to a function John Harris <niam@jghnorth.org.uk.invalid> - 2016-01-29 14:19 +0000
        Re: passing a set of numbers to a function Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-29 08:38 -0800
          Re: passing a set of numbers to a function Aleksandro <aleksandro@gmx.com> - 2016-01-29 13:54 -0300
            Re: passing a set of numbers to a function Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-29 10:11 -0800
              Re: passing a set of numbers to a function Aleksandro <aleksandro@gmx.com> - 2016-01-29 15:38 -0300
              Re: passing a set of numbers to a function Anders Wegge Keller <wegge@geostat.dk> - 2016-01-29 20:13 +0100
                Re: passing a set of numbers to a function Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-29 20:46 +0100
                  Re: passing a set of numbers to a function Aleksandro <aleksandro@gmx.com> - 2016-01-29 16:59 -0300
            Re: passing a set of numbers to a function Erwin Moller <erwinmollerusenet@xs4all.nl> - 2016-02-12 12:03 +0100
    Re: passing a set of numbers to a function Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-02 11:18 +0100
      Re: passing a set of numbers to a function Aleksandro <aleksandro@gmx.com> - 2016-02-02 12:31 -0300
      Re: passing a set of numbers to a function John Harris <niam@jghnorth.org.uk.invalid> - 2016-02-04 10:42 +0000
        Re: passing a set of numbers to a function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-02-04 15:38 +0000
          Re: passing a set of numbers to a function Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-04 17:33 +0100
            Re: passing a set of numbers to a function Scott Sauyet <scott.sauyet@gmail.com> - 2016-02-04 16:19 -0800
              Re: passing a set of numbers to a function Stefan Weiss <krewecherl@gmail.com> - 2016-02-05 14:06 +0100
                Re: passing a set of numbers to a function Scott Sauyet <scott.sauyet@gmail.com> - 2016-02-05 05:45 -0800
                  Re: passing a set of numbers to a function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-02-05 14:34 +0000
                    Re: passing a set of numbers to a function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-02-05 15:42 +0000
                  Re: passing a set of numbers to a function Stefan Weiss <krewecherl@gmail.com> - 2016-02-05 16:04 +0100
                    Re: passing a set of numbers to a function Scott Sauyet <scott.sauyet@gmail.com> - 2016-02-05 10:48 -0800
                      Re: passing a set of numbers to a function Stefan Weiss <krewecherl@gmail.com> - 2016-02-06 04:50 +0100
                        Re: passing a set of numbers to a function "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-02-06 10:05 -0800
                          Re: passing a set of numbers to a function Stefan Weiss <krewecherl@gmail.com> - 2016-02-06 23:30 +0100
                            Re: passing a set of numbers to a function Scott Sauyet <scott.sauyet@gmail.com> - 2016-02-06 17:32 -0800
                Re: passing a set of numbers to a function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-02-05 14:13 +0000
                  Re: passing a set of numbers to a function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-02-05 17:15 +0000
              Re: passing a set of numbers to a function Scott Sauyet <scott.sauyet@gmail.com> - 2016-02-05 05:19 -0800
                Re: passing a set of numbers to a function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-02-05 13:43 +0000
                  Re: passing a set of numbers to a function Scott Sauyet <scott.sauyet@gmail.com> - 2016-02-05 06:08 -0800
          Re: passing a set of numbers to a function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-02-04 20:25 +0000
          Re: passing a set of numbers to a function John Harris <niam@jghnorth.org.uk.invalid> - 2016-02-05 10:51 +0000

Page 3 of 3 — ← Prev page 1 2 [3]

#29541

Scott Sauyet <scott.sauyet@gmail.com> writes:
<snip>
> I wasn't thinking about practical implementation at all.
<snip>
> But they're an interesting exercise regardless.

I think there are practical uses.  I've used this method on a web site
(hey, topical!) that had complex match expressions in a search function.
To implement something like ("a" | "b") & ~"c" you parse the expression
and build a matching functions as you go.  Given something like

  function any(x) { return set(s => s.includes(x)); }

the result of parsing ("a" | "b") & ~"c" is

  const r = (any("a").union(any("b")).intersection(any("c").complement()));

and you simply test r.contains("whatever") to do the match.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#29546

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>To implement something like ("a" | "b") & ~"c" you parse the expression
>>and build a matching functions as you go.  Given something like
>
>   One also might replace every »"string"« by »(x==="string")«.

Yes, though that was not the intended semantics.  With your
interpretation the example has a redundant clause.

>   This would give:
>
> ((x==="string") | (x==="string")) & ~(x==="string")
>
>   . One then can also replace some operators:
>
> ((x==="string") || (x==="string")) && !(x==="string")
>
>   . Finally, one could then call »Function« with 
>
> new Function( 'x', '((x==="string") || (x==="string")) && !(x==="string")' )
>
>   if there were no problems with security and 
>   incorrect inputs.

As you say, it's possible to do this sort of thing via string
manipulation, but I've found it to be fiddly in practice.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#29544

On 02/05/2016 14:45, Scott Sauyet wrote:
> Stefan Weiss wrote:
>> Scott Sauyet wrote:
>>> We should also note that this misses at least one important notion 
>>> from mathematics as well.  I'm fairly certain that there is no way to 
>>> write a `subset` function.
>>
>> Why? Wouldn't "subset" just be one more predicate to be combined with
>> the set's predicate? "intersection" already does that. The same would go
>> for adding or removing individual members or (sub)sets, using "union"
>> and "intersection", respectively.
> 
> I just had the same realization about adding and removing members.

Yes, we do tend to post to this group at the same time. Odd :)

> But unless I'm missing something fundamental, I don't see how `subset`
> would work in the general case.  It's not an operation like `intersection`
> `union`, `add`, etc, but a predicate like `contains`.
> 
> If you are given `set(fn)` and want to know if set(x => x == ~~x)
> (the integers) is a subset of it, how would you test? What if fn was x =>
> x == ~~x && x != 9007199254740990?

Ah, I misunderstood what you meant by "a subset function". I took it to
mean "get a subset (fn)", not "is a subset (set)". The former is
basically the same as intersection, the latter may indeed be impossible.
This is beyond my amateur mathematical knowledge.

>> As for iterators, sets don't have an inherent order, so any kind of
>> ordered iteration would be an extension to the concept. The ability to
>> produce members, in any order, is also not a required property of a set.
> 
> Right, but most software implementations of set make it part of some
> group of types that can be iterated.  Since the storage mechanism would
> generally allow one to impose an order, even if it's not logical (think
> Java's hash-code order, for instance), it's not too strange to assume
> that a (finite) set can be iterated.  Of course this makes no sense at
> all for an uncountably infinite set.

Or even countably infinite :)

I think my point (also concerning the rest of the snipped text) is that
a purely predicate-based set implementation makes sense, and so does the
storage-based implementation. But I don't think the two can be combined.
The whole point of the predicate-based version (IMO) is to eliminate the
need for storage (= enumerating all elements). It might gain the ability
for iteration, but it would lose its descriptive nature and could no
longer handle infinite sets.


Having just read Ben's replies, I think I'll quietly back away now...
this goes way beyond my naive understanding of sets. Although I should
have remembered Russel's paradox. I recently read Logicomix, a
fascinating graphic novel about the search for the foundations of
mathematics, loosely based on Russel's life.


- stefan

[toc] | [prev] | [next] | [standalone]

#29548

Stefan Weiss wrote:
> Scott Sauyet wrote:
>> Stefan Weiss wrote:
>>> Scott Sauyet wrote:

> [ ... ]
>> I just had the same realization about adding and removing members.
> 
> Yes, we do tend to post to this group at the same time. Odd :)

Great minds run in the same gutter?  :-)

> [ ... ]

>> [ ... ] It's not too strange to assume that a (finite) set can 
>> be iterated.  Of course this makes no sense at all for an 
>> uncountably infinite set.
> 
> Or even countably infinite :)

Ahh, but here's where a little mathematical background was required.

:-)

`countably infinite` means in essence that it is of the same size as
the set of natural numbers.  (And same size means that there is a
1 - 1 mapping between them.)  A countably infinite set can be iterated,
but you'll never finish.  That's one way to think of streams.


> I think my point (also concerning the rest of the snipped text) is that
> a purely predicate-based set implementation makes sense, and so does the
> storage-based implementation. But I don't think the two can be combined.
> The whole point of the predicate-based version (IMO) is to eliminate the
> need for storage (= enumerating all elements). It might gain the ability
> for iteration, but it would lose its descriptive nature and could no
> longer handle infinite sets.

I agree.  I can't think of a sensible way to combine the two notions.
 

> Having just read Ben's replies, I think I'll quietly back away now...
> this goes way beyond my naive understanding of sets. Although I should
> have remembered Russel's paradox. I recently read Logicomix, a
> fascinating graphic novel about the search for the foundations of
> mathematics, loosely based on Russel's life.

Sounds fun.  Was Kurt Gödel the arch-villain, destroying everything our
brave hero tried to build?  :-)

  -- Scott

[toc] | [prev] | [next] | [standalone]

#29554

On 02/05/2016 19:48, Scott Sauyet wrote:
> Stefan Weiss wrote:
>> Scott Sauyet wrote:
>>> [ ... ] It's not too strange to assume that a (finite) set can 
>>> be iterated.  Of course this makes no sense at all for an 
>>> uncountably infinite set.
>>
>> Or even countably infinite :)
> 
> Ahh, but here's where a little mathematical background was required.
> 
> :-)
> 
> `countably infinite` means in essence that it is of the same size as
> the set of natural numbers.  (And same size means that there is a
> 1 - 1 mapping between them.)  A countably infinite set can be iterated,
> but you'll never finish.  That's one way to think of streams.

If finishing is not important, I can iterate over ℝ (uncountably
infinite) just as well as over ℕ (countably infinite): I start with 1,
2, 3... etc; when I get to the end of the natural numbers, I'll just go
the opposite direction.
Kidding aside, you were talking about using storage mechanisms in sets
for iteration. I think that for this purpose, any size of infinity is
large enough.

>> I recently read Logicomix, a fascinating graphic novel about the
>> search for the foundations of mathematics, loosely based on
>> Russel's life.
> 
> Sounds fun.  Was Kurt Gödel the arch-villain, destroying everything our
> brave hero tried to build?  :-)

Pretty much, in the end. It felt like a bit of an anticlimax, even
though the outcome was inevitable. Gödel presents his proof in front of
an auditorium including Hilbert and Russell, and von Neumann mutters
"It's all over" (this never actually happened, but it might have, and
the authors fully acknowledge taking some artistic licence here and
there). I also got the impression that the real hidden killer was
insanity - it's surprising how many of the mathematicians involved in
this lost their minds.

Logicomix is worth a read, if you like this kind of story telling. I
thought I'd stumbled across an obscure gem when I found it in a
bookstore in Vienna, but apparently it made #1 on the New York Times
bestseller list for graphic novels at some point. It's not 100%
historically accurate, and some of the more advanced concepts are
simplified, but overall I was deeply impressed by how the authors
managed to transform such an abstract topic into an enjoyable story.


- stefan

[toc] | [prev] | [next] | [standalone]

#29564

On Friday, February 5, 2016 at 9:51:00 PM UTC-6, Stefan Weiss wrote:

> If finishing is not important, I can iterate over ℝ (uncountably
> infinite) just as well as over ℕ (countably infinite): I start with 1,
> 2, 3... etc; when I get to the end of the natural numbers, I'll just go
> the opposite direction.

[snip]

No, you can't.

<https://en.wikipedia.org/wiki/Cantor's_diagonal_argument>

[toc] | [prev] | [next] | [standalone]

#29569

On 02/06/2016 19:05, Michael Haufe (TNO) wrote:
> On Friday, February 5, 2016 at 9:51:00 PM UTC-6, Stefan Weiss wrote:
>> If finishing is not important, I can iterate over ℝ (uncountably
>> infinite) just as well as over ℕ (countably infinite): I start with 1,
>> 2, 3... etc; when I get to the end of the natural numbers, I'll just go
>> the opposite direction.
> 
> [snip]
> 
> No, you can't.
> 
> <https://en.wikipedia.org/wiki/Cantor's_diagonal_argument>

It was a joke. I thought "when I get to the end of the natural numbers"
was obvious enough, but... The premise was that the iteration over
natural numbers would "never finish". That implies a non-zero duration
for a single iteration and an amount of time that is either finite or at
best (countably) infinite. Under these constraints, both iterators
produce the same series.


- stefan

[toc] | [prev] | [next] | [standalone]

#29571

Stefan Weiss wrote:
> Michael Haufe (TNO) wrote:
>> Stefan Weiss wrote:
>>> If finishing is not important, I can iterate over ℝ (uncountably
>>> infinite) just as well as over ℕ (countably infinite): I start with 1,
>>> 2, 3... etc; when I get to the end of the natural numbers, I'll just go
>>> the opposite direction.
>> 
>> [snip]
>> 
>> No, you can't.
>> 
>> <https://en.wikipedia.org/wiki/Cantor's_diagonal_argument>
> 
> It was a joke. I thought "when I get to the end of the natural numbers"
> was obvious enough, but... The premise was that the iteration over
> natural numbers would "never finish". That implies a non-zero duration
> for a single iteration and an amount of time that is either finite or at
> best (countably) infinite. Under these constraints, both iterators
> produce the same series.


I had responded earlier to Stefan's post.  Where it went, Google only 
knows.  I had guessed his response was a joke, but it wasn't clear, so, 
while I didn't point to Cantor's proof, I did discuss the difference, and
how countable sets can be iterated/streamed.  It might take a while to
reach, say M_74207281 [1], there is no actual number which is theoretically
out of bounds.

(I also expressed my sorrow to realize that Hilbert was alive to see
Gödel undermining his life's work.  It was probably harder for him 
than for Russell.  I don't know why I assumed he had died before then.)

In any case, these are an interesting variant of sets, and Ben has
shown that they do have at least some practical uses.

We now return you to your regularly scheduled barrage of USENET pedantry
and individual quibbles over the usage of the word "Javascript".

 
  [1]: <https://en.wikipedia.org/wiki/Great_Internet_Mersenne_Prime_Search>

  -- Scott

[toc] | [prev] | [next] | [standalone]

#29540

Stefan Weiss <krewecherl@gmail.com> writes:

> On 02/05/2016 01:19, Scott Sauyet wrote:
>> There is a simple way to implement mathematical sets, finite or 
>> infinite using predicate functions. [...]
>> 
>> But for those interested in sets which have the normal set operations 
>> of `contains`, `union`, `intersection`, and `complement`, the 
>> following looks to be quite simple:
>> 
>>     const set = pred => ({
>>       contains: pred,
>>       union: set2 => set(val => pred(val) || set2.contains(val)),
>>       intersection: set2 => set(val => pred(val) && set2.contains(val)),
>>       complement: () => set(val => !pred(val))
>>     });
>> 
>> One could use this to create sets such as these:
>> 
>>     const fizz = set(n => n % 3 == 0);
>>     const buzz = set(n => n % 5 == 0);
>>     const fizzBuzz = fizz.intersection(buzz);
>>     const fizzOrBuzz = fizz.union(buzz);
>>     const notBuzz = buzz.complement();
>
> A very nice example.
>
> [snip tests]
>
>> But, for one trying to use a set as a Collection, these are missing 
>> several important features.  Obviously there is no way to add or 
>> remove members.  There is also no generic way to iterate, although 
>> obviously one could create iterators to match specific Sets.  So, 
>> while this is reasonably close to mathematical sets, they are not 
>> really close to what are usually considered sets in software.
>> 
>> We should also note that this misses at least one important notion 
>> from mathematics as well.  I'm fairly certain that there is no way to 
>> write a `subset` function.
>
> Why? Wouldn't "subset" just be one more predicate to be combined with
> the set's predicate?

If S1 \subset S2 and S2 \subset S1 then S1 = S2.  Hence a correct subset
predicate could determines if two functions compute the same value in
all cases.

Similarly, you can't implement an isEmpty predicate either and, as Scott
suggested, I think some version of Rice's theorem will come into play so
that no "interesting" property of sets of sets will be decidable.

(I'm not knocking the method.  This is what I had in mind when I talked
about implementing infinite sets because membership was, at that point,
the only operation that was wanted.)

> "intersection" already does that. The same would go
> for adding or removing individual members or (sub)sets, using "union"
> and "intersection", respectively.
>
> As for iterators, sets don't have an inherent order, so any kind of
> ordered iteration would be an extension to the concept. The ability to
> produce members, in any order, is also not a required property of a
> set.

That's a hot topic!  See the well-ordering theorem of ZFC.  Mind you,
this is obviously not ZFC since it can express Russell's paradox:

  function russell(m, s) { return s.contains(m); }
  const R = set(x => !russell(x, x));
  R.contains(R);

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#29547

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Stefan Weiss <krewecherl@gmail.com> writes:
>
>> On 02/05/2016 01:19, Scott Sauyet wrote:
>>> There is a simple way to implement mathematical sets, finite or 
>>> infinite using predicate functions. [...]
>>> 
>>> But for those interested in sets which have the normal set operations 
>>> of `contains`, `union`, `intersection`, and `complement`, the 
>>> following looks to be quite simple:
>>> 
>>>     const set = pred => ({
>>>       contains: pred,
>>>       union: set2 => set(val => pred(val) || set2.contains(val)),
>>>       intersection: set2 => set(val => pred(val) && set2.contains(val)),
>>>       complement: () => set(val => !pred(val))
>>>     });
>>> 
>>> One could use this to create sets such as these:
>>> 
>>>     const fizz = set(n => n % 3 == 0);
>>>     const buzz = set(n => n % 5 == 0);
>>>     const fizzBuzz = fizz.intersection(buzz);
>>>     const fizzOrBuzz = fizz.union(buzz);
>>>     const notBuzz = buzz.complement();
>>
>> A very nice example.
>>
>> [snip tests]
>>
>>> But, for one trying to use a set as a Collection, these are missing 
>>> several important features.  Obviously there is no way to add or 
>>> remove members.  There is also no generic way to iterate, although 
>>> obviously one could create iterators to match specific Sets.  So, 
>>> while this is reasonably close to mathematical sets, they are not 
>>> really close to what are usually considered sets in software.
>>> 
>>> We should also note that this misses at least one important notion 
>>> from mathematics as well.  I'm fairly certain that there is no way to 
>>> write a `subset` function.
>>
>> Why? Wouldn't "subset" just be one more predicate to be combined with
>> the set's predicate?
>
> If S1 \subset S2 and S2 \subset S1 then S1 = S2.  Hence a correct subset
> predicate could determines if two functions compute the same value in
> all cases.
>
> Similarly, you can't implement an isEmpty predicate either and, as Scott
> suggested, I think some version of Rice's theorem will come into play so
> that no "interesting" property of sets of sets will be decidable.
>
> (I'm not knocking the method.  This is what I had in mind when I talked
> about implementing infinite sets because membership was, at that point,
> the only operation that was wanted.)
>
>> "intersection" already does that. The same would go
>> for adding or removing individual members or (sub)sets, using "union"
>> and "intersection", respectively.
>>
>> As for iterators, sets don't have an inherent order, so any kind of
>> ordered iteration would be an extension to the concept. The ability to
>> produce members, in any order, is also not a required property of a
>> set.
>
> That's a hot topic!  See the well-ordering theorem of ZFC.  Mind you,
> this is obviously not ZFC since it can express Russell's paradox:
>
>   function russell(m, s) { return s.contains(m); }

That's a terrible name!  It has very little to do with end result and
it's just as artefact left over from some editing.  If it's named at all
it should be

  function russell(s) { return !s.contains(s); }

(and R is then just set(russell)) but it's probably simpler just to
write

  const R = set(x => ! x.contains(x));
  R.contains(R);

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#29534

I (Scott Sauyet) wrote:
> There is a simple way to implement mathematical sets, finite or 
> infinite using predicate functions.  [ ... ]
> 
>     const set = pred => ({
>       contains: pred,
>       union: set2 => set(val => pred(val) || set2.contains(val)),
>       intersection: set2 => set(val => pred(val) && set2.contains(val)),
>       complement: () => set(val => !pred(val))
>     });
>
> [ ... ] But, for one trying to use a set as a Collection, these 
> are missing several important features.  Obviously there is no way 
> to add or remove members. [ ... ]

This was perhaps hasty.  Of course sets defined this way are 
immutable, and hence one cannot add or remove members, but just as
we can create new sets from old in `union`, we can easily derive
new sets with `add` and `remove` functions:

    const set = pred => ({ 
      contains: pred, 
      union: set2 => set(val => pred(val) || set2.contains(val)), 
      intersection: set2 => set(val => pred(val) && set2.contains(val)), 
      complement: () => set(val => !pred(val)),
      add: item => set(val => pred(val) || val === item),
      remove: item => set(val => pred(val) && val !== item)
    }); 

    const fizzOrBuzzOr7 = fizzOrBuzz.add(7);
    test(fizzOrBuzzOr7, [6, 7, 10, 14, 45]); 
    //=> {6: true, 7: true, 10: true, 14: false, 45: true}

    const fizzBuzzWo45 = fizzBuzz.remove(45);
    test(fizzBuzzWo45, [6, 10, 14, 15, 45]); 
    //=> {6: false, 10: false, 14: false, 15: true, 45: false} 

  -- Scott

[toc] | [prev] | [next] | [standalone]

#29535

Scott Sauyet <scott.sauyet@gmail.com> writes:

> I (Scott Sauyet) wrote:
>> There is a simple way to implement mathematical sets, finite or 
>> infinite using predicate functions.  [ ... ]
>> 
>>     const set = pred => ({
>>       contains: pred,
>>       union: set2 => set(val => pred(val) || set2.contains(val)),
>>       intersection: set2 => set(val => pred(val) && set2.contains(val)),
>>       complement: () => set(val => !pred(val))
>>     });
>>
>> [ ... ] But, for one trying to use a set as a Collection, these 
>> are missing several important features.  Obviously there is no way 
>> to add or remove members. [ ... ]
>
> This was perhaps hasty.  Of course sets defined this way are 
> immutable, and hence one cannot add or remove members, but just as
> we can create new sets from old in `union`, we can easily derive
> new sets with `add` and `remove` functions:

They can be made mutable by storing a predicate.  Then they would like
the mutable sets that most people are familiar with.  But since I prefer
a function style (as do you I think) I would not bother.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#29537

Ben Bacarisse wrote:
> Scott Sauyet writes:
>> Scott Sauyet wrote:
>>> There is a simple way to implement mathematical sets, finite or 
>>> infinite using predicate functions.  [ ... ]
>>> 
>>>     const set = pred => ({
>>>       contains: pred,
>>>       union: set2 => set(val => pred(val) || set2.contains(val)),
>>>       intersection: set2 => set(val => pred(val) && set2.contains(val)),
>>>       complement: () => set(val => !pred(val))
>>>     });
>>>
>>> [ ... ] But, for one trying to use a set as a Collection, these 
>>> are missing several important features.  Obviously there is no way 
>>> to add or remove members. [ ... ]
>>
>> This was perhaps hasty.  Of course sets defined this way are 
>> immutable, and hence one cannot add or remove members, but just as
>> we can create new sets from old in `union`, we can easily derive
>> new sets with `add` and `remove` functions:
> 
> They can be made mutable by storing a predicate.  Then they would like
> the mutable sets that most people are familiar with.  

I suppose so, but this sort of mutability is extreme mutability; if
you replace the predicate with its complement, you have in one blow
removed all elements from the set and added in all non-elements.  That's
pretty odd.

> But since I prefer a function style (as do you I think) I would not 
> bother.

You're certainly right that it's what I prefer, and I too would not
bother.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#29530

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>Computer programs can implement infinite sets though only very few of
>>them (even fewer, compared to how many there are, than for finite sets).
>
>   This is a helper function »contains« for array-like objects:
>
> function contains( alo, val )
> { for( let i = 0, l = alo.length; i < l; ++i ) 
>   if( alo[ i ]=== val )return true; return false; }
>   
>   . With this helper function, I can define a JavaScript
>   function that can compute the union of some sets. 
>
> function union(){ return contains( arguments, "Z" )? "Z" : "N"; }
>
>   Now, »union( "N", "N", "Z" )« will give »"Z"«, which agrees
>   with the fact that the mathematical union of the set »N«
>   (natural numbers) and the set »Z« (integers) (here, »N u N u Z«)
>   is »Z«.
>
>   I can extend my implementation to some other sets,
>   for example, I could include the finite set »{1}«,
>   which I might represent by the string »"{1}"«:
>
> function union()
> { return 0,
>   contains( arguments, "Z" )? "Z" :
>   contains( arguments, "N" )? "N" : "{1}"; }
>
>   So, I have shown an implementation for the subrealm »< N, Z,
>   {1} >«. But not an implementation for the realm of /all/ sets.
>   In mathematics, we have the operation »u« (union), and it
>   /is/ defined for all sets.
>
>   It was no problem for me that some of the sets of my 
>   implementation are not finite. But the realm of my sets
>   was finite (it included two, and later three, sets).
>
>   But while there is a theoretical limitation (we also cannot
>   implement all properties of real numbers with our
>   floating-point numbers), mathematical algebra systems (like
>   Mathematica) might still provide some useful implementation
>   for set operations for some common sets.

I've left it all because (as is not uncommon with your posts) I'm not
exactly sure what your point is.  You don't seem to be disagreeing with
me, but you are not advocating anything very exciting with your finite
collection of named sets.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#29532

On 4 Feb 2016 16:31:02 GMT, ram@zedat.fu-berlin.de (Stefan Ram) wrote:

  <snip>
>  Now, »union( "N", "N", "Z" )« will give »"Z"«, 

Only if N is a subset of Z.

>  which agrees
>  with the fact that the mathematical union of the set »N«
>  (natural numbers) and the set »Z« (integers) (here, »N u N u Z«)
>  is »Z«.
  <snip>

In fact, it's not a fact : N doesn't have to be a subset of Z. Any set
that obeys Peano's axioms can be used to represent N. (They are all
isomorphic).

If you decide you do want to use a subset of (some representation of)
Z to represent N then you should decide which subset. Is it
  {1, 3, 5, 7, ... } ? (Yes it does obey Peano's axioms).
Or is it the more convenient 
  {0, 1, 2, 3, ... } ?
Or some other?

  John

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.javascript

csiph-web