QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: CharlieJV on March 23, 2022, 05:59:26 pm

Title: What's your philosophy about constants?
Post by: CharlieJV on March 23, 2022, 05:59:26 pm
So putting on your QB64 hat and/or a "BASIC in General" hat ...

I wasn't happy with wwwBASIC's implementation of constants (https://github.com/google/wwwbasic/blob/master/wwwbasic.js), very early stages, direction I wasn't crazy for (search for third occurrence of"'const" on that page if you dare), so I decided to rejig things in BASIC Anywhere Machine's fork of wwwBASIC.

Without planning on it, I wound up with the CONST statement working exactly like a "FN-less" and parameter-less version of DEF FN.

So now the following code runs A-1 in my dev version (EDIT: now in my online version) of BASIC Anywhere Machine (https://basicanywheremachine.neocities.org/):

Code: QB64: [Select]
  1. dim currMiles#
  2. const currKilometers# = currMiles# * 1.60934
  3. '-------------------------------------------
  4.         cls
  5.         input "enter number of miles: "; currMiles#
  6.         print str$(currMiles#) + " miles, that's: " + str$( currKilometers# ) + " kilometers."
  7.         print : print "press a key to start again" : while inkey$ = "" : wend
  8.  

Although totally unorthodox for BASIC, there's something I semantically really like about it.  A special soupçon of je-ne-sais-quoi.

It has me wondering, though, what dp die-hard BASIC folk think of that?  Does it just annoy you?  Or give you the creeps?  Or is this a total 5-alarm fire ?

And how would you do this in an orthodox QB64 (or general/traditional BASIC) way ?
Title: Re: What's your philosophy about constants?
Post by: Pete 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
Title: Re: What's your philosophy about constants?
Post by: CharlieJV on March 23, 2022, 06:32:34 pm
(SNIP!)

I guess I'm seeing currKilometers# as being (tongue in cheek) CONS(IS)TANT(LY), or CONSTANTLY matching currMiles# ...

Groan ...
Title: Re: What's your philosophy about constants?
Post by: STxAxTIC on March 23, 2022, 06:33:00 pm
my ted talk on const, 2022 edition:
const is completely redundant to ordinary variables, and its implemented more stupidly. so don't use it.
no, i mean it: const is nothing but a brain diaper. if you aren't sure whether you're editing your variables, you should go use an easy language like QBAS--- wait. step away from the computer instead.
... and that's what i say!

my credentials for having this opinion:
i do motivational talks for battered women and entertainment at youth mitzvah parties

Title: Re: What's your philosophy about constants?
Post by: bplus on March 23, 2022, 06:44:28 pm
I use constants they are very handy, change one value in code and throughout your program the values are updated.

Only a fool would argue against such a convenience.
Title: Re: What's your philosophy about constants?
Post by: CharlieJV on March 23, 2022, 06:47:13 pm
(SNIP!)
const is completely redundant to ordinary variables, and its implemented more stupidly. so don't use it.
no, i mean it: const is nothing but a brain diaper.
(SNIP!)

I've got a couple of cognitive disorders going on, so I rely heavily on well-organized (EDIT: "well" is definitely in the eyes of the beholder, so let's say "organized to the gills in a way that fits the particular brain"), with very visible yet non-distracting visual cues to understand and remember.

Just saying I need that brain diaper because of cognitive incontinence.

How fortunate are those without dependence on a brain diaper?  (Yeah, a little envious am I ...)

Self-deprecating humour aside, them are great points.
Title: Re: What's your philosophy about constants?
Post by: Pete 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

Title: Re: What's your philosophy about constants?
Post by: bplus on March 23, 2022, 07:01:24 pm
Which is easier to type:

Const pi = 3.1415

or

Dim Shared pi as some type
pi = 3.1415
Title: Re: What's your philosophy about constants?
Post by: CharlieJV on March 23, 2022, 07:03:54 pm
I use constants they are very handy, change one value in code and throughout your program the values are updated.

Only a fool would argue against such a convenience.

Ditto.  (Except fool.  Anybody's fool might just be my Huckleberry for one thing or another...)

Although that can just as easily be done with a variable, constant has a certain cognitive soupçon of je-ne-sais-quoi along with a "define me and I will protect thee from thyself and any muck-ery which might be afoot down the road" safeguard.
Title: Re: What's your philosophy about constants?
Post by: bplus on March 23, 2022, 07:05:26 pm
Quote
"define me and I will protect thee from thyself and any muck-ery which might be afoot down the road"

LOL yes!
Title: Re: What's your philosophy about constants?
Post by: CharlieJV on March 23, 2022, 07:11:33 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

In a huge program with a lot of stuff going on and risk of typos, I could imagine defining something as a constant could help to easily catch a mistake when at some point assigning a new value to something that was meant to stay a constant.

Danged if I can think of a good example off the top of my head...
Title: Re: What's your philosophy about constants?
Post by: SMcNeill on March 23, 2022, 08:07:35 pm
In a huge program with a lot of stuff going on and risk of typos, I could imagine defining something as a constant could help to easily catch a mistake when at some point assigning a new value to something that was meant to stay a constant.

Danged if I can think of a good example off the top of my head...

A good example would be:

CONST True = -1

Now, instead of typing IF x = -1 THEN....  you can type IF x = True THEN.... 

This helps catch basic typos such as typing IF x = 1 THEN... (you forgot the minus there, or the keypress didn't register from too much Cheetos-dusting...)  Especially in conjunction with OPTION _EXPLICIT, you'd get a notification when you typed IF x = Tru THEN...

Names are more readable and have the added security of enhanced syntax checking.
Title: Re: What's your philosophy about constants?
Post by: OldMoses on March 23, 2022, 10:40:39 pm
I've used them on occasion, mostly for conversion factor stuff, but generally don't see the point. Use a shared variable that you don't change and it's the same thing as far as I can tell.
Title: Re: What's your philosophy about constants?
Post by: tomxp411 on March 24, 2022, 02:04:10 am
The whole point of a constant is that it can't be modified. The other point is that it's a literal replacement made at compile time.

Let's look at one of list of constants built in to the DotNet SDK, the keyboard scan codes. There are 773 keyboard scan codes in the System.Windows.Forms.Keys enumeration - just for a list of keys on the computer.

Now consider all of the other thousands of enumerations and constants in the system... the "Magic Number Database" has over 380,000. That's not all of them, either. So if you were to include all of the constants your program might need as variables every time you compile it, you would be adding in over 1.5 megabytes just for the variable storage, not to mention the other things that go into storing and retrieving a variable.

So there are two very important reasons to use CONST in your program:
1. It's an obvious semantic flag that says "this value isn't going to change."
2. Those values get converted directly to data during compile time. There's no variable storage or lookup for those values, and unused constants actually disappear from the object code, saving even more space.

Does it matter in a little dinky 30K demo? No. But does it matter in large applications, spanning thousands of source files and multiple megabytes of object code?

Absolutely.

Title: Re: What's your philosophy about constants?
Post by: CharlieJV on March 24, 2022, 08:09:06 pm
Just wanted to say thanks for all comments.  I've decided to introduce a new statement called "EQN" (for equation).  Although EQN and CONST use the same background stuff to implement them, I like the semantic differentiation.  I'm not liking a CONST statement allowing appearance of not looking like a constant.

If anybody knows of any BASIC that already has an EQN statement or function, please let me know.

Imagine an income tax program or something like that, here's how EQN works:

Code: QB64: [Select]
  1. dim line1, line2, line4
  2. eqn line3 = line1 + line2 , line5 = line3 + line4
  3. line1 = 3 : line2 = 7 : line4 = 4
  4. print line1
  5. print line2
  6. print line3
  7. print line4
  8. print line5

Title: Re: What's your philosophy about constants?
Post by: Pete 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.
Title: Re: What's your philosophy about constants?
Post by: tomxp411 on March 24, 2022, 09:37:28 pm
Just wanted to say thanks for all comments.  I've decided to introduce a new statement called "EQN" (for equation).  Although EQN and CONST use the same background stuff to implement them, I like the semantic differentiation.  I'm not liking a CONST statement allowing appearance of not looking like a constant.

If anybody knows of any BASIC that already has an EQN statement or function, please let me know.

Imagine an income tax program or something like that, here's how EQN works:

Code: QB64: [Select]
  1. dim line1, line2, line4
  2. eqn line3 = line1 + line2 , line5 = line3 + line4
  3. line1 = 3 : line2 = 7 : line4 = 4
  4. print line1
  5. print line2
  6. print line3
  7. print line4
  8. print line5

The more correct term for this would be DEFINE, as it's already used in C/C++ for in-line macros.

#DEFINE p2 Pi * 2

x = p2 * 4;

In fact, older C compilers don't really support constants. As a result, constants in C are typically implemented via #DEFINE preprocessor directives... so are really macros. So you might think about adding your new keyword similarly.
Title: Re: What's your philosophy about constants?
Post by: jack on March 24, 2022, 09:51:23 pm
const is better for constants, you have be careful with #define/macros
suppose that your define was #DEFINE p2 Pi + Pi then x=p2*4 would become Pi+Pi*4 unless you enclose it in parentheses
Title: Re: What's your philosophy about constants?
Post by: bplus on March 24, 2022, 09:58:37 pm
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.

Well maybe you don't need pi in your subs and functions but I do. For that it needs to be Shared (if Const was not available) and for that the Dim view.
Title: Re: What's your philosophy about constants?
Post by: tomxp411 on March 24, 2022, 10:13:41 pm
const is better for constants, you have be careful with #define/macros
suppose that your define was #DEFINE p2 Pi + Pi then x=p2*4 would become Pi+Pi*4 unless you enclose it in parentheses

He was literally describing a #define, but calling it "EQN". Hence my reply: call it DEFINE or MACRO.
Title: Re: What's your philosophy about constants?
Post by: _vince on March 24, 2022, 10:37:47 pm
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.
Title: Re: What's your philosophy about constants?
Post by: johnno56 on March 25, 2022, 03:14:28 pm
"My philosophy about constants"? I have none. Constants are just that. Constant. They offer a globally accepted fixed value. This is not a quantum mechanic's problem like Shrodinger's cat, constants are 100% fixed. There is no room for philosophy... Well... that was fun for 6am. Next question?
Title: Re: What's your philosophy about constants?
Post by: bplus on March 25, 2022, 03:55:03 pm
@johnno56 I think you are making a philosophical assumption that Constants exist.

One may argue that they are man made constructs invented to prolong the illusion of man's existence.
Title: Re: What's your philosophy about constants?
Post by: Dimster on March 25, 2022, 04:50:41 pm
I think you are onto something there @bplus . A Buddhist would argue "impermanence" . There is nothing in this world, either in thought or tangible which is constant (or permanent). Everything built, given enough time, will be changed, replaced or left to crumble. All thoughts and emotions are impermanent and all the math theories are constantly being challenged and reconstructed in the search for that one pure underlaying formula. I suspect your application of a constant (ie a tool which you can change to a different value) is the way to go with constants in coding. Especially a program which is under construction. And then, once it's complete it's onto the next project.

I kind of like the idea of Impermanence. It kind of forces you to improve your coding so the utility of your project may last at least your life time.

Maybe this was Too Deep a dive into constants
Title: Re: What's your philosophy about constants?
Post by: CharlieJV on March 25, 2022, 05:02:34 pm
Just wanted to say thanks for all comments.  I've decided to introduce a new statement called "EQN" (for equation).  Although EQN and CONST use the same background stuff to implement them, I like the semantic differentiation.  I'm not liking a CONST statement allowing appearance of not looking like a constant.

If anybody knows of any BASIC that already has an EQN statement or function, please let me know.

Imagine an income tax program or something like that, here's how EQN works:

Code: QB64: [Select]
  1. dim line1, line2, line4
  2. eqn line3 = line1 + line2 , line5 = line3 + line4
  3. line1 = 3 : line2 = 7 : line4 = 4
  4. print line1
  5. print line2
  6. print line3
  7. print line4
  8. print line5

At first, I thought EQN captured the semantics of what I have here.  After a good sleep and a day of subconscious chewing, I'm thinking: nah.

DEFDV does it better for me.  Don't mind me: I tend to suffer finding/creating a word that feels just right.  Tweak tweak tweak tweak ...

Code: QB64: [Select]
  1.  
  2. ' I've decided to change "EQN" to "DEFDV", meaning DEFine Derived Variable/Value.
  3. ' Internally, it is the same as a "DEF FN" for a function, but has no parameters.  It is a function that returns a value based on whatever expression using whatever global values.
  4. '
  5. ' It is just shorthand for whenever it can apply to something useful.
  6. ' Parentheses are optional, but they can be nice visual cues that we are dealing with something that is behind the scenes a function behaving as a derived variable.
  7. '
  8. dim line1, line2, line4
  9. defdv line3() = line1 + line2 , line5() = line3 + line4
  10. line1 = 3 : line2 = 7 : line4 = 4
  11. print line1
  12. print line2
  13. print line3()
  14. print line4
  15. print line5()

Kind of silly because it is just about defining functions.  I guess I can't help but get caught up with this desire to have something that displays a slightly different nature than a regular function, or a DEF FN function.

Anyway, that aside, I enjoy the comments.
Title: Re: What's your philosophy about constants?
Post by: Pete 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
Title: Re: What's your philosophy about constants?
Post by: SMcNeill on March 26, 2022, 06:37:13 am
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

No more so than if you calculated the value using a variable to store the results.

32-bit programs might give you an answer of 0.11111111111111117896 due to their 80-bit FPU math processors, while the 64-bit versions would give the result as 0.11111111111111121345, or some such, due to using 64-bit math processors.  Whether you store that result in a CONST, or a variable, it's not going to change the fact that the OS is going to produce that same mathematical answer each time it's ran.

Now, where it might generate errors for you, is if you start substituting values between CONST and literal results yourself.

Let's say for example that you have a formula that produces the results above.  CONST x = foo / whatever.  Now, you compile on a 32-bit OS and print out the results to see they're 0.11111111111111117896.

Somewhere in your code you have a line like:  IF program_calculation = 0.11111111111111117896 * 2 THEN... 

Now, on the 32-bit OS, x and 0.11111111111111117896 are going to be equal.  On a 64-bit OS, those values might be minutely different.  Your 32-bit compiled EXE may not run exactly the same on the 64-bit EXE, as the values won't match -- which makes it advisable to use CONST over literals in such cases, or to at least not mix-and-match them any more than possible.

(Note, the reverse situation is impossible -- the you CAN'T run a 64-bit EXE on a 32-bit OS.)
Title: Re: What's your philosophy about constants?
Post by: luke on March 26, 2022, 07:12:36 am
Please report any observed discrepancies in floating point calculations as they are intended to be the same across operating systems and x86 vs x86-64.
Title: Re: What's your philosophy about constants?
Post by: CharlieJV on March 26, 2022, 10:37:57 am
(SNIP!)
Somewhere in your code you have a line like:  IF program_calculation = 0.11111111111111117896 * 2 THEN... 

Now, on the 32-bit OS, x and 0.11111111111111117896 are going to be equal.  On a 64-bit OS, those values might be minutely different.  Your 32-bit compiled EXE may not run exactly the same on the 64-bit EXE, as the values won't match -- which makes it advisable to use CONST over literals in such cases, or to at least not mix-and-match them any more than possible.
(SNIP!)

IF BALLPARK(program_calculation, 0.11111111111111117896 * 2, +-0.11111111 ) ???

Just to say that has me thinking about a programming language full of funny expressions and colloquialisms .

So many interests, so little time ...
Title: Re: What's your philosophy about constants?
Post by: madscijr on March 26, 2022, 11:14:51 am
Which is easier to type:
Const pi = 3.1415
or
Dim Shared pi as some type
pi = 3.1415

What I'm wondering is, which performs better?

Also, for color values, I've been using functions, like
Code: QB64: [Select]
  1. Function cRed~& ()
  2.     cRed = _RGB32(255, 0, 0)
because of some thread on here long since forgotten (I think function because it would be read only, and because constants were integer only and colors need to be unsigned long).

I am wondering if doing it as a shared value like
Code: QB64: [Select]
  1. dim shared cRed~& : cRed = _RGB32(255, 0, 0)
would perform better?

Similarly, I don't know where I read this, or even if it was qb64 or c64 basic, but somewhere I read that variables perform better than literals. For example something like
Code: QB64: [Select]
  1. x% = column% * 8
would run slower than
Code: QB64: [Select]
  1. dim shared tileSize% : tileSize% = 8
  2. ...
  3. x% = column% * tileSize%

Which would perform better, a literal or a variable?
Title: Re: What's your philosophy about constants?
Post by: SMcNeill on March 26, 2022, 12:13:37 pm
IF BALLPARK(program_calculation, 0.11111111111111117896 * 2, +-0.11111111 ) ???

Just to say that has me thinking about a programming language full of funny expressions and colloquialisms .

So many interests, so little time ...

When dealing with floating point values, what you're suggesting is actually the best way to check for values.

Instead of something like: IF x = 10 THEN....

It's often better to use something more like: IF ABS(x - 10) < 0.0000001 THEN....

Floating point math has rounding glitches by its very nature.  For instance, it's impossible to represent 1/10 in base-2 math, just as it's impossible to represent 1/3 in base 10 math.  1/3 in decimal format is 0.3333333333333333333333333333333333333333333....  and more 3s on to infinity!  We can't perfectly represent 1/3 as a decimal, and it's just as impossible to represent 1/10 in binary format.

Over time, these rounding errors can add up, and even though we expect 0.1 added together 100 times to become 10, it may instead be 9.99999999999998721 or such.  A check for IF x = 10 THEN... will fail to pass muster, so instead we check the value against a chosen level of tolerance.  If the value is > 9.999999999999999 and the value is less than 10.000000000000001 then...  we're going to count it as being 10 with floating point errors counted in!  ;)
Title: Re: What's your philosophy about constants?
Post by: CharlieJV on March 26, 2022, 01:03:37 pm
Makes me wonder how the human species managed to land anything on Mars ...
Title: Re: What's your philosophy about constants?
Post by: Pete 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
Title: Re: What's your philosophy about constants?
Post by: CharlieJV on March 26, 2022, 01:34:22 pm
(SNIP!) why do people think if Martians existed, they would be smarter than humans? (SNIP!)

Pete

Now I have the movie "Paul" on the brain ...

(https://i.pinimg.com/236x/b4/d5/23/b4d5233a0ca7a162a066c4697b9275c3--lmao-aliens.jpg)
Title: Re: What's your philosophy about constants?
Post by: johnno56 on March 26, 2022, 04:04:29 pm
@johnno56
One may argue that they are man made constructs invented to prolong the illusion of man's existence.

This "One" would ask... In which Universe?
Title: Re: What's your philosophy about constants?
Post by: bplus on March 26, 2022, 05:32:46 pm
Truly one, there would be no otherness to question.
Title: Re: What's your philosophy about constants?
Post by: _vince on March 26, 2022, 08:29:24 pm
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

You are right, 32-bit machines are incapable of computing 64-bit values, just as Android phones don't do negative numbers, and your TV remote only deals with even numbers.  Be careful out there, guys.