FixedNumber.toHexString gives incorrect results for negative numbers

[abazlinton]

FixedNumber.from(-1).toHexString()

"0xfffffffffffffffff21f494c589c0000"

BigNumber.from(-1).toHexString()

"-0x01"

Thanks!

[ricmoo]

FixedNumber returns the normalized 2’s compliment value, for its width, that is compatible with the decimal types in Solidity, Vyper, etc.

BigNumber does not support this implicitly, because a BigNumber doesn’t have a known width to sign extend to.

[abazlinton]

So HexString isn't a consistent type as such? The docs (and function naming) I think imply that it would be...

[ricmoo]

More like each has separate forms of hexidecimal representation.

It is not possible to have a meaningful representation in hexidecimal in a fixed-width format.

For example, what should the decimal value -17.03125 look like in hexidecimal? It should be -0x11.08, but this value now requires padding which would represent underflow under the same format for adjacent values; i.e. the binary -0b10001.00001 bytes since we need to position the decimal point on a position that is congruent to 0 mod 4 (as each nibble is 4 bits wide), we need to extend this to -0b0001 0001 . 0000 1000, which now include 3 additional hex positions than the format can encode.

This is all off the top of my head, there may be maths mistakes, but the output format would be confusing and I don’t think it is meaningful in most cases.

What use case are you trying to solve with this?

[abazlinton]

I was just looking for a smooth way to move between FixedNumber and BigNumber, and had falsely assumed HexString was the same thing in both cases. But I guess each has their own specialty - FixedNumber's for precision, and BigNumber's for magnitude, so I guess it makes sense that there's going to be some trickiness there. My knowledge of number representation is a bit rusty. Anyway thanks for your thorough replies. I'm sure I can work around it :).