51–60 of 66 posts
Would this not be an excellent case for an optional type or Maybe monad? Instead of all NaN operations returning NaN, have them all return an optional type, similar to how swift dictionaries return an optional for property access. This is enforceable by the compiler.
NaNs are an incredibly good idea, but it turns out we really need only one. Also, two's complement signed integers have an asymmetry that INT_MIN Therefore, I were to design a CPU today, I would add arithmetic instructions that treated INT_MIN as a NaN, thus removing the asymmetry, and giving us an integer NaN. 16 bit int values would range from -32767 to +32767, with the bit pattern now used for -32768 being NaN. Yo…
2's complement (the binary representation of numbers in a cpu) has one awesome feature, if you add two signed numbers, even if one or both are negative, you get the right answer. This means that you can add two numbers without checking if one is negative, saving time and scarce circuit space. In order to add a NaN, you'd need a check for NaN. This would basically double the amount of time an add would take, and add m…
Also, most CPUs will set an overflow bit if addition overflows or underflows. I don't see how it would be that hard to also force the result to 0b100....000 if that happens.
And 'scarce circuit space'? There are areas where that is still true, but they are getting rarer and rarer. Certainly, for desktop CPUs, x86 shows that one can waste circuit space by keeping around the classical x87 FPU logic, a few variants of SSE that one should not use anymore, a few attempts at vector units, instructions for branching hints that the CPU ignores, etc, and yet be successful.
I think the price paid for the detection of logic errors would be worth it.
Crash immediately. A divide by zero is always an unrecoverable error. Same story with array out-of-bounds access and null dereferences.
Thinking back to when I was a novice programmer, and the consequences of my mistakes when working on stuff that was probably over my head, "terminate with extreme prejudice" seems like the only acceptable option. No result and a call from a user seems better than a wrong result. Folks will use a tool for safety (personal or financial) critical tasks without really thinking about failure modes. Things like pocket calc…
I'd definitely incline towards an immediate abort. But for processes that run overnight, presumably because they take a long time, who can say? If there's a 1 day turnaround time, and the results are so important that it absolutely must not stop, and yet inexperienced programmers are responsible for writing the code that runs... well, I'm not sure one thing is going to be a huge improvement over something else. It's probably going to end up a bit painful whatever you do.
If when faced with a problem you say "I know, I'll make my own computer language!" Now you have 2 problems.
But but but how would they ... don't worry about it, its a programming language for novices. If they knew what to do, they wouldn't be novices using a novice language anyway.
I like this design because its self limiting. If they don't understand the problem, they certainly won't understand how to fix it when it breaks anyway.
The problem with giving 3 year olds matches and knives and guns is not some weird inherent moral argument about the items, its because the kids have no idea how to fix some resulting problems and even the non-noobs can't fix some of the resulting problems. So don't give noobs the ability to shoot themselves in their foot. Its pretty simple.
Of course a logical next extension is removal of logarithms and many other math functions. Thats OK. Its a language for noobs so it doesn't have to have a full set of arithmetic. Unless this guy is implementing the next "mathematica" or "R" or similar, in which case he has big problems.
Earlier quoted context omitted.
Could you elaborate a little on what happened? What exactly went wrong?
Well, this was a server, and it was also multithreaded, so many synchronization bugs that didn't happen in debug builds did happen in release ones because of timing. Without assertions, though, none of these was caught on time, so I was left with mystical crashes, garbage data sent out to clients, etc etc. I spent hours and hours in valgrind and gdb, and only then realized that none of the assertions worked. When I r…
Earlier quoted context omitted.
Well, this was a server, and it was also multithreaded, so many synchronization bugs that didn't happen in debug builds did happen in release ones because of timing. Without assertions, though, none of these was caught on time, so I was left with mystical crashes, garbage data sent out to clients, etc etc. I spent hours and hours in valgrind and gdb, and only then realized that none of the assertions worked. When I r…
With total respect to what you're saying, I'd just like to say that I care about games and other non-mission-critical software. I am continually disappointed by buggy glitchy unreliable applications which have clearly been rushed out to meet a release window. It's as if we've all been trained to accept poor quality, based on the excuse that "it's not handling payments or running a nuclear reactor so it's OK to be slo…
Its commerce, and 'just in time' and 'just good enough' is all that sells.
A really sly option would be to, effectively, allow infinitesimals. So 10/0 would return 10/0 (perhaps a kind of NaN but with more information retained), and if you multiplied it by 0 elsewhere you'd get 10. Probably a bad idea for novice programmers but interesting to consider.
No, this is wrong. In order to work with infinitesimals in any reasonable way, you have to define how they work. There is a reasonable way to extend the real numbers in a larger field containing infinitesimals. Such a field is non-Archimedean and has very surprising properties: for example, you can construct a geometry in which Euclid's fifth postulate is false, and yet the angles on a triangle still always add up to…
I think it should be possible with appropriate precedence of the evaluation rules?
A really sly option would be to, effectively, allow infinitesimals. So 10/0 would return 10/0 (perhaps a kind of NaN but with more information retained), and if you multiplied it by 0 elsewhere you'd get 10. Probably a bad idea for novice programmers but interesting to consider.
No, this is wrong. In order to work with infinitesimals in any reasonable way, you have to define how they work. There is a reasonable way to extend the real numbers in a larger field containing infinitesimals. Such a field is non-Archimedean and has very surprising properties: for example, you can construct a geometry in which Euclid's fifth postulate is false, and yet the angles on a triangle still always add up to…