By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,257 Members | 1,616 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,257 IT Pros & Developers. It's quick & easy.

Has anyone posted code to convert longer HEX numbers to DEC strings?

P: n/a
MLH
The largest integer A97 can deal with is 2,147,483,647,
as I understand it from HELP. I would be content to represent
larger integers as strings. For example, "2147483648" would
suit me fine. I would be interested in converting larger HEX
numbers to decimal integer equivalents. For example, a 16-digit
HEX number is quite a large decimal value and I would be
happy to represent it as a string, as it would suit my purposes
fine. Since the math, however, is not going to be calculated
by Access, it seems an intimidating task to code it. Was wondering,
perhaps, if someone might have already done so.
Dec 2 '05 #1
Share this Question
Share on Google+
28 Replies


P: n/a
I believe Access97 had a variant decimal type.
And I believe such a type could handle up to 12 hex characters, even
doing math with same as follows:
Sub test()
Dim VariantDecimal As Variant
VariantDecimal = CDec("&hffffffffffff")
Debug.Print VariantDecimal
Debug.Print VariantDecimal / 5
Debug.Print Sqr(VariantDecimal)
End Sub

I also believe that somewhere, somehow, sometime, variant decimals were
changed, allowing larger numbers. And I believe that the VBA variant
decimal type is not identical with JET's decimal data type which
permits maximium values of only 10^28 - 1.

Dec 2 '05 #2

P: n/a
MLH
Well that is great news!
281474976710655 Variant Decimal
56294995342131 Above Amount Div by 5
16777216 Square Root of the First Number
Now, if I can come up with an ingenious way to break
down Variant Decimal values larger than &hFFFFFFFF,
I'll be home free. I'll bet someone clever has already
figured out and posted a way to convert numbers up
to 281474976710655 to HEX strings.

On 1 Dec 2005 16:30:06 -0800, "Lyle Fairfield" <ly***********@aim.com>
wrote:
I believe Access97 had a variant decimal type.
And I believe such a type could handle up to 12 hex characters, even
doing math with same as follows:
Sub test()
Dim VariantDecimal As Variant
VariantDecimal = CDec("&hffffffffffff")
Debug.Print VariantDecimal
Debug.Print VariantDecimal / 5
Debug.Print Sqr(VariantDecimal)
End Sub

I also believe that somewhere, somehow, sometime, variant decimals were
changed, allowing larger numbers. And I believe that the VBA variant
decimal type is not identical with JET's decimal data type which
permits maximium values of only 10^28 - 1.


Dec 2 '05 #3

P: n/a
MLH wrote:
Now, if I can come up with an ingenious way to break
down Variant Decimal values larger than &hFFFFFFFF,
I'll be home free. I'll bet someone clever has already
figured out and posted a way to convert numbers up
to 281474976710655 to HEX strings.


Great, I'm sure you'll find it. I hope you won't forget to post it here
so I can compare it with mine and perhaps pick up a pointer.

Dec 2 '05 #4

P: n/a
http://groups.google.co.uk/group/mic...c508264bc18a96
or

http://tinyurl.com/9d62n

--
Terry Kreft

"MLH" <CR**@NorthState.net> wrote in message
news:ur********************************@4ax.com...
The largest integer A97 can deal with is 2,147,483,647,
as I understand it from HELP. I would be content to represent
larger integers as strings. For example, "2147483648" would
suit me fine. I would be interested in converting larger HEX
numbers to decimal integer equivalents. For example, a 16-digit
HEX number is quite a large decimal value and I would be
happy to represent it as a string, as it would suit my purposes
fine. Since the math, however, is not going to be calculated
by Access, it seems an intimidating task to code it. Was wondering,
perhaps, if someone might have already done so.

Dec 2 '05 #5

P: n/a
Whoops, sorry just realised that's the other way round to what you want to
achieve.

--
Terry Kreft

"Terry Kreft" <te*********@mps.co.uk> wrote in message
news:xG********************@karoo.co.uk...
http://groups.google.co.uk/group/mic...c508264bc18a96
or

http://tinyurl.com/9d62n

--
Terry Kreft

