| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This makes finding the RC of prime powers multiplication instead of
exponentation, which is much easier to do mentally.
|
|
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).
|
|
Although I have the regular logarithm, its reciprocoal is useful to
determine the length of numbers in a certain radix. Like with the
totative ratio (where both it and its reciprocoal are useful), I showed
both in the regular view and only one in the compact view.
|
|
After thinking about how I want to best represent logarithms, I think
the best way is to see them as equivalent to the size of a digit.
Binary logarithms allow for using a familiar unit (bits) to represent
this size. Nepers exist for the natural logarithm, but almost no one
uses them.
Also, because binary is the smallest base out there, this value will
always be ≥1. This means I'm making the most out of my digits!
This does mean that digit length isn't immediately obvious, but this is
the same idea as "1 km = 1000 m" meaning that the number of km is 1/1000
the number of m - using the regular logarithm is like associating the km
with the number 1000, using the reciprocoal is like associating it with
1/1000=0.001.
Documentation has been changed to reflect this.
|
|
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.
|
|
|
|
|
|
The RUS is like the factor utility score, but for regulars (numbers
divisible by any power of the radix) instead of factors (numbers
divisible by the radix). It estimates the utility of fractions that
terminate but with more than one digit, like 4, 8 and 20 in decimal.
It is also (by coincidence) the reciprocoal of the totative ratio. I am
replacing it in the compact view because it is more useful, for two
reasons:
- It can be meaningfully compared with the factor utility score. By
subtracting RUS-FUS, you can find the utility of non-factor regulars.
This score can give a hint about how often these fractions will be
used in a radix. It also can tell you how much benefit you can get
from adding another copy of a radix's prime factors. For example,
senary (RUS-FUS=1.0) can gain a lot from adding another 2 or 3, while
octal (RUS-FUS=0.125) probably won't (in terms of factors at least,
the benefits for computers are separate to this)
- Because of the way they are calculated, the RUS is far more likely to
be a round/terminating decimal than the totative ratio. This means
that taking the reciprocoal to get the benefits of the other number is
far easier with the RUS than the totative ratio.
|
|
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).
|
|
- Use 'r' instead of 'n' as variable name for radix
- Use 'ln' instead of 'Ln'
Both of these are for consistency.
|
|
because it's not public API!
|
|
These radices are large enough that:
- there is no reason to use them as actual radices
- calculating them takes a lot of time!
Therefore, the exact MTC and radix type shouldn't be calculated by
default. If you want to take the time, you still can with -l. I am
keeping the original 2^32 limit even with -l, because the problem with
that is not performance, it is that the resulting MTC could overflow a
uint64 (also the CAN list only goes up to this range).
|
|
This can easily be estimated from existing information, so it's useful
to have, even in the compact view.
This estimate is more accurate (narrows the range down further) the
higher the radix's totative ratio. It also should be closer to the
actual value than the upper bound.
|
|
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.
|
|
Full digit maps will show every digit from 0 to 35, regardless of the
radix. This allows you to see extra fractions for small radices and to
get a digit map for radices above 36.
This isn't enabled by default because the extra "digits" added for small
radices aren't actually digits - so it may be unintuitive. There are
also some situations where only a radix's actual digits matter, such as
multiplication tables.
|
|
In general, components go in the order Factors → Totatives → Size. 2345
Score was moved to fit this order, since it concerns both factors (2-5)
and totatives (5). The compact view was rearranged to have a consistent
order with the normal view.
Also I added the MTC estimate for very large radices into the compact
view, because it can be there.
|
|
The compact output attempts to maximize the power-to-weight ratio of
this program, and the 2345 Score does not do this:
- It can already be easily determined from the prime factorization and
decimal radix, or trivially determined from the digit map.
- It does not take mixed radices (the radices you'll need to use bases
large enough to not show a digit map) into account.
- Although a big part of the 2345 Rank is strict improvements, some of
the decisions made in its design were necessarily arbitrary. The
alternatives give a more objective view.
The normal output is about showing everything worth showing, and the
2345 score is still useful there (especially for making sense of the
resulting complexity), so it is not removed from there.
|
|
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.
|
|
The non-compact display is intended as a "full info" display, so it
makes sense to have more precision in these numbers. The compact
display is unchanged.
|
|
|
|
This achieves two things:
- Decouples my code by putting the printing code into its own file
- Makes it easier to make alternate ways of printing (e.g. a compact
mode)
|
