My use case may be a little simple, but why is there not an unsigned float type in any language? It seems like positive real numbers is a useful subtype for many engineering problems? Are unsigned ints only done for performance reasons? edit: related to following stack overflow post [Nils Pipenbrinck] Why doesn't C have unsigned floats? c, types, floating-point, format asked by Nils Pipenbrinck on 04:06PM - 04 Feb 09 UTC

The stackoverflow post you linked is pretty good already. [image] djsegal: not an unsigned float type in any language Because there’s no hardware support and no standard for it. [image] djsegal: useful subtype for many engineering problems Is it? What problems do you have in mind? What real number problems never involve negation or substraction (see below)? There are many properties that unsigned integer format has but are not possible for a “unsigned floating point format”. The unsigned int and signed int has the same representation. Not possible with existing signed floating point type since it’s not stored as 2s complement. In fact, signed int is a special interpretation of unsigned int, not the other way around. I’m not aware of a way to make a signed floating point format that is based on an unsigned version with easy to understand semantics. Unsigned int has well defined wrapping behavior (related to 1). Not possible for floating point format. (Not any simple ways that I can come up with at least) Negation and substraction are well defined for/between any unsigned int(s). Direct consequence of 2. Not possible with floating point. Unsigned int is used to represent addresses and sizes, so computers natually need them. There isn’t a need like this for floating point. Also note that the OP in the stkovr question isn’t really asking for a different format, he is really asking for range check, which is a somewhat useful feature to have in languages and is possible in julia with custom types. (and there was a very recent thread about it here)

[image] yuyichao: (and there was a very recent thread about it here) Could you link that thread please?

[image] Range checking / bounds (of a variable) checking General Usage Hello, In my old memories, I recall that Ada (programming language) provide a concept of “range” for checking that a numerical value stored in a variable is always between a lower bound and an upper bound. This kind of check, is done at run time. I wonder if this kind of mechanism currently exist in Julia. For example I would like to say that I store an unsigned integer 8 but that upper bound can’t be upper than 10 and lower bound must be greater than or equal to 1. I only find information …

[image] yuyichao: [image] djsegal: not an unsigned float type in any language Because there’s no hardware support and no standard for it. That used to be the case, and while I think no standard (yet) I believe there’s Chinese hardware with UE8M0 already (and supported by Nvidia in PTX, not sure in actual hardware though, as a type, only intermediate coed?): [image] UE8M0 FP8 Number Format Training LLMs without H100 using UE8M0 FP8 number format. DeepSeek’s UE8M0 FP8 represents a breakthrough in efficient AI training, enabling massive language models to run on alternative hardware while maintaining competitive performance. This specialized 8-bit floating-point format trades precision for unprecedented efficiency, allowing models like DeepSeek-V3.1 to be trained without relying entirely on expensive Nvidia hardware. So the concept is there, just a question how Julia should support or adapt… it’s a trait now? Real and UReal abstract type? The type for AI, is I think never used on its own, but could be…

Hmph, isn’t UE8M0 just rebranding integer arithmetic? As in, couldn’t they take the same Int8 circuits from a MOS 6502, and call them the new floating point? No they’re not trolling, it’s literally supported by NVIDIA and used by DeepSeek! Ironic because I could have been a BASIC programmer in the 70s, when you had to emulate floating point by hand. (Also embedded people had to do it until fairly recently.) After being laid off since the 80s, I could be rehired as the expert in this new-fangled AI technique! More seriously, I guess hardware now does fast math with almost arbitrary precision, while complicating the software. Except hopefully you still use high-level PyTorch and it gets compiled into appropriate kernels with UE8M0 that nobody has to read. It’s just weird because floating point units were such an advance because they handled everything. I thought I couldn’t keep up with modernity, but maybe I can. Neural networks were antithetical to AI, now they define AI. Logistic regression was hopelessly out of date, now it’s deep learning (especially if you use SGD). Integer is the new floating point, slide rules are the new calculators. I just wish I had saved my flared jeans from the 70s.

[image] apo383: isn’t UE8M0 just rebranding integer arithmetic? As in, couldn’t they take the same Int8 circuits from a MOS 6502, and call them the new floating point? No, not exactly and note (Signed and) Unsigned Julia abstract type do assume integers, and all integers in a range (and 2’s complement for Signed), so can’t be used here but UE8M0 is unsigned yes (i.e. reprecenting half the number line, or rather up to its very limited typemax), but are still floating point reals, e.g. 1, 2, 4, 8 etc, though none in-between since yes, there’s neither any mantissa, also unusual. I assume but haven’t confirmed that you can represent 0, and having floats without 0 is interesting, so I would also like such a type. It most likely has an Inf, maybe only one bitpattern for it sharing with NaN and -Inf. It’s not too hard to emulate, with integers yes (even easier than old-style 8-bit micros/Microsoft floats), since it seems to be close to log2 logarithmic numbers, if not exactly the same.