"MLH" <CR**@NorthState.net> wrote in message
news:ur********************************@4ax.com...
The largest integer A97 can deal with is 2,147,483,647,
as I understand it from HELP. I would be content to represent
larger integers as strings. For example, "2147483648" would
suit me fine. I would be interested in converting larger HEX
numbers to decimal integer equivalents. For example, a 16-digit
HEX number is quite a large decimal value and I would be
happy to represent it as a string, as it would suit my purposes
fine. Since the math, however, is not going to be calculated
by Access, it seems an intimidating task to code it. Was wondering,
perhaps, if someone might have already done so.


Dec 2 '05 #6

P: n/a
MLH
I'm leaning toward dividing the subject value by the largest HEX
order of magnitude possible, MOD'ing off the remainder and working
with that as a starting point ==> concat'ing the remains of the
massacre once everything's been ripped apart 'n chewed up.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

On 1 Dec 2005 22:22:39 -0800, "Lyle Fairfield" <ly***********@aim.com>
wrote:
MLH wrote:
Now, if I can come up with an ingenious way to break
down Variant Decimal values larger than &hFFFFFFFF,
I'll be home free. I'll bet someone clever has already
figured out and posted a way to convert numbers up
to 281474976710655 to HEX strings.


Great, I'm sure you'll find it. I hope you won't forget to post it here
so I can compare it with mine and perhaps pick up a pointer.


Dec 2 '05 #7

P: n/a
Great! show us an example, please.

Dec 2 '05 #8

P: n/a
MLH <CR**@NorthState.net> wrote in
news:qv********************************@4ax.com:
On 1 Dec 2005 16:30:06 -0800, "Lyle Fairfield"
<ly***********@aim.com> wrote:
I believe Access97 had a variant decimal type.
And I believe such a type could handle up to 12 hex characters,
even doing math with same as follows:
Sub test()
Dim VariantDecimal As Variant
VariantDecimal = CDec("&hffffffffffff")
Debug.Print VariantDecimal
Debug.Print VariantDecimal / 5
Debug.Print Sqr(VariantDecimal)
End Sub

I also believe that somewhere, somehow, sometime, variant decimalswere changed, allowing larger numbers. And I believe that the VBA
variant decimal type is not identical with JET's decimal data typewhich permits maximium values of only 10^28 - 1.


Well that is great news!
281474976710655 Variant Decimal
56294995342131 Above Amount Div by 5
16777216 Square Root of the First Number
Now, if I can come up with an ingenious way to break
down Variant Decimal values larger than &hFFFFFFFF,
I'll be home free. I'll bet someone clever has already
figured out and posted a way to convert numbers up
to 281474976710655 to HEX strings.


???

Lyle's code operates on #hFFFFFFFFFFFF, which is the number you're
looking for.

I don't know what Lyle is talking about with his decimal veriant.

Surely a Double or a Single could store all the values you needed,
unless I've completely forgotten how to interpret exponential
notation. My Windows calculator tells me that your upper limit,
#hFFFFFFFFFFFF, is 2.81474976710655e+14, and the upper limit for
double data type is 1.79769313486232e+308, according to the A97
help
file. Now, the base number for your upper limit is bigger, but the
exponent is many orders of magnitude smaller, so it seems quite
clear to me that you should be able to store your numbers
accurately
in a double, a numeric data type.

Unless, of course, I'm terribly confused about how all this works.
If I am, I'm sure someone will correct me.

I'd certainly think it would be *much* easier to store numbers as
numbers than to have to convert them from strings in order to
perform operations on them.

Why would you *not* choose double or Single? What, exactly, would
you be gaining by storing your numbers as strings?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Dec 2 '05 #9

P: n/a
David W. Fenton <dX********@bway.net.invalid> wrote:
MLH <CR**@NorthState.net> wrote in
news:qv********************************@4ax.com:
On 1 Dec 2005 16:30:06 -0800, "Lyle Fairfield"
<ly***********@aim.com> wrote:
I also believe that somewhere, somehow, sometime, variant decimals
were changed, allowing larger numbers. And I believe that the VBA
variant decimal type is not identical with JET's decimal data type
which permits maximium values of only 10^28 - 1.


Well that is great news!
281474976710655 Variant Decimal
56294995342131 Above Amount Div by 5
16777216 Square Root of the First Number
Now, if I can come up with an ingenious way to break
down Variant Decimal values larger than &hFFFFFFFF,
I'll be home free. I'll bet someone clever has already
figured out and posted a way to convert numbers up
to 281474976710655 to HEX strings.


