search

disruptek / ryu

ryu for nim
MIT License
5 stars 2 forks source link

notes / questions #1

Open timotheecour opened 4 years ago

timotheecour commented 4 years ago

consider rename to nim-ryu or similar

the nimble package name can/should stay ryu, but the github repo name should probably be changed to nim-ryu otherwise it increases chances of conflict with original https://github.com/ulfjack/ryu (eg for users having forks + your package), since your package is not a fork but a port

thanks for working on this btw

status

looks good so far! not quite correct yet wrt https://github.com/nim-lang/Nim/issues/13196, eg:

  let x = 0.12345678901234567890123456789
  let j = %* x
  let y = (j.getFloat.f2s).parseJson().getFloat()
  echo x.f2s # 1.2345679e-1
  echo y.f2s # 1.2345679e-1
  doAssert x == y # currently fails

links

As I understand it, the fact that short numbers perform worse is an inherent aspect of the algorithm. Dtoa goes left to right and avoids generating too many noise digits, so the performance is better on short numbers as reflected in the table. Ryū generates an exact representation and then goes right to left removing noise digits, so the performance is better on the longest numbers. The Ryū benchmarks all focus on a random distribution of numbers, and those have on average a lot of digits.

disruptek commented 4 years ago

That's a good link, but it's also as expected, right? You don't use this to store a 4-digit decimal, right? What do you use? A string.

planetis-m commented 4 years ago

Also there is already a nim port https://github.com/LemonBoy/dtoa.nim

timotheecour commented 4 years ago

dtoa is a different algorithm (and IIUC not expected to produce the most compact stringification) but would be a great thing to compare against (eg for performance)

disruptek commented 4 years ago

@alaviss is writing a nimish version of Ryu that should deprecate this repo. So, the goal of this effort is to flesh out tests and benchmarks so that we can vet future implementations. I expect that the next implementation will be much friendlier to inclusion in the stdlib, for example.