All Digits

[luke]

Think you could pull it off with no GOTO?

Oh hey, 5 lines.

Code: QB64: [Select]

1. test$ = SPACE$(10)
2. FOR i = 1 TO 10
3.     MID$(test$, VAL(MID$(_TRIM$(STR$(VAL(COMMAND$(1)) ^ 2)) + _TRIM$(STR$(VAL(COMMAND$(1)) ^ 3)), i, 1)) + 1, 1) = "1"
4. NEXT
5. IF test$ = STRING$(10, "1") THEN PRINT "n n^2 n^3:"; VAL(COMMAND$(1)); VAL(COMMAND$(1)) ^ 2; VAL(COMMAND$(1)) ^ 3 ELSE SHELL _DONTWAIT COMMAND$(0) + STR$(VAL(COMMAND$(1))+1)

Not tested because I'm on mobile, but you get the idea.

Admittedly it would probably be nicer if you added a SYSTEM after the SHELL so you didn't get 70 windows cluttering your screen, but I don't want to use :

[bplus]

Well this worked but if it didn't end on it's own! ;-( 

Pretty scary just the same: DON'T TRY THIS AT HOME!

Code: QB64: [Select]

1. 1 test$ = SPACE$(10)
2. FOR i = 1 TO 10
3.     MID$(test$, VAL(MID$(_TRIM$(STR$(VAL(COMMAND$(1)) ^ 2)) + _TRIM$(STR$(VAL(COMMAND$(1)) ^ 3)), i, 1)) + 1, 1) = "1"
4. NEXT
5. IF test$ = STRING$(10, "1") THEN PRINT "n n^2 n^3:"; VAL(COMMAND$(1)); VAL(COMMAND$(1)) ^ 2; VAL(COMMAND$(1)) ^ 3 ELSE RUN "Untitled " + STR$(VAL(COMMAND$(1)) + 1)
6.  

I thought I'd skip a few windows by adding 68 to command$(1), I skipped to wrong place I thought my computer was dead stuck with this going. I shut if off and turned it on and it picked up where it left off. Yikes!!!!!

Fortunately it quit at 107 * 68 = 7276

yeah 7276^2 = 52940176 and first 2 digits in cube are 38, what luck!

[SMcNeill]

I think you could go shorter like:

a$ = “ 123456789 123456798...”
label: n = n + 1
IF  _INSTR(a$, STR$(n * n) + _TRIM$(STR$(n * n * n))) THEN PRINT n, n^2, n ^3 ELSE GOTO label

Of course a$ would need all the permutations of “123456789“, with a space in front to delimitate them.  I’m not at home to test it, but it seems to me that 3 lines would be all that’s needed with the program, with such a solution.

[bplus]

I think you could go shorter like:

a$ = “ 123456789 123456798...”
label: n = n + 1
IF  _INSTR(a$, STR$(n * n) + _TRIM$(STR$(n * n * n))) THEN PRINT n, n^2, n ^3 ELSE GOTO label

Of course a$ would need all the permutations of “123456789“, with a space in front to delimitate them.  I’m not at home to test it, but it seems to me that 3 lines would be all that’s needed with the program, with such a solution.

Don't forget 0 for all 10 digits.

[luke]

I think you could go shorter like:

a$ = “ 123456789 123456798...”
label: n = n + 1
IF  _INSTR(a$, STR$(n * n) + _TRIM$(STR$(n * n * n))) THEN PRINT n, n^2, n ^3 ELSE GOTO label

Of course a$ would need all the permutations of “123456789“, with a space in front to delimitate them.  I’m not at home to test it, but it seems to me that 3 lines would be all that’s needed with the program, with such a solution.

I think you might have a little bit of trouble posting the several megabytes of source code needed to the forum for that...

And of course, there's the obvious one-liner:

Code: [Select]

?69

[SMcNeill]

I think you might have a little bit of trouble posting the several megabytes of source code needed to the forum for that...

And of course, there's the obvious one-liner:

Code: [Select]

?69

Just remember, I never promised it'd be the smallest file size...  It'd just be the fewest lines for a program, that I can think of.  From my poor math skills, the permutation would be about 38MB for that first search line, so a$ is one laaaaaaarge string, but the rest of the program is rather short and simple.  :)

It also helps highlight one of the glaring problems I tend to notice with "shortest program" contests.  Sure, somebody might be able to cram everything onto a single line of code, but their overall character count is much higher than some of the other folks out there...  Fewest lines does not necessarily equate smallest program, in my opinion, but one has to play by the rules of any contest (and their loopholes...).   ;)

