long-term sustainability

[James Heinrich]

Originally Posted by LaurV

I mean SSD

You mean a flash drive. Or a microSD card inside a giant enclosure. Some of them are real, some of them are scams, but all of them are the same low reliability as any cheap flash drive.
Not at all to be confused with "real" SSDs that cost ~$100/TB.

[xilman]

Originally Posted by LaurV

Re compression: what compresses better, duplicate (redundant) information, or no information at all? Think about it.

OK, I thought about it.

Redundant information compresses very well, if the compression algorithm is any good.

The alternative given for consideration doesn't compress at all --- the compressed size is exactly the same as the uncompressed size.

Accordingly, my answer is "redundant information".

[retina]

Originally Posted by xilman

...
The alternative [no information] given for consideration doesn't compress at all --- the compressed size is exactly the same as the uncompressed size.

The compression ratios:
Redundant information: X divided by Y; X, Y > 0
No information: X divided by Y; X, Y = 0

If I compute the two ratios using FDIV on my FPU, and then use FCMP to compare them, what result will I get?

[xilman]

Originally Posted by retina

The compression ratios:
Redundant information: X divided by Y; X, Y > 0
No information: X divided by Y; X, Y = 0

If I compute the two ratios using FDIV on my FPU, and then use FCMP to compare them, what result will I get?

I do not know the specifications for those particular implementations of IEEE floating point arithmetic. As I am too lazy to look them up, my only honest answer is: I don't know.

When I implemented a FP instruction set back in the day, 0/0 yielded NaN (according to spec) and NaN was not comparable to any number, including itself (again according to spec).

[xilman]

Originally Posted by retina

The compression ratios:
Redundant information: X divided by Y; X, Y > 0
No information: X divided by Y; X, Y = 0

If I compute the two ratios using FDIV on my FPU, and then use FCMP to compare them, what result will I get?

You are comparing ratio of sizes. I was comparing difference in sizes.

I argue that my approach is more appropriate given that we are considering the storage space used in each case.

[retina]

Originally Posted by xilman

... not comparable ...

And thus is the answer to LaurV's question.

Although the FPU result could also be a #IA exception depending upon the setting in control word. Which would create a weird result to LaurV's question.

[EdH]

Serious question:

Wouldn't a "simple" list of all the primes known to exist within all the sequences be sufficient to reproduce all the sequences? IOW, wouldn't a copy of the 420k 420m primes held by factordb be more than enough to rebuild any sequence familiar to factordb?

[kruoli]

Yes, it would take some time, but I would assert it is a reasonable amount of time. You could "trial factor" each number by trying each prime known to FactorDB up to sqrt(number). I am thinking you could even improve that a lot by using some GCD trickery.

[R. Gerbicz]

Originally Posted by EdH

Serious question:

Wouldn't a "simple" list of all the primes known to exist within all the sequences be sufficient to reproduce all the sequences? IOW, wouldn't a copy of the 420k primes held by factordb be more than enough to rebuild any sequence familiar to factordb?

That is still an overshoot, you don't need to store the largest prime divisor for the numbers, of course unless that prime divisor is not a largest prime divisor for another number.

[Happy5214]

Originally Posted by LaurV

Re compression: what compresses better, duplicate (redundant) information, or no information at all? Think about it.

Based on my experience manually massaging aliquot log files to remove redundant information and comparing compression ratios, the manually stripped log archives were smaller, but the archives of the raw logs had better compression ratios.

Originally Posted by LaurV

1. No. Flat text files. [...] A separate index/hash file is maintained, which will help with searching. [...]

How many files, and what is the format of the index?

Originally Posted by LaurV

2. Yes, and there is no issue.

See below.

Originally Posted by LaurV

3. It does not. This is the job of the guy reading/interpreting it (the app used to show/add/edit/work the sequences). FDB works kinda the same. This poses no issue for terminating sequences. The primes are also stored in the DB, they are numbers, like any, and have their own lines. A line with a prime would look like "prime 1 a b", or "prime a b 1", where a, b, are the lowest sequence terminating in that prime and respectively the longest sequence, and "1" is the factor/flag (see below). There is a good reason why these need to be stored (for any line, not only for primes). Why would you need to store other info? Give me a real example of a case when you need more. Note that prime lines don't really need a flag, as the only factor is 1, this is flag-enough itself.

What do you do when there are two completely separate trees that terminate at the same prime (like 19, which is the aliquot sum of both 65 and 77)?

Originally Posted by LaurV

6. It does not. [...] When you look to two sequences that "merge", and it shows you the same info two times, it doesn't mean that the info is stored two times, once for each sequence. It is not. It is the "application" (database's elves) that "reconstruct" the sequence, calculate sigma for each line, get to that index, get the info of the new index, increment the index, calculate new sigma, check for cycle, etc. These things are not stored in the DB. [...]

It actually is stored in the database, just on the individual lines (in the form of a link to its aliquot sum entry) instead of a sequence table. It's reset when the whole database is reset and cached on the first load, which is why loading sequences takes so long after a database reset, and also why sequences that are "broken" stay broken without manual intervention by Markus.

[LaurV]

Originally Posted by Happy5214

What do you do when there are two completely separate trees that terminate at the same prime (like 19, which is the aliquot sum of both 65 and 77)?

1. How do you do this with the current (redundant) information in FDB? (think about, no need to reply).

2. In which situation do you actually need to "go back"? (i.e. given 19, get 65 and 75 out of it) (idem)

The "procedure", as I know it, is always in the opposite direction - you are giving 65, or 77, and need to get 19. Of course, to reconstruct the complete tree you need to be given BOTH 65 and 77, AND their factors (unless your name is sm88, see his related thread here around). Once you are given the factors of them, you can do this very easy (i.e. compute sigma, paint the trees).

Sometimes ago I posted that the most of the sequences terminate in 43. Also, when somebody asked (I think it was Dubslow) I posted that the largest prime a (not-trivial, not like M82589933) sequence terminates into, was (about 20 digits number, I don't have it now). How did I get that?