A few pushes to the Development build

[SMcNeill]

OPTION _EXPLICIT isn’t tossing you a warning; it throws you a full-fledged ERROR which you can’t ignore.

Try something simple like:

Code: [Select]

DIM foo AS LONG
By itself, that single line with toss you a warning — “Variable not used”, or some such.  You can still compile with the warning; it’s not a full fledged ERROR after all; but still, I find it annoying as the expected “OK” no longer shows up in the IDE.

Personally, I think OPTION _EXPLICT should toss warnings instead of errors, but that’s not how it was designed.  And, since I’m not one to use it at all, I’ll leave it to others to decide what’s the actual best behavior for it.  LET, CALL, OPTION BASE, OPTION _EXPLICIT, REM....  There’s a ton of commands in the language that I never use, and I figure if any of them needs changing, it’s probably best if the people who actually use them changes them.  ;)

[RhoSigma]

Ah, then I got this wrong, I thought it could workaround the requirements imposed by OPTION _EXPLICIT.
Thanks

[Bert22306]

Okay, so this binary operations addition, in the latest development build, is one very much appreciated new feature, which I sorely missed before. In the past, I had to go back to basics, when entering binary strings. I've been testing the new features out, and was pleased to see that we can enter binary numbers like this:

num = &B11110000

which works fine.

Or as string variables

binstring$ = "11110000"

which we can then decode as a decimal by doing

bindecconv = VAL("&b" + binstring$)

So far, so good. And, since the LEN of string variables can easily be determined, you should then be able to scale that binary number, if it's a fixed point. Cool.

What I can't seem to do, is what one can do in hex. Which is, how to create the binary number from a decimal input value. As in

HexNum$ = HEX$(dec)

Granted, that last one assumes the hex number is an integer (rounding any decimal fraction), although interestingly enough, you can enter a negative decimal and it assumes a 16-bit two's complement. I attempted this

BinNum$ = BIN$(dec)

No dice. Was this intentional? In theory, I was thinking, could be done much as the hex operation, also assuming integer and perhaps two's complement, 16-bit, for negative decimals? Just wondering. Obviously, we can work around that. Thanks again!

[bplus]

Hi Bert,

BIN$ is not in QB64 which is why I had it in my toolbox. To add BIN$ to QB64 it might have to be called _BIN$ and who wants that?

[Bert22306]

To add BIN$ to QB64 it might have to be called _BIN$ and who wants that?

:)

Well, Clippy wouldn't want that, for sure! Me, I've never objected to _. Although now that you mentioned it, I should have tried that _BIN$, before giving up! Thanks bplus!

[RhoSigma]

Hi Bert22306 and anyone else,

as I'am responsible for the latest changes regarding &B prefixed binary number strings (https://www.qb64.org/forum/index.php?topic=1933.msg111935#msg111935), it should be probably me too, who provides a appropriate function to do the opposite conversion from any given hex/oct/dec number to binary string.

Although there are already many approaches for a BIN$ function in the Forum, some of my own, some from bplus and Steve McNeill and probably others, I felt there should be one, which best mimics the regular behavior and results of the built-in HEX$ and OCT$ functions, rather than focusing on speed or extended flexibility.

So here it is:

• can handle positive and negative numbers
• returns the binary string without &B prefix, just as HEX$ and OCT$ do
• the result for positive numbers is just as long as needed, ie. no leading zeros are returned
• the result length for negative numbers is determined by the integer range, which the given input number does fit in, eg. 8 for numbers in _BYTE range (down until -128), 16 for INTEGER (down until -32768) etc.

Although not focused on super speed, I just used simple operations and so this BIN$ function is still pretty fast.

Code: QB64: [Select]

1. 'some average speeds I've measured for this BIN$ function:
2. '-----------------------+--------------------+--------------------+--------------------
3. '         CPU           |   QB64 v1.3 x64    |   QB64 v1.3 x86    | QB64 v0.954 (SDL)
4. '-----------------------+--------------------+--------------------+--------------------
5. ' Core i5-2430M @2.4GHz |  820000 LONGs/sec. |  620000 LONGs/sec. |  650000 LONGs/sec.
6. '-----------------------+--------------------+--------------------+--------------------
7. ' Xeon E-2174G  @3.8GHz | 1650000 LONGs/sec. | 1130000 LONGs/sec. | 1140000 LONGs/sec.
8. '-----------------------+--------------------+--------------------+--------------------
9.  

