Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Pete

Pages: 1 [2] 3 4 ... 158
16
QB64 Discussion / Re: What's your philosophy about constants?
« on: March 26, 2022, 01:26:57 pm »
Makes me wonder how the human species managed to land anything on Mars ...

Simple, they used my string-math method! Oh wait, that's how Columbus discovered India, only it turned out to be America. Oh well, he identified the indigenous people as Indians, so that's all that really mattered. But the more important question is, why do people think if Martians existed, they would be smarter than humans? After all, they have antenna, and we have cable!

Pete

17
QB64 Discussion / Re: What's your philosophy about constants?
« on: March 26, 2022, 01:14:15 am »
My philosophy on constants:  it's something between a micro-optimization and a sanity check for a symbolic representation of a literal (not live-computed) value.  I.e.:  it's ugly to type 3.141593 every time you need it so CONST pi=4*atn(1) lets the compiler calculate it for you at compile time then type it in for you.  The physical result is that it's global, just like a literal "3.1415.." is, and should compile with the same performance as a literal value.  What Steve and the gang actually do with it is none of my business, as long as my code looks pretty.

That one works, but I wonder if relying on the compiler to produce the value of some other calculated number to use as a constant could cause an inconsistency if one program was compiled on a 32-bit and another on a 64-bit system?

Pete

18
QB64 Discussion / Re: What's your philosophy about constants?
« on: March 24, 2022, 09:24:28 pm »
Which is easier to type:

Const pi = 3.1415

or

Dim Shared pi as some type
pi = 3.1415

Ah...

Pi = 3.1419

Nice thing about BASIC. It automatically uses a default SINGLE designation for Pi, in this case. No need to DIM it.

Pete

I take a dim view of Dim.

19
QB64 Discussion / Re: What's your philosophy about constants?
« on: March 23, 2022, 06:51:56 pm »
@bplus That's the most common use for "constants" in a program, but you don't actually need the CONST to do it...

pi = 3.14159
' blah, blah, blah
PRINT 27 * pi
' blah, blah, blah
PRINT pi / 2
' etc, etc., etc.

So just change the variable pi at the top, to any number of acceptable digits, and it works just the same as CONST, except it won't throw a compiler error if you mistakenly assign pi to a different number someplace else in the program.

Pete


