Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.fsmpi.rwth-aachen.de!news-2.dfn.de!news.dfn.de!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <2773314.7tFKgFW6fd@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Thu, 12 Jun 2014 20:25:51 +0200 User-Agent: KNode/4.12.4 Content-Transfer-Encoding: 8Bit Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEXTxa4RFk5dUWANED8PFEfy7+MGBiW+n3ZNF/QuAAACaElEQVQ4jVXUwVOcMBQG8Dc7Rc4PUntdWV2uxjDpGaGeozOp1woar4jd5t/v9wLstMwsA/ntlxdCAgUc1hjTc9/JCZfGoo3wG3HdmdAWrIJRHe7GM/TmpY5VFefuVcAkkPbLIaN8rmPmjloyZxgyR3GuJ4K0AGtJ2htz8o7yqikm759fldQXaMpbDzjKAG+8v+AugVTOPO5DOjLvGtUYQwh0CPjnVMyGd+8/GfUB5nLKJDD2aLDh5HYyMDJGDwQIo2ZmZcKbowNmAdB/AzyFhrmF2MHRb0QJJfaAnwGB6orZhoykLzJtGwF/xpYxI1dswomiUj3gTuAIqCn/4C7cULwGNBtwMTk3Y4LfKB5YUaOKBKYtpplm7u0vip8tU1NWWyI/7XdcSuIDoMt6rVHMWT0DbjHPGqDqZVSa6zleLcUTcIKLoMv3ueJluALtAo9B302zPPlrtiVScRdCjXvVh3e3JpYa/jjkuC9N+LrBMlz/eAN4eQijX2EdLo6c5tGGHwLyHFtXk89dDGHwCVhG9T0S/j55AhRZgkMCmUQXJ49TnS1wnQDvw0eAh9ICeMmEFbCnPMFzjAvsWoEWEFdYEx+S0MoUZ1gT1wId8+AF3Bl2OoEu906AUHx5VLw/gXYg/x84loOah/2UYNrgiwSwGO7RfUzVBbx/kgpckumGOi6QirtD6gkLTitbnxNol47S2jVc2vsN5kPqaAHT8uUdAJM4v/DanjYOwmUjWznGfwB7sGtAtor5BgofDuzaRj4kSQAqDakTsKORa3Q3xKi3gE1fhl71KRMqrdZ2AWNNg/YOhQyrVBnb+i+nEg4bsDA+egAAAABJRU5ErkJggg== X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. <5051886.MyCAqxjJIy@PointedEars.de> MIME-Version: 1.0 Lines: 116 NNTP-Posting-Date: 12 Jun 2014 20:25:52 CEST NNTP-Posting-Host: 51251666.newsspool3.arcor-online.net X-Trace: DXC=fB2E0GfP1=:RadXUBHgFh3McF=Q^Z^V384Fo<]lROoR18kF Am 12.06.2014 00:20, schrieb Thomas 'PointedEars' Lahn: >> First of all, this does _not_ express the C semantics in JavaScript, and >> there is no other way. “int” is a *generic* type in C/C++; IIUC, the >> result could be a 32-bit integer when compiled for a 32-bit platform or a >> 64-bit integer when compiled for a 64-bit platform. > > Not quite. int is a type whatever the compiler chooses it to be, let it > be 32 bit, 64 bit or 36 bit, no matter what the platform is. I have seen > platforms were int was a 16 bit type even tough the platform was 32 bit > wide. That is what I said. A “could” statement is never exclusive. > IOWs, the C to JavaScript compiler can surely implement a valid C model > on top of JavaScript with 32 bit ints, the decision to have ints 32 bit > wide is not invalidated by the platform having any other native register > size. If there were 32-bit ints in JavaScript. However, we have ascertained by now that this syntax does not result in the corresponding operation with asm.js. >> By contrast, using the binary bitwise OR operator, as with all ECMAScript >> binary bitwise operators, *always* creates an IEEE-754 double-precision >> *floating-point* value representing a *32-bit* integer value. Also, not >> only the result will be such a value, but also the operands are converted >> to such values internally, before the operation is performed. > > Within the limits of what JavaScript has to offer, this is the closest > it can do to emulate the C type system when operating on signed > datatypes; these are also first converted to int (here emulated as 32 > bit types), then the operation is performed. It can get very tricky to > emulate the *unsigned* types, and I wonder what the C to JavaScript > compiler would do about them. No, it fails badly at implementing the C “int” type because its "integers" by contrast are _not_ generic but *always* 32-bit. So there is considerable information loss involved in this conversion; a loss that would have turned out to be critical if this syntax would lead to the operation it suggests (but it does not; this is just a type marker for asm.js, which either extends or violates ECMAScript there). >> Conversion to an integer value of the ECMAScript Number type (i.e., where >> the fractional part of the mantissa is zero), which appears to be the >> goal here, can be better achieved with the Math.floor() and Math.ceil() >> functions, e.g.: > > No, I don't think that this is the goal here, i.e. rounding to an > integer number (avoiding the term "int" here intentionally). An "int" > has undefined behavior if an operation overflows. The behavior appears to me to be well-defined. > Just rounding would create another integer number, but one that is outside > of the bit range, possibly with even weirder side effects in the program. > That's possibly not quite what was intended. In the end, it probably does > not matter much because, as said, C leaves it undefined what happens on > overflow of the signed types, and the implementation just picked the > simplest possible choice to create a "round to zero". Rounding is not the point, achieving a zero fractional part is. That is what Math.floor() and Math.ceil() do, with positive and negative numbers, respectively, and without information loss up to the IEEE-754 doubles integer precision limits (−2⁵³ and 2⁵³). >> Of course, this still does not remotely implement the C semantics. One >> aspect of it is that code where you pass a non-integer would not compile. > > Not so. Instead, C would truncate the non-integer to the next integer > (cut off the fractional part) and would use that as input. The following > compiles fine: > > int plusone(int x) > { > return x+1; > } > > int main(int argc,char **argv) > { > > return plusone(2.2); > } Indeed it compiles (with gcc), even without warnings (using -Wall). C is even weirder than I thought. > I'm not sure how JavaScript handles negative values when applied to the > binary or operator, but I would suspect that it also performs a "round > to zero", which is exactly what C does, thus a perfect match. That is > possibly even intentional in JavaScript. (*Which* JavaScript are you talking about?) In all ECMAScript implementations I am aware of, “|0” does the same as the suggested Math.floor()/Math.ceil(), with the disadvantage that it breaks outside the 32-bit integer range. >> Since ECMAScript uses dynamic type-checking, it is not possible to >> prevent compilation. But at the very least passing unsuitable values >> should cause an exception to be thrown, so that it becomes unnecessary to >> handle them, e.g.: > > Certainly not, since C does not have exceptions either. “Either”? I am aware that C does not have exceptions. However, I have assumed, wrongly, that such C code would not compile. So in a language that uses dynamic type-checking, like ECMAScript implementations, throwing an exception would have come closest to that. -- PointedEars FAQ: | SVN: Twitter: @PointedEars2 | ES Matrix: Please do not Cc: me. / Bitte keine Kopien per E-Mail.