Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Scott Sauyet Newsgroups: comp.lang.javascript Subject: Re: How would you prepare for javascripting interview? Date: Sun, 11 Sep 2016 02:45:18 -0000 (UTC) Organization: A noiseless patient Spider Lines: 82 Message-ID: References: <50e38667-93da-4c5d-bc02-a78394f0ca3b@googlegroups.com> <1875389.irdbgypaU6@PointedEars.de> <9cstsb1uddjiltlflrdiks2ha2u3msi1ao@4ax.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Sun, 11 Sep 2016 02:45:18 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="18a55b4682c397bee68122b023fb526f"; logging-data="15249"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19mzVTKRZ8JHRyQwPI2D9Yb7tAou0FnKgI=" User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT b8fc14e git.gnome.org/git/pan2) Cancel-Lock: sha1:Vj7k7xJr5cBNhGrd53joc+TcFcA= Xref: csiph.com comp.lang.javascript:31313 Doc O'Leary wrote: > Scott Sauyet wrote: >> max([1, 2, 3]) // 3 >> == max(max([1]), max([2, 3])) // max(1, 3) == 3 >> == max(max([1, 2]), max([3])) // max(2, 3) == 3 >> != max(max([]), max([1, 2, 3])) // max(NaN, 3) == NaN >> >> Just by partitioning a set differently we can change its maximum. > > People need to stop making this mistaken argument. This has nothing > to do with the mathematical sets. It has to do with a function in a > library of computer code. Sorry, I should have used "list" here rather than "set". I tend to use the word "list" rather than "array" because of my work in Ramda, where we work with many iterable collections, but where things might fail horribly if you pass sparse arrays. But this has little to do with mathematics. I was simply pointing out that if `max([]); //=> NaN`, then we get some awkward behavior, a violation of the law I was proposing. If you split a list into two sublists and take the max of each, then the max of those two resulting values, logically, you should get the same result as if you took the max of the initial list. Returning `NaN` fails this, as demonstrated. Throwing is a different beast, because then you simply don't get a value. Returning `undefined`/`null` could go either way, depending upon their implementation, but it strikes me as illogical behavior to skip bad values so that `max([8, 6, 7, null, 5, 3, undefined, 0, 9]); //=> 9` Still, this is within the realm of possibility. > Even if it were implemented recursively, > it would be poorly programmed if it made a call of max([]), regardless > of what such a call might return. I'm sorry, but I make no sense of this. >> I lean toward the latter partly because I've done a lot of >> mathematical programming over the years (yes, even in Javascript) so >> having useful mathematical functions is important to me > > And that’s a fine argument, and especially appropriate here because > we *are* talking about what is implemented by the Math object. But > I would still argue that JS is not well-considered when it comes to > other objects (the some/every methods of Array) or even other methods > in Math (pow has a right identity, but still requires 2 arguments). > The inconsistencies make things ugly. I'm not sure what you're talking about with `Math.pow`, but I certainly agree with the general point. JS is full of warts. >> What I meant about the definition is that if you try to define these >> functions as returning the largest elements of their lists you start to >> raise questions of references versus values, of how to handle ties; it >> simply becomes tricky. > > *All* of computer science is essentially about the “tricky” stuff > that mathematics drops the ball on. If people don’t like dealing > with complexity like that, they shouldn’t be in the field. And the goal of API design is to abstract away that complexity, providing simple interfaces to users. I was suggesting that my definition ("max returns the smallest value that is no smaller than any element in the list") allows us to capture the meaning of the function faithfully, return something useful mathematically in every case, and does this as simply as possible. Alternatives that attempt to suggest that the function returns an element of the list add complexity and have no advantage. I'm sure that our views are colored by our various tolerance for things such as exceptions (which I mostly hate) and Infinity (which bothers me not at all), but I think it's hard to argue that this definition is not simpler than such alternatives. -- Scott