Re: Any chance for Ratio and BigInt support in ClojureScript?

[David Nolen]

On Sun, Aug 5, 2012 at 12:45 AM, Olaf Delgado-Friedrichs <olaf.d...@googlemail.com> wrote:

Hi,

I am currently learning Clojure/ClojureScript and enjoying it a lot. Since I have a bit of code I am planning to port that requires precise rational arithmetic, I am particular delighted by the fact that Clojure natively supports rational and arbitrary precision numbers. I'd also like to be able to run parts of that code in the browser, though, which currently seems to mean that I would have to define my own interface and implement it in a platform-dependent way.

So I'd like to know if there are currently any plans for adding Ratio, BigInt and BigDecimal support to ClojureScript, or at least make it easier for users to plug in their own code. I only had a brief glance at the sources, but it seems to me that by providing my own implementations of the 'emit-constant' multi-method for these types, I could make literals work. The standard arithmetic operators, on the other hand, seem to be implemented as macros that directly produce Javascript code. Any chance to have an interface IArithmetic or such in the near future?

Obviously, if no one's working on this or planning to, I'm happy to contribute my own feeble attempts if anyone thinks they might be useful. I'll just have to understand ClojureScript's implementation better first.

Cheers,

Olaf

It would be nice but would require a lot of thought with respect to performance. http://dev.clojure.org/display/design/Numerics

David 

[Olaf Delgado-Friedrichs]

Thanks for the link! I didn't know that the Closure library contained an arbitrary precision type, but should have expected it.

When you speak of performance, do you mean the extra cost of checking argument types for the arithmetic operators? I wonder if this could be addressed by introducing alternate operators +', -' and *' as in Clojure, make these support the additional numeric types and leave the existing operators alone. This is certainly something that makes sense for me to do in a library.

In order to support the BigInt and Ratio literals, would I have to modify the ClojureScript sources, or is it possible to extend emit-constant in "user space"?

Olaf

[David Nolen]

On Sun, Aug 5, 2012 at 10:43 PM, Olaf Delgado-Friedrichs
<olaf.d...@googlemail.com> wrote:
> Thanks for the link! I didn't know that the Closure library contained an
> arbitrary precision type, but should have expected it.
>
> When you speak of performance, do you mean the extra cost of checking
> argument types for the arithmetic operators? I wonder if this could be
> addressed by introducing alternate operators +', -' and *' as in Clojure,
> make these support the additional numeric types and leave the existing
> operators alone. This is certainly something that makes sense for me to do
> in a library.
>
> In order to support the BigInt and Ratio literals, would I have to modify
> the ClojureScript sources, or is it possible to extend emit-constant in
> "user space"?
>
> Olaf

Sorry, forgot to follow up this. I haven't put any deep thought into
it so I can offer no implementation guidance. I think it will be
pretty challenging to get full Clojure JVM numeric semantics into
ClojureScript w/o impacting performance.

It can probably be done but requires both a comprehensive design and
good implementation strategy. If someone wants to take it on ...
great!

David

[David Nolen]

I have no gut feelings about implementation strategies :)

On Sunday, August 12, 2012, dspiteself wrote:

Just to get your gut feeling, do you think the implementation would involve bittwittling with the native number, using strings or using byte arrays?

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

[David Nolen]

On Tuesday, August 14, 2012, dspiteself wrote:

I have extensive google closure experience, but little low level clojurescript experience.

Could we use the clojure library's Integer or long type. It will likely not be as fast but when you need it you need it.

http://closure-library.googlecode.com/svn/docs/closure_goog_math_integer.js.html

http://closure-library.googlecode.com/svn/docs/closure_goog_math_long.js.html
If you can tell me if I would be wasting my time or not I will start working on a comprehensive design.

What do you mean by "wasting your time"?

David

[Tyler Tallman]

By wasting my time I mean if it is clear goog.math.integer is a bad idea it would be great if someone who knows would help a brother out and tell me. :-)

I we are slowly moving a large google closure codebase into clojurescript so I have significantly more experience on the closure side.

goog.math.integer and goog.math.long apear to have about the same performance characteristics when one of our programmers tested a year and a half ago. 

my naive thought make the bigint cast and use the op' so people realize they are taking the performance hit.

(ns myjs
  (:require [goog.math.Integer :as gInteger]))

(defn bigint

  "Coerce to BigInt"
  [x] (cond
       (= (type x) goog.math.Integer) x
       (number? x) (Integer/fromInt x)
       (string? x) (Integer/fromString x);string may be a bad idea but it at least keeps javascript numbers from loosing information
       ))

Then we could make an arbitrary precision version of all the number related functions


(defn +'
  "Returns the sum of nums. (+) returns 0."
  ([] 0)
  ([x] (bigint x))
  ([x y] (.add (bigint x) (bigint y)))
  ([x y & more] (reduce +' (.add (bigint x) (bigint y)) more)))


I am not that familiar with clojurescript yet,but could probably do an extend type on goog.math.Integer
to support iequiv with js/numbers?

David

--

You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

--
Tyler Tallman
Project Manager
Breeze EHR
(m) (337) 205-2142

[David Nolen]

On Wed, Aug 15, 2012 at 6:10 PM, Tyler Tallman <dspit...@gmail.com> wrote:
> By wasting my time I mean if it is clear goog.math.integer is a bad idea it
> would be great if someone who knows would help a brother out and tell me.
> :-)
> I we are slowly moving a large google closure codebase into clojurescript so
> I have significantly more experience on the closure side.
> goog.math.integer and goog.math.long apear to have about the same
> performance characteristics when one of our programmers tested a year and a
> half ago.
> my naive thought make the bigint cast and use the op' so people realize they
> are taking the performance hit.

Send in your CA so you can contribute your thoughts here:
http://dev.clojure.org/display/design/Numerics

Then I and others can provide specific feedback. I think the best
approach would be a solution that first delivers all of Clojure's
numerics. Then some thought needs to be put into how it can be
implemented without slowing all the persistent data structures down.

David