mersenneforum.org A Tool for Studying Aliquot Sequence Data
 User Name Remember Me? Password
 Register FAQ Search Today's Posts Mark Forums Read

 2021-09-14, 16:28 #100 Aillas     Oct 2002 France 9E16 Posts EdH, I have a question about the source code: For open ended sequence, when looking for sequences that merge with Line 884: for(j=seqn+1;j 1000 that merge with prime related to sequence 1000. Or this is a bug and we should search the whole file? Thanks
2021-09-14, 20:18   #101
EdH

"Ed Hall"
Dec 2009
Adirondack Mtns

3×372 Posts

Quote:
 Originally Posted by Aillas EdH, I have a question about the source code: For open ended sequence, when looking for sequences that merge with Line 884: for(j=seqn+1;j 1000 that merge with prime related to sequence 1000. Or this is a bug and we should search the whole file? Thanks
I hope I understand your question. The regina_file has already taken the first occurrance of an o-e sequence into account and the first one will count as number 1. All others will increment in the regina_file as more merges are encountered. Instead of using the regina_file count, seqinfo2 should simply start counting at seq+1 for any matches to seq. I think that's what I'm doing with that line.

Let me know If I'm still unclear or if I'm off on this.

Thanks for the question.

 2021-09-16, 11:32 #102 Aillas     Oct 2002 France 2×79 Posts It's clear thanks. Bad news, I was updating the code to manage the perfect number, and there is a comparison with a prime number that could not fit in an uint64_t (seqd[seqn].elD == "191561942608236107294793378084303638130997321548169216") So I will try to update the code using double for this. This field is only used for comparison, so I don't think it will introduce issues. I need to try. I let you know.
 2021-09-16, 13:33 #103 EdH     "Ed Hall" Dec 2009 Adirondack Mtns 3·372 Posts Thanks for keeping us up-to-date on your work.
2021-09-22, 12:16   #104
Happy5214

"Alexander"
Nov 2008
The Alamo City

14078 Posts

Quote:
 Originally Posted by Aillas It's clear thanks. Bad news, I was updating the code to manage the perfect number, and there is a comparison with a prime number that could not fit in an uint64_t (seqd[seqn].elD == "191561942608236107294793378084303638130997321548169216") So I will try to update the code using double for this. This field is only used for comparison, so I don't think it will introduce issues. I need to try. I let you know.
I don't think a double (53-bit mantissa) is enough precision for that number, and even a long double on x86 (which I believe gives you the 80-bit x87 extended-precision float, with a 64-bit mantissa) isn't an improvement over uint64_t. I tried converting that number to float and back in Python (using double-precision) and it didn't return the same number:

Code:
>>> float(191561942608236107294793378084303638130997321548169216)
1.915619426082361e+53
>>> int(_)
191561942608236107294793378393788647952342390272950272
>>> _-191561942608236107294793378084303638130997321548169216
309485009821345068724781056

2021-10-26, 16:15   #105
Aillas

Oct 2002
France

2·79 Posts

Hi,

I was busy and not be able to finish the tool. Back to business now :)

Quote:
 Originally Posted by Happy5214 I don't think a double (53-bit mantissa) is enough precision for that number, and even a long double on x86 (which I believe gives you the 80-bit x87 extended-precision float, with a 64-bit mantissa) isn't an improvement over uint64_t. I tried converting that number to float and back in Python (using double-precision) and it didn't return the same number:
Yes, you're right. Thanks to pointing out. I saw this during debugging session.

Some updates:
- I finished to clean and factorize the code to avoid duplicates.
- I need to fix the "long integer" issue.

EdH, I have 3 questions for you:

1: To fix the long integer issue, there are 2 solutions. Use strings as you've done or use the GMP library.
For instance there is no computation done on these numbers, just comparisons.
Do you prefer I switch to GMP for future use or string is enough?

2: In the code, once you compare the prime number of a sequence (elD) to a "list of number" (If I well understand it's a list of 'perfect' number) and then the sequence number to a second shorter list of perfect number.
My question is probably stupid as I don't understand the math involved here, but could we simplify and compare both numbers to the same "longest" perfect number list?

3: The code needs now c++20 to compile as I use some new methods and features of c++20. Is it a problem?
I can do c++11 version of the source code if needed.

Thanks

 2021-10-26, 16:52 #106 EdH     "Ed Hall" Dec 2009 Adirondack Mtns 3·372 Posts Thanks for the update. This version is yours, so you should go with what you prefer. I'm not really doing anything more with my original as yours should far out do what I had. That being said, 1. The use of GMP could be an advantage in the future, but users of the program would need GMP available to compile. That was my reason for working without it. OTOH, any users of the program will probably already be using GMP for other things, anyway. 2. I'm going to have to go back and try to remember what I'm doing there. I'll get back with you a little later. 3. The only restriction I see, is what's available to someone trying to compile it. If the current g++ versions support 20, I see no reason to use 11.
2021-10-26, 18:15   #107
EdH

"Ed Hall"
Dec 2009
Adirondack Mtns

410710 Posts

Quote:
 Originally Posted by EdH . . . 2. I'm going to have to go back and try to remember what I'm doing there. I'll get back with you a little later. . . .
Here's my best description of what's happening with elD;

elD is fully dependent on elB in the following manner:

If elB<0 (negative value), elD is a cycle term, which includes perfect numbers. In order to spearate the perfect numbers, I look specifically for the first few, so they can be indentified as such. Otherwise the sequence is treated as one of the terms within a cyle of two or more terms and handled by that routine.
- Note that a negative elB also carries further info about the cycle, but I disregard that info and handle the result based on the actual cycle info from factordb.
- Note also that perfect numbers above the ones I specifically address are handled as cycles of one term.

If elB=0, elD is treated as the base for the Aliquot tree of which the sequence is a branch (or the base, for such as 276, etc.)

If elB=1, elD is the terminating prime and is handled as such.

2021-11-07, 03:42   #108
Happy5214

"Alexander"
Nov 2008
The Alamo City

52·31 Posts

Quote:
 Originally Posted by Aillas 1: To fix the long integer issue, there are 2 solutions. Use strings as you've done or use the GMP library. For instance there is no computation done on these numbers, just comparisons. Do you prefer I switch to GMP for future use or string is enough?
There actually is a third solution, the ugliest by far and the one GMP more-or-less does internally: create a two-member struct of uint64_t values (high and low). But I would not recommend it unless you're really desperate for performance and/or to avoid importing GMP, since you'll start requiring inline assembly for operations and have terribly ugly parsing.

 Thread Tools

 Similar Threads Thread Thread Starter Forum Replies Last Post schickel Aliquot Sequences 3621 2021-11-25 23:11 10metreh Aliquot Sequences 4 2021-10-28 22:17 arbooker Aliquot Sequences 11 2021-09-10 05:28 garambois Aliquot Sequences 24 2021-02-25 23:31 schickel Aliquot Sequences 67 2012-01-20 17:53

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

Wed Dec 1 07:04:37 UTC 2021 up 131 days, 1:33, 1 user, load averages: 1.56, 1.40, 1.34

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.