20
QB64 Discussion / Re: What's your philosophy about constants?
« on: March 23, 2022, 06:14:18 pm »
Code: QB64: [Select]
  1. DIM currMiles#
  2. CONST ConvertMilesToKilometers# = 1.60934
  3. '-------------------------------------------
  4.     CLS
  5.     INPUT "enter number of miles: "; currMiles#
  6.     PRINT STR$(currMiles#) + " miles, that's: " + STR$(currMiles# * ConvertMilesToKilometers#) + " kilometers."
  7.     PRINT: PRINT "press a key to start again": WHILE INKEY$ = "": WEND

I miss DEF FN, too, but by definition, CONSTANT means a variable that never changes. That is to say the compiler sets aside less space, because it is a fixed value.

I had a discussion in antoehr thread about this, let's see...

"I hardly ever use constants. From the old days, it was a way to save that coveted stack space. This is because a constant is compiled with less allocated space, since the compiler knows it won't be changing in value. Those days are behind us, so this type of optimization is now more of a coding preference than a necessity for large applications. Readability is somewhat an advantage to constants. The programmer, or someone else studying the code, is informed of the variables which are fixed. No need to track them when debugging. For coders who have a hard time keeping things straight, constants prevent the mistake of taking a non declared variable, meant to be a constant, and mistakenly assigning it a new value, someplace in the code. That's called OOPs programming!"

Pete

21
QB64 Discussion / Re: Variable v's Fixed Value
« on: March 22, 2022, 12:11:27 pm »
@Dimster I hardly ever use constants. From the old days, it was a way to save that coveted stack space. This is because a constant is compiled with less allocated space, since the compiler knows it won't be changing in value. Those days are behind us, so this type of optimization is now more of a coding preference than a necessity for large applications. Readability is somewhat an advantage to constants. The programmer, or someone else studying the code, is informed of the variables which are fixed. No need to track them when debugging. For coders who have a hard time keeping things straight, constants prevent the mistake of taking a non declared variable, meant to be a constant, and mistakenly assigning it a new value, someplace in the code. That's called OOPs programming!

I'm interested to seeing MasterGy's reply to your question, as well. It's great to get other coders perspectives on coding style. Something we should probably discuss more on these forums. Great question!

Pete

22
QB64 Discussion / Re: QB64 10-Liner programs or games
« on: March 21, 2022, 12:03:42 pm »
I don't like lines extended over to China horizontally because of use of colons but do like these little ditties, with single statements per line. Neither do I like too many single letter variables unless they are obvious like x, y, mx, my, s$ for temp string of text$. I like nice readable short code.

I have an idea for a game library to make writing 10 liners, more or less, easier.
Why waste code on the usual sh... stuff?

For instance the game library could have:
Code: QB64: [Select]
  1. Const Sh = 800, Sw = 600
  2. DIM SHARED AS LONG Mx, My, k$, done, Lim
  3. Screen _NewImage(Sw, Sh, 32)
  4.    Cls
  5.    Mx = _MouseX: My = _MouseY
  6.    k$ = Inkey$
  7.    PlayGameCodeHere  ' read and execute your 10 liner here
  8.    _Limit Lim ' let coder set Lim
  9. Loop Until done

Actually that would be the main code and then $Include the 10 liner game.

@bplus You have a lot of tricks up your sleeve, but I'll bet DIMming k$ as "LONG" is not one of them. :D

I completely agree about the line challenge and non-use of colons. Every colon is another line, in my opinion. Oh course, characters could be counted, but that's not entirely fair either, as certain keywords are longer than others.

I use the same approach to most of my larger programs. Make a central hub, and run sub-routines from it. This method allowed me to always know the program flow would continuously be cycled through that hub. Back in the old days, it provided a way to time the program, and evoke a screen saver. Other advantages existed, too.

@Dav Speaking of screen savers, in the paragraph above, I would have loved to have the plasma one you posted! Very cool!

@Kiara87 I get it, more of a discussion concerning optimization of BASIC code, rather than the use of BASIC libraries to develop OOP. Most of what I see of a practical aspect of this is the use of creative algorithms, mostly math formulas, like Dav and Bill posted in their 10-liners. The downside of "optimization" when it comes to limiting lines of code, ironically, results in obfuscation, much the same too many lines of convoluted code produce. Use of GOTO statements, for example, to cut down on a loop line code. I consider that bad coding practice, especially to introduce it, in a positive way, to a beginner. I consider BASIC best for coders who like to build things from the foundation up. All I ever heard from C communities is "You need a library for that." That was their response to me trying to write a keyboard function in C. I eventually accomplished it, because it was possible with C/C++ statements, but I was not too happy that such a large community completely lost track of how to build a program from the foundation up.

Pete

PS @Dimster That was just a typo on Mark's part. He was just giving a skeleton, almost pseudo-code, example of how to set up a 10-line hub to run a program. Sorry for the late reply, you posted while I was writing.

23
QB64 Discussion / Re: QB64 10-Liner programs or games
« on: March 20, 2022, 10:57:45 pm »
Ha ha. SCREEN 0. Bill finally made it to the Dark Side.

Pete

24
QB64 Discussion / Re: QB64 10-Liner programs or games
« on: March 20, 2022, 10:24:19 pm »
And then it gets even uglier...

Code: QB64: [Select]
  1. x$ = LTRIM$(STR$(INT(TIMER) MOD 10 + 1))
  2. 100 LINE INPUT "Guess a number between 1 and 10. "; num$
  3. IF num$ = x$ THEN PRINT "Correct!" ELSE GOTO 100

Pete

PS Steve? This is the first for me. I don't believe I made a guess a number routine before this.


25
QB64 Discussion / Re: QB64 10-Liner programs or games
« on: March 20, 2022, 09:48:36 pm »
@bplus Sure, but then it starts to get ugly...

Code: QB64: [Select]
  1. x$ = LTRIM$(STR$(INT(RND * 10 + 1)))
  2. 100 try = try + 1
  3. LINE INPUT "Guess a number between 1 and 10. "; num$
  4. IF x$ < num$ THEN j = 1 ELSE j = 10
  5. IF num$ <> x$ THEN PRINT MID$("Too high!Too Low!", j, 9)
  6. IF num$ = x$ THEN PRINT "Yes! Number of tires to guess it was:"; try ELSE GOTO 100
  7.  

Pete

26
Programs / Re: Flower
« on: March 20, 2022, 08:52:24 pm »
Makes me think we need a new QB64 keyword...

_ROUNDUP

Pete :D

27
QB64 Discussion / Re: QB64 10-Liner programs or games
« on: March 20, 2022, 08:48:02 pm »
Sure, libraries. For instance, I made a keyboard / mouse routine I can use in any program. Steve has one of a similar nature. I suppose if the community promoted library routines, eventually we would wind up adding OOP support to QB64. The push against that. and count me in as a big pusher, is that the spirit of BASIC is to build these routines, not just utilize them. If the community became divided over such philosophical differences, I would simply recommend doing what PowerBASIC did, simply split the project. Have an OOP version and a BASIC version. In regard to PB, that would be their PowerBASIC for WIndows vs PpwerBASIC for DOS.

Pete

28
QB64 Discussion / Re: QB64 10-Liner programs or games
« on: March 20, 2022, 08:02:14 pm »
You mean something like this?

Code: QB64: [Select]
  1. x$ = LTRIM$(STR$(INT(RND * 10 + 1)))
  2.     try = try + 1
  3.     LINE INPUT "Guess a number between 1 and 10. "; num$
  4.     IF x$ < num$ THEN j = 1 ELSE j = 10
  5.     IF num$ = x$ THEN EXIT DO ELSE PRINT MID$("Too high!Too Low!", j, 9)
  6. IF try = 1 THEN PRINT "You guessed it in 1 try!" ELSE PRINT "You guessed it in"; try; "tries!"

Pete

- I'm really more of a one-liner kind of guy.

29
Programs / Re: Double Pendulum Studies
« on: March 20, 2022, 06:51:00 pm »
If only we had QB64 for the iwatch! Oh well, I think I'll wait for the digital version.

Pete

30
Programs / Re: Double Pendulum Studies
« on: March 20, 2022, 01:12:59 pm »
Both of these last two code examples are great, but totally unrealistic. You guys are missing the Tangle Effect. This is a law of physics that states any string in motion eventually ends up as a knot. Yep, you guessed it. Pete's knot happy!

Maybe we need a computer simulation board. These are, kidding aside, very cool!

Pete

Pages: 1 [2] 3 4 ... 158