What's your philosophy about constants?

[Pete]

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.

[tomxp411]

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.

[jack]

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

[bplus]

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.

[tomxp411]

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.

[_vince]

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.

[johnno56]

"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?

[bplus]

@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.

[Dimster]

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

[CharlieJV]

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.

[Pete]

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

[SMcNeill]

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.)

[luke]

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.

[CharlieJV]

(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 ...

[madscijr]

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)
3. End Function

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?