I just thought, it would probably make more sense to define Infinity to be the largest magnitude 30 bit integer we can support in both the positive and negative range, so comparisons against infinity still make sense, and so does -Infinity.
- Maxime
On 10-12-16 10:00 PM, Maxime Chevalier-Boisvert wrote:
There are 38 uses of Infinity in the code and 1 use of NaN... these
must be removed!
In my code at least, I used infinity to say that there is no specified upper bound on something. One thing we can do, for now, is cheat. It seems that at least in V8, Infinity is a global variable. Possibly we could just do something like "const Infinity = {};", just for the bootstrap. We could do the same for NaN.
It happens so often that it would be abstracted: typeString(name,
"name");
Right now, assert is a function defined in debug.js. The plan is to eventually make it a special name that Tachyon will recognize, so that assertions are weeded out from our code when we aren't debugging. This is perhaps slightly more complicated if we start to have many functions whose purpose is only to perform an internal assertion. As you said, this would be better served by macros. For now, I would suggest keeping all assertions the way they are. I defined some helper functions in utility, such as isPosInt, to test for the common case that a value is a positive integer, so you can do "assert (isPosInt(x), ...);".
If you still think we should add extra functions that call assert, I would suggest using the "tachyon:inline" prologue annotation inside of them, so that when the internal assert gets weeded out, so does the whole call to the function doing the assertion. I would also suggest naming them in the form "assertSomething(...)", so in this case, "assertString(x, name)".
- Maxime
Too bad there aren't macros in JS... it would then be simply: typeString(name);
The following code is suspect:
allocator.min = function (a, accessFct) { if (accessFct === undefined) accessFct = function (x) { return x; };
var minIndex = 0; var minValue = 0; var i; for (i=0; i< a.length; ++i) { if (accessFct(a[i])> minValue) { minIndex = i; minValue = a[i]; } } return { index:minIndex, value:minValue };
};
shouldn't it be:
allocator.min = function (a, accessFct) { if (accessFct === undefined) accessFct = function (x) { return x; };
var minIndex = 0; var minValue = 0; var i; for (i=0; i< a.length; ++i) { var x = accessFct(a[i]); if (x< minValue) // NOTE:< instead of> { minIndex = i; minValue = x; // NOTE: x } } return { index:minIndex, value:minValue };
};
Let me know if that is not correct. Has this code been tested? Moreover, it would be simpler to return the index (the value can be gotten by the client using the index). Also, is the accessFct argument really useful? It doesn't seem to be used in the code! Let's not bloat the compiler needlessly!
Marc
Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list
Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list