Ad
  • Default User Avatar

    I think, there is no "clever" solution, only implimentations with brainDuck dependenses =)

  • Default User Avatar
  • Default User Avatar

    closing this issue as a duplicate, to keep the newer one that mentions JS as well

  • Default User Avatar

    done, but this is pointless, there are still many loopholes

  • Default User Avatar

    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.

  • Custom User Avatar

    it's weird because it's the same number of digits

    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.

  • Custom User Avatar

    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.

  • Default User Avatar

    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.

  • Custom User Avatar

    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.

  • Default User Avatar

    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?

  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    Read the post below yours, he asked the same question. And please mark your post as having spoiler content next time too.

  • Default User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    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...