Lonelygirl15

You guys really make my head hurt...! That was impressive. Does it translate into English? And, maybe, words of less than one syllable? <shudder>

This isn't even what your supposed to use this function for... (not gonna go into detail) but its not indended for digits.. or last time I remember using this it didn't...

Also by taking 10033 and putting it in the Psi or the Digamma Function... I got:

X = 9.21358,51025,55043,26890,56275,07065,44921,78346E+0 (41) [49]

(Not gonna show my work cause 1-causes confusion and 2- takes up too much room)

If these #'s actually tell me anything... I doubt it

I want to try and use Floating-point formula:

Floating-point numbers are typically packed into a computer datum as the sign bit, the exponent field, and the significand (mantissa), from left to right. For the common (IEEE standard) formats they are apportioned as follows:

sign exponent (exponent bias) significand total
single 1 8 (127) 23 32
double 1 11 (1023) 52 64
While the exponent can be positive or negative, it is stored as an unsigned number that has a fixed "bias" added to it. A value of zero, or all 1's, in this field is reserved for special treatment. Therefore the legal exponent range for normalized numbers is [-126, 127] for single precision or [-1022, 1023] for double.

When a number is normalized, its leftmost significand bit is known to be 1. In the IEEE single and double precision formats that bit is not actually stored in the computer datum. It is called the "hidden" or "implicit" bit. Because of this, single precision format actually has 24 bits of significand precision, while double precision format has 53.

For example, it was shown above that π, rounded to 24 bits of precision, has:

sign = 0 ; e=1 ; s=110010010000111111011011 (including the hidden bit)
The sum of the exponent bias (127) and the exponent (1) is 128, so this is represented in single precision format as

0 10000000 10010010000111111011011 (excluding the hidden bit) = 40490FDB in hexadecimal

to change see what crazy Hexidecimal I get but I am having trouble with it... Maybe you can figure it out Deagol. There is more on Wikipedia

My brain hurts from my own math lol

Getting back on track Just watchedthe new vid and most of them look hard to find...The easiest looking one is


(Tell me if this looks familiar)

I am gonna start with this pic... also at the beginning one picture looked suspiciously similiar to a spot in The Cowboy. I am gonna double check that...The snow is gonna make things hard to recognize from google earth... and also mountains are hard to interpret there size and position but I'll see what I can get.

Also, I was wondering if bethy saw that building on Wilshire or not.

also in the new video:




You can see housing going by where the houses are close together so the are in a residential area (at least for this part)

The one you can clearly see they slowed down near maybe its where they started/ending at... whoknows. but its still a landmark to find.

Just so you know, prime place to start looking is in the Sierra Nevada mountains, which are east of Ukiah on the California/Nevada border

or north of LA

deagol wrote:Ha, that's it! Remove the comma and you get 333, the triple trinity, or a half-beast... Wink

The real question is...which half?

Hey what if you did it backwards?

33.001
33+1/1000
[33, 1000]

or

3.3001
3+3001/10000
3+1/(10000/3001)
3+1/(3+997/3001)
3+1/(3+1/(3001/997))
3+1/(3+1/(3+10/997))
3+1/(3+1/(3+1/(997/10)))
3+1/(3+1/(3+1/(99+7/10)))
3+1/(3+1/(3+1/(99+1/(10/7))))
3+1/(3+1/(3+1/(99+1/(1+3/7))))
3+1/(3+1/(3+1/(99+1/(1+1/(7/3)))))
3+1/(3+1/(3+1/(99+1/(1+1/(2+1/3)))))
[3,3,3,99,1,2,3]

:big ol' freakin wink:


