Author: | ElasticDog |
---|---|
Mode: | factor |
Date: | Thu, 8 Jan 2009 02:08:12 |
! 13491207232426355523922219684951924511080915748019996427941749724410668821208806761415644080297941552075294443390858790167430762281370940029311464997594473722619612916042641934657810553384173246982085796989173506023091424520600931976373999768954158760073323437360079376560693869763716533304557573090169481921399 ! 9539724120441670384470112748238870640681578306483347281179500503959060967295949205792573386544303884369307917597991228108225837640562234235660318043154769954555533618380411985133729438843883824988097770691250942215422815204291344618089496131210531593601284610275004870689533048501285657618377623332036744871949 ! Both of the above integers return 0 incorrectly when used with number-length: : log10 ( m -- n ) log 10 log / ; : number-length ( n -- m ) log10 floor 1+ >integer ; (scratchpad) [ number-length ] bi@ --- Data stack: 0 0 ! If you use the slower method of converting to a string and checking the length, it works as expected. (scratchpad) [ number>string length ] bi@ --- Data stack: 311 310 ! I'm trying to speed up Project Euler #57, and there are 30 fractions where the number-length method fails to return an accurate number. Any thoughts?
Author: | slava |
---|---|
Mode: | factor |
Date: | Thu, 8 Jan 2009 03:09:57 |
The problem is that the number is converted to a float first, and precision is lost. I'm afraid you'll need to try a different algorithm.