???

Lyle's code operates on #hFFFFFFFFFFFF, which is the number you're
looking for.

I don't know what Lyle is talking about with his decimal veriant.


Why not upto #hFFFFFFFFFFFFFFFFFFFFFFFF
=79228162514264337593543950335, the largest variant decimal?

--
Paul
Dec 2 '05 #10

P: n/a
"kaniest" <ka*****@xs4all.nl> wrote in
news:43***********************@news.xs4all.nl:
David W. Fenton <dX********@bway.net.invalid> wrote:
MLH <CR**@NorthState.net> wrote in
news:qv********************************@4ax.com:
On 1 Dec 2005 16:30:06 -0800, "Lyle Fairfield"
<ly***********@aim.com> wrote:
I also believe that somewhere, somehow, sometime, variant
decimals were changed, allowing larger numbers. And I believe
that the VBA variant decimal type is not identical with JET's
decimal data type which permits maximium values of only 10^28 - 1.

Well that is great news!
281474976710655 Variant Decimal
56294995342131 Above Amount Div by 5
16777216 Square Root of the First Number
Now, if I can come up with an ingenious way to break
down Variant Decimal values larger than &hFFFFFFFF,
I'll be home free. I'll bet someone clever has already
figured out and posted a way to convert numbers up
to 281474976710655 to HEX strings.
???

Lyle's code operates on #hFFFFFFFFFFFF, which is the number
you're looking for.

I don't know what Lyle is talking about with his decimal

veriant.
Why not upto #hFFFFFFFFFFFFFFFFFFFFFFFF
=79228162514264337593543950335, the largest variant decimal?


Because MLH asked about a range up to #hFFFFFFFFFFFF in his
original
post.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Dec 3 '05 #11

P: n/a
David W. Fenton <dX********@bway.net.invalid> wrote:
"kaniest" <ka*****@xs4all.nl> wrote in
news:43***********************@news.xs4all.nl:
David W. Fenton <dX********@bway.net.invalid> wrote:
Lyle's code operates on #hFFFFFFFFFFFF, which is the number
you're looking for.

I don't know what Lyle is talking about with his decimal veriant.


Why not upto #hFFFFFFFFFFFFFFFFFFFFFFFF
=79228162514264337593543950335, the largest variant decimal?


Because MLH asked about a range up to #hFFFFFFFFFFFF in his
original
post.


That's only 12 hex digits, he asked for 16.
This returns a variant decimal from a string with upto 24 hex digits:

function f(x$):f=cdec(0)
dim i&:for i=1 to len(x)
f=16*f+("&h" & mid$(x,i,1))
next i
end function

--
Paul
Dec 3 '05 #12

P: n/a
It's a nice function.
How about the other way, ie return a variant decimal from a hex string
of up to 24 hex digits?

Dec 3 '05 #13

P: n/a
Of course I mean the other way:
hex string of up to 24 characters from a variant decimal.

Dec 3 '05 #14

P: n/a
Lyle Fairfield <ly***********@aim.com> wrote:
Of course I mean the other way:
hex string of up to 24 characters from a variant decimal.


function g$(x)
dim x0,x1
x0=int(abs(cdec(x)))
do while x0>0
x1=int(x0/16)
g=hex(x0-16*x1) & g
x0=x1
loop
if g="" then g="0"
end function

--
Paul
Dec 3 '05 #15

P: n/a
kaniest wrote:
Lyle Fairfield <ly***********@aim.com> wrote:
Of course I mean the other way:
hex string of up to 24 characters from a variant decimal.


function g$(x)
dim x0,x1
x0=int(abs(cdec(x)))
do while x0>0
x1=int(x0/16)
g=hex(x0-16*x1) & g
x0=x1
loop
if g="" then g="0"
end function


