Other Int types ?

einhugur

Just so I continue to spam......

Are there other Int types planned ? I am really struggling with porting algorithm code where math is done on Int16 or Int32 where putting it in Integer (64) bit simply gives different results because of the roll over of the smaller ints.

Garry

I'd prefer to keep a single Integer type to avoid introducing extra complexity around numeric conversions and mixed arithmetic. I do understand the problem, though, particularly when an algorithm relies on wrapping at a specific bit width.

I'm open to adding standard library helpers for those operations while keeping the values themselves as Integer.

Could you share an example algorithm (privately if needed) you're trying to port, ideally with the original code and expected results? That would help me understand exactly which operations are needed and whether library helpers would make the port straightforward.

einhugur

I got it to calculate right.........It got ugly though....

Basically after every math operation that can increase the value of the int then I need to call helper method to keep it right

    code = Int32Value(StringToNum(serial.Left(3)))
    result = Int32Value((((Int32Value((Int32Value(code * code)) + 50) Mod 3000) * 81) Mod 10000) + 10000)

Where the helper method is:

Public Function Int32Value(value As Integer) As Integer
Var val32 As Integer = value.BitAnd(0xFFFFFFFF)

# # 2. Check if the 32nd bit (bit 31) is set (the sign bit)
If val32.BitAnd(0x80000000) <> 0 Then
# Subtract 2^32 to convert the unsigned 32-bit range to signed 32-bit
Return val32 - 0x100000000
End If

Return val32

End Function

StringToNum there is a nasty function that does not same as Integer.Parse, but its exact copy of what the old legacy MacOS 9 and older StringToNum Toolbox routine did. (needed to hold compatibility with ancient file format)

bgrommes

I don't know what the 3 bytes coming from the stream are, but regardless of that, StringToNum() yields a native Objo Integer ... if you can't just do whatever you please mathematically with that and just store it back, it must be because whatever you're storing to is a UInt32, not a signed Int32. Maybe what's needed is just Read/WriteUint32() methods for stream and MemoryBlock? Or maybe those 3 bytes are so to speak a UInt24?

I think having unsigned versions of Read/Write Int16/32/64 would be helpful for working with data that could be found in the wild.

Apologies if I'm missing the point ...

einhugur

bgrommes

The first code section is tiny part of part of a crypto section. So the result from that one must be same as other languages generate, there is no compromise on that.

So the 2nd part of the code the Int32Value method forces the Objo int which is int64 to boundaries of Int32. (which is needed for the first thing to work correctly)

(StringToNum there is just side quirk I have to deal with not really relevant to the topic per see)

So basically in language which has Int32 then it would have been like this:

code = StringToNum(serial.Left(3))
result = ((((code * code) + 50) Mod 3000) * 81) Mod 10000) + 10000)

(some bracket mismatch there as I got confused when removing)

So without the integer fix then you get for example 12050 instead of 12030 from it.

Garry

Thanks for the example. Having looked at it more closely, I agree that wrapping each intermediate operation makes this unnecessarily awkward.

I've decided to add Integer32 and UInteger32, with signed and unsigned arithmetic that wraps at 32 bits. This should make algorithms like yours much more natural to port, and will also be useful for checksums, hashes and other code that depends on a particular integer width.

The existing 64-bit Integer will remain the default general-purpose choice. The new types will be optional, so existing code won't need changing.

I've logged the feature here: Add Integer32 and UInteger32 for fixed-width arithmetic.

bgrommes

Garry Please also add Read/Write methods for UInt32 on BinaryStream and MemoryBlock.

Also since MySql / Maria allows unsigned int columns, some support for that may need to be added / improved if not already there. Haven't looked.

Also it would be nice if type coercion were such that I wouldn't have to do casts in situations like:

For i As Integer32 = 0 To Integer32(someCollection.LastIndex)

... although if that's a can of worms, I could live with it.

I know, "greedy, greedy". :-\

Garry

Yes, ReadUInt32 and WriteUInt32 on both BinaryStream and MemoryBlock make sense. I’ve logged Add unsigned 32-bit binary reads and writes alongside the existing Integer32 and UInteger32 feature. Reads will return UInteger32, and both methods will respect the existing LittleEndian setting.

The existing 64-bit Integer can already represent the full range of MySQL’s INT UNSIGNED, and reading those values is supported. I’ll also check database reads and parameter binding with the new types.

For conversions, ordinary literals such as 0 will work naturally, and widening either 32-bit type to Integer will be automatic because it preserves the value.

I’ll keep conversion from an Integer variable to either 32-bit type explicit, though. LastIndex returns a 64-bit Integer, so your example will still need the cast if you specifically want an Integer32 counter. That conversion will be range checked, raising an error if the value doesn’t fit.

For normal collection traversal, I’d continue to use For i As Integer = 0 To someCollection.LastIndex. The new types are there for calculations that specifically need 32-bit behaviour; Integer remains the general-purpose choice.

Garry

This has been implemented for the next release.