| Age | Commit message (Collapse) | Author |
|---|
|
This metric shows how many combinations you'll need to memorize prime
powers, and how big the numbers are in complementary multiplication.
The YouTube video "the best way to count" inspired me to think I need
a metric to handle both size and factors, but the specific metric is
entirely original (or at least independently discovered).
|
|
|
|
This is the safest thing to do to ensure my software is free while
avoiding legal trouble ... hopefully, I'm not a lawyer!
|
|
go1.21, the previous requirement, was released a few months ago, so not
all systems have adopted it. go1.18 is old enough that most systems
should support it, but it introduces generics, which my testing code is
highly dependent on, so I can't easily go any earlier.
|
|
|
|
|
|
|
|
- Test that every number returned by factors.Factors is actually a
factor of its argument.
- Test that every number returned by factors.TotativeDigits is actually
a totative of its argument, and that len(factors.TotativeDigits(r)) ==
factors.Totient(r).
- Test the properties of factors.Split (regular * totative == digit,
totative is a totative of radix).
Some of these tests don't test every number in the range, instead
picking randomly, which is done in order to avoid tests taking too long
to execute. Some testing is better than no testing!
|
|
- TotativeDigits was defined incorrectly, previously counted totatives
from 0 to r-1, now counts digits from 1 to r. This ensures that
len(TotativeDigits(r)) = Totient(r).
|
|
|
|
|
|
When using really large numbers, factors.Score could overflow, which
would cause an incorrect result. Using arbitrary-precision arithmetic
fixes this. I only do so above 2^28, since below then factor sums are
guaranteed to not overflow, and normal arithmetic is faster.
|
|
|
|
Panics are not the best way of handling errors in Go. I've replaced
panics with default values whenever a sensible one exists.
Factors(0) does not have a sensible default value (as every number is a
factor of zero), so it still panics.
|
|
Instead of just saying how many totative digits there are, the new -t
flag allows the user to determine the specific digits. All totatives
will end in one of these digits, and all primes are either factors or
totatives. This feature is not useful in comparing radices, only
learning one you have already chosen.
Because there can be so many totatives (p - 1 of them for primes!), this
is not displayed by default. The digit map (without -f) gives this
information, and beyond its range every number will have more than 8
totatives, so do not use this flag if you only want the count.
|
|
factors.Type now supports all numbers; I have used lookup arrays instead
of determining whether a number is SAN or not. There are only 117
elements to store, and this makes the algorithm Θ(1), so it's an
improvement.
Also, I have changed the size of some integer values to correspond to
this change - they now indicate the size of numbers they can accept.
The only outputs that are hidden for large radices are:
- The digit map, which goes up to 36 because I don't have any more
digits beyond that point
- The multiplication table complexity, which is estimated above 2^16
(for performance), and can optionally be extended to 2^32 (above this,
the output could overflow a uint64).
|
|
The backing constants of NumberType and TotativeType have been changed
so that they can be compared (based on how desirable they are, more
desirable categories are given higher values), and so that I can add new
values in between without changing the constants.
|
|
This value can easily be calculated as φ(r)/r. There is no need to have
this now that I have a function φ(r) (renamed to its mathematical name,
Totient).
I removed totative ratio instead of totient because, while it is more
important, totient is an integer while totative ratio is a float. This
means that the totative ratio can be calculated exactly from the
totient, but not the other way round.
|
|
It now distinguishes between omega (factors of r - 1), alpha (factors of
r + 1) and the rest. The previous categorization determined whether or
not totatives and semitotatives have simple patterns; this new
categorization determines which simple patterns they follow)
|
|
This is done for a few reasons:
- Allow the user to easily determine the exact value of the totative
ratio
- This information is important when the digit map isn't accessible (for
radices >36)
- More consistency with factors
I don't show the exact values of totatives like I do with factors
because they're far more common - the superior highly composite (i.e.
one of the numbers with the highest factor count) number 720720 has
240 factors and 138240 totatives, for example.
|
|
This is not in the output yet, but it will be soon - printing it is
another task since I want colours in my output.
|
|
(or, as exact as possible within a float64 - I only do one float
division, and everything else is a uint, so I think this means I will
get the closest available float64 value every time)
|
|
This ensures the output can fit into a uint64. Also, calculating it at
this stage is slow, and not calculating it can make the program nearly
instant even for very large numbers!
|
|
This type measures which kind of classes each radix is a part of:
- Colossally Abundant (OEIS: A004490; factor score better than every
other number if you account for size be dividing by a certain power of
the number)
- Superabundant (OEIS: A004394; factor score better than every smaller
number)
- Ordered-Exponent (OEIS: A025487; exponents in prime factorization go
down as you get to bigger primes, and no prime is skipped)
- Practical (OEIS: A005153; factors can sum to any number below the
original number without duplication)
Each of these groups is a subset of the next, so only the most specific
label is reported.
The purpose of this program is to give you useful info to help you
determine which radices are the best, and these categories give a rough,
quantitative measure of how useful a radix's factors are:
- Practical is approximately the minimum requirement for a worthwhile
radix. Non-practical radices above ~16 are probably terrible to use.
- Ordered-Exponent radices act like local maxima - you can't get any
better (smaller) without changing the "shape" (exponents) of your prime
factorization.
- Superabundant radices are the best radices below the next
superabundant number (e.g. 12 is the best radix below 24).
- Colossally abundant radices are, in some sense, the best radices out of
all numbers.
|
|
(MTC = Multiplication Table Complexity)
|
|
Use methods from the new slices and maps modules to make my code faster
and more compact.
|
|
I can now use the function tableTest() to create a new test in one or
two lines of code! No more need to rewrite basically the same code ten
times...
|
|
|
|
|
|
|
|
|
|
|
