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

[rempas]

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!!! 😁