5 ms·
> literally only a single numeric type that is a 64-bit float After dealing with JavaScript and Lua, I am ready to call this a complete anti-pattern. To be a
by zeveb 10y ago
> literally only a single numeric type that is a 64-bit float
After dealing with JavaScript and Lua, I am ready to call this a complete anti-pattern. To be a good language, it must support at least one size each of machine floats and ints. To be really good, it should be possible for me to choose any size of machine-supported floats and ints. To be great, it should also support rationals, fixed-point and complex numbers out of the box.
Giving me floats but not ints just doesn't cut it. It works, in a kind of shoddy way, but … it's tasteless.
If you don't provide me with bitwise operations (earlier versions of Lua, I'm looking at you), then you don't get to call yourself a real language.
For a database, though, I suppose one could always store integers as their string representation. But please, no language ever do this again ever.
- ScottBurson 10y agoThis anti-pattern -- floats as the sole numeric type -- goes all the way back to BASIC in 1964. It's just as bad an idea now as it was then.
- SamReidHughes 10y agoThe only concrete problem anybody's mentioned with floats is that they only have 53 bits of precision, and some people need their integers to go up to 64 bits, or more.
- sedachv 10y agoWhat are you going to do for currency amounts if you do not have ints ? Strings with numbers in them?
- SamReidHughes 10y agoFloating point numbers handle integer values in the range -2^53..2^53 just fine.
- jnordwick 10y agoYou can definitely get around the currency issue by scaling yourself, but things like the timestamp issues (fractional seconds since the epoch with millisecond precision) are a little more problematic. You basically have to roll your own datetime format and lose any db support. Databases are about data after all. Why not have a rich way to describe it?
- SamReidHughes 10y agoI think so too. But I don't think, say, not having a 32-bit integer type, and 16-bit and 8-bit integers, is a big problem, if you've got doubles. Maybe it's a nice-to-have. A 64 bit type or bigint would add real value.
- jnordwick 10y agoI think as far as number types, you NEED (in the you should be considered seriously broken even if you can hobble along without) to have: - a 64-bit float - a 64-bit int everything else can be emulated in code from there and you can play all the encoding games you want to save space when you don't have to use it. This covers 99.999% of the use cases you reasonably see. From there, I would argue, you should also have: - a bit and byte - 32-bit ints - 32-bit float - 128-bit int (once you add UUIDs you might as well make them full numerics citizens). If I were doing a modern database, I'd have the kitchen sink as a type full numerics from 8 to 128 bit both signed and unsigned int and all supported hardware float sizes. I'd probably even have a 512-bit AVX type just to see what people would use it for.
- Dylan16807 10y agoWhy do you NEED a 64 bit int? Why not 32 bit? You're not storing pointers in a database. (And then you can implement your 32 bit int in terms of the 53 bits of int-capacity in a double.)
- jnordwick 10y ago
- overgard 10y agoHere's two actual concrete problems: efficiency and type safety. Indexing an array with "1.5" doesn't seem awesome, nor does using 8 bytes for a double where a 1 byte int would do fine.
- SamReidHughes 10y agoA double with integral value in 127..127 already takes 2 bytes to store in rethinkdb (the first being a tag distinguishing between array, object, string, etc), compared to some random double's 9 bytes. The type safety advantages of distinguishing doubles from integers are pretty minimal in a database, because you'd need a schema for that anyway, and the benefits of that far outweighs the add-on benefits of having type checked query logic.