[image] Palli: I assume but haven’t confirmed that you can represent 0 You cannot, the valid range is 2^{−127} to 2^{128}. Source: UE8M0 FP8 Number Format • luminary.blog NVidia is using 0xFF as special value for NaN, which reduces the range to 2^{−127} to 2^{127}.

[image] apo383: couldn’t they take the same Int8 circuits from a MOS 6502, and call them the new floating point? No: the Int8 circuit will compute 0x2 + 0x2 = 0x4, but in UE8M0 0x2 is 4, and 0x2 + 0x2 should return 0x3 (2^3 = 8).

[image] Palli: how Julia should support or adapt… This is too specific to fit into Julia’s generic scientific programming setup (the precision-speed trade-offs are quite extreme), and in any case we are talking about shifting a calculation into logarithms, a very old trick. Even in the ML context, there is probably no point in training with this type and then calculating with another, more precise one, as the results might be just way off. If someone really needs this, it should be put into a package, defined using a primitive type, which can be hooked into LLVM if/when the support arrives.

[image] Palli: UE8M0 … still floating point reals, e.g. 1, 2, 4, 8 They may represent reals but they’re just bits manipulated like integers, just as with all floating point exponents. I was just amused because this is way less than true floating point. In fixed point, addition is easy, and there’s little difference between fixed point and integer. An FPU is much more complex, taking way more surface area than an ALU. Multiplication is just a fixed point multiply of mantissa and integer addition of exponent, sounds easy? No because there’s a ton of circuitry to track and move the radix point. I’m mostly joking, but this new “floating point” UE8M0 is less than an integer arithmetic unit, since all you need is integer addition to do “FP multiplication”, and the mantissa is somebody else’s problem. [image] sijo: Int8 circuit will compute 0x2 + 0x2 = 0x4, but in UE8M0 0x2 is 4, and 0x2 + 0x2 should return 0x3 (2^3 = 8). My point is the Int8 0x2 + 0x2 = 0x4 is all you need to multiply two UE8M0. AFAIK addition of UE8M0s isn’t implemented in hardware. It’s kind of like how a slide rule is great for multiplication but terrible for addition. Happy to be corrected if I’m misinterpreting; I merely scanned the docs.

I don’t mean Julia should support this as with Float16, I mean does Julia need an UReal abstract type only (to enable the rest in a package, and better to have the abstract type in Base, as most others)? That’s a really cheap addition. Or does standard Real (abstract type) not really care if negative numbers can be represented or not? Or if zero is absent (which I don’t see clearly confirmed 0x00 could be zero, or in some design). Or even Infs, this has only (one) NaN. [image] apo383: An FPU is much more complex, taking way more surface area than an ALU. Not really, depends on the size of the floats, and the complexity scales when with smaller. add/subtract is simple with an ALU, and since this is basically logarithmic, then you use that, and some exceptional check. Multiplying Float64 is I believe already simpler than for UIn64, since the mantissa is smaller than 64-bits. And Float32 has better range and performance than Int64. Multiplying used to not be single-cycle since it’s inherently more complex so they throw transistors (basically lookup tables at the problem, not sure if even only one) to get single-cycle. For this addition gets more complex, but can be done with a 256-byte lookup table if I recall, at least with 256*256 lookup table for all binary ops, and 256-bite for e.g. square root. [image] Tamas_Papp: Even in the ML context, there is probably no point in training with this type and then calculating with another, more precise one, as the results might be just way off. Yes there is, it’s in the article. I believe though never only this one used only (this used for a shared exponent scale I believe, with I guess many regular FP8, FP6 or even FP4, not sure what they use), and not other for inference, but same.

Why is there no concept of unsigned floats?

General Usage

yuyichao August 26, 2018, 1:34am 4

Topic		Replies	Views
Printing of unsigned numbers Internals & Design numbers , io	29	3042	April 22, 2022
Posits - a new approach could sink floating point computation Numerics	49	11067	August 11, 2019
`Float` type like `Int` type General Usage proposal , faq	29	4817	March 14, 2017
Posit Standard (2022): Floats/IEEE vs Posits, and ternary math Offtopic	18	3426	February 5, 2026
Int v UInt General Usage	4	3863	June 6, 2018

Why is there no concept of unsigned floats?

Related topics