mersenneforum.org  

Go Back   mersenneforum.org > Factoring Projects > Aliquot Sequences

Reply
 
Thread Tools
Old 2021-09-14, 16:28   #100
Aillas
 
Aillas's Avatar
 
Oct 2002
France

100111102 Posts
Default

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<seqscount;j++){

We are looking only for "greater" sequences that merge with it. Is it the expected behavior? Or should we start at first sequence (like line 1003 and another one)?
If I well understand, if sequence 1000 is open ended, we are looking for sequences > 1000 that merge with prime related to sequence 1000.

Or this is a bug and we should search the whole file?

Thanks
Aillas is offline   Reply With Quote
Old 2021-09-14, 20:18   #101
EdH
 
EdH's Avatar
 
"Ed Hall"
Dec 2009
Adirondack Mtns

2·29·71 Posts
Default

Quote:
Originally Posted by Aillas View Post
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<seqscount;j++){

We are looking only for "greater" sequences that merge with it. Is it the expected behavior? Or should we start at first sequence (like line 1003 and another one)?
If I well understand, if sequence 1000 is open ended, we are looking for sequences > 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.
EdH is offline   Reply With Quote
Old 2021-09-16, 11:32   #102
Aillas
 
Aillas's Avatar
 
Oct 2002
France

2·79 Posts
Default

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.
Aillas is offline   Reply With Quote
Old 2021-09-16, 13:33   #103
EdH
 
EdH's Avatar
 
"Ed Hall"
Dec 2009
Adirondack Mtns

100268 Posts
Default

Thanks for keeping us up-to-date on your work.
EdH is offline   Reply With Quote
Old 2021-09-22, 12:16   #104
Happy5214
 
Happy5214's Avatar
 
"Alexander"
Nov 2008
The Alamo City

23×97 Posts
Default

Quote:
Originally Posted by Aillas View Post
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
Happy5214 is offline   Reply With Quote
Old 2021-10-26, 16:15   #105
Aillas
 
Aillas's Avatar
 
Oct 2002
France

100111102 Posts
Default

Hi,

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

Quote:
Originally Posted by Happy5214 View Post
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
Aillas is offline   Reply With Quote
Old 2021-10-26, 16:52   #106
EdH
 
EdH's Avatar
 
"Ed Hall"
Dec 2009
Adirondack Mtns

2×29×71 Posts
Default

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.
EdH is offline   Reply With Quote
Old 2021-10-26, 18:15   #107
EdH
 
EdH's Avatar
 
"Ed Hall"
Dec 2009
Adirondack Mtns

10000000101102 Posts
Default

Quote:
Originally Posted by EdH View Post
. . .
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.
EdH is offline   Reply With Quote
Old 2021-11-07, 03:42   #108
Happy5214
 
Happy5214's Avatar
 
"Alexander"
Nov 2008
The Alamo City

23·97 Posts
Default

Quote:
Originally Posted by Aillas View Post
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.
Happy5214 is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Aliquot sequence reservations schickel Aliquot Sequences 3626 2021-12-06 11:27
Useful aliquot-sequence links 10metreh Aliquot Sequences 4 2021-10-28 22:17
Extending an aliquot sequence backwards arbooker Aliquot Sequences 11 2021-09-10 05:28
A new tool to identify aliquot sequence margins and acquisitions garambois Aliquot Sequences 24 2021-02-25 23:31
Another Aliquot Sequence site schickel Aliquot Sequences 67 2012-01-20 17:53

All times are UTC. The time now is 06:28.


Wed Dec 8 06:28:22 UTC 2021 up 138 days, 57 mins, 1 user, load averages: 1.51, 1.13, 1.13

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.