Your functions are great and, I suspect they always return the right
answer, (I'm not so sure about that for mine!)
But I'm posting mine here not so much to suggest them as an alternative
but as a comment on the disparate ways humans can think!

Option Explicit

Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" _
(Destination As Any, Source As Any, ByVal Length As Long)

Public Function VariantDecimalAsHexString(ByVal VariantDecimal As
Variant) As String
Dim z(3) As Long
CopyMemory z(0), ByVal VarPtr(VariantDecimal) + 4, 4
CopyMemory z(1), ByVal VarPtr(VariantDecimal) + 8, 4
CopyMemory z(2), ByVal VarPtr(VariantDecimal) + 12, 4
If z(0) <> 0 Then _
VariantDecimalAsHexString = _
VariantDecimalAsHexString & Hex(z(0))
If z(2) <> 0 Then _
VariantDecimalAsHexString = _
VariantDecimalAsHexString & Hex(z(2))
If z(1) <> 0 Then _
VariantDecimalAsHexString = _
VariantDecimalAsHexString & Hex(z(1))
If Len(VariantDecimalAsHexString) = 0 Then
VariantDecimalAsHexString = "0"
End Function

Public Function HexStringAsVariantDecimal(ByVal HexString As String) As
Variant
HexStringAsVariantDecimal = CDec("0")
HexString = Right(String(24, "0") & HexString, 24)
Dim z(3) As Long
z(0) = "&h" & Mid$(HexString, 17, 8)
z(1) = "&h" & Mid$(HexString, 9, 8)
z(2) = "&h" & Mid$(HexString, 1, 8)
CopyMemory ByVal VarPtr(HexStringAsVariantDecimal) + 8, z(0), 4
CopyMemory ByVal VarPtr(HexStringAsVariantDecimal) + 12, z(1), 4
CopyMemory ByVal VarPtr(HexStringAsVariantDecimal) + 4, z(2), 4
End Function

Dec 4 '05 #16

P: n/a
Lyle Fairfield wrote:
Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" _


.... may save quite a few cycles. I could change f() to:

function f(x$):f=cdec(0)
dim x0$:x0=string(24-len(x),"0") & x
copymemory byval varptr(f)+4,clng("&h" & mid$(x0,1,8)),4
copymemory byval varptr(f)+12,clng("&h" & mid$(x0,9,8)),4
copymemory byval varptr(f)+8,clng("&h" & mid$(x0,17,8)),4
end function

The other way round is complicated by Hex() dropping leading
zeroes, well ... mmm ... zzz ...

BTW, what happend to the infamous 12 hex digit upper limit?

--
Paul
Dec 4 '05 #17

P: n/a
kaniest wrote:
BTW, what happend to the infamous 12 hex digit upper limit?


Is it 12 digits or 12 bytes?

--
Lyle Fairfield
Dec 4 '05 #18

P: n/a
Lyle Fairfield wrote:
kaniest wrote:
BTW, what happend to the infamous 12 hex digit upper limit?


Is it 12 digits or 12 bytes?


#hFFFFFFFFFFFF, according to David. That hints at 12 hex digits, or?
Dec 4 '05 #19

P: n/a
kaniest wrote:
Lyle Fairfield wrote:
kaniest wrote:
BTW, what happend to the infamous 12 hex digit upper limit?

Is it 12 digits or 12 bytes?


#hFFFFFFFFFFFF, according to David. That hints at 12 hex digits, or?


The length of a variant decimal is, like all variants, 16 bytes.

The first two bytes indicate the subtype of the variant, in this case,
14 -> decimal.
The third byte is the number of decimal places.
The fourth byte is zero for positive, 128 for negative. TTBOMK the other
bits of this byte are not used to add to the value of the decimal as
they might be in a twos complement kind of representation. Decimals are
not a twos complement kind of representation which is why
FFFFFFFFFFFFFFFFFFFFFFFF is not -1 but 79228162514264337593543950335.

The last twelve bytes are the value of the decimal, but in what is to me
a rather strange configuration. As nearly as I can tell the order of
the bytes is 1,2,3,4,9,10,11,12,5,6,7,8 if we thought about them in the
order we consider normal for decimal; I was prepared for byte 1 (of the
12) or byte 12 being 1 to 255, but not byte 8. Perhaps someone can shed
some light on this.

One can slam dunk 12 bytes of ff (with copymemory) and one gets a
working decimal. I think you previously posted the size:
79228162514264337593543950335
If one stores
79228162514264337593543.950335
or
-79228162514264337593543.950335
the 12 value bytes don't change at all; the third byte becomes 6 and the
4th byte becomes 128 (for the negative).

Perhaps, there is some validity to a limit of 12 hex digits for some
other data type (although I can't think of what it could be unless
perhaps doubles are limited to 6 bytes for integer part). I think there
is no such limit for the variant decimal.

--
Lyle Fairfield
Dec 4 '05 #20

P: n/a
"kaniest" <ka*****@xs4all.nl> wrote in
news:43***********************@news.xs4all.nl:
David W. Fenton <dX********@bway.net.invalid> wrote:
"kaniest" <ka*****@xs4all.nl> wrote in
news:43***********************@news.xs4all.nl:
David W. Fenton <dX********@bway.net.invalid> wrote: Lyle's code operates on #hFFFFFFFFFFFF, which is the number
you're looking for.

I don't know what Lyle is talking about with his decimal
veriant.

Why not upto #hFFFFFFFFFFFFFFFFFFFFFFFF
=79228162514264337593543950335, the largest variant decimal?


Because MLH asked about a range up to #hFFFFFFFFFFFF in his
original
post.


That's only 12 hex digits, he asked for 16.
This returns a variant decimal from a string with upto 24 hex
digits:

function f(x$):f=cdec(0)
dim i&:for i=1 to len(x)
f=16*f+("&h" & mid$(x,i,1))
next i
end function


You're right -- the original number got lost in the mix.

Nonetheless, I see no reason to worry about numbers larger than he
needs, especially given that there are two available Access numeric
formats that are able to handle numbers far larger than his 16-
digit
hex number,

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Dec 4 '05 #21

P: n/a
"kaniest" <ka*****@xs4all.nl> wrote in
news:43***********************@news.xs4all.nl:
Lyle Fairfield wrote:
kaniest wrote:
BTW, what happend to the infamous 12 hex digit upper limit?


Is it 12 digits or 12 bytes?


#hFFFFFFFFFFFF, according to David. That hints at 12 hex digits,
or?


You are correct that the OP asked for up to 16 digits, which
impplies #hFFFFFFFFFFFFFFFF as the upper limit of his requirements.

I just don't see why the numbers need to be stored in Hex when
single and double can easily accomodate numbers of that magnitude.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Dec 4 '05 #22

P: n/a
David W. Fenton wrote:
Nonetheless, I see no reason to worry about numbers larger than he
needs, especially given that there are two available Access numeric
formats that are able to handle numbers far larger than his 16-
digit
hex number,


It's not only about scale, *significant* digits may be an issue.
Decimal has 28, double has only 14.

?cdec(11111111111111) * cdec(11111111111111)
123456790123454320987654321
?cdbl(11111111111111) * cdbl(11111111111111)
1,23456790123454E+26
Dec 4 '05 #23

P: n/a
Dim d As Double
Dim v As Variant
v = CDec("&hfffffffffffff")
'13 hex digits
d = v
Debug.Print v, Format(d, "#.#")
'4503599627370495 4503599627370500

Dec 4 '05 #24

P: n/a
Lyle Fairfield wrote:

....[on variant decimals in memory] ...

DCOM's description clears up some points, I figure.

typedef struct tagDEC {
USHORT wReserved;
BYTE scale;
BYTE sign;
ULONG Hi32;
ULONGLONG Lo64;
} DECIMAL;
Dec 5 '05 #25

P: n/a
Explains everything. Why wasn't I smart enought to look this up?
Argggggh!

Dec 5 '05 #26

P: n/a
Lyle Fairfield wrote:
Argggggh!


And have nightmares about fixing Decimal with visual masm
for applications, like me?
Dec 5 '05 #27

P: n/a
kaniest wrote:
Lyle Fairfield wrote:
Argggggh!


And have nightmares about fixing Decimal with visual masm
for applications, like me?

.... zzz ...
function g$(x)
dim a&(0 to 2):copymemory a(0),byval varptr(x)+4,12
dim i:for each i in array(0,2,1)
dim h$:h=hex$(a(i))
if len(g)>0 then
g=g & string$(8-len(h),"0") & h
elseif h="0" imp i=2 then
g=h
end if
next i
end function
....zzz
Dec 5 '05 #28

P: n/a
kaniest wrote:
elseif h="0" imp i=2 then

....uh...
elseif h="0" imp i=1 then
....zzz
Dec 5 '05 #29

This discussion thread is closed

Replies have been disabled for this discussion.