Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ proposal: There are exactly 8 bits in a byte

open-std.org

Post reply on HN
Print view View original

291–300 of 357 posts

Re: C++ proposal: There are exactly 8 bits in a byte

#291

Post by itishappy »

kazinator wrote: post #138
jltsiren wrote: post #108

Earlier quoted context omitted.

I like the Rust approach more: usize/isize are the native integer types, and with every other numeric type, you have to mention the size explicitly. On the C++ side, I sometimes use an alias that contains the word "short" for 32-bit integers. When I use them, I'm explicitly assuming that the numbers are small enough to fit in a smaller than usual integer type, and that it's critical enough to performance that the ass…

> you have to mention the size explicitly It's unbelievably ugly. Every piece of code working with any kind of integer screams "I am hardware dependent in some way". E.g. in a structure representing an automobile, the number of wheels has to be some i8 or i16, which looks ridiculous. Why would you take a language in which you can write functional pipelines over collections of objects, and make it look like assembler.

Except defining your types with arbitrary names is still hardware dependent, it's just now something you have to remember or guess.

Can you remember the name for a 128 bit integer in your preferred language off the top of your head? I can intuit it in Rust or Zig (and many others).

In D it's... oh... it's int128.

https://dlang.org/phobos/std_int128.html

https://github.com/dlang/phobos/blob/master/std/int128.d

Re: C++ proposal: There are exactly 8 bits in a byte

#292

Post by asveikau »

larsbrinkhoff wrote: post #214
asveikau wrote: post #114

Earlier quoted context omitted.

I think the pdp-10 could have 9 bit bytes, depending on decisions you made in the compiler. I notice it's hard to Google information about this though. People say lots of confusing, conflicting things. When I google pdp-10 byte size it says a c++ compiler chose to represent char as 36 bits.

PDP-10 byte size is not fixed. Bytes can be 0 to 36 bits wide. (Sure, 0 is not very useful; still legal.) I don't think there is a C++ compiler for the PDP-10. One of the C compiler does have a 36-bit char type.

I was summarizing this from a Google search. https://isocpp.org/wiki/faq/intrinsic-types#:~:text=One%20wa....

As I read it, this link may be describing a hypothetical rather than real compiler. But I did not parse that on initial scan of the Google result.

Re: C++ proposal: There are exactly 8 bits in a byte

#293

Post by FooBarBizBazz »

stephencanon wrote: post #158
FooBarBizBazz wrote: post #127

Earlier quoted context omitted.

Whether double floats can silently have 80 bit accumulators is a controversial thing. Numerical analysis people like it. Computer science types seem not to because it's unpredictable. I lean towards, "we should have it, but it should be explicit", but this is not the most considered opinion. I think there's a legitimate reason why Intel included it in x87, and why DSPs include it.

Numerical analysis people do not like it. Having _explicitly controlled_ wider accumulation available is great. Having compilers deciding to do it for you or not in unpredictable ways is anathema.

I get what you mean and agree, and have seen almost traumatized rants against ffast-math from the very same people.

After digging, I think this is the kind of thing I'm referring to:

https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf

https://news.ycombinator.com/item?id=37028310

I've seen other course notes, I think also from Kahan, extolling 80-bit hardware.

Personally I am starting to think that, if I'm really thinking about precision, I had maybe better just use fixed point, but this again is just a "lean" that could prove wrong over time. Somehow we use floats everywhere and it seems to work pretty well, almost unreasonably so.

Re: C++ proposal: There are exactly 8 bits in a byte

#294

Post by FooBarBizBazz »

stephencanon wrote: post #264
bee_rider wrote: post #171

Earlier quoted context omitted.

It isn’t harmful, right? Just like getting a little accuracy from a fused multiply add. It just isn’t useful if you can’t depend on it.

It’s absolutely harmful. It turns computations that would be guaranteed to be exact (e.g. head-tail arithmetic primitives used in computational geometry) into “maybe it’s exact and maybe it’s not, it’s at the compiler’s whim” and suddenly your tests for triangle orientation do not work correctly and your mesh-generation produces inadmissible meshes, so your PDE solver fails.

Thank you, I found this hint very interesting. Is there a source you wouldn't mind pointing me to for those "head, tail" methods?

I am assuming it relates to the kinds of "variable precision floating point with bounds" methods used in CGAL and the like; Googling turns up this survey paper:

https://inria.hal.science/inria-00344355/PDF/p.pdf

Any additional references welcome!

Re: C++ proposal: There are exactly 8 bits in a byte

#295

Post by crote »

heinrich5991 wrote: post #251
jsheard wrote: post #80

Earlier quoted context omitted.

Maybe specifying that floats are always IEEE floats should be next? Though that would obsolete this Linux kernel classic so maybe not. https://github.com/torvalds/linux/blob/master/include/math-e...

Permalink (press 'y' anywhere on GitHub): https://github.com/torvalds/linux/blob/4d939780b70592e0f4bc6... .

