"5-line" engine

[GareBear]

I was not trying to belittle what James D. Jarvis or anyone else was doing. I think it is something else that someone can do that with any code and it does what it written for. There are those who belittle any dialect of Basic, thinking it is for doing doing simple stuff. They hasn't been here seeing what is being presented with pride and love for all to see. I like how the QB64pe is constantly is being updated for all to have a more modern experience in newer hardware as well older.

[SMcNeill]

Aye.  I didn't mean to step on anyone's toes with my opinion.  I just personally have a hard time considering colon separated code as being "one line".  At the end of the day, how much different would those colon designator be from a CRLF character such as CHR$(10)?  

Just because I turn word wrap off and you have to scroll to read each paragraph in my novel, that doesn't make it a shorter or better book than when word wrap is on.

Personally, I'd just rather see the code laid out without colons, so it's just as readable by people as it is the interpreter.  But then, that may just be *ME*.  

[JRace]

To each his own.

James wanted to see what he could accomplish in 5 lines.  I think that such self challenges are good.  They can force a person to think creatively, to see how much they can accomplish within their arbitrarily chosen constraints.

Sure, all those colons may be stretching (or breaking) the rules in some peoples' minds, but in coding challenges rules are made to be stretched.  It's all in fun.

[GareBear]

SMcNeill, Maybe I can help you understand GWBasic interpreter. It has to have a number for each line of instruction. To make the code fit in the least amount of memory colons were allowed to let more code per memory. To the interpreter this is one line with the chr$(13) at the end. Having Chr$(13) after each code took up more memory. The best way to see this take James D Jarvis's code and break it into a line for each instruction (no colons) and save it. Go to your file listing and see the original that James D. Jarvis did and the one that you took the colons out of and see the difference in size of the files. The IDE is not restrained with small memory. Like 64k for example. Colons are as you know are for backward compatibility. I hope you understand what I said. If not I may have muddied up the waters with my attempt. To use colons or not to use them is what the programmer want in the code they composed and it works for all to see.  - GareBear.

[SMcNeill]

SMcNeill, Maybe I can help you understand GWBasic interpreter. It has to have a number for each line of instruction. To make the code fit in the least amount of memory colons were allowed to let more code per memory. To the interpreter this is one line with the chr$(13) at the end. Having Chr$(13) after each code took up more memory. The best way to see this take James D Jarvis's code and break it into a line for each instruction (no colons) and save it. Go to your file listing and see the original that James D. Jarvis did and the one that you took the colons out of and see the difference in size of the files. The IDE is not restrained with small memory. Like 64k for example. Colons are as you know are for backward compatibility. I hope you understand what I said. If not I may have muddied up the waters with my attempt. To use colons or not to use them is what the programmer want in the code they composed and it works for all to see.  - GareBear.

Here's my point in one line:

Code: (Select All)

Screen _NewImage(80, 45, 0): _FullScreen: _ControlChr Off: _PrintString (1, 1), String$(3280, 219): dx = 40: dy = 20: Randomize Timer: s = Int(200 + Rnd * (100 * (1 + Rnd * 4))): For d = 1 To s: m$ = m$ + Chr$(49 + Int(Rnd * 4)): Next d: px = 40: py = 20: stand = 0: Do: dx = 40: dy = 20: Color 7: _PrintString (1, 1), String$(3280, 219): For c = 1 To Len(m$): _PrintString (dx, dy), ".": Select Case Mid$(m$, c, 1): Case "1": dy = dy - 1: Case "2": dx = dx + 1: Case "3": dy = dy + 1: Case "4": dx = dx - 1: End Select: Select Case dy: Case 40, 1: dy = 20: dx = 40: End Select: Select Case dx: Case 80, 1: dy = 20: dx = 40: End Select: Next c: Color 15: _PrintString (px, py), Chr$(2): Do: _Limit 40: kk$ = InKey$: Loop Until kk$ <> "": kk$ = UCase$(kk$): pxm = 0: pym = 0: Select Case kk$: Case "W": pym = -1: Case "S": pym = 1: Case "D": pxm = 1: Case "A": pxm = -1: End Select: Select Case Screen(pym + py, pxm + px, 0): Case 219: pxm = 0: pym = 0: End Select: px = px + pxm: py = py + pym: Loop Until kk$ = Chr$(27)

Now, how much sexier is my contributation to this effort, than the original 5-line program?  I managed to work and strain and shorten things down to where it can all be ran on just a single line...

