nextprime function is spooked by leading zero.

shortcipher · 2018-03-24, 06:49

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.

wblipp · 2018-03-25, 03:26

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?

shortcipher · 2018-03-26, 00:22

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

bsquared · 2018-03-26, 02:13

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?

shortcipher · 2018-03-26, 02:33

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.

bsquared · 2018-03-27, 13:59

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.

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.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Religious extremism leading to conflict and slaughter: how to handle this?	Brian-E	Soap Box	15	2014-05-16 03:12
nextprime() appears to be limited...	EdH	YAFU	7	2013-03-18 22:09
Leading Edge	Primeinator	Information & Answers	9	2010-06-25 07:36
Fixed leading bits in RSA modulus, vs NFS	fgrieu	Factoring	7	2009-09-23 11:45
Graph of leading edge of LL testing (and double-checking) over time	GP2	Data	10	2003-11-17 14:55

2018-03-25, 03:26	#2
wblipp "William" May 2003 New Haven 2,371 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, 02:33	#5
shortcipher Mar 2018 17 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 E21₁₆ 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.