Three lines, without compound statements on the same line, is the smallest number I think I can conceive for the problem at hand. 

[bplus]

10! permutations = 720*210*24 = 3,628,800 * (10 digits + 1 space) = 11! digits 39,916,800

Can a line that long be compiled?

[Cobalt]

10! permutations = 720*210*24 = 3,628,800 * (10 digits + 1 space) = 11! digits 39,916,800

Can a line that long be compiled?

2 programs needed to find that out.

program 1:

FOR I&= 0 TO 39916800
 A$=A$+LTRIM$(STR$(INT(RND*10)))
NEXT I&
_CLIPBOARD A$
END

Program 2
A$ = 'PASTE CLIPBOARD HERE

and wait........
and wait.......
and wait.......

will the IDE ever actually process that? I image someday it will but mine never finished.
well to be honest I got tired of waiting. It might have actually crashed but I just force closed the IDE.

[luke]

It also helps highlight one of the glaring problems I tend to notice with "shortest program" contests.  Sure, somebody might be able to cram everything onto a single line of code, but their overall character count is much higher than some of the other folks out there...  Fewest lines does not necessarily equate smallest program, in my opinion, but one has to play by the rules of any contest (and their loopholes...).   ;)

This is why code golf competitions are on number of characters, not number of lines.

https://codegolf.stackexchange.com/

[SMcNeill]

2 programs needed to find that out.

program 1:

FOR I&= 0 TO 39916800
 A$=A$+LTRIM$(STR$(INT(RND*10)))
NEXT I&
_CLIPBOARD A$
END

Program 2
A$ = 'PASTE CLIPBOARD HERE

and wait........
and wait.......
and wait.......

will the IDE ever actually process that? I image someday it will but mine never finished.
well to be honest I got tired of waiting. It might have actually crashed but I just force closed the IDE.

Why not generate the code as you go, so all you need to do is compile?

OPEN “test.bas” FOR OUTPUT AS #1
PRINT #1, “a$ = “; CHR$(34);
FOR I&= 0 TO 39916800
   PRINT #1, LTRIM$(STR$(INT(RND*10)));
NEXT I&
PRINT #1, CHR$(34)
PRINT #1, “PRINT a$”
CLOSE

Then just compile test.bas.  ;)

[bplus]

OK byte count it is (to save Steve from hell proving theoretical idea), a re-evaluation then of contenders :)
I also better explicitly state that the QB64 IDE v 1.4 stable sets the bytes and judges the syntax.

Richard Frost (rewritten by me to optimize bytes) 7 lines 225 bytes:

Code: QB64: [Select]

1. 1 n = n + 1
2. n$ = LTRIM$(STR$(n * n)) + LTRIM$(STR$(n ^ 3))
3. FOR i = 0 TO 9
4.     p = INSTR(n$, CHR$(48 + i))
5.     IF p THEN MID$(n$, p, 1) = "x" ELSE GOTO 1
6. NEXT i
7. IF n$ = "xxxxxxxxxx" THEN PRINT n; n * n; n ^ 3 ELSE GOTO 1
8.  

bplus 6 liner at 199 bytes:

Code: QB64: [Select]

1. 1 n = n + 1
2. t$ = SPACE$(10)
3. FOR i = 1 TO 10
4.     MID$(t$, VAL(MID$(_TRIM$(STR$(n * n)) + _TRIM$(STR$(n ^ 3)), i, 1)) + 1, 1) = "1"
5. NEXT
6. IF t$ = "1111111111" THEN PRINT n; n ^ 2; n ^ 3 ELSE GOTO 1
7.  

Luke's 5 liner but 301 bytes (rewritten with same byte savings applied to bplus and Richard Frost but not tested again)

Code: QB64: [Select]

1. 1 t$ = SPACE$(10)
2. FOR i = 1 TO 10
3.     MID$(t$, VAL(MID$(_TRIM$(STR$(VAL(COMMAND$(1)) ^ 2)) + _TRIM$(STR$(VAL(COMMAND$(1)) ^ 3)), i, 1)) + 1, 1) = "1"
4. NEXT
5. IF t$ = "1111111111" THEN PRINT VAL(COMMAND$(1)); VAL(COMMAND$(1)) ^ 2; VAL(COMMAND$(1)) ^ 3 ELSE RUN "Untitled " + STR$(VAL(COMMAND$(1)) + 1)
6.  

[SMcNeill]

OK byte count it is (to save Steve from hell proving theoretical idea), a re-evaluation then of contenders :)

And I was just starting to test my idea, with this little program:

Code: QB64: [Select]

