Can I cast a larger HEX$, grin?

[Mike Luther]

In PB 3.5, the following code returns an (expected!) overflow when
we hit quad integer sizes. But I need hex string functions for them
anyway. Now what can I do to cast a larger hex$, grin?

CLS
PRINT
PRINT "TESTING "; 9999999991
QMZ& = 999999999
QMY&& = 9999999991
PRINT "QMZ& = ";  QMZ&
PRINT "QMY&& = "; QMY&&
PRINT "HEX$ QMZ& = "; HEX$(QMZ&)
PRINT "HEX$ -QMZ& = "; HEX$(-QMZ&)
PRINT "HEX$ QMY&& = "; HEX$(QMY&&)  '  oops! 
PRINT "HEX$ -QMY&& = "; HEX$(-QMY&&) ' natch!
PRINT

Will someone teach me how to become an even better PowerBasic warlock!




------------------
Mike Luther
[email protected]

[This message has been edited by Mike Luther (edited March 04, 2005).]

[Mel Bishop]

not directly but you might consider converting the number(s) to
binary then chopping the binary string to hex$ equivelents.

there is a binari$ function in
http://www.powerbasic.com/support/pb...ad.php?t=24418

that will build a string length of 32k (if you can representate
a number that big) that maybe of assistance.

remember, if you go this route, you will give up pb's built in
functions and your program will probably run slower.


------------------

[Michael Mattias]

Maybe write your own function?

Hints: MyValue MOD 16 ; Myvalue\16

[Paul Dixon]

function bighex$(q&&)
dim p as long ptr
p=varptr32(q&&)
if @p[1] then
        function=hex$(@p[1])+right$("0000000"+hex$(@p),8)
        else
        function=hex$(@p)
        end if

end function

------------------

[Tim Camarda]

Hi Mike,

This routine can handle a Hex String over a Terabyte.

DIM N AS QUAD

N=999999999999999999
PRINT USING$("###,###,###,###,###,###",N) REM just formatting the decimal for displaying

GOSUB GETHEX
PRINT HEXSTRING1$
PRINT HEXSTRING2$
END

GETHEX:
REM Could put into a sub
REM HEXSTRING1$= Intel Little endian
REM HEXSTRING2$=HEX STRING

H8=N\7.205759403792794D+16:N=N-(7.205759403792794D+16*H8)
H7=N\281474976710656#:N=N-(281474976710656#*H7)
H6=N\1099511627776#:N=N-(1099511627776#*H6)
H5=N\4294967296#:N=N-(42949672 96#*H5)

H4=N\16777216#:N=N-(16777216#*H4):H3=N\65536!:N=N-(65536!*H3):H2=N\256:N=N-(256*H2):H1=N\1
REM
HEXSTRING1$=CHR$(H1)+CHR$(H2)+CHR$(H3)+CHR$(H4)+CHR$(H5)+CHR$(H6)+CHR$(H7)+CHR$(H8)
HEXSTRING2$=HEX$(H8)+HEX$(H7)+HEX$(H6)+HEX$(H5)+HEX$(H4)+HEX$(H3)+HEX$(H2)+HEX$(H1)
HEXSTRING2$=LTRIM$(HEXSTRING2$,"0")
RETURN

Best Regards,
Tim http://www.omnixray.com


[This message has been edited by Tim Camarda (edited March 07, 2005).]

[Mike Luther]

Thanks to all of you for your contributions.

But, it leads to another thought on this. OK, PB 3.5 for DOS handles
quad integers. It must do this by storing them at some point in memory
for them to be usable. Thus, what does PB use to process this in
memory as it's resident way of doing this? With that thought in mind,
is there a more 'coordinated' way to do this by using a pointer to
the location in memory where the number is stored? Then reading that
data directly from memory? And as an obviously related question; how
many digits in memory space does PB use to represent that && variable?

Which brings the next thrust of my quest forward. So I get the data
format for the && integer into hex. Now I need to cast it back into
the && style variable in PB 3.5 for DOS, so I can print it on the
screen and on paper and so on!

You can see these longer and larger number print in pure digit format
on the screen. Not base E represented. Thus PB is doing this internally
in some way. So why can't I use the data the way PB does this to do all
this, just like I've done for years with 'long' integers?

Inquiring mind wants to know! Thanks..




------------------
Mike Luther
[email protected]

[Paul Dixon]

Mike,
QUADs are just 8 bytes in memory and are a standard Intel data type, usually handled by the FPU in PB, but you probably don't need to know that.
Intel data types are little endian, lowest byte is in lowest address.
You can access them using pointers like any other data type:

a&&=&h1234567890123456   'a QUAD

dim p as byte ptr
p=varptr32(a&&)          'pointer to the bytes in that QUAD
for r& = 7 to 0 step-1
print right$("0"+hex$(@p[r&]),2);" ";
next
print

<<So why can't I use the data the way PB does this to do all this, just like I've done for years with 'long' integers? >>

Don't know. Why can't you?

Paul.

------------------