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

C Is Not Reasonable

osr.com

Post reply on HN
Print view View original

41–50 of 71 posts

Re: C Is Not Reasonable

#41

Post by nradov »

fredmorcos wrote: post #28
nradov wrote: post #18

Earlier quoted context omitted.

It would be nice if languages allowed us to overload function names with the exact same parameters but different return types. The compiler or runtime environment should be able to select the correct implementation automatically based on type inference, or allow the programmer to specify which one should be used with an annotation. This would make some code a little cleaner instead of having to give all of those func…

> or allow the programmer to specify which one should be used with an annotation. That's exactly: > give all of those functions different names.

Similar, but not exactly the same. It would make the syntax and documentation a little cleaner.

Re: C Is Not Reasonable

#42

Post by chriswarbo »

fredmorcos wrote: post #28
nradov wrote: post #18

Earlier quoted context omitted.

It would be nice if languages allowed us to overload function names with the exact same parameters but different return types. The compiler or runtime environment should be able to select the correct implementation automatically based on type inference, or allow the programmer to specify which one should be used with an annotation. This would make some code a little cleaner instead of having to give all of those func…

> or allow the programmer to specify which one should be used with an annotation. That's exactly: > give all of those functions different names.

Effectively; although "name" usually implies an opaque symbol, e.g. the language would see no difference between, say, "addAsInts" vs. "addAsFloats", compared to "addAsInts" vs. "divide".

Classes, namespaces, modules, etc. allow names to have a more fine-grained structure, e.g. "int.add" and "int.divide" come from the same module, whilst "int.add" and "float.add" are alternative implementations of the same signature.

Re: C Is Not Reasonable

#44

Post by pjc50 »

wott wrote: post #30
pjc50 wrote: post #7

Arithmetic is surprisingly hard to get "right". You might try to generalise from this example that "multiplying two N bit numbers together should give a result 2N" wide, then discover that for simple examples you run out of machine bits. Then there's overflow/saturation handling, which is a mess everywhere: lots of systems have hardware support for saturation arithmetic, but you can't conveniently specify it in C. If…

Yeah, I recently read on some forum someone who was looking for a quick C++ training for a friend and said "he doesn't need a deep training, just some basic syntax, he's not a programmer, that doesn't interest him, he's just doing scientific calculus". I was like: Oh boy... getting arithmetic calculation right is really tricky and you have to understand many not-obvious details, especially concerning the behaviour of…

The Cambridge (UK) maths undergraduate course used to do exactly this; include a numerical programming section without any training. They effectively just gave people a small volume of API calls and expected them to get on with it. The only reason it worked at all was a small number of undergraduates who could already program running guerilla assistance courses in C for bewildered mathematicians.

Programming is becoming increasingly important in science, but still treated as a skill that people should just casually pick up.

Oh, and then there's a whole bunch of stupid reproducibility issues caused by Intel using 80-bit FP internally but then truncating on load/store. Very important if your algorithm isn't rigorously convergent.

Re: C Is Not Reasonable

#45

Post by dllthomas »

masklinn wrote: post #38
dllthomas wrote: post #35

Earlier quoted context omitted.

> Haskell's typeclasses kind-of do that. You're over-hedging. As your example shows, Haskell's typeclasses exactly do that.

I'm mostly hedging on the "overloading" part as Haskell doesn't support arbitrary ad-hoc polymorphism in the sense of C++/Java/C# (IIRC the foundational paper on typeclasses is about making ad-hoc polymorphism less ad-hoc). Depending how far into the overloading field nradov is, typeclasses may not match their definition of or requirements for overloading. It's probably more noticeable in Rust than in Haskell.

Ah, that makes sense. I don't think there's a reasonable way to define "overloading" that excludes typeclasses, but it's true that there are things that can properly be termed "overloading" which typeclasses can't (or shouldn't) do.

Re: C Is Not Reasonable

#46

Post by to3m »

stevetrewick wrote: post #39
to3m wrote: post #20

Earlier quoted context omitted.

Well, uint64_t ;) - but ULONGLONG is uint64_t, so it's the same thing. The real "problem" here is presumably that ULONGLONG is a Windows-specific type, probably. (I say probably, because you can always make your own type called ULONGLONG - there's no rule to stop you.) People do like to mock people who program for Windows.

ULONGLONG is in fact a Windows Drivers Kit specific type. WDK has its own specialised set of weird and uncomfortable type conventions in the MS style [0] and although the author's point about C arithmetic type promotion is generic, his context is WDK device drivers, so ULONGLONG is absolutely correct, if possibly somewhat archaic (there's a ULONG64 lately). [0] https://www.osr.com/blog/2015/05/27/newbie-corner-theres…

It's in user mode too - as the return type of GetTickCount64, for example: https://msdn.microsoft.com/en-gb/library/windows/desktop/aa3...

Re: C Is Not Reasonable

#47

Post by AstralStorm »

dllthomas wrote: post #31
spacehunt wrote: post #12

Earlier quoted context omitted.

> When in doubt, stick a (double) in front of it If casting from an integer type, this loses precision. Why would this make tests pass? Are there any secondary effects? The author apparently made no effort to find out.

This may lose precision. Depending on architecture & compiler & flags, your mantissa may be big enough to hold your whole int. An 80 bit extended double has 64 bits of significand. https://en.wikipedia.org/wiki/Extended_precision#x86_extende...

This will lose precision, as any floating point operation is only accurate to 1 unit in the last place (ULP). Even simple addition.

Re: C Is Not Reasonable

#48

Post by AstralStorm »

asveikau wrote: post #27
OskarS wrote: post #4

Earlier quoted context omitted.

As someone who only has a passing knowledge of C, why is that wrong? Is it because it should be "uint_64" instead?

It's silly because no casts give you an integer type that is too small, but casting to double converts to floating point, performs floating point math, then assigns the result to the correct type they should have used in the beginning. Floating point math in low level C code is very often a WTF. You most often want integers.

Sadly, C does not support fixed point arithmetic. You can hack it on top, but the result is super ugly.

Re: C Is Not Reasonable

#49

Post by zzzcpan »

pjc50 wrote: post #7

Arithmetic is surprisingly hard to get "right". You might try to generalise from this example that "multiplying two N bit numbers together should give a result 2N" wide, then discover that for simple examples you run out of machine bits. Then there's overflow/saturation handling, which is a mess everywhere: lots of systems have hardware support for saturation arithmetic, but you can't conveniently specify it in C. If…

> then discover that for simple examples you run out of machine bits

Why? I don't think it would be common to run out of machine bits for correct programs (and not really run out, just go into bigints in some cases). But the compiler cannot calculate those bits based on machine types, instead it should track all possible values/ranges and multiply them too to decide whether the result could fit into the type or it needs a bit bigger one. And since values don't appear out of thin air, but come from literals or some input and checked for specific ranges all the time, it should be possible to automatically choose appropriate types and only warn about possible overflows or performance penalties due to bigints.

Naive approach of multiplying machine types is pointless, of course, on that I agree.

Re: C Is Not Reasonable

#50

Post by [deleted] »

AstralStorm wrote: post #47
dllthomas wrote: post #31

Earlier quoted context omitted.

This may lose precision. Depending on architecture & compiler & flags, your mantissa may be big enough to hold your whole int. An 80 bit extended double has 64 bits of significand. https://en.wikipedia.org/wiki/Extended_precision#x86_extende...

This will lose precision, as any floating point operation is only accurate to 1 unit in the last place (ULP). Even simple addition.

[deleted]
Post reply on HN