FAQ

[Clojure] Any chance for Ratio and BigInt support in ClojureScript?

Olaf Delgado-Friedrichs
Aug 5, 2012 at 6:09 pm
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

--
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 with your first post.
To unsubscribe from this group, send email to
clojure+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
reply

Search Discussions

9 responses

  • David Nolen at Aug 5, 2012 at 9:38 pm

    On Sun, Aug 5, 2012 at 12:45 AM, Olaf Delgado-Friedrichs 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

    --
    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 with your first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en
  • Olaf Delgado-Friedrichs at Aug 6, 2012 at 2:43 am
    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

    On Monday, 6 August 2012 07:38:50 UTC+10, David Nolen wrote:

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

    David
    --
    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 with your first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en
  • David Nolen at Aug 11, 2012 at 6:47 pm

    On Sun, Aug 5, 2012 at 10:43 PM, Olaf Delgado-Friedrichs 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

    --
    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 with your first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en
  • Dspiteself at Aug 15, 2012 at 5:50 pm
    Just to get your gut feeling, do you think the implementation would involve
    bittwittling with the native number, using strings or using byte arrays?
    On Saturday, August 11, 2012 1:47:06 PM UTC-5, David Nolen wrote:

    On Sun, Aug 5, 2012 at 10:43 PM, Olaf Delgado-Friedrichs
    <olaf.d...@googlemail.com <javascript:>> 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
    --
    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 with your first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en
  • David Nolen at Aug 15, 2012 at 5:53 pm
    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?
    On Saturday, August 11, 2012 1:47:06 PM UTC-5, David Nolen wrote:

    On Sun, Aug 5, 2012 at 10:43 PM, Olaf Delgado-Friedrichs
    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
    --
    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<javascript:_e({}, 'cvml', 'clojure@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+unsubscribe@googlegroups.com <javascript:_e({}, 'cvml',
    'clojure%2bunsubscribe@googlegroups.com');>
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en
    --
    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 with your first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en
  • Dspiteself at Aug 15, 2012 at 5:51 pm
    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.

    On Saturday, August 11, 2012 1:47:06 PM UTC-5, David Nolen wrote:

    On Sun, Aug 5, 2012 at 10:43 PM, Olaf Delgado-Friedrichs
    <olaf.d...@googlemail.com <javascript:>> 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
    --
    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 with your first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en
  • David Nolen at Aug 15, 2012 at 6:15 pm

    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

    --
    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 with your first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en
  • Tyler Tallman at Aug 15, 2012 at 10:10 pm
    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?

    On Wed, Aug 15, 2012 at 1:15 PM, David Nolen wrote:
    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

    --
    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 with
    your first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@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

    --
    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 with your first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en
  • David Nolen at Aug 15, 2012 at 10:20 pm

    On Wed, Aug 15, 2012 at 6:10 PM, Tyler Tallman 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

    --
    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 with your first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en

Related Discussions

Discussion Navigation
viewthread | post