Do you think I could just leave this part blank and it'd be okay? We're just going to replace the whole thing with a header image anyway, right?
You are not logged in.
Pages: 1
Numbers that have 4 letters:
Four
Five
Nine
Zero
I believe those are all of the base numbers, so you could theoretically find every single number by continuing the chain with those numbers.
Example:
Negative Fifty Six Thousand Five Hundred Sixty Two
Forty Three
Ten
Three
Five
Four
Reverse the process, and you can find Negative Fifty Six Thousand Five Hundred Sixty Two. You also can find what comes after that. The easiest way to do this is to try to stick to the smallest possible amount of letters to make it less stressful (or continue along yours if it's possible). I, however, am not smart enough to do that. BTW I did use a negative. It does 100% end the chain no matter what, but I wanted to use something big. Funny enough, it actually goes up to six. (but I wasn't trying to find one that goes up to 7)
Offline
wtf are u on
Offline
math
Offline
mm ketamine
Offline
Don't do meth kids. Or you too will end up trying to find random patterns in numbers.
★ ☆ ★ ☆ ★
☆ ★ ★
Offline
every number comes back to four
pick a number.. any number.. 15? okay,
f i f t e e n
seven letters
s e v e n
five letters
f i v e
four letters
one hundred sixty nine
o n e h u n d r e d s i x t y n i n e
n i n e t e e n
e i g h t
f i v e
f o u r
| hi, i'm anne! |
i do some silly things
Offline
Numbers that have 4 letters:
Four
Five
Nine
ZeroI believe those are all of the base numbers, so you could theoretically find every single number by continuing the chain with those numbers.
Example:
Negative Fifty Six Thousand Five Hundred Sixty Two
Forty Three
Ten
Three
Five
Four
Reverse the process, and you can find Negative Fifty Six Thousand Five Hundred Sixty Two. You also can find what comes after that. The easiest way to do this is to try to stick to the smallest possible amount of letters to make it less stressful (or continue along yours if it's possible). I, however, am not smart enough to do that. BTW I did use a negative. It does 100% end the chain no matter what, but I wanted to use something big. Funny enough, it actually goes up to six. (but I wasn't trying to find one that goes up to 7)
Dude, nice. I didn't even think of this little fun pattern of the universe xD.
If only calculus was this fun of a concept...
Hmmm, let's see so can this theoretically work with just sentences or regular words?
elephant
eight
five
four
the elephant is enormous
twenty one
nine
four
seems like a pretty deep concept that can transcend basic mathematical terms :O
Offline
every number comes back to four
pick a number.. any number.. 15? okay,
f i f t e e n
seven letters
s e v e n
five letters
f i v e
four letters
one hundred sixty nine
o n e h u n d r e d s i x t y n i n e
n i n e t e e n
e i g h t
f i v e
f o u r
Thanks I honestly had no idea what OP meant until you posted this. However since I'm not a meth addict I don't think this is neat at all.
thx for sig bobithan
Offline
seems reasonable. now prove it.
Offline
seems reasonable. now prove it.
To make this easier to understand, let's give numbers three qualities: value (the actual meaning of the number), length (in letters), and value:length ratio.
OP is right because four is the only number that has a 1:1 length:value ratio.
Think about it. Once you go above four, every single number goes below 1:1. That means the length goes to a lower value, creating a chain that goes all the way to four or lower. If you go below four, it goes back up because one and two go to three, which goes to five, which goes down to four. So it always goes back to four.
But maybe you're thinking if we go high enough, the number word will be convoluted and long enough to break the ratio. So let's make the longest number word we can.
Here's a chart of what numbers add to what length:
+3 one
+5 three
+7 thirteen
+7 hundred
+8 thousand
+7 million
+7 billion
+8 trillion
etc.
101 ( 3 + 7 + 5) onehundredthree
113 ( 3 + 7 + 7) onehundredthirteen
1101 (3 + 8 + 3 + 7 + 5) onethousandonehundredthree
1113 (3 + 8 + 3 + 7 + 7) onethousandonehundredthirteen
1301 (3 + 8 + 5 + 7 + 5) onethousandthreehundredthree
1313 (3 + 8 + 5 + 7 + 7) onethousandthreehundredthirteen
See where I'm going with this? If we can only add so little to the length, there's no way we can outpace the value of the actual number. We're exponentially going lower, and we always have a number short enough in length to return to four.
Offline
sixty nine funny
| hi, i'm anne! |
i do some silly things
Offline
hi rat!
i would
thanks, luz
yeah
Offline
this is giving me Look-and-say numbers vibes.
Offline
I like where n1kf is going with this. What would it take to make a legit mathematical proof of this?
It'd take proof by induction because of the repetition and the building on itself. (Right?)
To establish our base case, I imagine we'd need to prove enough beginning numbers to show what N1KF is pointing out. Mainly, that no addition to a given number string can 'jump over' our pool of known sequences leading to four.
So, what's the biggest jump we'd have to account for, the biggest change that could not be broken down in the middle. I.e., going from eighty-four million to nine hundred eighty four million ... we get a few more characters, but we have an interim point of "one hundred eighty four million"
Just some more thoughts. I suppose I'm missing the argument as to why we can assume that subdividing jumps allows us to conclude we have the otherwise max-jump size.
edit: wait, I'm looking at this all wrong.
Offline
Jumping 100 numbers ahead was fine as an informal way to show N1KF's point, but I think a formal proof should just use increments of 1 like any other induction, otherwise things probably get unnecessarily convoluted.
It would be sufficient to prove that every number greater than 4 is greater than the length of its text equivalent, because this would mean the pattern would be strictly reducing until you get to 4 or below, then as we've already shown it will just go back to 4.
It would be a proof by induction with a bunch of cases to handle based on the way we encode numbers to text.
Each case would affect the gap between the number and the length of the string, either making it bigger or smaller. If the gap gets bigger or stays the same (string gets smaller, stays the same or goes +1), then the assumption holds. If it gets smaller (string gets bigger by more than 1), then we have to prove that the gap doesn't close, i.e. that the number is still greater than the length of the string. That probably either requires us to prove a lower bound for the gap for each case where this happens, or we actually have to extend the assumption include a lower bound on the gap and do induction on that as well. I suspect the latter could work because it seems like the gap generally gets bigger, even if it fluctuates at times, so we assume a lower bound and just make sure the fluctuations are never big enough to make the gap close.
Something I can observe is that most of the increases in string size happen in the numbers 1-19. 2 digit numbers higher than that are the same as incrementing from 1-9. 3 digit numbers are encoded the same as 2 digit numbers but with some extra words in front, so we see the same pattern. It looks like incrementing a number ending in 9 is always non-increasing string-wise. Adding a new digit (99 -> 100, 999 -> 1000, etc.) is also non-increasing string-wise, since a bunch of digits become 0. Hopefully it's clear that there's a finite amount of stuff to prove here, since the encoding is systematic and you can kind of generalise it. Though technically every 3 digits we are adding a new word (thousand, million, billion, trillion, ...), which kind of needs a limit. If my observation is right then you only need to handle increases in string size in numbers 1-19, and show that those fluctuations get "corrected" and will never be big enough to close the gap for numbers over x. Just have to show all this stuff formally and you have your proof.
thx for sig bobithan
Offline
i love meth
yeah
Offline
Pages: 1
[ Started around 1732401456.4803 - Generated in 0.083 seconds, 12 queries executed - Memory usage: 1.61 MiB (Peak: 1.81 MiB) ]