This doesn't make smaller EXEs.   It doesn't translate to less assembly when compiling.  The c-output of the translated files isn't different.  The only change is it's more scrolling left to right in the IDE and no use of the vertical screen.  I've obfuscated the code so it's harder for a human to read, but did nothing to change the machine behavior -- but, by Golly, it's only a single line now!

[MasterGy]

SMcNeill, Maybe I can help you understand GWBasic interpreter. It has to have a number for each line of instruction. To make the code fit in the least amount of memory colons were allowed to let more code per memory. To the interpreter this is one line with the chr$(13) at the end. Having Chr$(13) after each code took up more memory. The best way to see this take James D Jarvis's code and break it into a line for each instruction (no colons) and save it. Go to your file listing and see the original that James D. Jarvis did and the one that you took the colons out of and see the difference in size of the files. The IDE is not restrained with small memory. Like 64k for example. Colons are as you know are for backward compatibility. I hope you understand what I said. If not I may have muddied up the waters with my attempt. To use colons or not to use them is what the programmer want in the code they composed and it works for all to see.  - GareBear.

Here's my point in one line:

Code: (Select All)

Screen _NewImage(80, 45, 0): _FullScreen: _ControlChr Off: _PrintString (1, 1), String$(3280, 219): dx = 40: dy = 20: Randomize Timer: s = Int(200 + Rnd * (100 * (1 + Rnd * 4))): For d = 1 To s: m$ = m$ + Chr$(49 + Int(Rnd * 4)): Next d: px = 40: py = 20: stand = 0: Do: dx = 40: dy = 20: Color 7: _PrintString (1, 1), String$(3280, 219): For c = 1 To Len(m$): _PrintString (dx, dy), ".": Select Case Mid$(m$, c, 1): Case "1": dy = dy - 1: Case "2": dx = dx + 1: Case "3": dy = dy + 1: Case "4": dx = dx - 1: End Select: Select Case dy: Case 40, 1: dy = 20: dx = 40: End Select: Select Case dx: Case 80, 1: dy = 20: dx = 40: End Select: Next c: Color 15: _PrintString (px, py), Chr$(2): Do: _Limit 40: kk$ = InKey$: Loop Until kk$ <> "": kk$ = UCase$(kk$): pxm = 0: pym = 0: Select Case kk$: Case "W": pym = -1: Case "S": pym = 1: Case "D": pxm = 1: Case "A": pxm = -1: End Select: Select Case Screen(pym + py, pxm + px, 0): Case 219: pxm = 0: pym = 0: End Select: px = px + pxm: py = py + pym: Loop Until kk$ = Chr$(27)

Now, how much sexier is my contributation to this effort, than the original 5-line program?  I managed to work and strain and shorten things down to where it can all be ran on just a single line...

This doesn't make smaller EXEs.   It doesn't translate to less assembly when compiling.  The c-output of the translated files isn't different.  The only change is it's more scrolling left to right in the IDE and no use of the vertical screen.  I've obfuscated the code so it's harder for a human to read, but did nothing to change the machine behavior -- but, by Golly, it's only a single line now!

[SMcNeill]

Here's something to showcase why we should stay away from these line conjoinment programs:

Code: (Select All)

Screen _NewImage(80, 45, 0)

_FullScreen

_ControlChr Off

'_PrintString (1, 1), String$(3280, 219)  'unneeded as the screen is blank to begin with

'dx = 40                                  'unneeded as it's set inside the DO LOOP

'dy = 20                                  'as above

Randomize Timer

's = Int(200 + Rnd * (100 * (1 + Rnd * 4))) 'why use a line for this?

For d = 1 To Int(200 + Rnd * (100 * (1 + Rnd * 4))) 's can just be used here directly.

    m$ = m$ + Chr$(49 + Int(Rnd * 4))

Next d

px = 40

py = 20

'stand = 0  'no need for this, there's no usage of stand in the whole program

Do

    dx = 40

    dy = 20

    Color 7

    _PrintString (1, 1), String$(3280, 219)

    For c = 1 To Len(m$)

        _PrintString (dx, dy), "."

        Select Case Mid$(m$, c, 1)

            Case "1": dy = dy - 1

            Case "2": dx = dx + 1

            Case "3": dy = dy + 1

            Case "4": dx = dx - 1

        End Select

        'Select Case dy        '  all these lines can be consolodated into one simple IF

        '    Case 40, 1: dy = 20: dx = 40

        'End Select

        'Select Case dx

        '    Case 80, 1: dy = 20: dx = 40

        'End Select

        If dy = 40 Or dy = 1 Or dx = 80 Or dx = 1 Then dy = 20: dx = 40

    Next c

    Color 15

    _PrintString (px, py), Chr$(2)

    'Do

    '    _Limit 40

    '    kk$ = InKey$

    'Loop Until kk$ <> "": kk$ = UCase$(kk$)

    kk$ = UCase$(Input$(1))

    pxm = 0

    pym = 0

    Select Case kk$

        Case "W": pym = -1

        Case "S": pym = 1

        Case "D": pxm = 1

        Case "A": pxm = -1

    End Select

    'Select Case Screen(pym + py, pxm + px, 0) 'three lines easily consolodates down to a single line

    '    Case 219: pxm = 0: pym = 0

    'End Select

    If Screen(pym + py, pxm + px, 0) = 219 Then pxm = 0: pym = 0

    px = px + pxm

    py = py + pym

