On 19 November 2012 17:57, Manu <turkey...@gmail.com> wrote: > On 19 November 2012 19:28, Iain Buclaw <ibuc...@ubuntu.com> wrote: >> >> On 19 November 2012 16:04, Manu <turkey...@gmail.com> wrote: >> > On 19 November 2012 06:19, Walter Bright <newshou...@digitalmars.com> >> > wrote: >> >> >> >> On 11/18/2012 4:31 PM, Manu wrote: >> >>> >> >>> If I told you this is how real should be implemented, would you vote >> >>> ++? >> >>> What >> >>> about double? Why? >> >>> Why not float for that matter? There seems like no reason for the >> >>> language to >> >>> define any floating point type at all if you consider this >> >>> acceptable... >> >> >> >> >> >> Because they are implemented in hardware. It's pretty dang hard for a >> >> compiler to look at a floating point emulator and figure out "gee, I >> >> have a >> >> nice hardware instruction that does the same thing as this 2K of code!" >> > >> > >> > Right, and this is my point precisely. It's hard for GDC for instance to >> > hook some complex library because it happens to have hardware to do it. >> > >> >>> 'half' isn't some custom float for niche use, it's an established >> >>> standard, >> >>> implemented in vastly more hardware than implements 'real'. >> >> >> >> >> >> It's implemented in GPUs, sure, but it is it implemented in hardware >> >> that >> >> D runs on? (I do know about this: >> >> http://gcc.gnu.org/onlinedocs/gcc/Half_002dPrecision.html) >> >> >> >> There is no major technical difficulty in implementing it as a basic >> >> type, >> >> but I want to be sure we've exhausted the library approach first. >> > >> > >> > Well it's available in hardware on basically all mobile devices (that's >> > a >> > LOT of devices (in the billions)), but even if it's just implemented in >> > software (x86), the values are consumed by the GPU, and the validity of >> > the >> > values is no less important. It still seems like a valuable 1st class >> > type; >> > why shouldn't it enjoy the same casting, assignment, literal, range >> > checking >> > rules as the rest of the floats? Additionally, convenience and >> > compatibility >> > with generic code would be significantly improved. >> > I don't see how it can be made to feel seamless with a lib... and that >> > sounds like an awful lot more work. >> > >> > >> > Anyway, I'm not desperate for this personally. I just wondered how >> > people >> > felt about it in general, and if it was something that should/would be >> > seriously considered. >> >> I'm neither here nor there. I'm just pointing out that you are >> proposing a dedicated type to be introduced that is supported on only >> one platform. :-) > > > real is only supported on one platform (x86, it's deprecated in x64 and x87 > will likely be removed/emulated in the future), but I think many here > consider it valuable(?). > And that's not strictly true either, virtually every machine has a GPU, and > host software still has to process data for it. I'm mainly encouraging this > for the sake of correctness/type safety, though hardware support on ARM > would be a particularly nice bonus. > > I also wanted to gauge the interest/opposition.
Real is mapped to the target's long double. It could be 64bit, 80bit, 96bit, or 128bit. The phobos math library already caters for this. :-) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';