1. OPEN “test.bas” FOR OUTPUT AS #1
2. PRINT #1, “a$ = “; CHR$(34);
3. FOR I&= 0 TO 39916800
4.    PRINT #1, LTRIM$(STR$(INT(RND*10)));
5. NEXT I&
6. PRINT #1, CHR$(34)
7. PRINT #1, “PRINT a$”
8. CLOSE

This gives us a single line with 39MB worth of data stored into a single string, and saves it as "test.bas".  Running the little program here takes about half a minute to finish generating our string for us, and saving it to disk...  Loading the file it creates into the IDE only takes about 2 seconds on my PC, and compilation into a working EXE only takes about 10 seconds or so.

Amazingly enough -- and I'm not certain how the hell this works -- but the EXE is *smaller* than the source code!!

Interestingly enough, neither QB64, nor the c-compiler we pack with QB64, had any issues whatsoever with the code.  It loaded, compiled, and executed just as simple as could be!

3 lines for the program (though incredibly loooooong lines of pre-generated data), is the fewest lines I think I'd call possible with this type of program in QB64.  (Of course, since we've decided to go by byte-count for "shortest program" and not "line-count", there's no reason for me to generate that data list and prove the concept valid any longer, so I'm not going to bother with any more testing than what I've did here.)

Regardless, it's always fun to try and think outside the box, to find a completely different solution than everyone else's.  I think my concept definitely does that, even if it does require a 39MB, 3-line program...  ;D

[bplus]

And I was just starting to test my idea, with this little program:

Code: QB64: [Select]

1. OPEN “test.bas” FOR OUTPUT AS #1
2. PRINT #1, “a$ = “; CHR$(34);
3. FOR I&= 0 TO 39916800
4.    PRINT #1, LTRIM$(STR$(INT(RND*10)));
5. NEXT I&
6. PRINT #1, CHR$(34)
7. PRINT #1, “PRINT a$”
8. CLOSE

This gives us a single line with 39MB worth of data stored into a single string, and saves it as "test.bas".  Running the little program here takes about half a minute to finish generating our string for us, and saving it to disk...  Loading the file it creates into the IDE only takes about 2 seconds on my PC, and compilation into a working EXE only takes about 10 seconds or so.

Amazingly enough -- and I'm not certain how the hell this works -- but the EXE is *smaller* than the source code!!

Interestingly enough, neither QB64, nor the c-compiler we pack with QB64, had any issues whatsoever with the code.  It loaded, compiled, and executed just as simple as could be!

3 lines for the program (though incredibly loooooong lines of pre-generated data), is the fewest lines I think I'd call possible with this type of program in QB64.  (Of course, since we've decided to go by byte-count for "shortest program" and not "line-count", there's no reason for me to generate that data list and prove the concept valid any longer, so I'm not going to bother with any more testing than what I've did here.)

Regardless, it's always fun to try and think outside the box, to find a completely different solution than everyone else's.  I think my concept definitely does that, even if it does require a 39MB, 3-line program...  ;D

Odd that you would quit now? Do you need the a$ = " part? 

working...

Hey what's with the weird quotes? i copied pasted your start code but yuck!

[bplus]

It's impossible to edit the file when the first line is written.

And this is loaded with errors:

Code: QB64: [Select]

1. a$ = “ 123456789 123456798...”
2. label: n = n + 1
3. IF  _INSTR(a$, STR$(n * n) + _TRIM$(STR$(n * n * n))) THEN PRINT n, n^2, n ^3 ELSE GOTO label
4.  

Had to make a code example for line 2 and 3 to write with the first line.

Code: QB64: [Select]

1. a$ = "4761328509 "
2. 1 n = n + 1
3. IF INSTR(a$, _TRIM$(STR$(n * n)) + _TRIM$(STR$(n ^ 3))) THEN PRINT n, n ^ 2, n ^ 3 ELSE GOTO 1

And run the first line maker again with all 3 lines written. Hopefully I can at least run the sucker.

[luke]

When I copied the bplus six liner it was 201 bytes instead of 199, not too sure why.

Anyway, if we do away with insisting on proper formatting and take a few other tricks, you can get it down to 142 characters:

Code: QB64: [Select]

1. 1n=n+1
2. t$=SPC(10)
3. FOR i=2TO 11
4. MID$(t$,VAL(MID$(STR$(n*n)+_TRIM$(STR$(n^3)),i,1))+1,1)="1"
5. NEXT
6. IF t$="1111111111"THEN?n;n^2;n^3 ELSE 1

I was thinking to replace VAL(MID$(x$, i, 1)) + 1 with 49 + ASC(x$, i), but unfortunately ASC gives an error if you go past the end of the string :(