Printing BigIntegers

149 views
Skip to first unread message

ataggart

unread,
May 16, 2011, 2:20:02 PM5/16/11
to Clojure Dev
See http://dev.clojure.org/jira/browse/CLJ-798

Should the fix be:
1. remove the print-dup for BigInteger
2. print it using the N notation (thus being read in as a BigInt)
3. add read support for the BIGINT notation

Christopher Redinger

unread,
May 25, 2011, 3:17:56 PM5/25/11
to cloju...@googlegroups.com
Hi Alex. Sorry for the delay in responding. A couple of us had a chance to take a look at this issue today. The patch looks reasonable, but we thought of one potential issue. The way the patch is written, you’ve chosen option #2: print a java.math.BigInteger using the N suffix, rather than the BIGINT suffix. As you say, that would result in the reader reading it as a clojure.lang.BigInt. While that wouldn’t result in any loss of numeric data (BigInt is implemented in terms of BigInteger), it’s slightly odd, as it means that a print/read roundtrip would change the type of the object. 

We could choose to take either of the other two routes (or indeed, to decide that the type change is no big deal), but it seems like there are enough subtleties here that further discussion is warranted. We’re planning to bring up the matter at the next Clojure/core meeting (Friday), so if you have any further thoughts, today or tomorrow would be a good time to share them.

--
Chris Redinger
Clojure/core

ataggart

unread,
May 25, 2011, 5:35:48 PM5/25/11
to Clojure Dev
The reason why I settled on the N notation was that the reader already
turns >64-bit literal integers into BigInts, thus the N notation
serves to force bignum math ops when using small int values. Since
BigIntegers count towards that contagious behaviour, it seemed
appropriate to have the same notation.

There are some other print-dup tickets:
http://dev.clojure.org/jira/browse/CLJ-797
http://dev.clojure.org/jira/browse/CLJ-799

Kevin Downey

unread,
Jun 3, 2011, 4:48:30 PM6/3/11
to cloju...@googlegroups.com
I am curious as to why this patch cannot be discussed in the open on
the mailing list. does it really have to wait until the next closed
door session of clojure/core?

> --
> You received this message because you are subscribed to the Google Groups
> "Clojure Dev" group.
> To post to this group, send email to cloju...@googlegroups.com.
> To unsubscribe from this group, send email to
> clojure-dev...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/clojure-dev?hl=en.
>

--
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

Christopher Redinger

unread,
Jun 3, 2011, 5:12:54 PM6/3/11
to cloju...@googlegroups.com
On Fri, Jun 3, 2011 at 4:48 PM, Kevin Downey <red...@gmail.com> wrote:
> I am curious as to why this patch cannot be discussed in the open on
> the mailing list. does it really have to wait until the next closed
> door session of clojure/core?

Clojure/core's Friday meeting isn't intended as a "closed door"
meeting. It's just a time we have all agreed to meet in order to
facilitate discussion.

We certainly encourage more discussion on the list! E.g. I did ask
Alex to share any other thoughts he had, which he did. And then
submitted a new patch based on our feedback.

This particular ticket was, at the beginning of the week, marked as
screened with this latest patch. See
http://dev.clojure.org/jira/browse/CLJ-798

Excepting any further comment from Rich it should be included in the next alpha.

--
Christopher Redinger
Clojure/core
http://clojure.com

Stuart Sierra

unread,
Jun 4, 2011, 12:57:02 PM6/4/11
to cloju...@googlegroups.com
In particular, Clojure/core meetings are our chance to get feedback and direction from Rich Hickey, who doesn't have as much time to follow the mailing list these days.

-Stuart Sierra
clojure.com

Chas Emerick

unread,
Jun 6, 2011, 12:14:52 PM6/6/11
to cloju...@googlegroups.com
It seems to me that a pr/read roundtrip should ideally not change the types of the objects involved, but even worse might be having two notations for functionally equivalent (ex. interop) concrete types.

Since all ops return BigInts anyway (i.e. you're only going to see a BigInteger when you explicitly ask for one or when doing interop), perhaps BigIntegers should be printed unreadably?

- Chas

ataggart

unread,
Jun 7, 2011, 4:06:40 PM6/7/11
to Clojure Dev


On Jun 6, 9:14 am, Chas Emerick <cemer...@snowtide.com> wrote:
> It seems to me that a pr/read roundtrip should ideally not change the types
> of the objects involved

In fact, Rich made clear my misunderstanding in a comment to one of
the tickets: "The point of print-dup is type preservation".
Reply all
Reply to author
Forward
0 new messages