Logical AND on a double

[mcescher]

Is there a way to do a logical AND on two numbers if they are a double?
I'm currently getting an overflow error.

Thanks,
Chris M.

 

[Stefan Hoffmann]

hi Chris,

Is there a way to do a logical AND on two numbers if they are a double?
I'm currently getting an overflow error.

What do you like to get as result?


mfG
--> stefan <--

 

[Tim Ferguson]

Is there a way to do a logical AND on two numbers if they are a double?
I'm currently getting an overflow error.

? 37 and 43
33

? 37# and 43#
33

? 37.2 and 43.33
33

? 37e5# and 43e6#
1056768

? 37e10 and 43E10
' overflow


I think you have to stay within the boundaries of a Long integer. How big
are your numbers?

HTH


Tim F

 

[mcescher]

hi Chris,

What do you like to get as result?


mfG
--> stefan <--

I just need to see if (A and B) is true then do something....

Perhaps a little more information. I need to store the US States a
person is licensed to work in. Created a table with State names and a
StateCode. StateCode= 2^x where x is the number of the state.

StateCode StateName StateAbbr
1 Alabama AL
2 Alaska AK
4 Arizona AZ
8 Arkansas AR

If agent has a code of 7, then he can work in AL, AK, and AZ

Public Function ShowStates(dblStateKey As Double) As String
Dim db As DAO.database, rs As DAO.Recordset, strTemp As String
Set db = CurrentDb()
Set rs = db.OpenRecordset("SELECT * FROM tblStates;")
With rs
.MoveFirst
Do While Not .EOF
If dblStateKey < !StateCode Then
If !StateCode And dblStateKey Then
strTemp = strTemp & !StateAbbr & ", "
End If
End If
.MoveNext
Loop
End With
ShowStates = Left(strTemp, Len(strTemp) - 2)
End Function

Code works fine except the overflow when the StateCode is too big for a
long int.

Help,
Chris M.

 

[mcescher]

I need to go up to 2^51

Thanks,
Chris M.

<<Stuff deleted >>
I think you have to stay within the boundaries of a Long integer. How big
are your numbers?

HTH
Tim F

 

[Allen Browne]

That's not going to work. The Double doesn't have enough digits of precision
for that.

While bitfields are occassionally useful, they are not the way to design a
relational database. You need to create a related table with fields like
this:
CompanyID foreign key to tblCompany.CompanyID
StateID foreign key to tblState.StateID
You can now enter as many states as each company needs, and query the field
orders of magnitude faster.

 

[Stefan Hoffmann]

hi Chris,

Perhaps a little more information. I need to store the US States a
person is licensed to work in. Created a table with State names and a
StateCode. StateCode= 2^x where x is the number of the state.

StateCode StateName StateAbbr
1 Alabama AL
2 Alaska AK
4 Arizona AZ
8 Arkansas AR

If agent has a code of 7, then he can work in AL, AK, and AZ

Is there reason for that kind of code?

Normally you would store that kind of information in a m:n relationship,
which is many times faster to evaluate for a RDBMS than your code.

AGENT 1:n AGENT_STATE m:1 STATE

with a minimal table layout of

AGENT: ID (PK), Name
STATE: ID (PK), Name
AGENT_STATE: AGENT_ID (FK), STATE_ID (FK), PK(AGENT_ID, STATE_ID)


mfG
--> stefan <--

 

[Tim Ferguson]

....

You need to create a related table with
fields like this:
CompanyID foreign key to tblCompany.CompanyID
StateID foreign key to tblState.StateID

<telepathic gasp>

Did you get the reference to numbers-of-states-in-the-USA from the 51, or
did you have prior knowledge? I was thinking something like numbers-of-
weeks-in-a-year-minus-Christmas ... <g>


All the best


Tim F

 

[mcescher]

<< NOT A FLAME >>
In the previous post the code referenced StateCode. So, his assumption
was correct, 50 states plus Washington DC.

Chris M.

 

[mcescher]

That's not going to work. The Double doesn't have enough digits of precision
for that.

It should have enough. Paraphrased from Access help:
A Double will hold up to 1.79 E 308
My data is only up to 2.25 E 15 (I'm only storing positive integers)

A double was able to hold it in the table. Only the "AND" function
failed on anything over what a long integer would hold.

With that being said, I've take the advice given in the thread and
created the other table.

A BIG THANK YOU!!!! To all who helped with this.

Chris M.

 

[Douglas J. Steele]

It should have enough. Paraphrased from Access help:
A Double will hold up to 1.79 E 308
My data is only up to 2.25 E 15 (I'm only storing positive integers)

You missed an important point in your paraphrasing. The original is "stored
as IEEE 64-bit (8-byte) floating-point numbers ranging in value
from -1.79769313486232E308 to -4.94065645841247E-324 for negative values and
from 4.94065645841247E-324 to 1.79769313486232E308 for positive values.".
Note that's 15 significant figures.

While 2^51 may be 2.25179981368525E+15, it's more than 15 significant
figures (in other words, it's not really 2251799813685250)

 

[mcescher]

OK, I'm a little confused, so IF I have a really big number stored in a
double.

i.e. 1.79769313486232E308

Then Access just fills in zeros after the first 15 digits? is that
correct?

One other question (realizing that I've created the above mentioned
table), could I have done a bitwise AND on a variant?

Thanks for all your patience everybody. And all your help.

Chris M.

 

[Douglas J. Steele]

OK, I'm a little confused, so IF I have a really big number stored in a
double.

i.e. 1.79769313486232E308

Then Access just fills in zeros after the first 15 digits? is that
correct?

Yup. Realistically, with numbers of this sort, the 8 byte field is divided
into a mantissa and an exponent, each occupying a fixed number of bits. That
means that, as far as Access knows, no more than 15 digits ever existed.
Special techniques are required to maximize the accuracy of answers: it's a
branch of computing known as Numerical Methods.

One other question (realizing that I've created the above mentioned
table), could I have done a bitwise AND on a variant?

Yes, but recognize that using a variant doesn't allow you to use any more
digits.

 

[mcescher]

THANK YOU for all your help.

Silly Variant help doesn't mention 15 digits of accuracy, so I thought
I would take a stab. Always trying to think outside the box.

(Wait, there's a box around here??)

Thanks again to all who contributed.

Chris M.

 

[Tim Ferguson]

In the previous post the code referenced StateCode. So, his assumption
was correct, 50 states plus Washington DC.

Aha, missed that...


Tim F