Re: [racket-users] Re: number->string format guarantees

Thank you Matthew. The new docs are crystal clear on what I want. Thank you. Jay On Mon, Apr 25, 2016 at 10:50 AM, Matthew Flatt wrote: > I agree that the spec for printing inexacts needs to be clarified. > > The current output format for flonums is consistent with scanf(),

Re: [racket-users] Re: number->string format guarantees

I agree that the spec for printing inexacts needs to be clarified. The current output format for flonums is consistent with scanf(), at least for non-infinity and non-NaN values, since it's produced by sprintf("%g", ...). Using "%g" means that the number sometimes prints with an "e..." part and

Re: [racket-users] Re: number->string format guarantees

Annoying that you cannot send them the floating point bits and have to rely on their (probably complex) number parsing routines! Robby On Mon, Apr 25, 2016 at 7:37 AM, Jay McCarthy wrote: > Interesting. FWIW, my particular interest is something that I can > reliably

Re: [racket-users] Re: number->string format guarantees

Perhaps you should introduce a library of functions with names that specifically point to Unix/Linux compatibility — Matthias > On Apr 25, 2016, at 8:37 AM, Jay McCarthy wrote: > > Interesting. FWIW, my particular interest is something that I can > reliably send to

Re: [racket-users] Re: number->string format guarantees

Interesting. FWIW, my particular interest is something that I can reliably send to other tools like Unix's bc or C's scanf. Going down this line, however, did make me question using `number->string` all over the place in demo Web programs. On Fri, Apr 22, 2016 at 10:22 AM, Robby Findler

Re: [racket-users] Re: number->string format guarantees

I think number->string is intended to be like `write` (ie written to be read back in hopefully without losing anything) and maybe you want something that's more in the spirit of `display`? (I.e., show something to a human in a hopefully useful format (at least that's how I see the difference

[racket-users] Re: number->string format guarantees

This is complicated by single-flonums which seem to pretty out in the reading format: (number->string 3f0) ===> "3.0f0" which is likely to look like an error to users. This makes me feel like I should never use number->string to show something to a user... which seems strange. On Wed, Apr 20,