Loop Until kk$ = Chr$(27)

Now, this is the exact same program as the original, though it's been spread out and expanded to make it more easily readable to humans.  By keeping it human readable, what do we see here:

1) Unneeded screen clear of a blank screen.
2) Unneeded initialization of variables dx and dy.  The DO loop does this as the very first thing.
3) Unneed use of a variable we could insert directly
4) A completely stray and unused variable.  Why hasn't someone caught and removed this already?
5) 6 lines of SELECT CASE which can be broken down to one simple IF statement
6) 4 lines of a DO..LOOP that can be easily replaced with a single line INPUT$ statement
7) 3 more lines of SELECT CASE which can be easily broken down to one simple IF statement

Why 5 lines was chosen to compress this program down into, is a mystery to me.  Why not ten?  Or three?  Or one?   

But if the goal is to reduce it to the smallest size possible, then why does it have unneeded initialization?  Unused variables?

Does this help to highlight WHY I'm not a big fan of these sort of "Cram it all on one line" programs?  Like @blpus , I'm one of those folks who like to see how short a program can get and what can be accomplished in the fewest number of lines possible.   I just dont personally feel like using colons to cram everything onto a single line really counts.

After all, I've shortened the original code here by several commands.  Yet....  If this was a contest, the original would win over this one just because....  It uses more colons??

[SMcNeill]

Another code reduction:

If Screen(pym + py, pxm + px, 0) = 219 Then pxm = 0: pym = 0
px = px + pxm
py = py + pym

This can be reduced down to:

If Screen(pym + py, pxm + px, 0) <> 219 Then px = px + pxm: py = py + pym

[MasterGy]

We are dealing with a very interesting question.

I feel that there are 2 different topics, and because of that, the perception may be different.

Topic 1: James playfully announced a challenge, the goal of which is to create a game by adding as little code (or as few lines) as possible. He himself tried to make the sizes as small as possible. It prefers to use a SELECT CASE instruction instead of IF, because it is well known that we are forced to press ENERT after the end of the IF line. Perhaps he considered the aesthetics of compression important and wanted to suggest that the program consists of 5 lines. It's a challenge. If we accept his rules of the game and what he asked the community to do, then different meaningful works can be created. A playful and creative process begins.

(this is what happens instead )

Topic 2: usefulness of coding compression
Do I need a ":" character? should we cram everything together, or should it be more transparent? I think that it partly depends on the individual (to whom what is more transparent), and on the other hand, the complexity of the task also determines what is more beneficial for us. In the case of James's program, if development and comprehensibility are the goal (rather than player challenge), then compression is unjustified. You are absolutely right! There is a limit to this. It is also important to consider how big the program will be. If I were to leave the code blank when writing a program, the pageup and pagedown buttons would quickly wear out. I'll try to compress it at the very beginning.

We agree that if the basic principle is that the programmer's code can be understood by himself and others, then it is appropriate to express the plot in the simplest possible way.

I think everyone who is here on the forum has enough experience to decide what is beneficial for themselves and what is beneficial in the event that we want to share a code with others.

[GareBear]

MadterGy, You put that the way I wanted to put it. Thank you!

SMcNeil, I am sorry to have offended you. It was not my intention to do any such thing. The difference between the two you did, James D Jarvis and the way you want to do is not much here in the sizes between them. 

Broke down into single command lines - 1.9k 1862 bytes - SMcNeill's
With colons - 1.0k or 1022 bytes - James D Jarvis'
1862 - 1022 = 840 bytes or 0.9k not much compression.

This prove MasterGy's program compression. Which GWBasic needed to run programs in which people then was trying to push the limits of the interpreter. Some like Jame D Jarvis like to have fun with the old way of using very little to no line numbers.

To all involved, Let us all try not take this too seriously and let others have flexibly in our creativity in the language we choose to use and learn from each other. - GareBear.