On 3 Nov. 2017 5:55 pm, "Andy Green" <andy@warmcat.com> wrote: On 11/03/2017 03:40 PM, Matthew Kerwin wrote: > > > On 3 November 2017 at 17:13, Andy Green <andy@warmcat.com <mailto: > andy@warmcat.com>> wrote: > ... Willy is proposing some kind of capability profiles with fixed limits at 32-bit etc: that's what you had replied to. I don't think that's going to give a nice result. There seems to be a basic choice to have some strict integer limit, or to avoid it by having a "stretchy" way to have arbitrary-sized ints. If people are OK with a strict limit, 64-bit is very widely supported at C level even down on "ESP8266" Willy mentioned. I think a 32-bit limit is a non-starter. If your implementation has trouble dealing with certain values (having to > rely on more-complicated data structures, algorithms, memory allocations, > etc), and you want to optimise for throughput/simplicity/etc., and the > header is clearly defined to have a limit within what you can handle > natively, why not be able to take advantage of that? I'm thinking of > JavaScript (including Node.js) here, by the way, which stores all its > numbers in IEEE 754 floats. > No, floats are not ints and cannot reliably be converted into them. They are a lossy approximation format. For example you cannot put key BIGINTs into floats. That they are stored in floats is an implementation detail, the ES6 spec says that safe JavaScript integers are limited to ~32 bit signed values (I think, I haven't read it lately). If there's demand for floats of course they can also be handled, but they can't be conflated with integers just 'cos node. The conflation was mine, the 32 bit limit is Node's. Cheers -- Matthew Kerwin
Received on Friday, 3 November 2017 08:17:42 UTC