On Tuesday, October 27, 2015 at 7:06:43 AM UTC-5, Fluid Dynamics wrote:
>
> On Monday, October 26, 2015 at 2:17:40 AM UTC-4, Andy Fingerhut wrote:
>>
>> I created this ticket: http://dev.clojure.org/jira/browse/CLJ-1832
>>
>> I don't know what will become of it, e.g. perhaps a change in behavior
On Monday, October 26, 2015 at 2:17:40 AM UTC-4, Andy Fingerhut wrote:
>
> I created this ticket: http://dev.clojure.org/jira/browse/CLJ-1832
>
> I don't know what will become of it, e.g. perhaps a change in behavior to
> the unchecked functions, perhaps a clarification to the documentation,
> pe
Thanks andy!
On Monday, October 26, 2015 at 1:25:42 AM UTC-5, Andy Fingerhut wrote:
>
> While waiting to see what becomes of that ticket, if someone felt
> energetic enough to document the gotchas with the unchecked functions, and
> recommend how to get the desired results, e.g. either ^long typ
While waiting to see what becomes of that ticket, if someone felt energetic
enough to document the gotchas with the unchecked functions, and recommend
how to get the desired results, e.g. either ^long type hints, or if (long
x) type conversions on the arguments work (I haven't checked), Reid
McKenz
I created this ticket: http://dev.clojure.org/jira/browse/CLJ-1832
I don't know what will become of it, e.g. perhaps a change in behavior to
the unchecked functions, perhaps a clarification to the documentation,
perhaps nothing. I wouldn't be surprised if the Clojure core team judged
the existing
Half of the time that I use the unchecked functions it's for the math, not
the speed, so getting the wrong behavior when I don't care enough about
perf to do the work for primitives is pretty annoying.
On Sunday, October 25, 2015 at 7:49:47 PM UTC-5, Gary Fredericks wrote:
>
> Maybe even not war
Maybe even not warn unless that one var where you can get
boxed-math-warnings is set appropriately.
On Sunday, October 25, 2015 at 2:04:36 PM UTC-5, Fluid Dynamics wrote:
>
> On Saturday, October 24, 2015 at 8:01:05 PM UTC-4, Gary Fredericks wrote:
>>
>> I've always thought this is bad behavior,
On Saturday, October 24, 2015 at 8:01:05 PM UTC-4, Gary Fredericks wrote:
>
> I've always thought this is bad behavior, since it's blatantly doing the
> opposite of what the name advertises. I think either the boxed versions
> should return the same result as the unboxed version, or (if the whole
I once set out to make a ticket for it, but ended up not probably because
it was going to take too much effort to describe or something. I was
probably busy.
On Saturday, October 24, 2015 at 7:01:05 PM UTC-5, Gary Fredericks wrote:
>
> I've always thought this is bad behavior, since it's blatant
I've always thought this is bad behavior, since it's blatantly doing the
opposite of what the name advertises. I think either the boxed versions
should return the same result as the unboxed version, or (if the whole
point is to give good performance and so we don't want want users to be
able to
I can't answer whether Clojure should do that.
It is doing it because unchecked-multiply falls back to normal multiply,
i.e. *, unless both of its arguments are primitive long values. Even boxed
Long values cause it to fall back to the behavior of *. The same goes for
unchecked-add and unchecked
Should `unchecked-multiply` throw an exception in this case? (see also:
http://stackoverflow.com/questions/33306984/why-does-my-hash-function-fail-with-arithmeticexception-integer-overflow-even/33308956#33308956
)
user> (reduce unchecked-multiply (range 1 22))
ArithmeticException integer overflow
12 matches
Mail list logo
