Page 1 of 2
New bytecalc-function (for PB 4.01+)
Posted: Fri Nov 03, 2006 8:44 pm
by AND51
Hello!
Here's my new
bytecalc() function for PB 4.01+. (Don't try to beat this, the german-forum-competition is over

and I've won).
This procedure turns a quad number of bytes into the greatest unit.
Eample:
1024 Byte => 1 KB
16777216 => 16 MB.
You can optionally switch on decimals numbers; the procedure automatically enforces no decimal numbers, if the greatest unit is "Byte", because it doesn't make sense to have 3.67 Byte, does it?
Code: Select all
Procedure.s bytecalc(byte.q, NbDecimals.b=0)
Protected unit.b=Round(Log(byte)/Log(1024), 0)
ProcedureReturn StrD(byte/Pow(1024, unit), NbDecimals*(unit And 1))+" "+StringField("Byte,KB,MB,GB,TB,PB,EB", unit+1, ",")
EndProcedure
Debug bytecalc(FileSize("C:\pagefile.sys"))
Debug bytecalc(3.67*1024)
Debug bytecalc($FFFFFF)
Debug bytecalc(1024)
Do you think, this code can be added to PB as a "native function"?

Posted: Fri Nov 03, 2006 9:32 pm
by Trond
Basically taking bytes as a quad is no use because you're converting to a double inside the function.
Posted: Fri Nov 03, 2006 9:58 pm
by Flype
hi,
and what about this one ?
Code: Select all
Import "shlwapi.lib"
CompilerIf #PB_Compiler_Unicode
bytecalc_(number.q, *buffer, length.l) As "_StrFormatByteSizeW@16"
CompilerElse
bytecalc_(number.q, *buffer, length.l) As "_StrFormatByteSize64A@16"
CompilerEndIf
EndImport
Macro bytecalc(num, lbuf = 255)
PeekS(bytecalc_(num, @buf.s{lbuf}, lbuf), lbuf)
EndMacro
For i = 0 To 62
Debug bytecalc(Pow(2, i))
Next
yes but i must admit it is not cross-platform !
but just one question :
what the hell means the 'P'b and 'E'b ?
Kb -> Kilo Bytes
Mb -> Mega Bytes
Gb -> Giga Bytes
Tb -> Tera Bytes
Pb -> ?
Eb -> ?
Posted: Fri Nov 03, 2006 10:06 pm
by Flype
ah yes - i found it !
it is :
Pb -> Peta Bytes
Eb -> Exa Bytes
you can verify it on wikipedia :
http://en.wikipedia.org/wiki/SI_prefix
Posted: Sat Nov 04, 2006 6:22 pm
by AND51
Trond wrote:Basically taking bytes as a quad is no use because you're converting to a double inside the function.
Yes, because the user might want to have decimal numbers; this couldn't be realized with not using doubles.
@ flype: I've no knowlege about the
import-function, so I cannot comment your solution. However, it seems to work, I tested it.
Posted: Sat Nov 04, 2006 6:24 pm
by Rescator
http://en.wikipedia.org/wiki/Binary_prefix
I would recommend following the IEC standard prefixes instead to avoid confusion with the SI prefixes.
Posted: Sat Nov 04, 2006 6:48 pm
by thamarok
No, Pb is PureBasic

Posted: Sat Nov 04, 2006 6:54 pm
by Trond
AND51 wrote:Trond wrote:Basically taking bytes as a quad is no use because you're converting to a double inside the function.
Yes, because the user might want to have decimal numbers; this couldn't be realized with not using doubles.
But then you can't take a byte count that is as large as a quad.
Posted: Sat Nov 04, 2006 9:24 pm
by AND51
Trond wrote:AND51 wrote:Trond wrote:Basically taking bytes as a quad is no use because you're converting to a double inside the function.
Yes, because the user might want to have decimal numbers; this couldn't be realized with not using doubles.
But then you can't take a byte count that is as large as a quad.
Correct, but this procedure hs been designed for programs for home PCs. ´has your PC files that are larger than 1 TB? I don't think so. So you can use my procedure without worries.
Even if you want the full power, then use flype's procedure.
Posted: Sat Nov 04, 2006 9:27 pm
by Dare
Read it - got confused.
Does it mean that 1Kb = 1000 and 1KiB = 1024 (the real K!)? And what is a Ko (apart from a knock out)?
Posted: Sat Nov 04, 2006 9:29 pm
by AND51
I won't use KiB, MiB, GiB, etc. it's just confusing.
Posted: Thu Nov 09, 2006 1:56 am
by GeoTrail
Dare wrote:
Read it - got confused.
Does it mean that 1Kb = 1000 and 1KiB = 1024 (the real K!)? And what is a Ko (apart from a knock out)?
Although computer data is normally measured in binary code, the prefixes for the multiples are based on the metric system. The nearest binary number to 1,000 is 2^10 or 1,024; thus 1,024 bytes was named a Kilobyte. So, although a metric "kilo" equals 1,000 (e.g. one kilogram = 1,000 grams), a binary "Kilo" equals 1,024 (e.g. one Kilobyte = 1,024 bytes). Not surprisingly, this has led to a great deal of confusion.
Posted: Thu Nov 09, 2006 2:07 am
by stubbsi
pariticularly when the EU got involved and decided that a kb was 1000 bytes not 1024.
logical - eh!! bureaucracy gone mad - obviously don't know that 2^10 = 1024.
Posted: Thu Nov 09, 2006 4:37 am
by Rescator
As long as you remain consistent within your program (i.e. do NOT mix KB and KiB etc.) then most users wont mind whether you use KB or KiB. It might be a nice touch to mention in the user documentation for your programs whether KB indicate KB or KiB though.
By users I here mean end users, as a programmer (PB user) I sure hope we know/see the difference what is KB or KiB

Posted: Thu Nov 09, 2006 8:53 am
by Dare
Hi GeoTrail, stubbsi and Rescator,
Thanks. So officially a KiB = 1024?
And a Ko is .. what?
lol. Bring back feet and inches and tons and gallons and furlongs! And shillings and pence for that matter! (This program is 27 acres zipped and requires 132 acres of diskspace when decompressed. It costs 8 pounds seven shillings and sixpence - download now?)