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

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

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

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

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

> 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

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

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

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

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

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

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

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

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.

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

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

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

> 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

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

(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

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

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

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

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,

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

> 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

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

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

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

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)

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

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

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

> 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

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

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?

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

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

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

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

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

>> 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

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),

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

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