acing at the moment. To explain it in detail, please
> have a look on this following macro I wrote, which is an upgraded version of
> spec/keys:
>
> (ns myns
> (:refer-clojure :exclude [keys])
> (:require
> [clojure.set :as set]
> [clojure.core :as core]
> [c
I wrote, which is an upgraded version
> of *spec/keys*:
>
> (ns myns
> (:refer-clojure :exclude [keys])
> (:require
> [clojure.set :as set]
> [clojure.core :as core]
> [clojure.spec.alpha :as spec]))
>
> (defmacro keys
> "Same as `clojure.spec/keys
upgraded version
of *spec/keys*:
(ns myns
(:refer-clojure :exclude [keys])
(:require
[clojure.set :as set]
[clojure.core :as core]
[clojure.spec.alpha :as spec]))
(defmacro keys
"Same as `clojure.spec/keys`, but accepts additional boolean option
:additional-keys. U
How to write and validation Boolean (Yes/No) in clojure
--
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
http://blog.klipse.tech/lambda/2016/07/24/lambda-calculus-2.html
The purpose of this article is to show how we represent boolean values in
lambda calculus. And to show the code of the basic boolean operations:
negation, conjunction and disjunction a.k.a not,and and or.
--
You received this
Forgot the this parameter. Sorry. Please ignore. :-(
On Wednesday, February 3, 2016 at 3:18:34 PM UTC-5, William la Forge wrote:
>
> Having a bit of a problem implementing the IAtom interface in a record.
> Specifically, this is the signature giving me grief:
>
> boolean compa
ally, this is the signature giving me grief:
> >
> > boolean compareAndSet(Object oldv, Object newv);
> >
> > This isn't the answer:
> >
> > (^boolean compareAndSet [oldv newv] ... )
> >
>
> ^Boolean?
>
> >
> > I get "Can&#
om f))
(swap [this f arg]
(swap! data-atom
(fn [data]
(lset! lens data (f (lget lens data) arg)
(swap [this f arg1 arg2]
(swap! data-atom
(fn [data]
(lset! lens data (f (lget lens data) arg1 arg2)
(swap [this f x y args]
(swap!
you're missing the `this` argument in the argvec.
(compareAndSet [this oldv newv] ..)
the boolean type hint shoulnd't be necessary.
On Wed, Feb 3, 2016 at 8:18 PM, William la Forge wrote:
> Having a bit of a problem implementing the IAtom interface in a record.
> Specifica
On Feb 3, 2016 2:18 PM, "William la Forge" wrote:
>
> Having a bit of a problem implementing the IAtom interface in a record.
Specifically, this is the signature giving me grief:
>
> boolean compareAndSet(Object oldv, Object newv);
>
> This isn't the answer:
>
Having a bit of a problem implementing the IAtom interface in a record.
Specifically, this is the signature giving me grief:
boolean compareAndSet(Object oldv, Object newv);
This isn't the answer:
(^boolean compareAndSet [oldv newv] ... )
I get "Can't define method no
On Apr 17, 2014, at 07:38 , Tassilo Horn wrote:
> Michael Gardner writes:
>
>>> And now you have an if without then which will give you another
>>> exception.
>>
>> Not true. It's more common to use 'when', but single-branch ifs are
>> perfectly fine.
>
> Yes, but that was a zero-branch if, a
Michael Gardner writes:
>> And now you have an if without then which will give you another
>> exception.
>
> Not true. It's more common to use 'when', but single-branch ifs are
> perfectly fine.
Yes, but that was a zero-branch if, and that's not ok.
Bye,
Tassilo
--
You received this message b
Op donderdag 17 april 2014 13:26:35 UTC+2 schreef Michael Gardner:
>
> On Apr 17, 2014, at 02:34 , Tassilo Horn >
> wrote:
>
> > And now you have an if without then which will give you another
> > exception.
>
Yep, but that one I solved already.
>
> Not true. It's more common to use 'when
On Apr 17, 2014, at 02:34 , Tassilo Horn wrote:
> And now you have an if without then which will give you another
> exception.
Not true. It's more common to use 'when', but single-branch ifs are perfectly
fine.
--
You received this message because you are subscribed to the Google
Groups "Cloj
a where some method wants some "real"
>> boolean, then there's already clojure.core/boolean.
>
> In this exercise you are not allowed to use boolean.
Ah, ok, then it makes sense. :-)
Bye,
Tassilo
--
You received this message because you are subscribed to the Goog
Op donderdag 17 april 2014 09:34:52 UTC+2 schreef Tassilo Horn:
>
> Stanislas Nanchen > writes:
>
> > You miss one parentheses at the end of your expression
> >
> > (defn boolean [x]
> > (if (and (nil? x) (false? x))
> > ))
>
> And now
Stanislas Nanchen writes:
> You miss one parentheses at the end of your expression
>
> (defn boolean [x]
> (if (and (nil? x) (false? x))
> ))
And now you have an if without then which will give you another
exception. And the test expression is a contradiction, i.e., it
Otherwise I have to be true.
>
> So I tried this :
>
> (defn boolean [x]
> (if (and (nil? x) (false? x))
> )
>
> But then I see a very long error message:
>
> xception in thread "main" java.lang.RuntimeException: EOF while reading,
> starting at l
Hello,
You miss one parentheses at the end of your expression
(defn boolean [x]
(if (and (nil? x) (false? x))
))
cheers,
stan.
On Thursday, April 17, 2014 9:11:13 AM UTC+2, Roelof Wobben wrote:
>
> Hello,
>
> IM working at the Iloveponies github tutorial and Im stuck here,
&
Hello,
IM working at the Iloveponies github tutorial and Im stuck here,
I have to check if x is a nil or false and then the output must be false,\
Otherwise I have to be true.
So I tried this :
(defn boolean [x]
(if (and (nil? x) (false? x))
)
But then I see a very long error message
Awesome turnaround, Thanks.
I was kinda worried I was nuts or about to do some urandom debugging.
--
--
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 m
ided to play with simple-check for the first time and was working
>> through the examples on github. I noticed that all the values that use
>> gen/boolean are returning false. I never get a true.
>>
>> At the extreme end, the following never returns when run in the repl:
&g
On Saturday, January 25, 2014 10:03:13 PM UTC+1, Michael Daines wrote:
>
> I decided to play with simple-check for the first time and was working
> through the examples on github. I noticed that all the values that use
> gen/boolean are returning false. I never get a true.
>
&
I decided to play with simple-check for the first time and was working
through the examples on github. I noticed that all the values that use
gen/boolean are returning false. I never get a true.
At the extreme end, the following never returns when run in the repl:
(gen/sample (gen/such-that
on it returns (using Field.get()) a Boolean that for clojure will
> be always false.
>
> In order to solve this issue I created the follow fn:
>
> (defn- get-val
> [^java.lang.reflect.Field f instance]
> (let [value (.get f instance)]
> (if (instance? java.lang.Boolean val
turns (using Field.get()) a Boolean that for clojure
will be always false.
In order to solve this issue I created the follow fn:
(defn- get-val
[^java.lang.reflect.Field f instance]
(let [value (.get f instance)]
(if (instance? java.lang.Boolean
There is also this page on ClojureDocs that might shed some light on this
quirk:
http://clojuredocs.org/clojure_core/clojure.core/if
On Sun, Oct 6, 2013 at 6:14 PM, Rob Browning wrote:
> Gary Trakhman writes:
>
> > Clojure's false and true are Boolean/FALSE and Bool
Gary Trakhman writes:
> Clojure's false and true are Boolean/FALSE and Boolean/TRUE, and for speed
> reasons (I think) anything that checks for truthiness uses java's ==, which
> will fail on any new Boolean object. Usually, this isn't a problem, but
> sometimes it
Clojure's false and true are Boolean/FALSE and Boolean/TRUE, and for speed
reasons (I think) anything that checks for truthiness uses java's ==, which
will fail on any new Boolean object. Usually, this isn't a problem, but
sometimes it is. You can see that this assumption is perva
Hey Devs,
I have fighting against an issue that can summarized in the following line:
user=> (not (new java.lang.Boolean false))
false
Is that behavior correct?
Because if I run:
user=> (type false)
java.lang.Boolean
Can someone help me to understand it?
Thanks,
--
Bauna
--
--
You received
On Fri, May 24, 2013 at 1:25 PM, atkaaz wrote:
> It kinda makes sense except I wouldn't have expected that on the map it
> would return a vector (but then how else could it return both key and value
> right? ) so everyone expects the "input" to the pred would be a vector
> when passed in a map.
> => (source every?)
> (defn every?
> "Returns true if (pred x) is logical true for every x in coll, else
> false."
> {:tag Boolean
>:added "1.0"
>:static true}
> [pred coll]
> (cond
>(nil? (seq coll)) true
>(pred (first coll))
Thank you, I see it now. Based on your comment I actually took at look at
the source code for "every?" (haven't checked it before, oddly enough)
=> (source every?)
(defn every?
"Returns true if (pred x) is logical true for every x in coll, else
false."
;
> On Thu, May 23, 2013 at 9:00 PM, Michał Marczyk
> wrote:
>
>> On 23 May 2013 18:30, atkaaz wrote:
>> > when you say the word "false" I'm assuming you're referring to "false?"
>> the
>> > function (not "false"
Firstly let me just say that I really enjoy this conversation, ergo I thank
you!
On Thu, May 23, 2013 at 9:00 PM, Michał Marczyk wrote:
> On 23 May 2013 18:30, atkaaz wrote:
> > when you say the word "false" I'm assuming you're referring to "false?"
>
o "false?" the
> > function (not "false" the boolean value), otherwise I don't understand
> > I mean false-the-Boolean-value.
> > To rephrase the point I was making previously, "(false x) is a truthy
> value for any x in []" is a true sentence,
On 23 May 2013 18:30, atkaaz wrote:
> when you say the word "false" I'm assuming you're referring to "false?" the
> function (not "false" the boolean value), otherwise I don't understand
I mean false-the-Boolean-value.
To rephrase the point I
A while back I saw some java slides that elude me now, they mentioned
approaches to safety like defensive copying, immutability, etc.. their
conclusion at the end, that I seem to remember, was it only really made
sense to validate user input, a sort of wall, where anything past the wall
is assumed
On Thu, May 23, 2013 at 11:30 AM, atkaaz wrote:
> So all I was saying above is that it should throw when [] is empty just as
> it does when [] is not empty, but it doesn't throw when empty because it's
> never called (by "it" i mean "false" not "false?")
>
This sort of behavior is handy for user
when you say the word "false" I'm assuming you're referring to "false?" the
function (not "false" the boolean value), otherwise I don't understand
so like: "What matters is that *false?* returns truthy values when called
with any members of []
Whether (false 1) or (false true) is truthy is irrelevant. What
matters is that false returns truthy values when called with any
members of [], which is of course the case, as [] has no members. (For
it not to be the case, there would have to exist an x in [] for which
(false x) were not truthy --
Well, seems to me more like this:
if [] is empty then return true
otherwise check (pred everyx in coll)
however this allows for any pred especially(in this case) invalid preds:
`false` is not a function/pred
=> (false 1)
ClassCastException java.lang.Boolean cannot be cast to clojure.lang.IFn
cgws.n
On 22 May 2013 18:34, atkaaz wrote:
> I think the exception is thrown because you basically called (every? false
> coll) however on my clojure version I cannot reproduce it oh wait there we
> go, some bug here with empty collection (maybe someone can pick it up):
> => (every? false [1 2 3])
> Cla
On Wed, May 22, 2013 at 9:32 AM, Peter Mancini wrote:
> (defn all-true?
> [coll]
> (every? (fn [x] (= x true)) coll))
(defn all-true?
[coll]
(every? true? coll))
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com
there's another edge case when using and/or :
getting passed an unbound var where for example `nil?` and `str` applied
to it don't throw, and of course also `or` and `and`, ie.:
=> (def a)
#'cgws.notcore/a
=> a
#
=> (nil? a)
false
=> (str a)
"Unbound: #'cgws.notcore/a"
=> (or a)
#
=> (or 1 2 a)
I think the exception is thrown because you basically called (every? false
coll) however on my clojure version I cannot reproduce it oh wait there we
go, some bug here with empty collection (maybe someone can pick it up):
=> (every? false [1 2 3])
ClassCastException java.lang.Boolean cannot be cas
Duh never mind - simplified it and it works like a charm now.
(defn all-true?
[coll]
(every? (fn [x] (= x true)) coll))
(all-true? '(true true true))
(all-true? '(true true false))
(all-true? '(true true 3))
(all-true? '(3 \# !))
No exception on bad input data but if I really need to do that
Try:
user=> (every? #(= Boolean (type %)) [true false false])
true
user=> (every? #(= Boolean (type %)) [true false false 1])
false
On 22 May 2013 18:20, atkaaz wrote:
> => (type identity)
> clojure.core$identity
>
>
>
> On Wed, May 22, 2013 at 7:17 PM, Peter Mancin
=> (type identity)
clojure.core$identity
On Wed, May 22, 2013 at 7:17 PM, Peter Mancini wrote:
> So I did some coding and came up with this but it is broken;
>
> (= java.lang.Boolean (type false)) ;;evaluates to true
>
> (defn all-true?
> [coll]
> (every? (cond (= java.lang.Boolean (type i
So I did some coding and came up with this but it is broken;
(= java.lang.Boolean (type false)) ;;evaluates to true
(defn all-true?
[coll]
(every? (cond (= java.lang.Boolean (type identity)) identity :else false)
coll)) ;;compiles
(all-true? '(true true true)) ;; throws java.lang.ClassCas
On Wed, May 22, 2013 at 12:14 AM, Chris Ford wrote:
> The reason "and" is a macro is that it's designed to short-circuit - ie if
> the first result is false the rest shouldn't even be evaluated.
>
> Using it on raw booleans works, because booleans evaluate to themselves,
> but it's really designed
gt; The nil behavior of the 'or' version breaks what I wanted, but I may
> > create functions that return just true or false though the odd edge
> > case where "and" will return a value will mean I'll have to handle that.
>
> wrap that call in a
On 22/05/13 15:54, Peter Mancini wrote:
The nil behavior of the 'or' version breaks what I wanted, but I may
create functions that return just true or false though the odd edge
case where "and" will return a value will mean I'll have to handle that.
wrap that call
Thanks everyone for the help. The nil behavior of the 'or' version breaks
what I wanted, but I may create functions that return just true or false
though the odd edge case where "and" will return a value will mean I'll
have to handle that. My preference would be to throw an exception but thats
On 22 May 2013 08:09, Baishampayan Ghose wrote:
> Using a lambda seems to be a sane approach -
>
> (reduce #(and %1 %2) '(false false true))
> ;=> false
Note that this will always traverse the entire input collection,
whereas every? stops at the first false value.
Same thing goes for reducing wi
Oh i see now, thank you!
so it's like this:
"otherwise it returns the value of the last expression.
(and) returns true."
i though "expr." is the short for of the word "expression" which requires a
dot, but the dot was in fact an end of sentence.
On Wed, May 22, 2013 at 2:40 PM, John D. Hume wr
On May 22, 2013 5:35 AM, "atkaaz" wrote:
>
> I find the wording of this confusing "otherwise it returns the value of
the last expr. (and) returns true."
> I mean, I know it returns the last true value, but that's because I've
tested it not because the doc is trying(failing) to tell me so with that
I find the wording of this confusing "otherwise it returns the value
of the last
expr. (and) returns true."
I mean, I know it returns the last true value, but that's because I've
tested it not because the doc is trying(failing) to tell me so with that
phrase.
On Wed, May 22, 2013 at 1:28 PM, atk
On Wed, May 22, 2013 at 3:06 AM, Peter Mancini wrote:
> I noticed that '(nil nil true) will cause "and" to produce false, so I am
> aware of that edge case. Anything else I should be aware of?
>
> What about the other edge?
user=> (reduce #(and %1 %2) '(1 true 2))
2
user=> (eval (conj '(1 true
The reason "and" is a macro is that it's designed to short-circuit - ie if
the first result is false the rest shouldn't even be evaluated.
Using it on raw booleans works, because booleans evaluate to themselves,
but it's really designed to be given forms.
The absence of a pure function for conjun
Using eval should be a rarity.
I'd use (every? identity [false false true]) to do a reduce-and, and I'd
use (some identity [false false true]) to do a reduce-or (keeping in mind
the latter actually returns nil rather than false).
--
--
You received this message because you are subscribed to the
Using a lambda seems to be a sane approach -
(reduce #(and %1 %2) '(false false true))
;=> false
On Wed, May 22, 2013 at 5:36 AM, Peter Mancini wrote:
> OK long time lurker here. I've been growing in my Clojure strength for a
> while now. For the most part I think I get it and I have no problem
OK long time lurker here. I've been growing in my Clojure strength for a
while now. For the most part I think I get it and I have no problem getting
programs to do what I want. However, sometimes I get stumped.
I have one function that produces a list of booleans like '(false false
true). It se
This seems to be a question on whether clojure supports java auto-boxing.
What java is doing here:
if (new Boolean(false)) {
// true
}
is calling .booleanValue on the Boolean object (as mentioned above).
And here:
int x = new Integer(6) + 4;
intValue is being called on the Integer object
the JVM and CLR (and JS).
The JVM and CLR (and JS) in this context are engines running language
implementations, not language implementations by themselves.
Clojure is not Java and vice-versa. Java objects are values to Clojure.
So is a Boolean object. What you have shown here is a Java spe
What is the situation in ClojureCLR?
And, seeing the if code cited, I just run this code:
public class BoolTest {
public static void main(String[] args)
{
Boolean f = new Boolean(false);
System.out.println(f.equals(false)); // true
System.out.println(f == false); // true
System.out.println(f
>
> So 'false?' doesn't help you here.
>
It does, actually (see earlier responses for details)
> So if anyone runs into this problem _in real world code_ it's because
>
> they are calling a Java API that somehow returns a Java Boolean object
> embedded
Armando Blancas writes:
> It's the other way around: false is boxed into Boolean/FALSE.
That's exactly what I've said, no?
TH> That [Boolean.FALSE] is the canonical false Boolean object you get
TH> when auto-boxing the primitive boolean false, or when calling
TH&
wow!!! i wasn't expecting that one...
Jim
On 13/04/12 21:17, Armando Blancas wrote:
It's the other way around: false is boxed into Boolean/FALSE. Here's
the if stmt:
public Object eval() {
Object t = testExpr.eval();
if(t != null && t != Boolean.FALSE)
return
It's the other way around: false is boxed into Boolean/FALSE. Here's the if
stmt:
public Object eval() {
Object t = testExpr.eval();
if(t != null && t != Boolean.FALSE)
return thenExpr.eval();
return elseExpr.eval();
}
On Friday, April 13, 2012 12:45:02 PM UTC-7, Andy Finger
Andy Fingerhut writes:
> Boolean/FALSE is documented as being of type Boolean in Java
> documentation, yet it is treated by Clojure the same as primitive
> boolean false:
>
> user=> (clojure-version)
> "1.3.0"
> user=> (if Boolean/FALSE "logical true&
Hi,
Am 13.04.2012 um 21:45 schrieb Andy Fingerhut:
> One little nit that confuses me.
>
> Boolean/FALSE is documented as being of type Boolean in Java documentation,
> yet it is treated by Clojure the same as primitive boolean false:
>
> user=> (clojure-version)
> &quo
One little nit that confuses me.
Boolean/FALSE is documented as being of type Boolean in Java documentation,
yet it is treated by Clojure the same as primitive boolean false:
user=> (clojure-version)
"1.3.0"
user=> (if Boolean/FALSE "logical true" "logic
On Fri, Apr 13, 2012 at 3:33 AM, Vinzent wrote:
> Just like Boolean's javadoc puts a strong
> emphasis on the fact that public Boolean(boolean value) constructor usually
> shouldn't be used, clojure's docstring should say that (= x false) may give
> you a result which
You are reporting this to the wrong language group.
The fact that Java:
A) has a public constructor for Boolean (a type with only 2 possible instances)
B) whose doc string says "Note: It is rarely appropriate to use this
constructor."
and then
C) goes on to use it in some library
What of the original issue, that deserializing a large nested
datastructure with boxed booleans in it results in misbehaving Boolean
"false" instances?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, s
right? It's actually a trivial fix that would save a lot of time and
OMGWTFs for the new clojure users. Just like Boolean's javadoc puts a
strong emphasis on the fact that public *Boolean*(boolean value)
constructor usually shouldn't be used, clojure's docstring should say t
Again, (Boolean. false) is an object. Objects returned from Java are values
from Clojure's perspective like numbers,
Clojure is a Lisp but allows you to access Java's object world.
It's not because the object wraps a property containing a boolean primitive
value that it
sh
l is the only false value, and there's no way to create
a new nil value that's not identical to nil. Scheme is similar in
having only #t and #f as boolean values with no possibility of creating
new instances of #t and #f.
> user=> (if some-thing "then" "else&qu
Stefan Kamphausen writes:
> According to e.g.
>
> http://nathanmarz.com/blog/fun-with-equality-in-clojure.html
>
> it's a speed trade-off.
Partly. See Daniel's post where he fixed my contrieved micro-benchmark
and showed that testing on Boolean-equality in `if` slows
According to e.g.
http://nathanmarz.com/blog/fun-with-equality-in-clojure.html
it's a speed trade-off. Something one can live with, but a wart
nevertheless.
Best,
Stefan
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, sen
uot;)
"then"
user=> (if (= some-thing false) "then" "else")
"then"
How can some-thing evaluate to true but be equal (in whatever sense =
defines equality) to false?
IMHO it looks like some inconsistency in the contract between truthiness
and equality.
>
> > 'false' is a clojure built-in,
>
> false and true are JVM built-ins.
>
LOL. Don't let him get away with anything!
--
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
>
> The cheatsheet at http://clojure.org/cheatsheet (and the tooltip variants
> available at http://jafingerhut.github.com) link to the clojuredocs
> pages, so they have visibility to people who use the cheatsheet, or
> clojuredocs.org directly.
>
>
or anyone else who uses this awesome feature
The cheatsheet at http://clojure.org/cheatsheet (and the tooltip variants
available at http://jafingerhut.github.com) link to the clojuredocs pages,
so they have visibility to people who use the cheatsheet, or
clojuredocs.orgdirectly.
Or anyone else who uses this awesome feature of leinigen 2:
ng would rather be the same as if (subvec [1 2 3] 1) would return
> [2 3] and (subvec '(1 2 3) 1) would return "haha, gotcha!" :)
>
> Since you are complaining about =, do you mean that = should be
>>
>> special-cased to do an identity-check instead of an equ
complaining about =, do you mean that = should be
>
> special-cased to do an identity-check instead of an equality check for
> java.lang.Booleans? E.g., are you demanding that (= false
> (Boolean. false)) should be false? That would be horrible.
>
It's not that I'm complaining ab
all `subvec' on a list.
> 'false' is a clojure built-in,
false and true are JVM built-ins.
> so I'd expect that its behaviour is similar. 'false' is equal to
> (Boolean. false); it implies that they represents the same
> value. Thus, the same value can
t its behaviour is
similar. 'false' is equal to (Boolean. false); it implies that they
represents the same value. Thus, the same value can be considered as both
truthy and falsey by clojure, which is like blowing my mind.
Of course it's possible to say that one of ='s argu
Vinzent writes:
> 1. Clearly state in the section on interop that clojure, unlike java,
> doesn't treat 'false' and (Boolean. false) as equal objects.
Of course, it does! But `if` doesn't check equality, it checks if the
test expression's result is *identical*
Well, changing the behaviour of 'if' is not the only way to fix the problem
(and it's impossible because of backward compatibility anyway). In my mind,
more realistic solution would be:
>
> 1. Clearly state in the section on interop that clojure, unlike java,
doesn't
On Tue, Apr 10, 2012 at 8:46 AM, Vinzent wrote:
> So I agree: you cannot make it work for each and every JVM language, so
>> the current simplistic behavior is just fine.
>>
> Yeah, but my question about 'if' and equality remains open.
>
Not really, your example is trying to assign some special
>
> So I agree: you cannot make it work for each and every JVM language, so
> the current simplistic behavior is just fine.
>
Yeah, but my question about 'if' and equality remains open.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this
Daniel Solano Gómez writes:
> Second, I revised my code yet again and ran it outside the profiler.
> I am finding that eval2 is at least an order of magnitude slower,
> somewhere around 20×.
Indeed, I can confirm that. :-)
Bye,
Tassilo
--
You received this message because you are subscribed t
numbers, Booleans "created properly" with valueOf(),
> > Booleans created with the constructor, Strings, and nulls.
> >
> > To my amazement, the variant that explicitly checks for Boolean wrapper
> > objects is not at all slower. On my machine with IcedTea7-2.1,
de (attached) using an
> instrumenting profiler shows that the version that checks for the
> Boolean instance is about 6% slower than the version that does not.
There's nothing attached. ;-)
> In any case, these are somewhat meaningless micro-benchmarks.
> Ultimately, whether or n
; Booleans created with the constructor, Strings, and nulls.
>
> To my amazement, the variant that explicitly checks for Boolean wrapper
> objects is not at all slower. On my machine with IcedTea7-2.1, the 10
> million checks with either the current null/false-check or the
> null/false
Vinzent writes:
> That's interesting, thanks for your investigation! Then such decision
> was clearly made because Java is not the only JVM language, just as
> Luc said. For example, JRuby has its own class which wraps false:
> http://jruby.org/apidocs/org/jruby/RubyBoolean.False.html Obviously,
That's interesting, thanks for your investigation! Then such decision was
clearly made because Java is not the only JVM language, just as Luc said.
For example, JRuby has its own class which wraps false:
http://jruby.org/apidocs/org/jruby/RubyBoolean.False.html
Obviously, it's impossible to imple
1 - 100 of 149 matches
Mail list logo
