I reported a Bignums problem maybe 6-8 months ago, I think I've run into another.
Snap thinks that 1^19 + 7^19 = 7^19. Adding Use Bignums doesn't fix it. Dropping the exponent to 18 does fix it.
In this longer version I try to set the results of the exponentiation to intermediate variables, hoping that they'll each get stored into Bignums and make it work, like maybe if Bignums only get created after all the snap Operations blocks have overflowed ints into floats.
I don't know how fast this could get fixed, but it would be awesome for me if it worked by next Wed.
I'm teaching a CS class, and the whole point of this is to show a simple program that will search through all quadruples a,b,c,w, and HALT if a^w + b^w = c^w and w>2, thus disproving Fermat's Last Theorem. But because of the Halting Problem, we know we can't just somehow analyze the program to know in a finite time whether it would halt, the best we can do is let it run, and if it runs forever (which it would, now that Fermat's Last Theorem has been proven), we'll never know if it's going to run forever or will halt after a finite time longer than however long we waited so far.
Similar for Goldbach's conjecture, assuming a primality test block
@djdolphin Confirmed. The problem is in =, not ^ or +, which give correct bignum answers. = seems to be comparing its inputs as floats? Sort of...
1+(7^19)=(7^19) is true with bignums on or off.
3+(7^19)=(7^19) is false with bignums on or off.
But 2+(7^19)=(7^19) is true with bignums on, false with off, counterintuitively.
Hmmm, so based on that, I tried forcing a string compare by pushing both sides of the = through 1-arg join, but it still didn't work right
aha! 'is identical to' works in place of '='
Awesome. I was going to suggest (JOIN X ) to prevent conversion back to number.
Yeah I'm not sure why that didn't work, is Snap! (or Snap! Bignums) like perl in that all numbers are stored as strings, and == converts to numbers for comparison?
The part about converting for = is true. All numbers stored as strings isn't, but a string of digits does count as a number when you do arithmetic on it.
I find that odd without having separate comparators for strings (like perl's eq lt le gt ge), but I guess it's the right decision to make Snap! most intuitive for newbs
Ohh, it was simpler than I supposed...
There is an error in "BigNums" block.
Function to report "=" has wrong name.
Should be reportEqual**s**: function (a, b)
Also, there is no support for new logical operators available by "relabel".
ok, I'm curious about why 'is identical to' works. The help says it's good for lists and mutability, but when comparing these bignums, does it treat them as strings = lists of chars and compare them that way? Or is it just that Bignums is not buggy for the identical reporter?
Sweet! I was able to edit the block imported into my script. I guess my imported copy is distinct from whatever lives in the library
thanks, problem solved!
Thank you! I'll fix those things for the next release.
yeah... the help is wrong. It used to be right. Now, the = predicate is useful for lists. I found out that the identical to block just checks for exactly the same things.
edit: the help is right.
yeah, just like that.
What? That's what it's supposed to do. = checks for same values in the list; IDENTICAL checks for the very same location in memory, not two copies of the same values.
that's what I meant. I just didn't know how to say it.
Oh! Duh, I'm sorry. I thought you were saying IDENTICAL checks for the same things that = checks for.
How is it wrong?
Another thing: identical to also does case-sensitive string comparisons.