That file hasn't been touched in over 19 years. I don't think we have to worry about the non-permalink url breaking any time soon.

Re: C++ proposal: There are exactly 8 bits in a byte

#296

Post by renox »

Cloudef wrote: post #237
Laremere wrote: post #144

Earlier quoted context omitted.

Zig is even better: 1. u8 and i8 are 8 bits. 2. u16 and i16 are 16 bits. 3. u32 and i32 are 32 bits. 4. u64 and i64 are 64 bits. 5. Arithmetic is an explicit choice. '+' overflowing is illegal behavior (will crash in debug and releasesafe), '+%' is 2's compliment wrapping, and '+|' is saturating arithmetic. Edit: forgot to mention @addWithOverflow(), which provides a tuple of the original type and a u1; there's also…

Zig allows any uX and iX in the range of 1 - 65,535, as well as u0

u0?? Why?

Re: C++ proposal: There are exactly 8 bits in a byte

#297

Post by tntxtnt »

mort96 wrote: post #222
harry8 wrote: post #25

Is C++ capable of deprecating or simplifying anything? Honest question, haven't followed closely. rand() is broken,I;m told unfixable and last I heard still wasn't deprecated. Is this proposal a test? "Can we even drop support for a solution to a problem literally nobody has?"

How is rand() broken? It seems to produce random-ish values, which is what it's for. It obviously doesn't produce cryptographically secure random values, but that's expected (and reflects other languages' equivalent functions). For a decently random integer that's quick to compute, rand() works just fine.

RAND_MAX is only guaranteed to be at least 32767. So if you use `rand() % 10000` you'll have real biased towards 0-2767, even `rand() % 1000` is already not uniform (biased towards 0-767). And that assumes rand() is good uniform from 0-RAND_MAX in the first place.

Re: C++ proposal: There are exactly 8 bits in a byte

#298

Post by seoulbigchris »

quietbritishjim wrote: post #266
seoulbigchris wrote: post #239

Earlier quoted context omitted.

Which one? Remember the decimal IEEE 754 floating point formats exist too. Do folks in banking use IEEE decimal formats? I remember we used to have different math libs to link against depending, but this was like 40 years ago.

Nothing prevents banks (or anyone else) from using a compiler where "float" means binary floating point while some other native or user-defined type supports decimal floating point. In fact, that's probably for the best, since they'll probably have exacting requirements for that type so it makes sense for the application developer to write that type themselves.

I was referring to banks using decimal libraries because they work in base 10 numbers, and I recall a big announcement many years ago when the stock market officially switched from fractional stock pricing to cents "for the benefit of computers and rounding", or some such excuse. It always struck me as strange, since binary fixed and floating point represent those particular quantities exactly, without rounding error. Now with normal dollars and cents calculations, I can see why a decimal library might be preferred.

Re: C++ proposal: There are exactly 8 bits in a byte

#299

Post by fourier54 »

sirsinsalot wrote: post #198
fourier54 wrote: post #183

Earlier quoted context omitted.

That is a bit in information theory. It has nothing to do with the computer/digital engineering term being discussed here.

This comment I feel sure would repulse Shannon in the deepest way. A (digital, stored) bit, abstractly seeks to encode and make useful through computation the properties of information theory. Your comment must be sarcasm or satire, surely.

I do not know or care what would Mr. Shannon think. What I do know is that the base you chose for the logarithm on the entropy equation has nothing to do with the amount of bits you assign to a word on a digital architecture :)

Re: C++ proposal: There are exactly 8 bits in a byte

#300

Post by epcoa »

__turbobrew__ wrote: post #204
smaudet wrote: post #195

Earlier quoted context omitted.

> If you are creating life critical medical devices you should not be using linux. Hmm, what do you mean? Like, no you should not adopt some buggy or untested distro, instead choose each component carefully and disable all un-needed updates... But that beats working on an unstable, randomly and capriciously deprecated and broken OS (windows/mac over the years), that you can perform zero practical review, casual or ot…

I mean you should be building life critical medical devices on top of an operating system like QNX or vxworks which are much more stable and simpler.

Regulations are complex, but not every medical device or part of it is "life critical". There are plenty of regulated medical devices floating around running Linux, often based on Yocto. There is some debate in the industry about the particulars of this SOUP (software of unknown provenance) in general, but the mere idea of Linux in a medical device is old news and isn't crackpot or anything.

The goal for this guy seems to be a Linux distro primarily to serve as a reproducible dev environment that must include his own in-progress EDT editor clone, but can include others as long as they're not vim or use Qt. Ironically Qt closed-source targets vxWorks and QNX. Dräger ventilators use it for their frontend.

https://www.logikalsolutions.com/wordpress/information-techn...

Like the general idea of a medical device linux distros (for both dev host and targets) is not a bad one. But the thinking and execution in this case is totally derailed due to outsized and unfocused reactions to details that don't matter (ancient IRS tax computers), QtQuick having some growing pains over a decade ago, personal hatred of vim, conflating a hatred of Agile with CI/CD.

Post reply on HN