On Thu, Jul 28, 2011 at 10:52 PM, Meikel Brandmeyer (kotarak)
wrote:
> I think this is one of the misunderstandings or points of disagreements (or
> whatever you want to name it) in this whole discussion: this code is *not*
> broken.
Code that runs on 1.2 but throws an exception on 1.3 is "broken
On Fri, Jul 29, 2011 at 2:36 AM, Meikel Brandmeyer (kotarak)
wrote:
> Hi,
>
> Am Freitag, 29. Juli 2011 08:24:54 UTC+2 schrieb Ken Wesson:
>>
>> Er, "fast" would be for primitive integer arithmetic to wrap rather
>> than throw an exception or auto-promote. Both of the latter behaviors
>> require e
Hi,
Am Freitag, 29. Juli 2011 08:24:54 UTC+2 schrieb Ken Wesson:
> Er, "fast" would be for primitive integer arithmetic to wrap rather
> than throw an exception or auto-promote. Both of the latter behaviors
> require every math op to be accompanied by a test of some sort and a
> branch (to either
On Fri, Jul 29, 2011 at 1:52 AM, Meikel Brandmeyer (kotarak)
wrote:
> Hi,
>
> Am Freitag, 29. Juli 2011 01:28:27 UTC+2 schrieb Sean Corfield:
>>
>> Kinda hard since that expression is not valid in 1.3 anyway:
>>
>> ArithmeticException integer overflow
>> clojure.lang.Numbers.throwIntOverflow (Numb
Hi,
Am Freitag, 29. Juli 2011 01:28:27 UTC+2 schrieb Sean Corfield:
>
> Kinda hard since that expression is not valid in 1.3 anyway:
>
> ArithmeticException integer overflow
> clojure.lang.Numbers.throwIntOverflow (Numbers.java:1374)
>
> So that code breaks explicitly in 1.3 and in many ways (for
> I can't think of a single good reason why any of these pages should
> not be world-readable. We're an open source project. It's not as if we
> have trade secrets or something.
>
> I have no problem, of course, with restricting *edit* privileges to
> those with accounts that have proven to be res
On Thu, Jul 28, 2011 at 9:03 PM, pmbauer wrote:
> That wasn't called for.
??
> Given Stu linked to the page (and is linked in the 1.3 release notes), it's
> reasonable to assume the permission error is merely a mistake and not some
> nefarious plot to withhold information from the Clojure commun
That wasn't called for.
Given Stu linked to the page (and is linked in the 1.3 release notes), it's
reasonable to assume the permission error is merely a mistake and not some
nefarious plot to withhold information from the Clojure community.
On Thursday, July 28, 2011 4:48:34 PM UTC-7, Ken Wess
On Thu, Jul 28, 2011 at 7:30 PM, Sean Corfield wrote:
> I think one of the authors / core members needs to change the
> permissions. I have edit access on the parent page
> http://dev.clojure.org/display/doc/Enhanced+Primitive+Support and the
> sibling page http://dev.clojure.org/display/doc/Bit+O
On Thu, Jul 28, 2011 at 7:28 PM, Sean Corfield wrote:
> On Thu, Jul 28, 2011 at 1:53 PM, Ken Wesson wrote:
>>> Chas has already pointed you at the rationale / discussion but I'm a
>> Discussions about primitive arithmetic, not BigInteger arithmetic.
>
> I take it you didn't actually bother to rea
I think one of the authors / core members needs to change the
permissions. I have edit access on the parent page
http://dev.clojure.org/display/doc/Enhanced+Primitive+Support and the
sibling page http://dev.clojure.org/display/doc/Bit+Operations but,
like you, don't have view access to the Numerics
On Thu, Jul 28, 2011 at 1:53 PM, Ken Wesson wrote:
>> Chas has already pointed you at the rationale / discussion but I'm a
> Discussions about primitive arithmetic, not BigInteger arithmetic.
I take it you didn't actually bother to read the page he linked to?
Let me quote the relevant part for yo
On Thu, Jul 28, 2011 at 3:05 AM, Sean Corfield wrote:
> On Wed, Jul 27, 2011 at 5:56 PM, Ken Wesson wrote:
>>> In Clojure 1.2:
>>>
>>> (type (bigint 2)) => java.math.BigInteger
>>>
>>> In Clojure 1.3:
>>>
>>> (type (bigint 2)) => clojure.lang.BigInt
>>> (type 2N) => clojure.lang.BigInt
>>
>> What
Hi,
Is there any way to get to those docs? First I had to crate a user
account, then I was told that
You cannot view this page
Page level restrictions have been applied that limit access to this page.
Thanks,
Perry
==
"This must be Thursday. I never could get the hang of Thursdays" -- Ar
> What the devil? Why was this done? Seems like wheel reinvention to me.
Understanding the motivation for such a decision requires taking the time to
understand the limitations of what Java provides. Java provides no wheel here
-- BigInteger's hash is broken.
The draft docs are here:
http://
As I said tweaking `format` to work on rationals could be too much,
and i can restate that as "it is too much".
Nevertheless, extending it to work on bigint doesn't seem to me really
an edge case, given that i could get a bigint out of any function that
uses autopromotion, so:
(printf "%d" (autop
Tweaking `format` so that it accounts for all sorts of edge cases almost
certainly isn't going to happen, and would be a horrible kludge in any case.
To extend Tom's point, if you really want a format that knows about all of
Clojure's scalars and data structures, cl-format is what you want, and
Thanks for your replies,
+1 for enhancing format
Maybe it could handle also rationals, converting them to doubles, but
it could be to much.
On Jul 28, 9:47 am, Sean Corfield wrote:
> On Wed, Jul 27, 2011 at 11:48 PM, Tom Faulhaber
> wrote:
> > FWIW, clojure.pprint.cl-format handles this fine
On Wed, Jul 27, 2011 at 11:48 PM, Tom Faulhaber wrote:
> FWIW, clojure.pprint.cl-format handles this fine in 1.3:
>
> (cl-format nil "~d" 2N)
> => "2"
Wow, I just spent the last 30 minutes reading Common Lisp the
Language, 2nd Ed, chapter 22 which describes how powerful and
mind-bending that is..
On Wed, Jul 27, 2011 at 5:56 PM, Ken Wesson wrote:
>> In Clojure 1.2:
>>
>> (type (bigint 2)) => java.math.BigInteger
>>
>> In Clojure 1.3:
>>
>> (type (bigint 2)) => clojure.lang.BigInt
>> (type 2N) => clojure.lang.BigInt
>
> What the devil? Why was this done? Seems like wheel reinvention to me.
FWIW, clojure.pprint.cl-format handles this fine in 1.3:
(cl-format nil "~d" 2N)
=> "2"
On Jul 27, 11:45 am, Andrea Tortorella wrote:
> Hi everyone,
> I don't know where to post about bugs (if this is a bug).
> Anyway in clojure 1.3 with the new numerics:
>
> (format "%d" 2N)
>
> throws IllegalF
On Jul 27, 2011, at 8:56 PM, Ken Wesson wrote:
>> In Clojure 1.2:
>>
>> (type (bigint 2)) => java.math.BigInteger
>>
>> In Clojure 1.3:
>>
>> (type (bigint 2)) => clojure.lang.BigInt
>> (type 2N) => clojure.lang.BigInt
>
> What the devil? Why was this done? Seems like wheel reinvention to me.
On Wed, Jul 27, 2011 at 8:25 PM, Sean Corfield wrote:
> On Wed, Jul 27, 2011 at 4:32 PM, Ken Wesson wrote:
>> => (.format (java.util.Formatter.) "%d" (into-array Object [(bigint 2)]))
>> #
>>
>> (2N isn't recognized as a BigInteger literal by Clojure 1.2, it seems.)
>>
>> In my copy of Clojure 1.
On Wed, Jul 27, 2011 at 4:32 PM, Ken Wesson wrote:
> => (.format (java.util.Formatter.) "%d" (into-array Object [(bigint 2)]))
> #
>
> (2N isn't recognized as a BigInteger literal by Clojure 1.2, it seems.)
>
> In my copy of Clojure 1.2, format also seems to work:
>
> => (format "%d" (bigint 2))
>
On Wed, Jul 27, 2011 at 4:33 PM, Alan Malloy wrote:
> On Jul 27, 11:45 am, Andrea Tortorella wrote:
>> Hi everyone,
>> I don't know where to post about bugs (if this is a bug).
>> Anyway in clojure 1.3 with the new numerics:
>>
>> (format "%d" 2N)
>>
>> throws IllegalFormatConversionException, is
On Jul 27, 11:45 am, Andrea Tortorella wrote:
> Hi everyone,
> I don't know where to post about bugs (if this is a bug).
> Anyway in clojure 1.3 with the new numerics:
>
> (format "%d" 2N)
>
> throws IllegalFormatConversionException, is it a bug? are there any
> workarounds?
Unlikely to change an
26 matches
Mail list logo
