Loading collection data...
Collections are a way for you to organize kata so that you can create your own training routines. Every collection you create is public and automatically sharable with other warriors. After you have added a few kata to a collection you and others can train on the kata contained within the collection.
Get started now by creating a new collection.
I think, there is no "clever" solution, only implimentations with brainDuck dependenses =)
closing this issue as a duplicate, to keep the newer one that mentions JS as well
done, but this is pointless, there are still many loopholes
Node versions will not be restricted. The point of the kata is to implement the algorithm yourself, this is why it is 4-kyu, if you do not want to do that, skip the kata. It is a known issue that the JS version is not cheat-proof (see issues below). Completely disabling a built-in is very hard on Codewars, this kata should never have had a JS version to start with. Hopefully someday the JS version can be nuked, but I believe it is not currently possible to do that.
You assume that computer sees numbers as digits the same way as you do. For computer, it;s not the same number of digits. The 11 which got lost is exactly the digits which did not fit into the place where the number is located.
Do NOT use
parseInt
, that's the whole point of this kata. This has nothing to do with JavaScript and the only "issue" is on your end.it's weird because it's the same number of digits, but the answer is wrong. I'm not sure how that happens. That seems like a bit of an issue. Of course, my instructor told me they wrote javascript in a few weeks or something, so maybe I'm expecting too much refinement.
It's difficult to tell exactly without knowing what you test and how, but generally the thing is (warning: simplifications and thought shortcuts ahead): the basic type of numbers in JS has a limited size in memory. When you multiply two large numbers, it's possible that the result is so large it will not fit into the designated space in memory. When this happens, what JS does is to keep the high part of the number, and lose the lower part of the number. The difference of 11 you see is the part which got lost because it couldnt be crammed into the space the number was located.
It's a simplification, and there are places where things are done differently. For example, numbers in JS can be bigger than in some languages, and smaller than in other languages. Some languages do not cut off large numbers and always keep them whole. Some languages do no allow for cutting off and if it should occur, they crash. Details can vary depending on circumstances.
So, I was trying to find out how large a number the system can handle in javascript. I started just multiplying numbers, but it's giving the wrong answer. It gave 343,545,875,935,755,970 as the answer to 367,574,839 * 934,628,379. It should be 343,545,875,935,755,981. That's a difference of 11. With the numbers I'm multiplying ending in 9, we know the answer has to end in 1. Why is this happening?
This comment is hidden because it contains spoiler information about the solution
Read the post below yours, he asked the same question. And please mark your post as having spoiler content next time too.
This comment is hidden because it contains spoiler information about the solution
This comment is hidden because it contains spoiler information about the solution
It means that your result is a number (in floating point notation), whereas it should be a string. Do NOT convert those strings to numbers.
Loading more items...