Why is int regarded as type INT64

[czardas]

I understand there is still a lot of work in progress, and I hope you now understand my confusion. I did try one or two experiments with large numbers - but that was with an earlier beta release (testing code posted by someone else). It seemed that there may have been some issues (inconclusive - partly because I was testing something else at the time). 15 digit precision was the limit for a long time, and I believe this also applied to integers ==> +/-9.99999999999999e+014

I'm not sure which operators / maths functions are able to handle 64-bit integers, or what the current floating point limit is - well actually, I think it's double precision (rounded to exactly 15 digits).

Edited March 1, 2014 by czardas

[czardas]

The problem I can see -and it's a true bug from my view- is when the interpretor sees a 4-byte hex literal having the leftmost bit set: it interprets it as a 32-bit negative value.

 

It's interesting that you consider this to be a bug: I consider it to be an inherent limitation of binary systems generally - one which can never be satisfactorily resolved. Any potential patch will always end up looking rather ugly.

[jchd]

Of course it's a bug. It means that leading zeroes are significant. It also means there are two distinct representations for some values.

2's complement representation uses a given bit size. With typed languages like C there is no problem as the size of the storage element is well defined. Since AutoIt uses dynamic typing there is no such fixed bit size.

Local Const $32bit = 0xffffffff
Local Const $33bit = 0x00ffffffff

ConsoleWrite($32bit & " and " & $33bit & " are " & (($32bit = $33bit) ? "equal" : "different") & @LF)

Using leading zeroes like this is contrary to every convention available. It is also contrary to the description made in the help.

[czardas]

I even think defining the container is still a bit of an ugly solution - from an aesthetic point of view - but with binary I see absolutely no alternative. Adding preceeding zeros seems a difficult system to work with, and will most likely prove unreliable. While there exist an infinite number of positive and negative integers, 2's compliment will always be problematic - clever as it may be, 2's compliment is the bug.

Edited March 11, 2014 by czardas

[jchd]

May I differ?

2's complement is fine and unambiguous. What is ambiguous is hex representation without indication of container type. Hex denotes the image of a value, not the value. Look at Hex(0.3).

The problem is with mandatory leading zeroes for negative values as examplified above.

It would be much, really much clearer if hex values were using the L convention for instance:

0xffffffff = -1

0xffffffffL = 4294967295

[czardas]

Well I understand you and respect both your views and experience. The number of binary variants in existance is also difficult to quantify. Hex is a perfect representation for binary, but a number base is something without containment. This is where I find 2's compliment restrictive: yet again something of a trade-off.

BTW, Long Long Long Long - where does it end? I'm not saying this 'L convention' is bad - just rather ugly and somewhat unfortunate.

Edited March 11, 2014 by czardas

[jchd]

One final L (or not) is enough to differentiate 32- and 64-bit signed ints, which are the only variants where this matters AFAICT. This convention is already in use in a few contexts.

[czardas]

Understood. I'm sure I'll get used to that. It's preferable to the current ambiguity.

[czardas]

I would prefer something like AutoItSetOption("Integer", 32) or AutoItSetOption("Integer", 64) to fix this bug. I think it's less intrusive, and I imagine easier for the developers to implement. Since it only affects reading certain ranges, I don't believe introducing a totally new hex syntax is the way forward.

Edited April 1, 2014 by czardas

[jchd]

I differ. You might very well have to use different Int sizes in various parts (or loops) of a script, so that would need issuing AutoItSetOption("Integer", 32) or 64 before any use of $n = 0x165489. I personnally find a trailing L easier: 0x165489 or 0x165489L

[czardas]

How often is someone going to do that jchd - I mean mix and match that way? And yes if you intend to do that, why make it inconsistant with other languages for the sake of such exceptional usage? Why make everyone else have to rewrite every 8 digit hex value above/below 0x80000000 because one person is coding adhoc? It only affects reading the data, right? All the affected numbers are within the 15 digit limit anyway, and can be hard coded or converted to decimal so as to be read correctly. I think adding an option would be less intrusive and backwards compatible to a greater degree. In addition there would generally be less bloat. Forward compatibility is also a feature: because we can easily go 128, 256 etc... when the time comes.

I might also want to export numeric data to another language. It's inconvenient to have to reformat the data. I think the case for setting an option is very strong and the case for adding L is, so far, not very convincing.

Edited April 1, 2014 by czardas

[jchd]

Portability of AutoIt code to some other language is pretty artificial in my view.

Nothing would need rewriting anyway. The issues only arises with hex values 0x80000000 .. 0xFFFFFFFF which you need to consider unsigned. Existent code is OK.

We can force these values to Int64 by writing 0x080000000 .. 0x0FFFFFFFF but unsuspecting users may miss the need for the leading zero (this is not conventional in any language I kow of). Having 0x80000000L .. 0xFFFFFFFFL would be fine, but I agree that this is a minor inconvenience to fix.

OTOH a global option, even if resetable would need to keep track of the current setting hex constants convey. For instance it woulld need to be explicitely set in every include using ambiguous hex, and so on in user code.

[czardas]

I'm not fully aware of the extent to which this might cause problems. There are currently no problems with the includes as far as I know, but I do see where you are coming from. I just don't quite understand why it has to be a problem. Perhaps it's just slightly more difficult to impliment than I at first thought. It would appear to require file scope, although it ought not to affect any globals (in either case) providing that the included libraries are declared (as is customary) at the start of a script. One way or another, any solution should be suitable to accomodate future 64bit bitwise operands. Maybe your suggestion is better in some ways - I'm not sure. Good points you made.

Edited April 1, 2014 by czardas

[trancexx]

If you want number in either form to be 64 bits wide then you'd currently use Int function.

It's as inconvenienet as current solution for bitwise operations (hint - functions), and therefore consistent.

Solution that would include adding global options is unacceptable from more than one logical reason, one or two of which are alredy mentioned here.

[czardas]

Ha trancexx, It's better to be consistently inconvenient than inconsistently inconvenient. Then at least you know what's going on. Thanks for the hints - to both you and jchd. I see there's more to this than meets the eye.

The 'L' is starting to grow on me.

Edited April 1, 2014 by czardas

[JohnOne]

I would like to see czardas MVP.

He knows the dance, helps loads of people etc...

He's fucking ace.

[czardas]

JohnOne, I very much appreciate the vote of confidence. I only wish I had time to help more people than I do. I am also impressed by your development, and I know you spend more time helping others than I do.

BTW - the big boss will be in town tomorrow and hopefully we can confirm the Manchester event.

Edited April 2, 2014 by czardas