[I'm pretty quick to pick up on math stuff]

Balmung wrote:Hey what if you did it backwards?

33.001
33+1/1000
[33, 1000]

or

3.3001
...
[3,3,3,99,1,2,3]

:big ol' freakin wink:


[I'm pretty quick to pick up on math stuff]

Excellent! Finally someone understands my post

I like that 1, 2, 3 in the end on that one. Fits with that Contact 3, 2, 1 video on YT 10033, and of course it comes backwards, as it should.

Also, .33100 would be

.33001
0+33001/100000
0+1/(3+997/33001)
0+1/(3+1/(33+100/997))
0+1/(3+1/(33+1/(9+97/100)))
0+1/(3+1/(33+1/(9+1/(1+3/97))))
0+1/(3+1/(33+1/(9+1/(1+1/(32+1/3)))))
[0,3,33,9,1,32,3]

A couple more:
330.01
330+1/100
[330,100]

3/3001
0+1/(3001/3)
0+1/(1000+1/3)
[0,1000,3]

Finally, someone said if it could be words in english. I don't know about 10033, but you can certainly use the letters of a word as numbers, but avoid using 1's because there can be ambiguity if the last number is a 1. So, you could have a=27, b=2, c=3, ... z=26, or ascii codes, or any other mapping you can think of. Then you just put each word's letters in one continued fraction. That way you could encode whole texts as a series of rational numbers. Here's an example: I'll encode the phrase "pizza ice cream spin art" using a=27, b=2, etc.
Doing this by hand is a very tedious process. Thankfully, there are online calculators to convert fractions or decimal numbers to and from the continued fraction form. However, you'd still have to do it word by word, so a long letter would still be a pain to encode/decode. It would make more sense to encode a vigenere key or encryption password using continued fractions, and then use it on a cipher or encryption for the whole letter.

A long word like 'acknowledge' would result in a very long fraction, and it actually gets messed up by the precision limit in the online calculator, so they should be broken up in chunks.

haha i was actually thinking about encoding that way earlier today at school.

is it possible for a continued fraction to convert to a decimal, and then when you convert it back to a continued fraction, you get a different set of numbers? kind of like how 2/4 goes to .5 then 1/2



another thing that came to mind is

aren't latitude and longitude coordinates sometimes expressed as a list of numbers? is it possible that 10033 [in some form] is a location?

Balmung wrote:is it possible for a continued fraction to convert to a decimal, and then when you convert it back to a continued fraction, you get a different set of numbers? kind of like how 2/4 goes to .5 then 1/2

Nope, there's no ambiguity (with a caveat), and that's critical for it to work as code. Every continued fraction has a unique real number in decimal, and every real number has a unique continued fraction, as well as a trivial variant.

The caveat is that there is ambiguity about the last number in the list, since it's possible to add a 1 at the end, as it can happen with words ending in 'a' and having a=1. Every continued fraction list with the last number (call it n) greater than 1 can be expressed with a slight difference in the end. All the numbers in the list are the same, except that last n becomes n-1 and a 1 is added. For example:

100.33
100+33/100
100+1/(3+1/33)

This is already legal as [100,3,33], but you could go one step further without breaking the rules:

100+1/(3+1/33)
100+1/(3+1/(32+1/1))
[100,3,32,1]

So if a=1, there would be some confusion. An 'a' at the end of a word would be encoded as a 1 at the end of the list, and although there is a unique decimal representation for it, you wouldn't know which form of the continued fraction to use when decoding. For example:
Either way you get some messed up words. My solution was to make a=27 and never take that last step to get the final 1. An alternative solution would be to require the decoder to always take that last step with the 1 at the end, but you'd have to encode every word in the message with an extra 'a' appended, which would need to be removed after decoding:
If the encoder and decoder agreed to this scheme, there would be no confusion as the decoder would remember to figure those last 1's to get "santaa nellaa dropa" (instead of "santb nellb droq" if he didn't). Obviously, he would also know that he needs to remove the extra 'a's in every word.

Using ascii code doesn't have this problem since there's no valid ascii for 1, but it does require more words to be broken up due to the higher values and the calculator's limited digits, unless it's done by hand.

ah. i see what you mean with the 1 at the end, that could cause issues.

what do you think about the location theory?

if i remember right, latitude is written in degrees, minutes, and seconds, in latitude and longitude.

could you possibly encode a location using a continued fraction?

[degrees N, minutes, seconds, degrees W, minutes, seconds]

it would be interesting to see if some version of 10033 could give us a 6 integer answer, and check the coordinates, wouldn't it?





in the long run, i'm sure 10033 is either completely random, or it's significance is either so small or so obscure that no one will find out i's true meaning before it is revealed.

it's sure fun to look, though.

[not to mention i learned a new code ]





p.s. is it universally accepted that a = 27, or did you come up with the idea of using continued fractions as a code just now? if so, one would think a could be 2, b =3 , etc. with z being 27.

so with different interpreters, you could have that difference to work with.

i supposed it's just a matter of checking each way, or decoding as if it had been encoded with a rotational cipher..