And finally the function:

Code: QB64: [Select]

1. '---------------------------------------------------------------------
2. 'Function:  Convert any given dec/hex/oct number into a binary string.
3. '           Can handle positive and negative values and works in that
4. '           similar to the QB64 built-in HEX$ and OCT$ functions.
5. '
6. 'Synopsis:  binary$ = BIN$ (value&&)
7. '
8. 'Result:    binary$ --> the binary representation string of the given
9. '                       number without leading zeros for positive values
10. '                       and either 8/16/32 or 64 chars for negatives,
11. '                       depending on the input size
12. '
13. 'Inputs:    value&& --> the pos./neg. number to convert, may also be
14. '                       given as &H or &O prefixed value
15. '
16. 'Notes:     You may also pass in floating point values, as long as its
17. '           represented value fits into the _INTEGER64 (&&) input, hence
18. '           approx. -9.223372036854776E+18 to 9.223372036854776E+18.
19. '           Different from HEX$ and OCT$, BIN$ won't throw an overflow
20. '           error, if this range is exceeded, but the result is probably
21. '           wrong in such a case.
22. '---------------------------------------------------------------------
23. FUNCTION BIN$ (value&&)
24. '--- option _explicit requirements ---
25. DIM temp~&&, charPos%, highPos%
26. '--- init ---
27. temp~&& = value&&
28. BIN$ = STRING$(64, "0"): charPos% = 64: highPos% = 64
29. '--- convert ---
30. DO
31.     IF (temp~&& AND 1) THEN MID$(BIN$, charPos%, 1) = "1": highPos% = charPos%
32.     charPos% = charPos% - 1: temp~&& = temp~&& \ 2
33. LOOP UNTIL temp~&& = 0
34. '--- adjust negative size ---
35. IF value&& < 0 THEN
36.     IF -value&& < &HFFFFFFFF~& THEN highPos% = 33
37.     IF -value&& < &H0000FFFF~& THEN highPos% = 49
38.     IF -value&& < &H000000FF~& THEN highPos% = 57
39.     IF -value&& < &H00000000~& THEN highPos% = 1
40. END IF
41. '--- set result ---
42. BIN$ = MID$(BIN$, highPos%)
43. END FUNCTION
44.  

[Bert22306]

Nice, RhoSigma! I'll be using this. Many thanks.

[Qwerkey]

If a new stable version (1.4?) is coming up for release, this is what I'd ask for (I think that I'm in a minority of one):  we've discussed elsewhere (https://www.qb64.org/forum/index.php?topic=1577.msg107972#msg107972, https://www.qb64.org/forum/index.php?topic=1531.msg107516#msg107516, https://www.qb64.org/forum/index.php?topic=1531.0) that when a FUNCTION is called, it modifies the calling argument (By Reference) by default.

For y = f(x), I still hate the x being changed when you want a function of x.  So, I'd like FUNCTION to always be By Value (argument unchanged) by default.

Ah well, I know that it's not going to happen, but I'm asking anyway.  It came to my attention again in a recent project where I had something like:

A = funct(A), where funct is a FUNCTION which alters A, but A in the lines of funct code is not altered.  So you have the seemingly daft line A = funct(A) which says A is altered by funct, but the By Reference says A is not altered.

This horse is dead, but I'm flogging it anyway!

[FellippeHeitor]

The only reason stopping that from happening is that the default behaviour in our mother language, QuickBASIC 4.5, is to pass by reference.

If a function is to have its parameters protected by default, but still needs to do any operations on them, it's safer to copy their values at the beginning.

Code: QB64: [Select]

1. function myFunc(temp_parameter)
2.     parameter = temp_parameter
3.     '(rest of code here)
4. end function

[RhoSigma]

Added a small fix (one line) to the BIN$ function here https://www.qb64.org/forum/index.php?topic=1933.msg112096#msg112096 to make sure that even the lowest possible negative _INTEGER64 number (-9.223.372.036.854.775.808) is correctly returned as 64 bits/chars, instead of 8 bits/chars only and just containing zeros.

Also added some documentation.