Re: [racket-users] Narrow radix of string->number.

[Robby Findler]

For the app that you're using, can you provide a histogram of the
inputs that you supply to number->string or, if it isn't too much
trouble, point me at the app so I can grab that?

Robby


On Wed, Jan 11, 2017 at 12:31 PM, JCG  wrote:
> On Thursday, December 29, 2016 at 5:54:08 PM UTC-5, gustavo wrote:
>> I'm not too worried about a x4 slowdown in number->string because I
>> don't expect it to be in a tight loop, but it would be nice that it
>> were faster.
>
> In fact, I find number->string already a tad slow, because I do use it in a 
> loop.
>
> Anyway, I don't want to complain about speed down the road without mentioning 
> now that I would consider any 4x slowdown unpleasant.
>
> A base-10 user,
> JG
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Narrow radix of string->number.

[JCG]

On Thursday, December 29, 2016 at 5:54:08 PM UTC-5, gustavo wrote:
> I'm not too worried about a x4 slowdown in number->string because I
> don't expect it to be in a tight loop, but it would be nice that it
> were faster.

In fact, I find number->string already a tad slow, because I do use it in a 
loop.  

Anyway, I don't want to complain about speed down the road without mentioning 
now that I would consider any 4x slowdown unpleasant.

A base-10 user,
JG

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Narrow radix of string->number.

[Alex Knauth]

> On Jan 4, 2017, at 1:49 PM, Robby Findler  wrote:
> 
> Is changing the alphabet something that can be done post-facto with
> string replacements?

Could there be a more general list-of-digits->number that could work with any 
base?

(list-of-digits->number (list 50 73) 90) ;=> 4573

Then using an arbitrary alphabet could work by replacing numbers within a list 
instead of finding sequences within a string, which sounds much more hacky.

Alex Knauth

