+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: Official Links (https://qb64phoenix.com/forum/forumdisplay.php?fid=16)
+--- Forum: Learning Resources and Archives (https://qb64phoenix.com/forum/forumdisplay.php?fid=13)
+---- Forum: Keyword of the Day! (https://qb64phoenix.com/forum/forumdisplay.php?fid=49)
+---- Thread: DAY 002: CVSMBF (/showthread.php?tid=1066)
DAY 002: CVSMBF - SMcNeill - 11-07-2022
Yay! Today, we get one of those keywords that I personally find utterly useless, but it is what it is.
Let's start by talking about how to decipher that long string of random characters, and try and understand what CVSMBF might actually stand for:
CV -- Convert
S -- SINGLE
M -- Microsoft
B -- Binary
F -- Format
So, what does it do?
It converts a properly formatted string (one stored in Microsoft Binary Format -- which is outdated and obsoleted and thus why I find this to be basically a worthless command, unless one is working with ancient data from the late 70s or early 80s) into a SINGLE precision number.
Let me share an example of this, and its twin function MKSMBF, and then I'll explain a little more about how and where one might use these type commands:
Code: (Select All)
a! = 700.2213
Print "Value of a!:"; a!
b$ = MKSMBF$(a!): c$ = MKS$(a!)
Print "Value of a! encoded using MKSMBF$: "; b$
Print "The string above, decoded using CVSMBF:"; CVSMBF(b$)
Print "Value of a! encoded using MKS$: "; c$
Print "The string above, decoded using CVS:"; CVS(c$)Now you'll notice that I started the above by converting a SINGLE value into a STRING. The reason for this is simple -- I don't know the string representations of the values off the top of my head, so it's just easier to start with a number which I do know how to represent, and then showcase the conversion back and forth.
You'll also notice that, in the example above, I also showcased MKS$ and CVS. These do exactly the same as MKSMBF$ and CVSMBF, with one exception -- they convert to the modern standard SINGLE values and not the antiquated Microsoft Binary Format.
So *WHY* would someone want to convert these values into such odd strings? Why not just use STR$(a!) and be done with it??
STR$() converts a number to a string -- but it basically preserves the formatting of that string. STR$(700.2213) would become " 700.2213" -- an eight digit string.
MKS$ and MKSMBF$ converts a number to a string -- but those strings are *always* going to be 4-bytes in size. The character representation you get is (more or less) going to be exactly the same as that value looks like in memory. (With the exception of MKSMBF which is, as I've said several times, an outdated method of representing the value in memory nowadays.)
123.456789 will convert to a 4-byte string.
1.1 will convert to a 4-byte string.
0 will convert to a 4-byte string.
And why is this 4-byte constant so important for us??
When saving data to the drive FOR BINARY or RANDOM access!!
We can store 100 numbers in a text file, in MKS$ format, and use a total of 400 bytes to store those numbers. Unlike variable length data entries, we can easily access our file and tell instantly where any certain number is in it.
At position 1 in the file is the zero-index number. (Think of my index here as DIM array(0 TO 99), for my 100 numbers.)
At position 5 in the file is the one-index number.
At position 41 in the file is the ten-index number.
At position (p) in the file in the file is the ((p - 1) / 4)-index number.
We convert the value to a set string size, so we can easily track where that value lands inside a larger string or a data file. Set and constant sized data makes data alignment a breeze.
RE: DAY 002: CVSMBF - Dimster - 11-07-2022
Hi Steve, so in your opening sentence "Let's start by.." you list the command as CVDMBF. Is that a typo or the command also works with Double?
RE: DAY 002: CVSMBF - SMcNeill - 11-07-2022
(11-07-2022, 12:49 PM)Dimster Wrote: Hi Steve, so in your opening sentence "Let's start by.." you list the command as CVDMBF. Is that a typo or the command also works with Double?
It's a typo, but if you look at our wiki pages, you'll find that there's a half dozen different commands which look almost identical to this one.
CVD - QB64 Phoenix Edition Wiki
CVS - QB64 Phoenix Edition Wiki
CVI - QB64 Phoenix Edition Wiki
CVL - QB64 Phoenix Edition Wiki
CVDMBF - QB64 Phoenix Edition Wiki
CVSMBF - QB64 Phoenix Edition Wiki
Now, if you keep in mind that CV stands for "CONVERT to..", it's not hard to understand the rest of the command:
CVD -- convert string to Double.
CVS -- convert string to Single.
CVI -- convert string to Integer.
CVL -- convert string to Long.
MBF -- in Microsoft Binary Format.
The rest of the commands work *exactly* as I described above, but for their perspective variable type. Doubles are a constant 8-byte character string, Single and Long are 4-bytes, and Integers become constant 2-byte strings.
So even though I had a typo, the simple truth is you can still convert to Double/Long/Integer with just a single change of a letter in the command name. CVD converts to double, whereas CVS converts to single.
And, for those who want a slightly more modern version of these old commands (notice no underscore with these -- they were originally QBASIC conversion commands from waaay back in the day), there's always just _CV - QB64 Phoenix Edition Wiki and _MK$ - QB64 Phoenix Edition Wiki, which should work with any of the basic variable types you'd want, including Integer64, Byte, and Bit.
RE: DAY 002: CVSMBF - Pete - 11-07-2022
(11-07-2022, 12:49 PM)Dimster Wrote: Hi Steve, so in your opening sentence "Let's start by.." you list the command as CVDMBF. Is that a typo or the command also works with Double?
Actually, he listed it as: CVSMBF. So you also made a typo. Since two negatives make a positive, I guess we are all good now.
So when is that bleeping random generator going to produce something useful like SCEEN 0, the only screen mode you'll ever need?
Kidding aside, the 4-byte explanation is important for anyone wanting to switch from using sequential files to binary files to save and retrieve data. That's something I haven't played around with, but someday, who knows.
Pete
RE: DAY 002: CVSMBF - bplus - 11-07-2022
oops, got wrong day number sorry...
RE: DAY 002: CVSMBF - Dimster - 11-07-2022
I'm losing my mind Pete - it was "D" when I first read it but an obvious "S" now.
RE: DAY 002: CVSMBF - Pete - 11-07-2022
(11-07-2022, 07:57 PM)Dimster Wrote: I'm losing my mind Pete - it was "D" when I first read it but an obvious "S" now.
D, S, no biggie. Hey Mark got the day wrong, so there's that. You know guys it's all about the learning and the important lesson we all need to learn from this thread is... STEVE MESSED UP!
RE: DAY 002: CVSMBF - SMcNeill - 11-07-2022
(11-07-2022, 07:57 PM)Dimster Wrote: I'm losing my mind Pete - it was "D" when I first read it but an obvious "S" now.
It was, but there's this secret button called "EDIT" that a poster can use to correct typos and such, once someone points them out to them.