On Sun, Feb 9, 2014 at 4:46 AM, Michał Marczyk wrote:
The Contrib library algo.generic provides a function fmap which does
> preserve the type of its input.
>
Thanks for the pointer.
> So, these are some of the available conceptual arguments. There is
> also a rather convincing practical argume
Agreed - there are always tradeoffs. Another common example is that pretty
well any language that uses IEEE floating point is also breaking
referential transparency in the interest of pragmatism:
user=> (= 0.3 (+ 0.1 0.2))
false
user=> (= (bigdec 0.3) (+ (bigdec 0.1) (bigdec 0.2)))
true
- Kor
There are many types and flavors of equality, and only handful of symbols.
Symbol '=' in Clojure does not represent yours fundamental = comparison
operator. = in Clojure compares for the actual value ignoring concrete
types of collections and the internal representation of how the items are
stored.
The Contrib library algo.generic provides a function fmap which does
preserve the type of its input.
As for the idea that clojure.core/map should preserve type, it's worth
remembering that in order to map a function over a set and return a
set, we must do two things: (1) apply the function to each
Maybe physical identity is too strong of a requirement for equality. So
another way to think about it is that it's 'hash-set', 'set', and '#{}'
that are--you know--"broken", but that there's a fix, which is to always
use 'sorted-set'. (I'm assuming that calling 'seq' on any two sorted sets
th
Maybe another way to put it is that what is, uh, "broken" isn't 'map' or
'seq', but '=', which is willing to tell you that two things (sets) are the
same when they're not! We also have the non-broken predicate 'identical?',
however, that gets it right. It's nice to also have a set-equal predic
I can ensure all of you that it is very uncomfortable for a newcomer with a
goofy nick to just come in and say things are broke LOL . So at that point
I have two choices:
1) as suggested, find another programming language but that would mean that
I would have to erase my Clojure tattoo (very painf
To add just one more thing to this: Referential transparency is clearly
valuable, but it's not the *only* valuable property a function or system might
have. There are always tradeoffs to be made. Clojure has made different
tradeoffs than you expected, or would yourself have made, but that doesn't
/
Hi Andy,
Andy C wrote:
>
>
>> user> (= s1 s2)
>> true
>> user> (= (seq s1) (seq s2))
>> false
>
>
> Thx. If a=b then f(a) must = f(b). Something is broken here.
If a seq is a sequential view of a thing, and a set is an unordered thing, then
it does not seem shocking to me that multiple sequenti
It is working as designed.
If you do not want this, consider using sorted sets / sorted maps, where (=
s1 s2) implies (= (seq s1) (seq s2)).
Or, perhaps another programming language would be more to your liking.
Andy
On Sat, Feb 8, 2014 at 4:10 PM, Andy C wrote:
>
> user> (= s1 s2)
>> true
>
> user> (= s1 s2)
> true
> user> (= (seq s1) (seq s2))
> false
>
Thx. If a=b then f(a) must = f(b). Something is broken here.
--
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 pos
On Feb 8, 2014, at 7:59 AM, Andy C wrote:
> Your assertion that I "am misunderstanding something" is wrong.
Now that you've seen everyone else's responses, perhaps you understand my
assertion was correct? :)
Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
"If you're
Well it does not break referential transparency if both equalities (for
input values and for results) are of a same kind. You would have to compare
inputs by value and outputs by identity, if you want to percieve an
inconsistency.
JW
On Saturday, February 8, 2014 6:49:39 PM UTC+1, Andy Fingerh
I've forgot the most interesting part :)
user> (= s1 s2)
true
user> (= (seq s1) (seq s2))
false
JW
On Sat, Feb 8, 2014 at 11:32 PM, Jozef Wagner wrote:
> Yes. Behold a Murmur3 hash collision:
>
> user> (def n1 -2023261231)
> #'user/n1
> user> (def n2 9223372036854771971)
> #'user/n2
> user> (=
Yes. Behold a Murmur3 hash collision:
user> (def n1 -2023261231)
#'user/n1
user> (def n2 9223372036854771971)
#'user/n2
user> (== (hash n1) (hash n2))
true
user> (def s1 (conj #{} n1 n2))
#'user/s1
user> (def s2 (conj #{} n2 n1))
#'user/s2
user> (= s1 s2)
But practically, I cannot think of any sc
On Feb 8, 2014, at 15:14 , Andy C wrote:
> It all boils down this:
> is it possible to have two clojure.lang.PersistentHashSet with identical
> values (in mathematical sense) but producing different seqs?
Are you serious? The entire point of the email you responded to was to answer
that ques
On Sat, Feb 8, 2014 at 1:46 PM, Jozef Wagner wrote:
> Two collections equivalent by their values may easily have a different
> order of their items.
>
It all boils down this:
is it possible to have two clojure.lang.PersistentHashSet with identical
values (in mathematical sense) but producing
By 'same' I've meant an identical :).
Two collections equivalent by their values may easily have a different
order of their items. This is because in unordered collections, their
internal order (as any other implementation detail) must not be taken into
account when comparing for value equivalence
First, thanks everybody for explanations of design decision behind map and
collections. I should in fact change subject to seq semantics ;-).
For me the bottom line is that while I do not care about order so much I
still can count on that seq function will produce consistent sequences. Or
wait a
On Sat, Feb 8, 2014 at 6:39 PM, Timothy Baldridge wrote:
> First of all, you are right. Map with things like sets is a bit of iffy
> concept. Now, most of the the time, I just don't care. If I was to increment
> every value in a set I'll just do (set (map inc #{1 2 3})) and not really
> care less
The sequence abstraction is documented here:
http://clojure.org/sequences
Clearly map is documented as working on sequences.
A sequence is not a concrete type as explained by others on
this thread.
If you really need some specific behavior from a concrete type then
do not rely on sequences. Use
This might be too detailed a point, but I wanted to mention that while you
will always get the same order for the same collection (same as determined
by identical?, or Java ==, i.e. it is the same object in memory), you are
*not* guaranteed to get the same order for collections of the same type
tha
First of all, you are right. Map with things like sets is a bit of iffy
concept. Now, most of the the time, I just don't care. If I was to
increment every value in a set I'll just do (set (map inc #{1 2 3})) and
not really care less about data structure theory. It works and I can get
work done.
Ho
The definition of map in Clojure is that it is a function on seqs. It is
defined as operating on a seq, and returning a seq.
Whereas in Scala, you hold an object and have thus access to its class (so
you can call Set.map on a set and List.map on a map), in Clojure there is
only one function clojur
On Sun, Feb 9, 2014 at 12:40 AM, Andy C wrote:
> >Every persistent collection in Clojure supports conversion to the
> sequence of items. This is clearly documented in the official docs and
> there is no surprise here.
>
> Would you mind to point me to that piece where doc describes what order
> s
>Every persistent collection in Clojure supports conversion to the sequence
of items. This is clearly documented in the official docs and there is no
surprise here.
Would you mind to point me to that piece where doc describes what order seq
chooses when converting a set to it. (I honestly tried to
Every persistent collection in Clojure supports conversion to the sequence
of items. This is clearly documented in the official docs and there is no
surprise here.
The order or items in the resulting sequence is dependent on the collection
type. As the conversion to the sequence is a referentia
On Sat, Feb 8, 2014 at 12:06 AM, Sean Corfield wrote:
> But you're misunderstanding what map does: it converts its collection
> arguments to _sequences_ and then it processes those sequences. Map
> doesn't operate on sets, or vectors, or maps, only on sequences.
>
Your assertion that I "am misun
But you're misunderstanding what map does: it converts its collection
arguments to _sequences_ and then it processes those sequences. Map
doesn't operate on sets, or vectors, or maps, only on sequences.
Scala goes out of its way to retain input types as output types on
many of its collection opera
> Following your intuition, what would you expect from the following?
> > (map + [1 3 5] '(2 4 6))
> # => ?
>
It only gets worse, as the result of below should be undefined (using
classic set definition):
user=> (map + #{0 1} #{0 1})
(0 2)
user=> (map + #{1 0} #{1 0})
(0 2)
--
You received this
On Friday, February 7, 2014 10:17:15 PM UTC-6, Andy C wrote:
>
> But what really bothers me is that laziness / not laziness affects the
> result of evaluation as in above example. That is against some fundamental
> rules of FP (gotta check how Haskell does it :-P).
>
Well, it's not really lazine
On Fri, Feb 7, 2014 at 9:41 PM, Andy C wrote:
> I do perceive sets, lists, vector as atoms which are indivisible (well,
> this is not true but this is popular meaning) from semantics standpoint.
> Therefore map is just a function which processes them as whole, again from
> semantics point of view
On Feb 7, 2014, at 22:17 , Andy C wrote:
> Having map to produce a lazy seq implies that the input must be serializable
> (or linear).
That's just what map is in Clojure: an operation on sequences. It works on
various concrete types because those can be viewed as sequences; map knows
nothing
I actually like the laziness by default but as you suggest, wish there is a
way to switch it on/off for blocks of the code (rather than compiler
option). Scala guys did some research and in most practical cases Lists are
very short hence they are not lazy and evaluated at once. Just an
interesting
Andy C, I think that in the Clojure world, there is a widespread view that
lazy sequences should be the (or one of the) primary datatypes, that
iteration should usually produce lazy sequences, etc. They are something
like the default in Clojure. Clojure includes a systematically organized
and
I do perceive sets, lists, vector as atoms which are indivisible (well,
this is not true but this is popular meaning) from semantics standpoint.
Therefore map is just a function which processes them as whole, again from
semantics point of view. Implementation and laziness should not matter
really a
user=> (map #(mod % 3) #{3 6})
(0 0)
user=> (set (map #(mod % 3) #{3 6}))
#{0}
--
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 pat
On Sat, Feb 8, 2014 at 3:05 AM, Andy C wrote:
>
> set-s are indeed a sticky point here since the result of a map would
> different depending in the convention.
>
>
No the result would be the same. Only the order of the elements in the lazy
sequence would differ, but that's to be expected since se
dering if there is a strong
argument to use one vs another.
set-s are indeed a sticky point here since the result of a map would
different depending in the convention. So by that token there is something
not abstracted well or I just do not understand map semantics well.
This topic was i
Why should it build a concrete result?
Here's my reasons why it makes sense to be lazy here:
- It would use more memory otherwise. Since, if you are transforming a list
to a set there's got to a transformed copy of the original data structure
when it's materialized.
- It might take longer than ne
Hi,
I have a short question, why map builds up a LazySeq instead of an input
collection as found below:
user=> (type (map #(mod % 3) #{3 6}))
clojure.lang.LazySeq
user=> (type (map #(mod % 3) '(3 6)))
clojure.lang.LazySeq
user=> (type (map #(mod % 3) [3 6]))
clojure.lang.LazySeq
user=> (type (map
41 matches
Mail list logo