I got a string of many numbers and was wondering how to go about finding a pattern if there is one without knowing in advance what the pattern might be and what the length of the pattern might be. All it know is that there are only numbers and the maximum range of any given number is 1 - 59.
Example:
12 13 34 45 48 51 56 22 37 30 8 5 47
Although I am starting to think if this was possible it'd be like predicting the future which I don't think it's possible.
If I understand your question correctly, I guess you would like to do something as they do here:
http://alteredqualia.com/visualization/hn/sequence/
http://www.algebra.com/algebra/homework/Sequences-and-series/Sequences-and-series.faq.question.155130.html
That is, looking at the differences between the numbers 1 or more times, and finding patterns. Writing a program to do this for arbitrary sequences is quiet challenging however.
Related
I would like to store some binary data in a BASIC program on the Commodore 64 as DATA statements. To save space, I'd prefer to store as a string, rather than as a sequence of numbers.
Is it possible to store any character, from CHR$(0) through CHR$(255), in a DATA statement, or are certain characters impossible to represent this way? What is the complete list of characters that cannot be represented in a DATA statement (if any)?
I'm particularly wondering about CHR$(0), double quote ("), newline and carriage return. If these can be represented, how?
Short answer: No. And you said why: the double-quote character inside a string generates an error: there are no quote-escape characters. For every Other value, you might be able to poke stuff into your DATA statement strings and then just never touch those lines again with the C64 BASIC editor, but the double quotes would kill you.
The best and fastest solution I've yet to think up is poor mans hex. It works like this:
Take each binary byte. Separate it into its two hex digits (/16 and keep the remainder for the second digit).
For each hex digit, take the binary value and add 48.
Now you have two characters in the set (0,1,2,3,4,5,6,7,8,9,:,;,<,=,>,?) that represent one byte.
Those two characters go into your data statement string.
Reverse the process to read them and poke them out.
There is a way to do this, you can POKE bytes directly into RAM. It's a bit of a long way around though, and you need to know where you're POKEing the bytes to. You could negate the need for lots of zeros in your DATA statement though, like this:
0 FOR I=0 TO 7
1 READ A(I)
2 NEXT I
3 PRINT A(0), A(4)
63998 PRINT "FIN"
63999 DATA ,,,,4,,7,8
We know that 2048 is the start of the BASIC area (unless you've moved the pointers), so at a guess, one could do this:
0 DATA" "," "," "," "," "
Then POKE around 2050 or 2051 with a character that you'd recognise and then list it. If you see the character added in between the double quotes then you win. Of course, then you need to calculate each position between the quotes thereafter. When you're done, renumber your line number and carry on programming. I'm not sure how you'd POKE a double quote in between a double quote as there is no notion of escaping a string in Commodore BASIC as far as I know.
I'd personally just use numbers though.
I have stored the following data statement, each element as a string, in a C64 program. I chose CHR$(172) - CHR$(190), and two above CHR$(4000).
100 data "©","ª","«","¬"," ","®","¯","¶","¼","½","¾","™","ח","⦁"
And I ran the following code:
10 FOR X=1 TO 14
20 READ A$
30 PRINT ASC(A$)
40 NEXT X
100 data "©","ª","«","¬"," ","®","¯","¶","¼","½","¾","™","ח","⦁"
The results were mixed. I knew it would not recognize anything above 255. But the CHR$(173) printed as a 32 instead:
RUN
169
170
171
172
32
174
175
182
188
189
190
?SYNTAX ERROR IN 100
READY.
I resisted the program, and my DATA statement now looks like this:
100 DATA "©","ª","«","¬"," ","®","¯","¶","¼","½","¾",""","",""
Using another BASIC dialect, one more modern and written in the past few years, this was my output of the CHR$ for 172 to 190:
The ASCII value of A is: 65
The ASCII value of A should be 65, like it is on a PC.
If it is not 65, then a conversion table must be loaded
and the results converted to match the PC so code
CHR$ VALUES
—————————————————
CHR$(169)=© CHR$(170)=ª CHR$(171)=« CHR$(172)=¬ CHR$(173)=
CHR$(174)=® CHR$(175)=¯ CHR$(176)=° CHR$(177)=± CHR$(178)=²
CHR$(179)=³ CHR$(180)=´ CHR$(181)=µ CHR$(182)=¶ CHR$(183)=·
CHR$(184)=¸ CHR$(185)=¹ CHR$(186)=º CHR$(187)=» CHR$(188)=¼
CHR$(189)=½ CHR$(190)=¾
For C64 BASIC, you either must use the string of numbers, or you will have to use the HEX values and store the actual characters as I have done in my original C64 DATA statement.
I don't know exactly how much space you think you are going to save, but it will be minimal at best, as C64 can't go past CHR$(255).
However, the other dialect I used, SmartBASIC, I went out past CHR$(20480).
I hope this helps.
for example if an int was on 63 and i wanted it to go up to 70 as a max but the commuter did not know how much exactly to add until it was at 70 is there a simple way I could do this?
There's no number type built into python that does what you're asking for. Instead, when your value changes you can use value = min(value, 70) to make it a maximum of 70.
I'm toying with the idea of objects doing this automatically in this repository https://github.com/tmerr/experimental/tree/master/nconstrain, but it's a little sketchy.
I’m trying to print out a 178-character string in brainfuck. This wouldn’t be a problem except I’m limited to using 270 characters of brainfuck. I was thinking of hashing the 178-character string using a two-way hashing function, but I've been having trouble finding a solution that works. Here is the string: "Wikipedia is the best thing ever. Anyone in the world can write anything they want about any subject, so you know you are getting the best possible information." - Michael Scott.
Running the string straight-up in some ascii->brainfuck programs is giving me about 1,409 characters, far off from my target of 270. I think I should be able to create the brainfuck code with a string of about 60 characters. So my question is, is there any way to convert the above string to a string of 60 characters that can later be decoded back to the string?
It's most probably impossible. Brainfuck isn't magic. The current record for shortest code to print the 13-char string "Hello, World!" is an entire 78 bytes.:
--<-<<+[+[<+>--->->->-<<<]>]<<--.<++++++.<<-..<<.<+.>>.>>.<<<.+++.>>.>>-.<<<+.
I suggest you read the post, but a TL;DR for you is that the tape is first initialized with a recurrence relation, then poke around the tape to print the appropriate characters.
78 bytes for thirteen characters. On a relatively simple string. That's 6 bytes for each character. Using the same metric as a rough guide (and this result is an underestimate), your string would take 1068 characters--at a minimum. Given that, however, the tape initialization occurs only once, and this can be surprisingly small, you may (may) be able to get it down to the high 900 or 800s. Your string also happens to be more complex and differ very widely in ASCII values, something even a recurrence relation is unlikely to solve. I however have no example that small.
If you give the inverse of Base (#.^:_1) a list as the left argument, it will produce the same result as Antibase (#:):
24 60 (#.^:_1) 123456
17 36
24 60 (#:) 123456
17 36
If you give Antibase (#:) a single left argument, it duplicates the Residue (|), rather than the inverse of Base (#.^:_1):
8 #: 1234
2
8 | 1234
2
8 (#.^:_1) 1234
2 3 2 2
Under what circumstances would the behavior of Antibase be superior to an inverted Base? And why wouldn't you just use Residue in those places? I feel like I must be missing something obvious about the utility of Antibase's behavior.
To start with: the J Dictionary defines #.^:_1 to be equivalent to #:, so it shouldn't be surprising that they're (mostly) interchangeable. In particular, the Vocabulary page for #: says :
r&#: is inverse to r&#."
And this theoretical equivalence is also supported in practice. If you ask the implementation of J for the its definition of #.^:_1, using the super-cool adverb b., you'll get:
24 60 60&#. b._1
24 60 60&#:
Here, we can see that all #.^:_1 is doing is deferring to #:. They're defined to be equivalent, and now we can see #.^:_1 -- at least in the case of a non-scalar LHA¹ -- is simply passing its arguments through to #:.
So how do we explain the discrepancy you observed? Well it turns out that, even in the pure halls of J, theory differs from practice. There is an inconsistency between dyads #: and #.^:_1 and, at least in the case of scalar left arguments, the behavior of the latter is superior to the former.
I would (and have) argue that this discrepancy is a bug: the Dictionary, quoted above, states the two dyads are equivalent, but that assertion is wrong when 0-:#$r (i.e. r is a scalar). Take r=.2 for example: (r&#: -: r&#.^:_1) 1 2 3 does not hold. That is, if the Dictionary's assertion (quoted above) is true, that statement should return 1 (true), but it actually returns 0 (false).
But, as you pointed out, it is a useful bug. Which is to say: I'd prefer the definition of #: were changed to match #.^:_1, rather than vice-versa. But that's the only time #.^:_1 is more convenient than #:. In all other cases, they're equivalent, and because #: is a primitive and #.^:_1 is compound phrase with a trailing _1, the former is much more convenient.
For example, when your right-hand argument is a numeric literal, it's easy to get that inadvertently attached to the _1 in #.^:_1, as in 2 2 2 2 #.^:_1 15 7 4 5, which will raise an error (because _1 15 7 4 5 is lexed as a single word, and therefore taken, as a whole, to be the argument to ^:). There are ways to address this, but none of them are as convenient or simple as using #:.
You could make a counterargument that in most cases, the LHA will be a scalar. That's an empirical argument, which will vary from codebase to codebase, but I personally see a lot of cases like 24 60 60 #: ..., where I'm trying to break up timestamps into duration buckets (hours, minutes, seconds), or (8#2)#: ..., where I'm trying explode bytes into exactly 8-bit vectors (contrasted to, e.g., 8 #.^:_1 ..., which will break bytes into as many bits as it takes, whether that's 8 or 3 or 17¹). And I'd further argue that in the J community, these are both commonly-used and instantly-recognizable idioms, so the use of #: assists with clarity and team communication.
But, bugs notwithstanding, ultimately #: and #.^:_1 are defined to be equivalent, so which one you use is really a matter of taste. (Then why define #.^:_1 at all, you ask? Well, that's a whole 'nother story.)
¹ PS: Wanna see something cool? How does #.^:_1 achieve its magic for scalar LHAs? Let's just ask J!
2&#. b._1
($&2#>:#(2&(<.#^.))#(1&>.)#(>./)#:|#, #: ]) :.(2&#.)
First off, notice the (by now) completely unsurprising use of #:. All #.^:_1 is doing is calculating the appropriate LHA for #:.
Second, the phrase $&2#>:#(2&(<.#^.))#(1&>.)#(>./)#:|#, shows you how J calculates the number of digits required to represent (the maximum value of) the y in the base (or radix) x. And it's a useful phrase unto itself, so much so that I keep a version of it around in my personal utility library:
ndr =: 10&$: :(>:#<.#^. (1 >. >./#:|#,))
ndr 1 10 100 101 NB. Number Digits Required in [default] base 10
3
16 ndr 1 10 100 101 NB. Number Digits Required in hexadecimal
2
Perhaps not an overwhelmingly compelling application but,
(4 # 256) #: 8234092340238420938420394820394820349820349820349x
is 10x faster than
256 #. inv (2^32x) | 8234092340238420938420394820394820349820349820349x
Is there is any relation between numbers' bits when one is divisible by another? What is the relation between the bits of 36 and the bit sequences of 9 or 4 or 12, or between 10 (1010) and 5 (101), or 21 (10101) and 7 (00111)?
Thanks. I am sorry if some sentence is not correct, but I hope you understand what I want.
I know this is not exactly what you're asking, but it may be helpful. There are many tricks for establishing binary number divisibility by manipulation of bits. For example a binary number is divisible by three if the sum of its even binary bits minus the sum of its odd binary bits all modulus 3 is zero. Here's a link discussing binary divisibility.
Let's take the example of 36.
36 = 0010 0100
36 is 4 * 9, that is
4 = 0100
9 = 1001
If you multiply them (like you would on a normal multiplication) you'll have
0100 x
1001
--------
0100
0000
0000
0100
-------
0100100
So essentially 0100 x 1001 = 0010 0100 (you can repeat the same for any other pair of divisors of course)
Now, is there any special relation that will allow you to get all the divisors of 36 just by looking at its bits? The answer, alas, is no :)
EDIT: there is no KNOWN relation at least but, who knows, in the future maybe some smart mathematician will find one. As of today, the answer is still no.
So you want to know if you can 'quickly' do Integer Factorization by just looking at the bits?
Good luck with that!
Obviously, that a is a multiple of b can be recognized given the binary representions of a and b (it's what the hardware does when executing the following code
boolean isMultiple = a % b == 0;
) and hence there is such a relationship.
Ask a more specific question to get a more specific response ...
The easiest to see is the number of consecutive 0 in the least significant digits designates the largest power of two that is a factor of your number n. There are apparently other tests, as DonnyD pointed out (I hadn't known that one) but I expect they're not going scale very well. If they did, public key cryptography, as it's generally implemented, would quickly become a thing of the past.
That's not to say that such methods can't be discovered / invented. For instance it's been shown that arbitrarily large numbers can be easily factored using quantum methods, but nobody's ever been actually able to implement a working system.
The bottom line is that we've entrusted our online financial system and national security apparatus to PKI based methods primarily because we assume that factoring numbers is hard for arbitrarily large numbers. But as Moron seemed to be implying in his answer, you're welcome to give it a whirl.