> Robby
> 
> On Wed, Jan 4, 2017 at 12:46 PM, Deren Dohoda  wrote:
>> Some food for thought on this topic, I use base conversion for all sorts of
>> silly things. To this end I require a great deal of flexibility in
>> representation. When I wrote my continued-fractions package I included this
>> as a separate module. Here's an example:
>> 
>> Welcome to DrRacket, version 6.7 [3m].
>> Language: racket/base, with debugging [custom]; memory limit: 2048 MB.
>>> (require continued-fractions/bases)
>> 
>> (define rep (make-representation #:radix #\!
>> #:negate #\+
>> #:terms
>> "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"))
>> 
>> (parameterize ((representation rep)
>>   (digits 10))
>>  (let ((n (/ -125382661425156036913657 101559956668416)))
>>(let ((s (->string n)))
>>  (displayln s)
>>  (let ((n* (->number s)))
>>(= n n*)
>> +KF12OI!4FZZZXRSP
>> #t
>>> 
>> 
>> This may be pointlessly more flexible than a normal user of number->string
>> would want but an arbitrary alphabet is something I'd request people
>> consider for a few moments if changing number->string is open for debate.
>> Maybe it is too much flexibility for racket/base, though, which is where
>> number->string lives.
>> 
>> Deren
>> 
>> On Wed, Jan 4, 2017 at 11:38 AM, Gustavo Massaccesi 
>> wrote:
>>> 
>>> I'm still worried about bignums. So I borrowed the idea of Mathew of
>>> splitting the number in 1/2/3 digits chucks, but I use fixnum chunks.
>>> For each fixnum chunk I calculate the string representation as usual,
>>> but as most of the calculations involve only fixnum, then It's x4
>>> faster for bignums.
>>> 
>>> It's slightly slower for the DrRacket distribution and fixnums and
>>> (5%-10%).
>>> 
>>> The code assumes that a 9 is a fixnum, this is true for 32 and
>>> 64 bit's racket. (In case Racket is ported in the future to a 16 bits
>>> platform, the code is still correct but slower.)
>>> 
>>> DrRacket distribution of numbers
>>> number->string cpu time: 4907 real time: 4898 gc time: 77
>>> number->string* cpu time: 3703 real time: 3701 gc time: 0
>>> number->string** cpu time: 6782 real time: 6777 gc time: 16
>>> number->string*** cpu time: 3797 real time: 3796 gc time: 16
>>> 
>>> Always N=123 (10 times less calls)
>>> number->string cpu time: 859 real time: 846 gc time: 0
>>> number->string* cpu time: 1688 real time: 1676 gc time: 31
>>> number->string** cpu time: 672 real time: 673 gc time: 0
>>> number->string*** cpu time: 1796 real time: 1800 gc time: 0
>>> 
>>> Always N=1234567890123456789012345678901234567890 (10 times less calls)
>>> number->string cpu time: 5625 real time: 5623 gc time: 0
>>> number->string* cpu time: 102125 real time: 102100 gc time: 403
>>> number->string** cpu time: 750 real time: 748 gc time: 15
>>> number->string*** cpu time: 26343 real time: 26337 gc time: 95
>>> 
>>> Gustavo
>>> 
>>> ;Here is ony the code of the new function and benchmarks
>>> ;I'm not happy with the names of the auxiliary functions.
>>> 
>>> (define (number->string***/fixed N short-size trim)
>>>  (define str (make-string short-size #\0))
>>>  (let loop ([N N] [i short-size])
>>>(cond
>>>  [(zero? N)
>>>   (if trim
>>>   (substring str i short-size)
>>>   str)]
>>>  [else
>>>   (define q (quotient N 10))
>>>   (define r (remainder N 10))
>>>   (define d (integer->char (+ r (char->integer #\0
>>>   (string-set! str (- i 1) d)
>>>   (loop q (- i 1))])))
>>> 
>>> (define (number->string***/bignum/list N tail)
>>>  (define-values (q r) (quotient/remainder N (expt 10 9)))
>>>  (cond
>>>[(zero? q)
>>> (cons (number->string***/fixed r 9 #t) tail)]
>>>[else
>>> (number->string***/bignum/list q (cons (number->string***/fixed r
>>> 9 #f) tail))]))
>>> 
>>> (define (number->string*** N)
>>>  (cond
>>>[(fixnum? N)
>>> (cond
>>>   [(< N 10)
>>>(string (integer->char (+ (char->integer #\0) N)))]
>>>   [(< N (expt 10 9))
>>>(number->string***/fixed N 9 #t)]
>>>   [else
>>>(apply string-append (number->string***/bignum/list N '()))])]
>>>[else
>>> (apply string-append (number->string***/bignum/list N '()))]))
>>> 
>>> ;(define-syntax-rule (test-it id ...) ...)
>>> 
>>> (define iterations 5)
>>> 
>>> (define-syntax-rule (time-it id ...)
>>>  (begin
>>>(define numbers (for/list ([i (in-range 1000)])

Re: [racket-users] Narrow radix of string->number.

[Deren Dohoda]

Yes, Robby, if the new base fits within the range allowed by number->string.

On Wed, Jan 4, 2017 at 1:49 PM, Robby Findler 
wrote:

> Is changing the alphabet something that can be done post-facto with
> string replacements?
>
> Robby
>
>
> On Wed, Jan 4, 2017 at 12:46 PM, Deren Dohoda 
> wrote:
> > Some food for thought on this topic, I use base conversion for all sorts
> of
> > silly things. To this end I require a great deal of flexibility in
> > representation. When I wrote my continued-fractions package I included
> this
> > as a separate module. Here's an example:
> >
> > Welcome to DrRacket, version 6.7 [3m].
> > Language: racket/base, with debugging [custom]; memory limit: 2048 MB.
> >> (require continued-fractions/bases)
> >
> > (define rep (make-representation #:radix #\!
> >  #:negate #\+
> >  #:terms
> > "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"))
> >
> > (parameterize ((representation rep)
> >(digits 10))
> >   (let ((n (/ -125382661425156036913657 101559956668416)))
> > (let ((s (->string n)))
> >   (displayln s)
> >   (let ((n* (->number s)))
> > (= n n*)
> > +KF12OI!4FZZZXRSP
> > #t
> >>
> >
> > This may be pointlessly more flexible than a normal user of
> number->string
> > would want but an arbitrary alphabet is something I'd request people
> > consider for a few moments if changing number->string is open for debate.
> > Maybe it is too much flexibility for racket/base, though, which is where
> > number->string lives.
> >
> > Deren
> >
> > On Wed, Jan 4, 2017 at 11:38 AM, Gustavo Massaccesi 
> > wrote:
> >>
> >> I'm still worried about bignums. So I borrowed the idea of Mathew of
> >> splitting the number in 1/2/3 digits chucks, but I use fixnum chunks.
> >> For each fixnum chunk I calculate the string representation as usual,
> >> but as most of the calculations involve only fixnum, then It's x4
> >> faster for bignums.
> >>
> >> It's slightly slower for the DrRacket distribution and fixnums and
> >> (5%-10%).
> >>
> >> The code assumes that a 9 is a fixnum, this is true for 32 and
> >> 64 bit's racket. (In case Racket is ported in the future to a 16 bits
> >> platform, the code is still correct but slower.)
> >>
> >> DrRacket distribution of numbers
> >> number->string cpu time: 4907 real time: 4898 gc time: 77
> >> number->string* cpu time: 3703 real time: 3701 gc time: 0
> >> number->string** cpu time: 6782 real time: 6777 gc time: 16
> >> number->string*** cpu time: 3797 real time: 3796 gc time: 16
> >>
> >> Always N=123 (10 times less calls)
> >> number->string cpu time: 859 real time: 846 gc time: 0
> >> number->string* cpu time: 1688 real time: 1676 gc time: 31
> >> number->string** cpu time: 672 real time: 673 gc time: 0
> >> number->string*** cpu time: 1796 real time: 1800 gc time: 0
> >>
> >> Always N=1234567890123456789012345678901234567890 (10 times less calls)
> >> number->string cpu time: 5625 real time: 5623 gc time: 0
> >> number->string* cpu time: 102125 real time: 102100 gc time: 403
> >> number->string** cpu time: 750 real time: 748 gc time: 15
> >> number->string*** cpu time: 26343 real time: 26337 gc time: 95
> >>
> >> Gustavo
> >>
> >> ;Here is ony the code of the new function and benchmarks
> >> ;I'm not happy with the names of the auxiliary functions.
> >>
> >> (define (number->string***/fixed N short-size trim)
> >>   (define str (make-string short-size #\0))
> >>   (let loop ([N N] [i short-size])
> >> (cond
> >>   [(zero? N)
> >>(if trim
> >>(substring str i short-size)
> >>str)]
> >>   [else
> >>(define q (quotient N 10))
> >>(define r (remainder N 10))
> >>(define d (integer->char (+ r (char->integer #\0
> >>(string-set! str (- i 1) d)
> >>(loop q (- i 1))])))
> >>
> >> (define (number->string***/bignum/list N tail)
> >>   (define-values (q r) (quotient/remainder N (expt 10 9)))
> >>   (cond
> >> [(zero? q)
> >>  (cons (number->string***/fixed r 9 #t) tail)]
> >> [else
> >>  (number->string***/bignum/list q (cons (number->string***/fixed r
> >> 9 #f) tail))]))
> >>
> >> (define (number->string*** N)
> >>   (cond
> >> [(fixnum? N)
> >>  (cond
> >>[(< N 10)
> >> (string (integer->char (+ (char->integer #\0) N)))]
> >>[(< N (expt 10 9))
> >> (number->string***/fixed N 9 #t)]
> >>[else
> >> (apply string-append (number->string***/bignum/list N '()))])]
> >> [else
> >>  (apply string-append (number->string***/bignum/list N '()))]))
> >>
> >> ;(define-syntax-rule (test-it id ...) ...)
> >>
> >> (define iterations 5)
> >>
> >> (define-syntax-rule (time-it id ...)
> >>   (begin
> >> (define numbers (for/list ([i (in-range 1000)])
> >>   (sample/drr)))
> >> (begin
> >>   

Re: [racket-users] Narrow radix of string->number.

[Robby Findler]

Is changing the alphabet something that can be done post-facto with
string replacements?

Robby


On Wed, Jan 4, 2017 at 12:46 PM, Deren Dohoda  wrote:
> Some food for thought on this topic, I use base conversion for all sorts of
> silly things. To this end I require a great deal of flexibility in
> representation. When I wrote my continued-fractions package I included this
> as a separate module. Here's an example:
>
> Welcome to DrRacket, version 6.7 [3m].
> Language: racket/base, with debugging [custom]; memory limit: 2048 MB.
>> (require continued-fractions/bases)
>
> (define rep (make-representation #:radix #\!
>  #:negate #\+
>  #:terms
> "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"))
>
> (parameterize ((representation rep)
>(digits 10))
>   (let ((n (/ -125382661425156036913657 101559956668416)))
> (let ((s (->string n)))
>   (displayln s)
>   (let ((n* (->number s)))
> (= n n*)
> +KF12OI!4FZZZXRSP
> #t
>>
>
> This may be pointlessly more flexible than a normal user of number->string
> would want but an arbitrary alphabet is something I'd request people
> consider for a few moments if changing number->string is open for debate.
> Maybe it is too much flexibility for racket/base, though, which is where
> number->string lives.
>
> Deren
>
> On Wed, Jan 4, 2017 at 11:38 AM, Gustavo Massaccesi 
> wrote:
>>
>> I'm still worried about bignums. So I borrowed the idea of Mathew of
>> splitting the number in 1/2/3 digits chucks, but I use fixnum chunks.
>> For each fixnum chunk I calculate the string representation as usual,
>> but as most of the calculations involve only fixnum, then It's x4
>> faster for bignums.
>>
>> It's slightly slower for the DrRacket distribution and fixnums and
>> (5%-10%).
>>
>> The code assumes that a 9 is a fixnum, this is true for 32 and
>> 64 bit's racket. (In case Racket is ported in the future to a 16 bits
>> platform, the code is still correct but slower.)
>>
>> DrRacket distribution of numbers
>> number->string cpu time: 4907 real time: 4898 gc time: 77
>> number->string* cpu time: 3703 real time: 3701 gc time: 0
>> number->string** cpu time: 6782 real time: 6777 gc time: 16
>> number->string*** cpu time: 3797 real time: 3796 gc time: 16
>>
>> Always N=123 (10 times less calls)
>> number->string cpu time: 859 real time: 846 gc time: 0
>> number->string* cpu time: 1688 real time: 1676 gc time: 31
>> number->string** cpu time: 672 real time: 673 gc time: 0
>> number->string*** cpu time: 1796 real time: 1800 gc time: 0
>>
>> Always N=1234567890123456789012345678901234567890 (10 times less calls)
>> number->string cpu time: 5625 real time: 5623 gc time: 0
>> number->string* cpu time: 102125 real time: 102100 gc time: 403
>> number->string** cpu time: 750 real time: 748 gc time: 15
>> number->string*** cpu time: 26343 real time: 26337 gc time: 95
>>
>> Gustavo
>>
>> ;Here is ony the code of the new function and benchmarks
>> ;I'm not happy with the names of the auxiliary functions.
>>
>> (define (number->string***/fixed N short-size trim)
>>   (define str (make-string short-size #\0))
>>   (let loop ([N N] [i short-size])
>> (cond
>>   [(zero? N)
>>(if trim
>>(substring str i short-size)
>>str)]
>>   [else
>>(define q (quotient N 10))
>>(define r (remainder N 10))
>>(define d (integer->char (+ r (char->integer #\0
>>(string-set! str (- i 1) d)
>>(loop q (- i 1))])))
>>
>> (define (number->string***/bignum/list N tail)
>>   (define-values (q r) (quotient/remainder N (expt 10 9)))
>>   (cond
>> [(zero? q)
>>  (cons (number->string***/fixed r 9 #t) tail)]
>> [else
>>  (number->string***/bignum/list q (cons (number->string***/fixed r
>> 9 #f) tail))]))
>>
>> (define (number->string*** N)
>>   (cond
>> [(fixnum? N)
>>  (cond
>>[(< N 10)
>> (string (integer->char (+ (char->integer #\0) N)))]
>>[(< N (expt 10 9))
>> (number->string***/fixed N 9 #t)]
>>[else
>> (apply string-append (number->string***/bignum/list N '()))])]
>> [else
>>  (apply string-append (number->string***/bignum/list N '()))]))
>>
>> ;(define-syntax-rule (test-it id ...) ...)
>>
>> (define iterations 5)
>>
>> (define-syntax-rule (time-it id ...)
>>   (begin
>> (define numbers (for/list ([i (in-range 1000)])
>>   (sample/drr)))
>> (begin
>>   (collect-garbage)
>>   (time
>>(for* ([x (in-range iterations)]
>>   [n (in-list numbers)])
>>  (id n))
>>(printf "~a " 'id))) ...))
>>
>> (time-it number->string number->string* number->string**
>> number->string***)
>>
>> (define-syntax-rule (time-it-N N id ...)
>>   (begin
>> (begin
>>   (collect-garbage)
>>   (time
>>(for* ([x (in-range (* 100 iterations))])
>> 

Re: [racket-users] Narrow radix of string->number.

[Deren Dohoda]

Some food for thought on this topic, I use base conversion for all sorts of
silly things. To this end I require a great deal of flexibility in
representation. When I wrote my continued-fractions package I included this
as a separate module. Here's an example:

Welcome to DrRacket, version 6.7 [3m].
Language: racket/base, with debugging [custom]; memory limit: 2048 MB.
> (require continued-fractions/bases)

(define rep (make-representation #:radix #\!
 #:negate #\+
 #:terms
"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"))

(parameterize ((representation rep)
   (digits 10))
  (let ((n (/ -125382661425156036913657 101559956668416)))
(let ((s (->string n)))
  (displayln s)
  (let ((n* (->number s)))
(= n n*)
+KF12OI!4FZZZXRSP
#t
>

This may be pointlessly more flexible than a normal user of number->string
would want but an arbitrary alphabet is something I'd request people
consider for a few moments if changing number->string is open for debate.
Maybe it is too much flexibility for racket/base, though, which is where
number->string lives.

Deren

On Wed, Jan 4, 2017 at 11:38 AM, Gustavo Massaccesi 
wrote:

> I'm still worried about bignums. So I borrowed the idea of Mathew of
> splitting the number in 1/2/3 digits chucks, but I use fixnum chunks.
> For each fixnum chunk I calculate the string representation as usual,
> but as most of the calculations involve only fixnum, then It's x4
> faster for bignums.
>
> It's slightly slower for the DrRacket distribution and fixnums and
> (5%-10%).
>
> The code assumes that a 9 is a fixnum, this is true for 32 and
> 64 bit's racket. (In case Racket is ported in the future to a 16 bits
> platform, the code is still correct but slower.)
>
> DrRacket distribution of numbers
> number->string cpu time: 4907 real time: 4898 gc time: 77
> number->string* cpu time: 3703 real time: 3701 gc time: 0
> number->string** cpu time: 6782 real time: 6777 gc time: 16
> number->string*** cpu time: 3797 real time: 3796 gc time: 16
>
> Always N=123 (10 times less calls)
> number->string cpu time: 859 real time: 846 gc time: 0
> number->string* cpu time: 1688 real time: 1676 gc time: 31
> number->string** cpu time: 672 real time: 673 gc time: 0
> number->string*** cpu time: 1796 real time: 1800 gc time: 0
>
> Always N=1234567890123456789012345678901234567890 (10 times less calls)
> number->string cpu time: 5625 real time: 5623 gc time: 0
> number->string* cpu time: 102125 real time: 102100 gc time: 403
> number->string** cpu time: 750 real time: 748 gc time: 15
> number->string*** cpu time: 26343 real time: 26337 gc time: 95
>
> Gustavo
>
> ;Here is ony the code of the new function and benchmarks
> ;I'm not happy with the names of the auxiliary functions.
>
> (define (number->string***/fixed N short-size trim)
>   (define str (make-string short-size #\0))
>   (let loop ([N N] [i short-size])
> (cond
>   [(zero? N)
>(if trim
>(substring str i short-size)
>str)]
>   [else
>(define q (quotient N 10))
>(define r (remainder N 10))
>(define d (integer->char (+ r (char->integer #\0
>(string-set! str (- i 1) d)
>(loop q (- i 1))])))
>
> (define (number->string***/bignum/list N tail)
>   (define-values (q r) (quotient/remainder N (expt 10 9)))
>   (cond
> [(zero? q)
>  (cons (number->string***/fixed r 9 #t) tail)]
> [else
>  (number->string***/bignum/list q (cons (number->string***/fixed r
> 9 #f) tail))]))
>
> (define (number->string*** N)
>   (cond
> [(fixnum? N)
>  (cond
>[(< N 10)
> (string (integer->char (+ (char->integer #\0) N)))]
>[(< N (expt 10 9))
> (number->string***/fixed N 9 #t)]
>[else
> (apply string-append (number->string***/bignum/list N '()))])]
> [else
>  (apply string-append (number->string***/bignum/list N '()))]))
>
> ;(define-syntax-rule (test-it id ...) ...)
>
> (define iterations 5)
>
> (define-syntax-rule (time-it id ...)
>   (begin
> (define numbers (for/list ([i (in-range 1000)])
>   (sample/drr)))
> (begin
>   (collect-garbage)
>   (time
>(for* ([x (in-range iterations)]
>   [n (in-list numbers)])
>  (id n))
>(printf "~a " 'id))) ...))
>
> (time-it number->string number->string* number->string** number->string***)
>
> (define-syntax-rule (time-it-N N id ...)
>   (begin
> (begin
>   (collect-garbage)
>   (time
>(for* ([x (in-range (* 100 iterations))])
>  (id N))
>(printf "~a " 'id))) ...))
>
> (time-it-N 123 number->string number->string* number->string**
> number->string***)
> (time-it-N 1234567890123456789012345678901234567890 number->string
> number->string* number->string** number->string***)
> ;---
>
>
> On Sun, Jan 1, 2017 at 8:01 PM, Robby Findler
> 

Re: [racket-users] Narrow radix of string->number.

[Gustavo Massaccesi]

I'm still worried about bignums. So I borrowed the idea of Mathew of
splitting the number in 1/2/3 digits chucks, but I use fixnum chunks.
For each fixnum chunk I calculate the string representation as usual,
but as most of the calculations involve only fixnum, then It's x4
faster for bignums.

It's slightly slower for the DrRacket distribution and fixnums and (5%-10%).

The code assumes that a 9 is a fixnum, this is true for 32 and
64 bit's racket. (In case Racket is ported in the future to a 16 bits
platform, the code is still correct but slower.)

DrRacket distribution of numbers
number->string cpu time: 4907 real time: 4898 gc time: 77
number->string* cpu time: 3703 real time: 3701 gc time: 0
number->string** cpu time: 6782 real time: 6777 gc time: 16
number->string*** cpu time: 3797 real time: 3796 gc time: 16

Always N=123 (10 times less calls)
number->string cpu time: 859 real time: 846 gc time: 0
number->string* cpu time: 1688 real time: 1676 gc time: 31
number->string** cpu time: 672 real time: 673 gc time: 0
number->string*** cpu time: 1796 real time: 1800 gc time: 0

Always N=1234567890123456789012345678901234567890 (10 times less calls)
number->string cpu time: 5625 real time: 5623 gc time: 0
number->string* cpu time: 102125 real time: 102100 gc time: 403
number->string** cpu time: 750 real time: 748 gc time: 15
number->string*** cpu time: 26343 real time: 26337 gc time: 95

Gustavo

;Here is ony the code of the new function and benchmarks
;I'm not happy with the names of the auxiliary functions.

(define (number->string***/fixed N short-size trim)
  (define str (make-string short-size #\0))
  (let loop ([N N] [i short-size])
(cond
  [(zero? N)
   (if trim
   (substring str i short-size)
   str)]
  [else
   (define q (quotient N 10))
   (define r (remainder N 10))
   (define d (integer->char (+ r (char->integer #\0
   (string-set! str (- i 1) d)
   (loop q (- i 1))])))

(define (number->string***/bignum/list N tail)
  (define-values (q r) (quotient/remainder N (expt 10 9)))
  (cond
[(zero? q)
 (cons (number->string***/fixed r 9 #t) tail)]
[else
 (number->string***/bignum/list q (cons (number->string***/fixed r
9 #f) tail))]))

(define (number->string*** N)
  (cond
[(fixnum? N)
 (cond
   [(< N 10)
(string (integer->char (+ (char->integer #\0) N)))]
   [(< N (expt 10 9))
(number->string***/fixed N 9 #t)]
   [else
(apply string-append (number->string***/bignum/list N '()))])]
[else
 (apply string-append (number->string***/bignum/list N '()))]))

;(define-syntax-rule (test-it id ...) ...)

(define iterations 5)

(define-syntax-rule (time-it id ...)
  (begin
(define numbers (for/list ([i (in-range 1000)])
  (sample/drr)))
(begin
  (collect-garbage)
  (time
   (for* ([x (in-range iterations)]
  [n (in-list numbers)])
 (id n))
   (printf "~a " 'id))) ...))

(time-it number->string number->string* number->string** number->string***)

(define-syntax-rule (time-it-N N id ...)
  (begin
(begin
  (collect-garbage)
  (time
   (for* ([x (in-range (* 100 iterations))])
 (id N))
   (printf "~a " 'id))) ...))

(time-it-N 123 number->string number->string* number->string**
number->string***)
(time-it-N 1234567890123456789012345678901234567890 number->string
number->string* number->string** number->string***)
;---


On Sun, Jan 1, 2017 at 8:01 PM, Robby Findler
 wrote:
> I'm skeptical of an unbounded cache.
>
> If we go by the sample from DrRacket's start up, then we don't really
> need a cache to do better than the built-in number->string. Below is
> some code that takes the version I had earlier with what I understood
> to be Gustavo's suggestions and then just does better on the fixnums
> between 0 and 9. I then changed the random inputs to sample from the
> distribution that DrRacket demonstrated and you won't be surprised to
> learn that this does better than having a cache. Below is the code.
>
> I also tried to collect the arguments to number->string during
> rebuilding all of the .zo files. Of the first 2.3 million calls about
> 99.5% of them were exact integers between 0 and 9 so probably this is
> the only optimization we need to do. (My sampling method turned out to
> be noisy, tho, but I don't think it affects the results.)
>
> ... unless someone comes up with some other benchmark or app we care about?
>
> Robby
>
> #lang racket
> (require (for-syntax syntax/parse))
>
> (define-syntax (mk-sample stx)
>   (syntax-parse stx
> [(_ (value:exact-nonnegative-integer
> occurrences:exact-nonnegative-integer) ...)
>  (define-values (cond-clauses count)
>(for/fold ([other-cases '()]
>   [so-far 0])
>  ([value (in-list (syntax->list #'(value ...)))]
>   [occurrences (in-list (syntax->list 

Re: [racket-users] Narrow radix of string->number.

[Robby Findler]

I'm skeptical of an unbounded cache.

If we go by the sample from DrRacket's start up, then we don't really
need a cache to do better than the built-in number->string. Below is
some code that takes the version I had earlier with what I understood
to be Gustavo's suggestions and then just does better on the fixnums
between 0 and 9. I then changed the random inputs to sample from the
distribution that DrRacket demonstrated and you won't be surprised to
learn that this does better than having a cache. Below is the code.

I also tried to collect the arguments to number->string during
rebuilding all of the .zo files. Of the first 2.3 million calls about
99.5% of them were exact integers between 0 and 9 so probably this is
the only optimization we need to do. (My sampling method turned out to
be noisy, tho, but I don't think it affects the results.)

... unless someone comes up with some other benchmark or app we care about?

Robby

#lang racket
(require (for-syntax syntax/parse))

(define-syntax (mk-sample stx)
  (syntax-parse stx
[(_ (value:exact-nonnegative-integer
occurrences:exact-nonnegative-integer) ...)
 (define-values (cond-clauses count)
   (for/fold ([other-cases '()]
  [so-far 0])
 ([value (in-list (syntax->list #'(value ...)))]
  [occurrences (in-list (syntax->list #'(occurrences ...)))])
 (define next-count (+ so-far (syntax-e occurrences)))
 (values (cons #`[(< x #,next-count) #,value] other-cases)
 next-count)))
 #`(λ ()
 (define x (random #,count))
 (cond #,@(reverse cond-clauses)))]))

(define sample/drr
  (mk-sample
   (0 2399)
   (1 8116)
   (2 4278)
   (3 2196)
   (4 1346)
   (5 901)
   (6 364)
   (7 230)
   (8 106)
   (9 96)
   (10 42)
   (11 5)
   (12 3)
   (72 1)
   (100 34)
   (241 1)))

(define number->string**
  (let ([digits (list->vector (string->list "0123456789"))]
[cache (make-hasheqv)])
(λ (N)
  (hash-ref! cache N
 (λ ()
   (list->string
(let loop ([N N][acc empty])
  (define q (quotient N 10))
  (define next-acc (cons (vector-ref digits
(remainder N 10)) acc))
  (if (zero? q)
  next-acc
  (loop q next-acc)


(define (number->string* N)
  (cond [(and (exact-nonnegative-integer? N) (< N 10))
 (string (integer->char (+ (char->integer #\0) N)))]
[else
 (let* ([short-size 10]
[str (make-string short-size)])
   (let loop ([N N] [digits null] [i short-size])
 (cond
   [(zero? N)
(if (<= i 0)
(if (null? digits)
str
(string-append (apply string digits) str))
(substring str i short-size))]
   [else
(define q (quotient N 10))
(define r (remainder N 10))
(define d (integer->char (+ r (char->integer #\0
(cond
  [(<= i 0)
   (loop q (cons d digits) i)]
  [else
   (string-set! str (- i 1) d)
   (loop q '() (- i 1))])])))]))

(define-syntax-rule (test-it id ...)
  (begin
(module+ test
  (require rackunit)
  (check-equal? (id 1234567890987654321)
(number->string 1234567890987654321))
  (for ([x (in-range 1)])
(check-equal? (id x )
  (number->string x ...))

(test-it number->string**)
(test-it number->string*)

(define iterations 1)

(define-syntax-rule (time-it id ...)
  (begin
(define numbers (for/list ([i (in-range 1000)])
  (sample/drr)))
(begin
  (collect-garbage)
  (time
   (for* ([x (in-range iterations)]
  [n (in-list numbers)])
 (id n))
   (printf "~a " 'id))) ...))

(time-it number->string number->string* number->string**)

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Narrow radix of string->number.

[Matthew Butterick]

> On Dec 31, 2016, at 12:05 PM, Robby Findler  
> wrote:
> 
> But this introduces an additional cost that's a little bit more
> troublesome to measure. Specifically, each namespace that instantiates
> `racket/base` will now take a tiny bit more space and take a tiny bit
> longer to initialize. 

> As one data point, here's a histogram of the 20k or so calls to
> number->string that happen during the start up of DrRacket (first
> entry in each list is the argument passed to number->string and the
> second is the number of times that call happened)

Hmm, well if the distribution of inputs is that imbalanced, perhaps this is the 
better cheat:

; 100,000 conversions of 100 random integers < 123
cpu time: 779 real time: 791 gc time: 16; number->string
cpu time: 769 real time: 771 gc time: 13; number->string**

; 100,000 conversions of 100 random integers < 123456
cpu time: 1365 real time: 1384 gc time: 22  ; number->string
cpu time: 941 real time: 955 gc time: 13; number->string**

; 100,000 conversions of 100 random integers < 123456789
cpu time: 1891 real time: 1904 gc time: 26  ; number->string
cpu time: 963 real time: 979 gc time: 17; number->string**


;
#lang racket

(define number->string**
  (let ([digits (list->vector (string->list "0123456789"))]
[cache (make-hasheqv)])
(λ (N)
  (hash-ref! cache N
 (λ ()
   (list->string
(let loop ([N N][acc empty])
  (define q (quotient N 10))
  (define next-acc (cons (vector-ref digits (remainder N 
10)) acc))
  (if (zero? q)
  next-acc
  (loop q next-acc)

(define-syntax-rule (test-it id ...)
  (begin
(module+ test
  (require rackunit)
  (check-equal? (id 1234567890987654321)
(number->string 1234567890987654321))
  (for ([x (in-range 1)])
   (check-equal? (id x )
 (number->string x ...))

(test-it number->string**)

(define iterations 10)

(define-syntax-rule (time-it number-to-convert id ...)
  (begin
(define numbers (for/list ([i (in-range 100)])
  (random number-to-convert)))
(begin
  (collect-garbage)
  (time
   (for* ([x (in-range iterations)]
  [n (in-list numbers)])
 (id n ...))

(time-it 123 number->string number->string**)
(time-it 123456 number->string number->string**)
(time-it 123456789 number->string number->string**)

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Narrow radix of string->number.

[Robby Findler]

(PS: those are the calls only in the special case that a fixnum was
supplied and it was base 10 or base 16.)

On Sat, Dec 31, 2016 at 2:05 PM, Robby Findler
 wrote:
> As one data point, here's a histogram of the 20k or so calls to
> number->string that happen during the start up of DrRacket (first
> entry in each list is the argument passed to number->string and the
> second is the number of times that call happened):
>
> '((0 2399)
>   (1 8116)
>   (2 4278)
>   (3 2196)
>   (4 1346)
>   (5 901)
>   (6 364)
>   (7 230)
>   (8 106)
>   (9 96)
>   (10 42)
>   (11 5)
>   (12 3)
>   (72 1)
>   (100 34)
>   (241 1))
>
> Two others apps we care about are building the documentation and
> recompiling all of the .zos in the main distribution.
>
> (But we might also just decide that we don't care if number->string is
> fast, too.)
>
> Robby
>
>
> On Sat, Dec 31, 2016 at 1:57 PM, Robby Findler
>  wrote:
>> On Sat, Dec 31, 2016 at 12:57 PM, Matthew Butterick  wrote:
>>> Is it cheating to avoid divisions by using table lookups?
>>
>> Everything is fair in love, war, and benchmarking. :)
>>
>> But this introduces an additional cost that's a little bit more
>> troublesome to measure. Specifically, each namespace that instantiates
>> `racket/base` will now take a tiny bit more space and take a tiny bit
>> longer to initialize. I think this would boil down to a judgment call,
>> but a first step before making that judgment call would be to get some
>> benchmarks we think are representative (that actually call
>> number->string) and figure out what inputs they supply (and how often
>> they supply them). Based on that, then minimize the size of the table
>> and then I'd say that we're in a good position to make the judgment
>> call.
>>
>> Robby

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Narrow radix of string->number.

[Robby Findler]

As one data point, here's a histogram of the 20k or so calls to
number->string that happen during the start up of DrRacket (first
entry in each list is the argument passed to number->string and the
second is the number of times that call happened):

'((0 2399)
  (1 8116)
  (2 4278)
  (3 2196)
  (4 1346)
  (5 901)
  (6 364)
  (7 230)
  (8 106)
  (9 96)
  (10 42)
  (11 5)
  (12 3)
  (72 1)
  (100 34)
  (241 1))

Two others apps we care about are building the documentation and
recompiling all of the .zos in the main distribution.

(But we might also just decide that we don't care if number->string is
fast, too.)

Robby


On Sat, Dec 31, 2016 at 1:57 PM, Robby Findler
 wrote:
> On Sat, Dec 31, 2016 at 12:57 PM, Matthew Butterick  wrote:
>> Is it cheating to avoid divisions by using table lookups?
>
> Everything is fair in love, war, and benchmarking. :)
>
> But this introduces an additional cost that's a little bit more
> troublesome to measure. Specifically, each namespace that instantiates
> `racket/base` will now take a tiny bit more space and take a tiny bit
> longer to initialize. I think this would boil down to a judgment call,
> but a first step before making that judgment call would be to get some
> benchmarks we think are representative (that actually call
> number->string) and figure out what inputs they supply (and how often
> they supply them). Based on that, then minimize the size of the table
> and then I'd say that we're in a good position to make the judgment
> call.
>
> Robby

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Narrow radix of string->number.

[Robby Findler]

On Sat, Dec 31, 2016 at 12:57 PM, Matthew Butterick  wrote:
> Is it cheating to avoid divisions by using table lookups?

Everything is fair in love, war, and benchmarking. :)

But this introduces an additional cost that's a little bit more
troublesome to measure. Specifically, each namespace that instantiates
`racket/base` will now take a tiny bit more space and take a tiny bit
longer to initialize. I think this would boil down to a judgment call,
but a first step before making that judgment call would be to get some
benchmarks we think are representative (that actually call
number->string) and figure out what inputs they supply (and how often
they supply them). Based on that, then minimize the size of the table
and then I'd say that we're in a good position to make the judgment
call.

Robby

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Narrow radix of string->number.

[Matthew Butterick]

> On Dec 31, 2016, at 10:57 AM, Matthew Butterick  wrote:
> 
>> I started with Ryan's code from `~r` and tried to emulate some special
>> cases I see the C code (and didn't worry about negative numbers) and
>> ended up with something 4-5x slower than the C code version. :(  Code
>> follows.
> 
> 
> Is it cheating to avoid divisions by using table lookups? 


Whoops, my `test-it` macro had a typo in it. Here are results for different 
number lengths. 

; convert 123
cpu time: 893 real time: 925 gc time: 21; number->string
cpu time: 3306 real time: 3376 gc time: 74  ; number->string* (Findler 
algorithm)
cpu time: 583 real time: 614 gc time: 26; number->string** (table 
lookup)

; convert 123456
cpu time: 1393 real time: 1433 gc time: 38  ; number->string
cpu time: 5474 real time: 5544 gc time: 86  ; number->string* (Findler 
algorithm)
cpu time: 1325 real time: 1423 gc time: 79  ; number->string** (table 
lookup)

; convert 123456789
cpu time: 1950 real time: 1980 gc time: 46  ; number->string
cpu time: 7835 real time: 7882 gc time: 97  ; number->string* (Findler 
algorithm)
cpu time: 2293 real time: 2532 gc time: 174 ; number->string** (table 
lookup)


;;
#lang racket

(define (number->string* N)
 (cond [(zero? N)
(string #\0)]
   [else
(let* ([short-size 10]
   [str (make-string short-size)])
  (let loop ([N N] [digits null] [i short-size])
(cond
  [(zero? N)
   (if (<= i 0)
   (if (null? digits)
   str
   (string-append (apply string digits) str))
   (substring str i short-size))]
  [else
   (define-values (q r) (quotient/remainder N 10))
   (define d (integer->char (+ r (char->integer #\0
   (cond
 [(<= i 0)
  (loop q (cons d digits) i)]
 [else
  (string-set! str (- i 1) d)
  (loop q '() (- i 1))])])))]))


(define-syntax-rule (digit-vector id ...)
  (for*/vector ([id (in-range 10)] ...)
   (append (string->list (number->string id)) ...)))

(define number->string**
 (let ([digits (digit-vector i)]
   [double-digits (digit-vector i j)]
   [triple-digits (digit-vector i j k)])
   (λ (N)
 (list->string
  (let loop ([N N])
(cond
  [(< N 10) (vector-ref digits N)]
  [(< N 100) (vector-ref double-digits N)]
  [(< N 1000) (vector-ref triple-digits N)]
  [else
   (append (loop (quotient N 1000))
   (vector-ref triple-digits (remainder N 1000)))]))

(define-syntax-rule (test-it id ...)
 (begin
   (module+ test
 (require rackunit)
 (check-equal? (id 1234567890987654321)
   (number->string 1234567890987654321))
 (for ([x (in-range 1)])
  (check-equal? (id x )
(number->string x ...))

(test-it number->string* number->string**)

(define iterations 1000)

(define-syntax-rule (time-it number-to-convert id ...)
 (begin
   (begin
 (collect-garbage)
 (time
  (for ([x (in-range iterations)])
   (id number-to-convert ...))

(time-it 123 number->string number->string* number->string**)
(time-it 123456 number->string number->string* number->string**)
(time-it 123456789 number->string number->string* number->string**)

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Narrow radix of string->number.

[Gustavo Massaccesi]

I'm not too worried about a x4 slowdown in number->string because I
don't expect it to be in a tight loop, but it would be nice that it
were faster.

I made some tests. (You must change the 100 to number-to-convert in
your sample program.)

I made a new function number->string**, replacing
(define-values (q r) (quotient/remainder N 10))
with
(define q (quotientr N 10))
(define r (remainder N 10))

The problem is that quotient/remainder is very slow for fixnums (IIRC
it can be JIT-inlined).


I increased the number of iterations x10, so the run time is a few seconds:
(define iterations 1000) ; x10 of original number
(define number-to-convert 123)
cpu time: 1734 real time: 1740 gc time: 0   ;number->string
cpu time: 7234 real time: 7258 gc time: 0   ;number->string*
cpu time: 3578 real time: 3580 gc time: 31  ;number->string**

So the new function is only x2 times slower. Perhaps tweaking it for
fixnums can get a 10% or 20% increase of speed.


But for bignum the story is totally different. Here I used the
original number of iterations because everything is much slower.
(define iterations 100) ; original number
(define number-to-convert 1234567890123456789012345678901234567890)
cpu time: 1125 real time: 1128 gc time: 16   ;number->string
cpu time: 14828 real time: 14818 gc time: 94   ;number->string*
cpu time: 20735 real time: 20736 gc time: 222  ;number->string**

The new function is even slower. But both functions are very slow
(x15) in comparison with the C version.

(Note: To compare the times remember to consider the x10 factor in the
iterations, for example the run time of the original C function is
proportional to 1734 vs 11250, as expected it's faster for the
fixnum.)

Gustavo



On Wed, Dec 28, 2016 at 5:41 PM, Robby Findler
 wrote:
> I started with Ryan's code from `~r` and tried to emulate some special
> cases I see the C code (and didn't worry about negative numbers) and
> ended up with something 4-5x slower than the C code version. :(  Code
> follows.
>
> Robby
>
> #lang racket
> (define (number->string* N)
>   (cond [(zero? N)
>  (string #\0)]
> [else
>  (let* ([short-size 10]
> [str (make-string short-size)])
>(let loop ([N N] [digits null] [i short-size])
>  (cond
>[(zero? N)
> (if (<= i 0)
> (if (null? digits)
> str
> (string-append (apply string digits) str))
> (substring str i short-size))]
>[else
> (define-values (q r) (quotient/remainder N 10))
> (define d (integer->char (+ r (char->integer #\0
> (cond
>   [(<= i 0)
>(loop q (cons d digits) i)]
>   [else
>(string-set! str (- i 1) d)
>(loop q '() (- i 1))])])))]))
>
> (module+ test
>   (require rackunit)
>   (check-equal? (number->string* 1234567890987654321)
> (number->string 1234567890987654321))
>   (for ([x (in-range 1000)])
> (check-equal? (number->string* x )
>   (number->string x
>
> (define iterations 100)
> (define number-to-convert 123)
>
> (collect-garbage)
> (time
>  (for ([x (in-range iterations)])
>(number->string 100)))
>
> (collect-garbage)
> (time
>  (for ([x (in-range iterations)])
>(number->string* number-to-convert)))
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Narrow radix of string->number.

[Robby Findler]

I started with Ryan's code from `~r` and tried to emulate some special
cases I see the C code (and didn't worry about negative numbers) and
ended up with something 4-5x slower than the C code version. :(  Code
follows.

Robby

#lang racket
(define (number->string* N)
  (cond [(zero? N)
 (string #\0)]
[else
 (let* ([short-size 10]
[str (make-string short-size)])
   (let loop ([N N] [digits null] [i short-size])
 (cond
   [(zero? N)
(if (<= i 0)
(if (null? digits)
str
(string-append (apply string digits) str))
(substring str i short-size))]
   [else
(define-values (q r) (quotient/remainder N 10))
(define d (integer->char (+ r (char->integer #\0
(cond
  [(<= i 0)
   (loop q (cons d digits) i)]
  [else
   (string-set! str (- i 1) d)
   (loop q '() (- i 1))])])))]))

(module+ test
  (require rackunit)
  (check-equal? (number->string* 1234567890987654321)
(number->string 1234567890987654321))
  (for ([x (in-range 1000)])
(check-equal? (number->string* x )
  (number->string x

(define iterations 100)
(define number-to-convert 123)

(collect-garbage)
(time
 (for ([x (in-range iterations)])
   (number->string 100)))

(collect-garbage)
(time
 (for ([x (in-range iterations)])
   (number->string* number-to-convert)))

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Narrow radix of string->number.

[Robby Findler]

On Wed, Dec 28, 2016 at 12:08 AM, Matthew Butterick  wrote:
> FWIW Racket's own `~r` function already accepts radixes (radices? radishes?) 
> up to 36.

Ah, good point! I think it makes a lot of sense to do exactly what it
does (or, if people find useful things, something more (but maybe not
something different)).

One thing that would also be nice here would be to move the
implementation(s) out of C.

Robby

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Narrow radix of string->number.

[Matthew Butterick]

> On Dec 27, 2016, at 1:57 PM, Robby Findler  
> wrote:
> 
> The main thing I worry about is that there are standard conventions
> that we're missing from other language families. Would someone mind
> investigating a few other, popular languages


FWIW Racket's own `~r` function already accepts radixes (radices? radishes?) up 
to 36.

Personally I'm a fan of base 62 (used in short-URL generators, such as that 
employed by beautifulracket.com ).


[1] 
https://docs.racket-lang.org/reference/strings.html?q=~x#%28def._%28%28lib._racket%2Fformat..rkt%29._~7er%29%29
 




-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Narrow radix of string->number.

[Robby Findler]

The main thing I worry about is that there are standard conventions
that we're missing from other language families. Would someone mind
investigating a few other, popular languages to see what they do so
that can be taken into account? And perhaps pointing to the docs or
showing some example code? (If we don't like what they do, we don't
have to do it that way, but gratuitous difference seems unwise.)

Robby


On Tue, Dec 27, 2016 at 3:54 PM, Vincent St-Amour
 wrote:
> I don't see any reason why not, and it doesn't seem (by the discussion)
> that anyone is strongly against.
>
> Would you be interested in submitting a pull request to extend
> `string->number`? You'd probably want to extend `number->string` as
> well, and possibly others.
>
> Vincent
>
>
>
> On Thu, 22 Dec 2016 05:51:06 -0500,
> Dmitry Igrishin wrote:
>>
>> >> Why restricting it to 36?
>> >
>> >
>> > I guess that the original poster implied 10 digits + 26 Latin letters for
>> > notation.
>> True. And this notation is used in standard numeric conversion
>> functions in C, C++ and Common Lisp. So, I think it's reasonable to
>> use it in Racket.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to racket-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Narrow radix of string->number.

[Vincent St-Amour]

I don't see any reason why not, and it doesn't seem (by the discussion)
that anyone is strongly against.

Would you be interested in submitting a pull request to extend
`string->number`? You'd probably want to extend `number->string` as
well, and possibly others.

Vincent



On Thu, 22 Dec 2016 05:51:06 -0500,
Dmitry Igrishin wrote:
> 
> >> Why restricting it to 36?
> >
> >
> > I guess that the original poster implied 10 digits + 26 Latin letters for
> > notation.
> True. And this notation is used in standard numeric conversion
> functions in C, C++ and Common Lisp. So, I think it's reasonable to
> use it in Racket.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: [racket-users] Narrow radix of string->number.

[Jos Koot]

You have a valid argument here,
Jos 

-Original Message-
From: racket-users@googlegroups.com [mailto:racket-users@googlegroups.com] On 
Behalf Of Dmitry Pavlov
Sent: jueves, 22 de diciembre de 2016 11:30
To: racket-users@googlegroups.com
Subject: Re: [racket-users] Narrow radix of string->number.



On 12/21/2016 11:33 PM, Jos Koot wrote:
>
> Or up to 60, 60 even nowadays being a commonly used radix in time notation.

FWIW, the radix of the time notation does not seem that simple to me.
I would rather say it is a combined notation.

base-10 (days), base-60 (up to 24 hours+minutes+seconds), base-10 (fractions of 
a second)

or

base-60 (up to 360 degrees+minutes+seconds), base-10 (fractions of a second)



> Why restricting it to 36?

I guess that the original poster implied 10 digits + 26 Latin letters for 
notation.



Best regards,

Dmitry

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Narrow radix of string->number.

[Dmitry Igrishin]

>> Why restricting it to 36?
>
>
> I guess that the original poster implied 10 digits + 26 Latin letters for
> notation.
True. And this notation is used in standard numeric conversion
functions in C, C++ and Common Lisp. So, I think it's reasonable to
use it in Racket.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Narrow radix of string->number.

[Dmitry Pavlov]

On 12/21/2016 11:33 PM, Jos Koot wrote:


Or up to 60, 60 even nowadays being a commonly used radix in time notation.


FWIW, the radix of the time notation does not seem that simple to me.
I would rather say it is a combined notation.

base-10 (days), base-60 (up to 24 hours+minutes+seconds), base-10 (fractions of 
a second)

or

base-60 (up to 360 degrees+minutes+seconds), base-10 (fractions of a second)




Why restricting it to 36?


I guess that the original poster implied 10 digits + 26 Latin letters for 
notation.



Best regards,

Dmitry

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: [racket-users] Narrow radix of string->number.

[Jos Koot]

 
Or up to 60, 60 even nowadays being a commonly used radix in time notation.
Why restricting it to 36?
Jos

-Original Message-
From: racket-users@googlegroups.com [mailto:racket-users@googlegroups.com] On 
Behalf Of Dmitry Igrishin
Sent: miércoles, 21 de diciembre de 2016 20:41
To: Racket Users
Subject: [racket-users] Narrow radix of string->number.

Hello,

Why the radix of string->number is narrowed to (2 16)? Shouldn't it be
(2 36)? There is a real need for it.

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.