Re: to_hex() for negative inputs

On Wed, 25 Jan 2023 at 21:43, Peter Eisentraut wrote: > > On 24.01.23 14:10, Dean Rasheed wrote: > > I also think it might be useful for it to gain a couple of boolean options: > > > > 1). An option to output a signed value (defaulting to false, to > > preserve the current two's complement

Re: to_hex() for negative inputs

On 24.01.23 14:10, Dean Rasheed wrote: I also think it might be useful for it to gain a couple of boolean options: 1). An option to output a signed value (defaulting to false, to preserve the current two's complement output). I find the existing behavior so strange, I would rather give up and

Re: to_hex() for negative inputs

Hi Dean, > > So in your opinion what is the expected result of to_hex(INT_MIN, > > with_sign => true)? > > > > "-8000" or "-0x8000", depending on whether the prefix is > requested. Whether this is the right result is very debatable. 0x8000 is a binary representation of -2147483648:

Re: to_hex() for negative inputs

On Wed, 25 Jan 2023 at 10:57, Aleksander Alekseev wrote: > > > Of course there is. This is easy to code in C using unsigned ints, > > without resorting to abs() (yes, I'm aware that abs() is undefined for > > INT_MIN). > > So in your opinion what is the expected result of to_hex(INT_MIN, >

Re: to_hex() for negative inputs

Hi Dean, > Of course there is. This is easy to code in C using unsigned ints, > without resorting to abs() (yes, I'm aware that abs() is undefined for > INT_MIN). So in your opinion what is the expected result of to_hex(INT_MIN, with_sign => true)? -- Best regards, Aleksander Alekseev

Re: to_hex() for negative inputs

On Wed, 25 Jan 2023 at 09:02, Aleksander Alekseev wrote: > > > I don't see how a couple of extra arguments will expand to hundreds. > > Maybe I was exaggerating, but the point is that adding extra flags for > every possible scenario is a disadvantageous approach in general. > There is no need to

Re: to_hex() for negative inputs

Hi Dean, > I don't see how a couple of extra arguments will expand to hundreds. Maybe I was exaggerating, but the point is that adding extra flags for every possible scenario is a disadvantageous approach in general. There is no need to increase the code base, the amount of test cases and the

Re: to_hex() for negative inputs

On Tue, 24 Jan 2023 at 13:43, Aleksander Alekseev wrote: > > Adding extra arguments for something the user can implement > (him/her)self doesn't seem to be a great idea. With this approach we > may end up with hundreds of arguments one day. > I don't see how a couple of extra arguments will

Re: to_hex() for negative inputs

Hi Dean, > I only recently realised that to_hex() converts its input to unsigned > before converting it to hex (something that's not mentioned in the > docs): Technically the documentation is accurate [1]: """ Converts the number to its equivalent hexadecimal representation. """ But I agree

to_hex() for negative inputs

I only recently realised that to_hex() converts its input to unsigned before converting it to hex (something that's not mentioned in the docs): to_hex(-1) -> I think that's something that some users might find surprising, especially if they were expecting to be able to use it to