mersenneforum.org > YAFU nextprime function is spooked by leading zero.
 Register FAQ Search Today's Posts Mark Forums Read

 2018-03-24, 06:49 #1 shortcipher   Mar 2018 17 Posts nextprime function is spooked by leading zero. An example on Windows 7:- Code: C:\Users\Christopher\Downloads\yafu-1.34>yafu-x64 "nextprime(723391033893233, 0)" ans = 723391033893197 but Code: C:\Users\Christopher\Downloads\yafu-1.34>yafu-x64 "nextprime(0723391033893233, 0)" ans = 2 In case you say "just leave off the leading zero", this reproduces a YAFU call where the argument was generated by another program.
 2018-03-25, 03:26 #2 wblipp     "William" May 2003 New Haven 23×103 Posts Is it the "leading zero means the number is octal" issue? And the number isn't a valid octal number, so "string to integer" returns zero?
2018-03-26, 00:22   #3
shortcipher

Mar 2018

1116 Posts

@wblipp

Good point, but in the docfile.txt of YAHU 1.34 it says
Quote:
 YAFU can handle input/output in several different bases, specified by the IBASE and OBASE reserved words. Recognized bases include (for the moment) hexadecimal and decimal. Binary and Octal as well as arbitrary bases are on the agenda. Once IBASE is set to a base, all other input is interpreted in that base. Likewise once OBASE is set, all output appears in that representation. This behavior can be overridden on input by using 0x before a number to indicate hexadecimal, or 0d for decimal.

2018-03-26, 02:13   #4
bsquared

"Ben"
Feb 2007

67738 Posts

Quote:
 Originally Posted by shortcipher @wblipp Good point, but in the docfile.txt of YAHU 1.34 it says
Which says that it doesn't support octal

Chances are it will be an easy fix, but also likely is that the fix will only appear in source revision, not a new released version. Can you build from source?

 2018-03-26, 02:33 #5 shortcipher   Mar 2018 218 Posts Thanks @bsquared. I can't build from source, but this is not an urgent fix for me as I have amended that "other program" to remove the leading zero.
 2018-03-27, 13:59 #6 bsquared     "Ben" Feb 2007 3·1,193 Posts I looked at the code and here is what's happening. Yafu's parser looks at the input and decides that yes, 0723391033893233 is a number (not a variable name or function). Whereupon it hands the number to gmp's mpz_set_str function; I've been using that function with base 0, meaning autodecode the base. Gmp's autodecoder just needs a leading 0 to decide octal, but the number is not octal so the call fails. Wblipp was right. Yafu's parser correctly decoded decimal (it looks for leading 0o for octal), so I if change anything I could use the base decoder in my parser instead of relying on gmp. However, 0o is not standard notation for octal... a single leading 0 is historically the way to represent them. So Gmp's interpretation is the correct one. I'll leave things as they are except I will add a printed warning if the conversion fails.

 Similar Threads Thread Thread Starter Forum Replies Last Post Brian-E Soap Box 15 2014-05-16 03:12 EdH YAFU 7 2013-03-18 22:09 Primeinator Information & Answers 9 2010-06-25 07:36 fgrieu Factoring 7 2009-09-23 11:45 GP2 Data 10 2003-11-17 14:55

All times are UTC. The time now is 08:07.

Tue Dec 7 08:07:24 UTC 2021 up 137 days, 2:36, 0 users, load averages: 1.23, 1.44, 1.50