I want to complain ...


Recommended Posts

Where is my article??

You can't delete my article...You haven't power to delete my article...

DAQFactory must be modify many unsuitable problems..Don't give me more no help excuse...

I give you advise...You should be grateful...But don't delete my article again..

Here!Below is some another question:

0|0x100000000 error

0|2^32 error

0x100000000 error

SetBit(0,32) error

2^32 correct..

In any language are simple computing...

Please fix these problem...And now how to settle these problem...

Link to comment
Share on other sites

Which article? None of your articles have been deleted. All posts are moderated, so anything you submitted must be reviewed and approved by AzeoTech. We do not delete valid questions or even complaints, but simply moderate for spam. Spammers like to post large lists of websites to open forums and so an unmoderated forum is not a good thing. We have messages indicating that your posts are moderated all over.

As for your problems, I have added to the fix list to make the bit operations 32 bit instead of 31 bit, however this will not fix anything you indicated here, as your samples are setting the 33rd bit. The 32 bit will likely be done for 5.78. As I said in your other post, we cannot at this time support 64 bit integers because internally we use 64 bit floating point values which have only 52 bits of precision. Supporting 33 bits instead of 32 does not really make sense.

In any language are simple computing...

This is because other languages use strong variable typing and support more than just two variable types. To make DAQFactory easier to program, we support only two variable types: a double precision floating point (64 bit with 52 bits of precision) and a string. We do also do a lot of things that make DAQFactory much easier to program than the other languages you mention. Every language has its strengths and weaknesses, and non-support for 64 bit integers may be DAQFactory's weakness, but its made up for certainly by its strengths.

This is also an easily work-aroundable problem. For example, just make some functions for yourself to handle higher precision values. If you need 64 bit, you'll probably need to store it in an array of two 32 bit values (which, by the way, is how Microsoft MFC largely handles 64 bit and higher integers). If you need less than 52 bits, then you can just use a single value, but you'll need to split the value into two and perform the operation on both sides. For example:

function And(x,y)

private bit32 = 2^32
private x1 = x % bit32
private x2 = floor(x / bit32)
private y1 = y % bit32
private y2 = floor(y / bit32)
private r1 = x1 & y1
private r2 = x2 & y2
return (r1 + r2 * bit32)

You can probably optimize this a bit. I split everything up for clarity. Note this only works to 52 bit.

Link to comment
Share on other sites

You get an error for one of two reasons:

1) 0xffffffff is 32 bits and as I've been saying, we only go to 31 bits right now

2) you need to actually do something with the and(). I would just do a ? in the command line.

I actually don't get an error if I ? it, but the value is wrong because DF truncated 0xffffffff to 31 bits. However, if I do and(2^32-1, 2^32-1) I get -1, which of course is incorrect. This is because of the & in the and() function is using a signed value. You may need to add an if() in there to check for it, or, if we switch to unsigned values for bitwise functions in 5.78, you can just wait until then.

Yes I split it for clarity. I could have written it as:

function And(x,y)
   return((x%(2^32)&y%(2^32)) + (floor(x/(2^32)&y/(2^32))*2^32

Of couse that would be harder to debug, especially considering the bug I just mentioned. To fix the -1 bug, you do this:

function And(x,y)

private bit32 = 2^32
private x1 = x % bit32
private x2 = floor(x / bit32)
private y1 = y % bit32
private y2 = floor(y / bit32)
private r1 = x1 & y1
if (r1 < 0)
   r1 += 2^32
endif
private r2 = x2 & y2
return (r1 + r2 * bit32)

Link to comment
Share on other sites

  • 3 weeks later...

Alas, that is the only way you are going to get more than 32 bits. As I've said several times in response to your posts, all numbers are stored in DAQFactory as double precision floats which means that they only have 52 bits of integer precision. These values are converted to 32 bit unsigned longs to perform bitwise operations as C++ does not support bitwise operations on floating point values. We have updated DAQFactory in 5.78 to allow 32 bit numbers in the bitwise operators, but you are still limited to 31 bits for 0x notation. This is because the Standard Template Library function we use in C++ is limited to 31 bits. This limitation is stated in the users guide.

So, while

? 0xffffffff & 0xffffffff

will not work because 0xffffffff is 32 bits and 0x only support 31 bits, this:

? 4294967295 & 4294967295

will work correctly. 4294967295 is 0xfffffff in decimal. I should add that:

? -1 & -1

will also return 4294967295 because the -1 gets converted to a 32 bit unsigned long, which is 2^32-1.

We cannot update DAQFactory to use 64 bit integers to give you the full 52 bits available to a double. This is because 64 bit math is quite a bit slower than 32 bit math (unless you are using one of the 64 bit versions of windows, which few are) and so the change could adversely affect all the other users that use the bitwise functions and need the speed.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.