Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #402660
| From | BGB <cr88192@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c, comp.arch |
| Subject | Re: Taking hypot(3) To The Edge |
| Date | 2026-10-03 15:20 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <119ro2v$3avqk$1@dont-email.me> (permalink) |
| References | (3 earlier) <20261001141212.00002f20@yahoo.com> <119lh8n$14irr$2@dont-email.me> <119otie$2c89q$1@dont-email.me> <119paam$2gt26$1@dont-email.me> <119pok8$2l2ql$1@dont-email.me> |
Cross-posted to 2 groups.
On 10/2/2026 9:17 PM, Lawrence D’Oliveiro wrote: > On Fri, 2 Oct 2026 17:13:35 -0500, BGB wrote: > >> ... much like how cheap support for "double" doesn't mean that no >> one uses "float"...). > > Double is pretty much the default precision, though. High-level > languages like Python and JavaScript only support one real-number > precision, and that’s double. > > Even the naming of the C run-time routines -- an “f” suffix denotes > single precision, “l” denotes long double, while no suffix defaults to > meaning double. Can note that Binary64/double does make more sense as a general purpose format. It is also kinda interesting that people 40 years ago seemingly knew which format was best for general purpose use, and the needle hasn't really moved since then. Say, 40 years ago: int : 2 bytes char* : 2 bytes float : 4 bytes double : 8 bytes long double : 10 bytes Now: int : 4 bytes char* : 8 bytes float : 4 bytes double : 8 bytes long double : 16 bytes We have since gained "half" / "short float", sometimes... So, say: long double : 16 bytes, rarely used, overkill double : 8 bytes, general purpose float : 4 bytes, 3D and lots of stuff short float : 2 bytes, graphics, sound, and NNs Or, smaller still: FP8 : 1 byte (S.E4.M3), NNs mostly FP8A : 1 byte (S.E3.M4), audio, rotation quats, *1 FP8U : 1 byte (E4.M4), HDR graphics, *2. *1: 4x FP8A is a usable format for rotation quaternions when precision isn't a high priority. Otherwise 4xBinary16 or 4xBinary32 are more typical in my uses. Though, 4xFp8A isn't used as an in-register format, more for in-memory, with 4xFP16 as the corresponding in-register format. *2: Image fidelity is comparable to RGB555 in this case, but with a larger dynamic range. Had observed (in TKRA-GL) that one can do HDR 3D rendering by shoving this through an LDR RGBA32 path (reusing most of the LDR math on the HDR color values), which isn't super accurate, but interestingly gave limitations and artifacts very close to those of HDR on the Radeon HD 4850 card I was using in the early 2010s. The main obvious feature being that things like wonk with texture interpolation, blending, and the restrictions on the use of an alpha channel; and that (in the final output) the pixels only really had limited accuracy (if fetching the framebuffer image as HALF_FLOAT, low 6 bits of mantissa were zeroed, etc). If asking AI: its response is that this card did not have native HDR paths in HW and was in-fact shoving HDR through the LDR path with a similar strategy (hence the visual similarity in the results). Can note though that despite "float" being widely used in 3D, had noted that it isn't quite good enough for things like CSG clipping for 3D mesh building; as it can leave small gaps between vertices. To some extent this issue can be reduced after the fact by finding vertices that are close together, averaging them, and then snapping them to some level of grid points (typically something smallish).
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Taking hypot(3) To The Edge Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-01 00:47 +0000
Re: Taking hypot(3) To The Edge "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-01 01:02 +0000
Re: Taking hypot(3) To The Edge Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-01 01:55 +0000
Re: Taking hypot(3) To The Edge "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-01 03:44 +0000
Re: Taking hypot(3) To The Edge bart <bc@freeuk.com> - 2026-10-01 02:33 +0100
Re: Taking hypot(3) To The Edge Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-01 02:38 +0000
Re: Taking hypot(3) To The Edge David Brown <david.brown@hesbynett.no> - 2026-10-01 10:17 +0200
Re: Taking hypot(3) To The Edge Michael S <already5chosen@yahoo.com> - 2026-10-01 14:12 +0300
Re: Taking hypot(3) To The Edge David Brown <david.brown@hesbynett.no> - 2026-10-01 13:47 +0200
Re: Taking hypot(3) To The Edge Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-02 20:35 +0200
Re: Taking hypot(3) To The Edge bart <bc@freeuk.com> - 2026-10-02 21:17 +0100
Re: Taking hypot(3) To The Edge BGB <cr88192@gmail.com> - 2026-10-02 17:13 -0500
Re: Taking hypot(3) To The Edge Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-03 02:17 +0000
Re: Taking hypot(3) To The Edge BGB <cr88192@gmail.com> - 2026-10-03 15:20 -0500
Re: Taking hypot(3) To The Edge Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-03 21:46 +0000
Re: Taking hypot(3) To The Edge BGB <cr88192@gmail.com> - 2026-10-03 20:35 -0500
Re: Taking hypot(3) To The Edge Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-04 23:54 +0000
Re: Taking hypot(3) To The Edge Michael S <already5chosen@yahoo.com> - 2026-10-03 21:06 +0300
Re: Taking hypot(3) To The Edge Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-03 20:22 +0200
Re: Taking hypot(3) To The Edge Michael S <already5chosen@yahoo.com> - 2026-10-03 22:01 +0300
Re: Taking hypot(3) To The Edge Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-03 23:20 +0200
Re: Taking hypot(3) To The Edge MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-04 17:49 +0000
Re: Taking hypot(3) To The Edge Thomas Koenig <tkoenig@netcologne.de> - 2026-10-03 19:47 +0000
Re: Taking hypot(3) To The Edge bart <bc@freeuk.com> - 2026-10-01 23:05 +0100
Re: Taking hypot(3) To The Edge Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-02 02:34 +0000
Re: Taking hypot(3) To The Edge Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-01 21:14 -0700
Re: Taking hypot(3) To The Edge bart <bc@freeuk.com> - 2026-10-02 11:39 +0100
csiph-web