sumti Places Requiring Sets: Difference between revisions

From Lojban
Jump to navigation Jump to search
mNo edit summary
 
m (Conversion script moved page Sumti Places Requiring Sets to sumti Places Requiring Sets: Converting page titles to lowercase)
 
(6 intermediate revisions by one other user not shown)
Line 1: Line 1:
<code>[20:31] <rlpowell> Now, get rid of gismu places that require sets: *fuck* yes.  But only the requirement, not the places.


Robin's Palm Writings: Category: misc
[20:33] <Melvar> Do the places make sense without sets?


Navigation: [[Robin's Palm Writings: misc|misc Index]] [[Robin's Palm Writings|Robin's Palm Writings Top-Level Index]] 
[20:33] <rlpowell> vensa: Also, I *do* try to listen, and respect people's objections and stuff.  :)  Just be nice, and I'll be nice back.


; Find the on-disk file associated with a field - #f if none such (meths local to this mooix Scheme interface return #f).  Handles parent recursion and mixins.
[20:34] <rlpowell> Melvar: They make sense with any distributive group.


(define (fieldfile this args)
[20:34] <Melvar> Exactly.


; This gets a bit complicated - we walk parents, looking for the file or for an object ref that matches the mixin (if any).  If we find the file, great: compose the dir (which we've been appending things to) and the file, and return that.  If we find the mixin, we walk that object and parents in the same way.  Once we've found the mixin, we do not ever return and try further parents of the original object.
[20:34] <rlpowell> Which isn't just sets.


(define (parent-walk dir file mixin)
[20:34] <Melvar> What then?


(if (file-exists? (make-absolute-pathname dir file]
[20:35] <rlpowell> In fact, most of them make *way* more sense with loi than lo'i


(make-absolute-pathname dir file)
[20:35] <Melvar> Huh? Masses, distributive?


(let* (
[20:35] <rlpowell> Example: kampu: x1 (property - ka) is common/general/universal among members of set x2 (complete set)


(mixin-obj (this (car mixin])
[20:36] <rlpowell> Erm, yes?  That's their entire purpose?


(mixin-dir (and mixin-obj (procedure? mixin-obj) (mixin-obj "dir"])
[20:36] <rlpowell> Masses are for "the students surrounded the building".  Use that example as your analogical case and you can't really go wrong.  :)


)
[20:36] <rlpowell> No one student is doing the surrounding.  The *set* of students certainly doesn't surround anything, because sets only have membership and cardinality.


(if mixin-dir
[20:37] <rlpowell> Lojban calls the non-distributive plural "masses".


(parent-walk mixin-dir file #f)
[20:38] <rlpowell> vensa: ^^ and that's why sets are kind of pointless.


(parent-walk (make-absolute-pathname dir "/parent") file mixin)
[20:38] <Melvar> Have you contradicted yourself or am I not understanding something important?


)
[20:39] <rlpowell> The *only* attributes sets have are membership and cardinality.  This makes them almost useless to say anything with outside of math.


)
[20:39] <rlpowell> Melvar: As far as I know everything I said makes sense; what doesn't make sense to you?


)
[20:40] <Melvar> It seems to me that once you called masses distributive, and another time nondistributive, or else I misassigned a response …


)
[20:41] <rlpowell> You're absolutely right.


(let* (
[20:41] <rlpowell> < rlpowell> Melvar: They make sense with any distributive group. -- I meant non-distributive.


(pbits (decompose-path (car args])
[20:45] <paldanyli> Why does kampu make more sense with masses than sets?


(file (make-pathname "" (second pbits) (third pbits])
[20:46] <rlpowell> paldanyli: Because sets only have cardinality and membership.


(mixin (string-match "(.+)_(.+)"  file]
[20:46] <rlpowell> They have no other properties.


(dir (this "dir"]
[20:47] <rlpowell> The only thing that's "common" to a set is, I dunno, the most frequent member or something?  It doesn't even really make sense.


)
[20:48] <Melvar> The way I thought of it is that the concept of membership makes a set act as a distributive.


(and
[20:49] <paldanyli> It makes sense to me. We're talking about the members, no?


; If implemented here, return #f immediately
[20:49] <rlpowell> Distributiveness is exactly not-helpful here; that's why you can't do "kampu mi .e do", because that distributes to "kampu mi" and "kampu do"


(not (this "can" args]
[20:49] <rlpowell> Yeah, the idea is it's supposed to be "common among the members of the set", but "among the members of the mass" works just fine too.


(or
[20:49] <rlpowell> And "common to the mass" also.


; Check for the object itself defining the field - if not, walk up the parents looking for file or mixins to search
[20:50] <paldanyli> That doesn't make much sense to me. How could something be common in a mass? Perhaps I think of masses differently than everyone else.


(this "defines" args)
[20:51] <Melvar> Masses don’t have members, do they?


(parent-walk dir mixin)
[20:51] <rlpowell> How could they not?


)
[20:51] <Melvar> ∈ is not defined on them.


)
[20:51] <rlpowell> I mean, if sets have members, I don't see how a mass could possibly not; they're both plural abstractions.


)
[20:51] <rlpowell> Umm.  Nothing mathematical is defined on masses; we made them up.


)
[20:52] <paldanyli> Wouldn't be much use if masses didn't have members. But if the purpose is to aggregate their properties, using them to get at their members properties seems strange.


; Returns true if the named method is handled by this mooix Scheme interface or by a file-based method on the object
[20:53] <rlpowell> That's true for sets, too. :)


(define (implements this args)
[20:53] <paldanyli> Not to aggregate their properties. Just to indicate the membership.


(or (this "can" args)
[20:54] <rlpowell> To me, a mass of something has all of the properties of its members, in proportion to their frequency.  So the mass of rats is mostly X inches long, but somewhat Y inches long.


(let [[jbocre: file (this "fieldfile" args|file (this "fieldfile" args]])
[20:54] <rlpowell> That view is probably idiosyncratic, though.


(and file (file-execute-access?  file]
[20:54] == mode/#lojban [[+o kpreid|+o kpreid]] by ChanServ


)
[20:54] <paldanyli> That was my view as well. Which is why kampu on masses confuses me.


)
[20:55] <rlpowell> Well, something that is common to all of them is clearly a major part of the mass, yeah?


)
[20:55] <Melvar> kampu: p ↦ A ↦ ∀a∈A:p(a)


; Returns true if this object directly defines the field / method in question - no mixins, no inheritance
[20:55] <rlpowell> I can't see most of that, sorry.


(define (defines this args)
[20:56] <Melvar> Wait a sec.


(let* [[jbocre: pbits (decompose-path (car args|pbits (decompose-path (car args]])
[20:56] <paldanyli> I don't think there's any reason that masses couldn't serve as sets, but it's not what I think of their purpose as being. It's confusing to me to make a set then "break it apart".


(file (make-pathname (this "dir") (second pbits) (third pbits])
[20:56] <paldanyli> Make a mass, rather.


)
[20:56] <rlpowell> Right, but whether you use a set or a mass there, you're asking about the members, not the set or the mass.


(file-exists? file)
[20:56] <rlpowell> So I don't see that it matters much.


)
[20:57] <paldanyli> Probably not. I can't think of a property of sets that wouldn't apply to masses.


(define (getfieldtext this args)
[20:58] <rlpowell> And this all is why I wouldn't suggest getting rid of sets; if it's this easy to argue about, it's not clear cut.  :D


(let [[jbocre: file (this "fieldfile" args|file (this "fieldfile" args]])
[20:58] <Melvar> $kampu: p \mapsto { A \mapsto \forall a \in A : p(a) }$ approximately.


(and file
[21:01] <paldanyli> I suppose the cardinality of a mass of masses would be in question.


(file-exists? file)
[21:02] <paldanyli> Likewise its membership?


(read-string file]
[21:03] <rlpowell> Hadn't thought about it.


)
[21:05] == tom''' has changed nick to _wtw_


)
[21:08] <Melvar> You could say I see sets as enumerable, but not masses.


(define (fieldfile-lang this args)
[21:10] <rlpowell> Which I think is a valid POV.


(define mooix-langs (string-split [[jbocre: mooix-root "abstract") "language") "languages") "list") "\n"]]
[21:10] <rlpowell> I just don't know if that's how the language works.  :)


; Walk up the parents using the algorithm at !URL!.  Returns an association list keyed on language code with each of the acceptably specific fields. The list has the fiels' complete file names as its data.  "" indicates no lang, just the plain field, which always wins
[21:11] <rlpowell> I'd love it if you could summarize all this to the appropriate BPFK page, btw.  Perhaps the gadri one.


(define (walk-parents this field)
</code>
 
(let (
 
(parent (this "parent"]
 
(entry (lambda (lang) (let [[jbocre: file (this (if (not (equal? lang ""]] (string-join field "." lang) field] (if file (list lang file) (list #f #f])
 
(collect (lambda () (alist-delete #f (map (lambda (lang) (entry lang] (mooix-langs]
 
)
 
(if parent
 
....
 
(
 
)
 
)
 
)
 
(let (
 
(alist (walk-parents this (car args])
 
(ulang [[jbocre: cadr args) "langauge"|cadr args) "langauge"]]
 
)
 
(and
 
; Try the user's lang first - otherwise just take the first one
 
(cadr (assoc (ulang "code") alist]
 
(cadr (car alist]
 
)
 
)
 
)
 
(define dispatch-table
 
("can" can-dispatch)
 
("hybridgetfield" hybridgetfield)
 
("get" get)
 
("fieldfile" fieldfile)
 
("test" test)
 
("implements" implements)
 
("getfieldtext" getfieldtext)
 
("fieldfile-lang" fieldfile-lang)
 
("fieldfile_lang" fieldfile-lang)
 
.!a!nd so on
 
)
 
)

Latest revision as of 08:35, 30 June 2014

[20:31] <rlpowell> Now, get rid of gismu places that require sets: *fuck* yes. But only the requirement, not the places.

[20:33] <Melvar> Do the places make sense without sets?

[20:33] <rlpowell> vensa: Also, I *do* try to listen, and respect people's objections and stuff.  :) Just be nice, and I'll be nice back.

[20:34] <rlpowell> Melvar: They make sense with any distributive group.

[20:34] <Melvar> Exactly.

[20:34] <rlpowell> Which isn't just sets.

[20:34] <Melvar> What then?

[20:35] <rlpowell> In fact, most of them make *way* more sense with loi than lo'i

[20:35] <Melvar> Huh? Masses, distributive?

[20:35] <rlpowell> Example: kampu: x1 (property - ka) is common/general/universal among members of set x2 (complete set)

[20:36] <rlpowell> Erm, yes? That's their entire purpose?

[20:36] <rlpowell> Masses are for "the students surrounded the building". Use that example as your analogical case and you can't really go wrong.  :)

[20:36] <rlpowell> No one student is doing the surrounding. The *set* of students certainly doesn't surround anything, because sets only have membership and cardinality.

[20:37] <rlpowell> Lojban calls the non-distributive plural "masses".

[20:38] <rlpowell> vensa: ^^ and that's why sets are kind of pointless.

[20:38] <Melvar> Have you contradicted yourself or am I not understanding something important?

[20:39] <rlpowell> The *only* attributes sets have are membership and cardinality. This makes them almost useless to say anything with outside of math.

[20:39] <rlpowell> Melvar: As far as I know everything I said makes sense; what doesn't make sense to you?

[20:40] <Melvar> It seems to me that once you called masses distributive, and another time nondistributive, or else I misassigned a response …

[20:41] <rlpowell> You're absolutely right.

[20:41] <rlpowell> < rlpowell> Melvar: They make sense with any distributive group. -- I meant non-distributive.

[20:45] <paldanyli> Why does kampu make more sense with masses than sets?

[20:46] <rlpowell> paldanyli: Because sets only have cardinality and membership.

[20:46] <rlpowell> They have no other properties.

[20:47] <rlpowell> The only thing that's "common" to a set is, I dunno, the most frequent member or something? It doesn't even really make sense.

[20:48] <Melvar> The way I thought of it is that the concept of membership makes a set act as a distributive.

[20:49] <paldanyli> It makes sense to me. We're talking about the members, no?

[20:49] <rlpowell> Distributiveness is exactly not-helpful here; that's why you can't do "kampu mi .e do", because that distributes to "kampu mi" and "kampu do"

[20:49] <rlpowell> Yeah, the idea is it's supposed to be "common among the members of the set", but "among the members of the mass" works just fine too.

[20:49] <rlpowell> And "common to the mass" also.

[20:50] <paldanyli> That doesn't make much sense to me. How could something be common in a mass? Perhaps I think of masses differently than everyone else.

[20:51] <Melvar> Masses don’t have members, do they?

[20:51] <rlpowell> How could they not?

[20:51] <Melvar> ∈ is not defined on them.

[20:51] <rlpowell> I mean, if sets have members, I don't see how a mass could possibly not; they're both plural abstractions.

[20:51] <rlpowell> Umm. Nothing mathematical is defined on masses; we made them up.

[20:52] <paldanyli> Wouldn't be much use if masses didn't have members. But if the purpose is to aggregate their properties, using them to get at their members properties seems strange.

[20:53] <rlpowell> That's true for sets, too. :)

[20:53] <paldanyli> Not to aggregate their properties. Just to indicate the membership.

[20:54] <rlpowell> To me, a mass of something has all of the properties of its members, in proportion to their frequency. So the mass of rats is mostly X inches long, but somewhat Y inches long.

[20:54] <rlpowell> That view is probably idiosyncratic, though.

[20:54] == mode/#lojban +o kpreid by ChanServ

[20:54] <paldanyli> That was my view as well. Which is why kampu on masses confuses me.

[20:55] <rlpowell> Well, something that is common to all of them is clearly a major part of the mass, yeah?

[20:55] <Melvar> kampu: p ↦ A ↦ ∀a∈A:p(a)

[20:55] <rlpowell> I can't see most of that, sorry.

[20:56] <Melvar> Wait a sec.

[20:56] <paldanyli> I don't think there's any reason that masses couldn't serve as sets, but it's not what I think of their purpose as being. It's confusing to me to make a set then "break it apart".

[20:56] <paldanyli> Make a mass, rather.

[20:56] <rlpowell> Right, but whether you use a set or a mass there, you're asking about the members, not the set or the mass.

[20:56] <rlpowell> So I don't see that it matters much.

[20:57] <paldanyli> Probably not. I can't think of a property of sets that wouldn't apply to masses.

[20:58] <rlpowell> And this all is why I wouldn't suggest getting rid of sets; if it's this easy to argue about, it's not clear cut. :D

[20:58] <Melvar> $kampu: p \mapsto { A \mapsto \forall a \in A : p(a) }$ approximately.

[21:01] <paldanyli> I suppose the cardinality of a mass of masses would be in question.

[21:02] <paldanyli> Likewise its membership?

[21:03] <rlpowell> Hadn't thought about it.

[21:05] == tom has changed nick to _wtw_

[21:08] <Melvar> You could say I see sets as enumerable, but not masses.

[21:10] <rlpowell> Which I think is a valid POV.

[21:10] <rlpowell> I just don't know if that's how the language works.  :)

[21:11] <rlpowell> I'd love it if you could summarize all this to the appropriate BPFK page, btw. Perhaps the gadri one.

Retrieved from "https://mw-live.lojban.org/index.php?title=sumti_Places_Requiring_Sets&oldid=100310"