Right way to show numbers in binary/hex/octal in your opinion? (page 2)

On Monday, 27 December 2021 at 06:55:37 UTC, Rumbu wrote:

When people are dumping numbers to strings în any other base than 10, they are expecting to see the internal representation of that number. Since the sign doesn't have a reserved bit in the representation of integrals (like it has for floats), for me it doesn't make any sense if I see a negative sign before a hex, octal or binary value.

However, binary uses the most significant digit to identify if the number is positive or negative. I suppose that if you want to not "show" a digit when converting to "hex" and "octal", you could first convert to binary (signed) and then convert this number to "hex" or "octal" but still, these system are used for specific purposes and they don't have a real negative representation so it still doesn't make sense no matter how you see it.

The trickiest value for integrals is the one with the most significant bit set (e.g. 0x80). This can be -128 for byte, but also 128 for any other type than byte. Now, if we go the other way around and put a minus before 0x80, how do we convert it back to byte? If we assume that 0x80 is always 128, -0x80 will be -128 and can fit a byte. On the other side, you cannot store +0x80 in a byte because is out of range.

Yeah, this is why I think that showing the sign is actually a good way to show that it is a signed negative number. If there is no sign, the number can be either positive signed number or unsigned. In the end, a "string" will only be used to print the number to a user so there will be no confusion to the programmers themselves

This is also an issue în phobos:

https://issues.dlang.org/show_bug.cgi?id=20452
https://issues.dlang.org/show_bug.cgi?id=18290

Yeah, I can see why, lol!

December 30, 2021

Re: Right way to show numbers in binary/hex/octal in your opinion?

Posted by rempas
in reply to Rumbu

Permalink

rempas

Posted in reply to Rumbu

Permalink

On Wednesday, 29 December 2021 at 07:12:02 UTC, Rumbu wrote:

I don't care about overflows

WHAT DO YOU.... Just kidding :P. But seriously tho, what do you mean that you don't care about overflows? Overflows can be sneaky and we must always check for them. If not then tell me, what happens when you try to save the number "-500" in a "ubyte"? First of all, D will not let you do that, you need to implicitly cast it. But let's say that you do. What you got? 12!!! Cool ha? There are two problems here. First unsigned types cannot store negative numbers. So our library function should check if the number is negative and in that case not let you do that (an assertion will do). Now even if you say: "well in that case the function will negate the number and return it" but well... This is not logically correct. And second, the value 500 cannot fit into a byte so will must also check that. In
any case, overflows should be checked in debug builds at least.

I care about the fact that D must use the same method when it converts numbers to string and the other way around.

I don't understand what you mean when saying methods (methods as in code, the same algorithm?). But what I understand is that the example "Siarhei Siamashka" did about both -1 and 65535 become exactly the same string after conversion ("FFFF") is a practical problem where there are two actual problem happening.
A. When printing the number, we cannot tell if the number is positive or negative.
B. We cannot get back the original number because we don't know if it's positive or negative.
If we had the "-" sign before the number then the library could negate the number and then add "-" in the front of the string and problem solved!

Yes, this can be a solution to dump it as "-80", but the standard lib does not even parse the "-" today for other bases than 10.

RANT ALERT!!!
Yeah because D's library (Phobos) is fucking stupid and is constantly criticized by everyone (including its maintainers) and it is one of the reasons D has the populations it has (along side the GC which I love to hate!). This is why I asked what YOU guys thought and not what how the stupid library does it. I don't want to copy a wrong and bad behavior, this is the idea of making something new. This is why I'm trying to make a library that will work and make things easy and simple as they should be. RELAXED NOW

That's why I gave you the "long" example. We don't have (yet) a 128-bit type. That was the idea in the first place, language has a limited range of numbers. And when we will have the cent, we will lack a 256-bit type.

Well 128-bit, 256-bit, 512-bit are not true types. Our computers have 64-bit registers. To go above that, you use multiple registers that hold a part of the value each. At least that's what I read in a PDF about assembly and it makes sense.

I would like to consider that I know exactly what kind of value I am expecting to read.

I don't understand what you mean here, could you please explain?

Happy New Year :)

Happy New Year buddy! Wish you the best!!! 😁

On 31/12/2021 2:52 AM, rempas wrote: >> That's why I gave you the "long" example. We don't have (yet) a 128-bit type. That was the idea in the first place, language has a limited range of numbers. And when we will have the cent, we will lack a 256-bit type. > > Well 128-bit, 256-bit, 512-bit are not true types. Our computers have 64-bit registers. To go above that, you use multiple registers that hold a part of the value each. At least that's what I read in a PDF about assembly and it makes sense. And before 64bit registers we had (and still do) emulation for that as well. All this talk is irrelevant, just add fixed point types and you can have whatever precision you want. This also solves the issue with money. So it is a pretty compelling solution.

On Thursday, 30 December 2021 at 14:12:23 UTC, rikki cattermole wrote: > And before 64bit registers we had (and still do) emulation for that as well. Yeah, of course! This is how 32-bit computers can use 64-bit types (and even bigger) as well > All this talk is irrelevant, just add fixed point types and you can have whatever precision you want. > > This also solves the issue with money. So it is a pretty compelling solution. Yeah, don't get me wrong. I'm not saying that I don't like the idea. It's actually the really opposite. However, I'm really interested about how stable and productive ready it is.

Forums