On Mon, 7 May 2018 12:00:30 -0700 (PDT) Xiongqi ZHANG <zhangxion...@gmail.com> wrote:
> Ah ha, you used floating points in converting my variant. What's the > reason behind that? I have done it to ensure that this program is a valid Ruby and Crystal code at the same time. With the only difference that Crystal is ~40x times faster. In Ruby all integers can be arbitrarily large by default and no overflow may ever happen. In Crystal the default integer data type is 32-bit. If nothing is done about this, then the program will be working incorrectly when compiled by the Crystal compiler because of overflows. This can be resolved by explicitly adding 64-bit type annotations to the code (the use of the ".to_i64" method), but then the program won't be a valid Ruby code anymore. So as a workaround, I can use a 64-bit floating point data type, which can losslessly represent up to something like 52-bit integers and this is good enough to avoid overflows here. The floating point version is slightly slower than the int64 version, but nothing really dramatic. Of course, there is no need to use exactly the same source file for both Ruby and Crystal. Just like there is no need to have the same source file for Python2 and Python3 or for C and C++. But in some (or many?) cases this is possible, and I thought that it was a useful demonstration. Any Ruby enthusiasts may try https://play.crystal-lang.org and compile/run snippets of Crystal code there just to see what works the same and what is different between Ruby and Crystal. -- Best regards, Siarhei Siamashka -- You received this message because you are subscribed to the Google Groups "Google Code Jam" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-code+unsubscr...@googlegroups.com. To post to this group, send email to google-code@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-code/20180508011332.777c11c0%40i7. For more options, visit https://groups.google.com/d/optout.
