Logical AND on a double

  • Thread starter Thread starter mcescher
  • Start date Start date
M

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.
 
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.
Click to expand...
What do you like to get as result?


mfG
--> stefan <--
 
Is there a way to do a logical AND on two numbers if they are a double?
I'm currently getting an overflow error.
Click to expand...

? 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
 
Stefan said:
hi Chris,

What do you like to get as result?


mfG
--> stefan <--
Click to expand...

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.
 
I need to go up to 2^51

Thanks,
Chris M.

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

HTH
Tim F
Click to expand...
 
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.
 
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
Click to expand...
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 <--
 
....

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

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

Chris M.
 
Allen said:
That's not going to work. The Double doesn't have enough digits of precision
for that.
Click to expand...

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.
 
mcescher said:
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)
Click to expand...

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)
 
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.
 
mcescher said:
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?
Click to expand...

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?
Click to expand...

Yes, but recognize that using a variant doesn't allow you to use any more
digits.
 
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.
 
Back
Top