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 w
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
> 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 a
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:
>
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
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].
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'
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 bette
> 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.
>
(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
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
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 i
> 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.
>
>
>
> 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?
cpu time:
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
(def
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)
(st
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
someth
> 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 rad
I think it better to extend the radix of `string->number` and
`number->string` to 2...36(inclusive) for now, and take more time to
think about bigger ranges.
I'm not sure about a good convention for a bigger radix, like 60.
(number->string 100 60 #:symbols '("01" "02" ... "59") #:separator ":")
(n
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?
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:
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
>> 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 messag
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), b
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
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 a
26 matches
Mail list logo