Groups > comp.lang.javascript > #30891 > unrolled thread

How would you prepare for javascripting interview?

Started by	justaguy <lichunshen84@gmail.com>
First post	2016-07-18 09:10 -0700
Last post	2016-07-19 16:16 -0300
Articles	20 on this page of 84 — 16 participants

Back to article view | Back to comp.lang.javascript

How would you prepare for javascripting interview? justaguy <lichunshen84@gmail.com> - 2016-07-18 09:10 -0700
Re: How would you prepare for javascripting interview? Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2016-07-18 18:37 +0200
Re: How would you prepare for javascripting interview? justaguy <lichunshen84@gmail.com> - 2016-07-18 11:09 -0700
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-07-21 01:04 +0000
Re: How would you prepare for javascripting interview? John Harris <niam@jghnorth.org.uk.invalid> - 2016-07-21 14:24 +0100
Re: How would you prepare for javascripting interview? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-07-23 16:25 +0200
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-07-23 15:56 +0000
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-03 19:39 +0000
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-04 15:56 +0000
Re: How would you prepare for javascripting interview? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-05 00:06 +0100
Re: How would you prepare for javascripting interview? John Harris <niam@jghnorth.org.uk.invalid> - 2016-09-05 14:49 +0100
Re: How would you prepare for javascripting interview? $Bill <news@todbe.com> - 2016-09-05 10:01 -0700
Re: How would you prepare for javascripting interview? Gene Wirchenko <genew@telus.net> - 2016-09-06 09:36 -0700
Re: How would you prepare for javascripting interview? John Harris <niam@jghnorth.org.uk.invalid> - 2016-09-05 15:05 +0100
Re: How would you prepare for javascripting interview? Andreas Bergmaier <andber93@web.de> - 2016-09-05 20:31 +0200
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-06 15:15 +0000
Re: How would you prepare for javascripting interview? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-09-06 19:40 +0200
Re: How would you prepare for javascripting interview? John Harris <niam@jghnorth.org.uk.invalid> - 2016-09-06 19:25 +0100
Re: How would you prepare for javascripting interview? Andreas Bergmaier <andber93@web.de> - 2016-09-06 22:16 +0200
Re: How would you prepare for javascripting interview? John Harris <niam@jghnorth.org.uk.invalid> - 2016-09-07 17:17 +0100
Re: How would you prepare for javascripting interview? Andreas Bergmaier <andber93@web.de> - 2016-09-07 20:07 +0200
Re: How would you prepare for javascripting interview? John Harris <niam@jghnorth.org.uk.invalid> - 2016-09-08 14:36 +0100
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-05 18:46 +0000
Re: How would you prepare for javascripting interview? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-05 20:32 +0100
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-05 17:27 +0000
Re: How would you prepare for javascripting interview? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-05 20:12 +0100
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-06 16:48 +0000
Re: How would you prepare for javascripting interview? Andreas Bergmaier <andber93@web.de> - 2016-09-06 19:56 +0200
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-07 20:16 +0000
Re: How would you prepare for javascripting interview? Gene Wirchenko <genew@telus.net> - 2016-09-07 10:01 -0700
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-07 20:21 +0000
Re: How would you prepare for javascripting interview? Gene Wirchenko <genew@telus.net> - 2016-09-09 11:41 -0700
Re: How would you prepare for javascripting interview? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-09-09 15:35 -0700
Re: How would you prepare for javascripting interview? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-09-09 20:40 -0700
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-10 15:12 +0000
Re: How would you prepare for javascripting interview? Gene Wirchenko <genew@telus.net> - 2016-09-12 11:14 -0700
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-13 21:07 +0000
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-06 16:20 +0000
Re: How would you prepare for javascripting interview? Ken Tilton <kentilton@gmail.com> - 2016-09-05 11:37 -0700
Re: How would you prepare for javascripting interview? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-09-06 19:26 +0200
Re: How would you prepare for javascripting interview? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-09-08 12:41 -0700
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-05 20:37 +0000
Re: How would you prepare for javascripting interview? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-05 22:13 +0100
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-06 02:33 +0000
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-06 16:02 +0000
Re: How would you prepare for javascripting interview? Gene Wirchenko <genew@telus.net> - 2016-09-06 09:50 -0700
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-07 01:36 +0000
Re: How would you prepare for javascripting interview? Gene Wirchenko <genew@telus.net> - 2016-09-07 10:07 -0700
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-10 00:03 +0000
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-10 00:12 +0000
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-10 15:34 +0000
Re: How would you prepare for javascripting interview? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-11 01:32 +0100
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-12 19:26 +0000
Re: How would you prepare for javascripting interview? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-13 01:02 +0100
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-13 21:38 +0000
Re: How would you prepare for javascripting interview? "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-09-14 00:56 +0200
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-15 15:09 +0000
Re: How would you prepare for javascripting interview? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-14 00:47 +0100
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-15 15:34 +0000
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-11 02:45 +0000
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-12 19:10 +0000
Re: How would you prepare for javascripting interview? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-12 21:06 +0100
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-07 03:12 +0000
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-07 19:53 +0000
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-10 02:14 +0000
Re: How would you prepare for javascripting interview? John Harris <niam@jghnorth.org.uk.invalid> - 2016-09-10 11:25 +0100
Re: How would you prepare for javascripting interview? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-10 15:49 +0100
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-10 18:39 +0000
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-11 02:45 +0000
Re: How would you prepare for javascripting interview? John Harris <niam@jghnorth.org.uk.invalid> - 2016-09-11 16:23 +0100
Re: How would you prepare for javascripting interview? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-12 20:32 +0100
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-12 18:49 +0000
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-13 00:27 +0000
Re: How would you prepare for javascripting interview? Tim Streater <timstreater@greenbee.net> - 2016-09-13 08:51 +0100
Re: How would you prepare for javascripting interview? Jon Ribbens <jon+usenet@unequivocal.eu> - 2016-09-13 12:33 +0000
Re: How would you prepare for javascripting interview? Scott Sauyet <scott@sauyet.com> - 2016-09-14 01:17 +0000
Re: How would you prepare for javascripting interview? Tim Streater <timstreater@greenbee.net> - 2016-09-14 11:15 +0100
Re: How would you prepare for javascripting interview? Doc O'Leary <droleary@2015usenet1.subsume.com> - 2016-09-15 15:02 +0000
Re: How would you prepare for javascripting interview? John Harris <niam@jghnorth.org.uk.invalid> - 2016-09-13 10:06 +0100
Re: How would you prepare for javascripting interview? John Harris <niam@jghnorth.org.uk.invalid> - 2016-09-06 19:53 +0100
Re: How would you prepare for javascripting interview? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-07-18 22:30 +0200
Re: How would you prepare for javascripting interview? justaguy <lichunshen84@gmail.com> - 2016-07-18 14:56 -0700
Re: How would you prepare for javascripting interview? Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2016-07-19 16:01 -0300
Re: How would you prepare for javascripting interview? Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2016-07-19 16:16 -0300

Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →

#31281

From	"Michael Haufe (TNO)" <tno@thenewobjective.com>
Date	2016-09-08 12:41 -0700
Message-ID	<5a88e860-b555-43f5-8a05-08e6fd8daaf0@googlegroups.com>
In reply to	#31229

On Sunday, September 4, 2016 at 6:07:06 PM UTC-5, Ben Bacarisse wrote:
> (Stefan Ram) writes:
> 
> > Doc O'Leary writes:
> >>They'll have to do worse if they expect to function correctly based 
> >>on the current behavior.  You could perhaps raise it as an exception 
> >>if you prefer, but it's just plain *wrong* to return a number that 
> >>wasn't given to you.
> >
> > |> 5 ** 0
> > |< 1
> >
> >   Why does it evaluate to 1?
> >
> >   5³ = 5 · 5 · 5 = 125
> >
> >   5² = 5 · 5     =  25
> >
> >   5¹ = 5         =   5
> >
> >   5° =           =   1, why??
> 
> Lots of reasons... you want 5**x to be continuous (for real x)... you
> want 5**a x 5**b = 5 ** (a+b)... and so on.

I'm a fan of Knuth's discussion of this on page 6:

"Two Notes on Notation"
<http://arxiv.org/pdf/math/9205211v1.pdf>

[toc] | [prev] | [next] | [standalone]

#31245

From	Scott Sauyet <scott@sauyet.com>
Date	2016-09-05 20:37 +0000
Message-ID	<nqkl2e$6bt$1@dont-email.me>
In reply to	#31227

Doc O'Leary wrote:
> Scott Sauyet wrote:

>> Remember that the context was the functions `Math.max` and `Math.min`,
>> so a number-centric implementation makes perfect sense.
> 
> No, it doesn’t.  It makes *zero* sense for either function to return a
> number that wasn’t in the input set.  That’s just a bad decision in the
> language’s design.  

I disagree.  The realistic choices are

  (A) Return something of the correct type, even though it's not 
      in the (empty) input list.

  (B) Return some semaphore of a different type that signals that 
      things have gone wrong: `undefined` or `null` are most likely.

  (C) Throw an error.

None of these choices is ideal, but we have to choose between them.  I'd
say that the best ordering is A > C > B.

Of course this is better for numbers than for some other types because 
numbers specifically encompass maximum and minimum values of their type.  
But this is the `Math` API.  Why should it not speak to the number type?

> It also creates an inconsistent behavior if they
> every *do* want to add such functions for other data types.

Since the second choice in my hierarchy is to throw an error, I think it 
would be reasonable to do so if the type does not permit a reasonable 
maximum or minimum value.  For Javascript, only three ordered types come 
to mind: Numbers, Dates, and Strings, although I may be missing some.  
Dates have an underlying fixed bit-sized number, so we could easily do 
the same for Dates.  An imaginary `String.max()` could be satisfied with 
the empty String, but `String.min()` would be much harder; I think it 
would have to throw.  For custom types, since it's already incumbent on 
the creator to make the ordering functions, it's not so hard to ask them 
to either supply such max/min values or to signal that it would throw in 
this case.

It's not that I think this is a bad point. I simply don't believe it's as 
clear-cut as described.

>> A null object or undefined have significant disadvantages that they are
>> not of the right type.  Downstream code will need to type-check the
>> result if the function is designed like that.

> They’ll have to do worse if they expect to function correctly based on
> the current behavior.  You could perhaps raise it as an exception if you
> prefer, but it’s just plain *wrong* to return a number that wasn’t given
> to you.  

Garbage in, garbage out.  It's no more wrong to do this than to supply a 
function that needs a non-empty list with an empty one.  I assume that 
you would rather throw in this case or to return `null` or `undefined`.  
To my mind, either of these is significantly worse.  By returning a 
number, you allow the user to proceed with numeric calculations, 
including, most importantly, using this result in a further max or min 
calculation.  (This is very much related to the arguments that Stefan Ram 
has made.)

> That’s why this behavior makes for a suitable trick question,
> but a terrible one for finding a JavaScript developer that actually
> thinks about the work they’re doing.

But remember the context of this question: I've already determined that 
the candidate has reasonably strong skills in Javascript.  I'm using this 
to try to determine how well she can think through a strange-sounding, 
but ultimately discoverable fact.  I provide guidance as needed, and 
never leave this until she's either solved it or I've given her the 
answer.  It's simply a way to help me see how she thinks.

This is not a trick question in the sense that I'm asking the candidate 
about the esoterica of the language; I'm not asking her to explore 
obscure corners of the spec.  In fact, I haven't actually bothered to 
check the spec to see if this behavior is required or if it would be 
considered acceptable to throw.  (I guess I'll do that before the next 
interview.)  I intentionally use the phrase "trick-question" when 
describing it to the candidate to put her in the frame of mind it might 
take to think about how such a function might be implemented as opposed 
to what she might want from it.  But I don't think it's actually a trick 
question.  Very much the opposite; this is the only one where I make sure 
that she understands the answer before the interview is complete.  
Because if I get around to asking this one, I've very interested in 
watching her learning process, and seeing the "aha" moment.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#31246

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2016-09-05 22:13 +0100
Message-ID	<87h99uxd75.fsf@bsb.me.uk>
In reply to	#31245

Scott Sauyet <scott@sauyet.com> writes:

> Doc O'Leary wrote:
>> Scott Sauyet wrote:
>
>>> Remember that the context was the functions `Math.max` and `Math.min`,
>>> so a number-centric implementation makes perfect sense.
>> 
>> No, it doesn’t.  It makes *zero* sense for either function to return a
>> number that wasn’t in the input set.  That’s just a bad decision in the
>> language’s design.  
>
> I disagree.  The realistic choices are
>
>   (A) Return something of the correct type, even though it's not 
>       in the (empty) input list.
>
>   (B) Return some semaphore of a different type that signals that 
>       things have gone wrong: `undefined` or `null` are most likely.
>
>   (C) Throw an error.
>
> None of these choices is ideal, but we have to choose between them.  I'd
> say that the best ordering is A > C > B.

I'd also distinguish a B/A option which is to return a value of a type
derived from that of the list (or arguments).  It's the ML/Haskell
way[1] -- you return a 'Maybe Number' object that is either 'Nothing' or
'Just m' (where m is the number found).

I realise you may have drawn up your list specifically in the context of
ECMAScript where such a type is much less handy (though we now have
destructuring bindings), but I thought I'd throw it into the mix anyway.

[1] Though it's not used, as it happens, for 'maximum' in Haskell which
opts for your (C).

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#31247

From	Scott Sauyet <scott@sauyet.com>
Date	2016-09-06 02:33 +0000
Message-ID	<nql9u1$tmc$1@dont-email.me>
In reply to	#31246

Ben Bacarisse wrote:
> Scott Sauyet wrote:
>> Doc O'Leary wrote:
>>> Scott Sauyet wrote:

>>>> Remember that the context was the functions `Math.max` and
>>>> `Math.min`, so a number-centric implementation makes perfect sense.
>>>
>>> No, it doesn’t.  It makes *zero* sense for either function to return a
>>> number that wasn’t in the input set.  That’s just a bad decision in
>>> the language’s design.
>>
>> I disagree.  The realistic choices are
>>
>>   (A) Return something of the correct type, even though it's not
>>       in the (empty) input list.
>>
>>   (B) Return some semaphore of a different type that signals that
>>       things have gone wrong: `undefined` or `null` are most likely.
>>
>>   (C) Throw an error.
>>
>> None of these choices is ideal, but we have to choose between them. 
>> I'd say that the best ordering is A > C > B.
> 
> I'd also distinguish a B/A option which is to return a value of a type
> derived from that of the list (or arguments).  It's the ML/Haskell
> way -- you return a 'Maybe Number' object that is either 'Nothing' or
> 'Just m' (where m is the number found).

Yes, that is another option.  I believe I mentioned that in an earlier 
post.  But the difference, of course, is that such a signature is a 
departure from the `:: [Number] -> Number` types we've been discussing.

> I realise you may have drawn up your list specifically in the context of
> ECMAScript where such a type is much less handy (though we now have
> destructuring bindings), but I thought I'd throw it into the mix anyway.

This is certainly worth considering.  The FantasyLand specification [1] 
is gaining some traction, and many implementations of it include a 
`Maybe` implementing such types as Functor, Applicative, and Monad.  
General-purpose functional libraries such as Ramda [2] (disclaimer: I'm 
one of the authors) interoperate easily with such types, and ones like 
Sanctuary [3] go further and choose to make functions such as `head` safe 
by having them always return `Maybe a`.

So if you're willing to change the signature from `[Number] -> Number`, 
then this is a strong contender.  (And of course by returning 
`undefined`, `null` or another non-number, you're really doing this 
anyway.)

  [1]: <https://github.com/fantasyland/fantasy-land>
  [2]: <http://ramdajs.com/>
  [3]: <http://sanctuary.js.org/>

  -- Scott

[toc] | [prev] | [next] | [standalone]

#31250

From	Doc O'Leary <droleary@2015usenet1.subsume.com>
Date	2016-09-06 16:02 +0000
Message-ID	<nqmpag$kit$1@dont-email.me>
In reply to	#31245

For your reference, records indicate that 
Scott Sauyet <scott@sauyet.com> wrote:

> I disagree.  The realistic choices are
> 
>   (A) Return something of the correct type, even though it's not 
>       in the (empty) input list.
> 
>   (B) Return some semaphore of a different type that signals that 
>       things have gone wrong: `undefined` or `null` are most likely.
> 
>   (C) Throw an error.
> 
> None of these choices is ideal, but we have to choose between them.  I'd
> say that the best ordering is A > C > B.

Then I wonder if you’ve ever done any sort of sophisticated 
programming.  There is a *reason* why languages developed mechanisms 
other than “return a valid value and let the programmer figure out 
if it’s *actually* a good result, or just some kind of error”.

> Of course this is better for numbers than for some other types because 
> numbers specifically encompass maximum and minimum values of their type.  
> But this is the `Math` API.  Why should it not speak to the number type?

It’s best dealt with abstractly, because the concept applies to 
things other than numbers.  If you can order it, you can determine 
a “max” value.  And if there is *no* values to order, it is ludicrous 
to say the correct result is a valid value you have simply fabricated.

But even restricted to numbers, the abuse of infinity remains an 
implementation hack.  NaN is also a number, and also already used 
by min/max to signal an error.  It makes zero sense (beyond the 
hack) to return an infinity.

> Since the second choice in my hierarchy is to throw an error, I think it 
> would be reasonable to do so if the type does not permit a reasonable 
> maximum or minimum value.  For Javascript, only three ordered types come 
> to mind: Numbers, Dates, and Strings, although I may be missing some.  

You’re missing an infinity of objects that developers can define 
for themselves.  Or just the infinity of uses a Number can have.  
You’re stuck thinking about the objects you have rather than the 
*uses* the objects are put to.  Stop and actually *think* about 
what you actually have to do to write a program that behaves 
properly when you define functions that fabricate “valid” results.

> Dates have an underlying fixed bit-sized number, so we could easily do 
> the same for Dates.  An imaginary `String.max()` could be satisfied with 
> the empty String, but `String.min()` would be much harder; I think it 
> would have to throw.

That’s an utter mess.  You should never be allowed to write a 
software library that is used by anyone else.

> It's not that I think this is a bad point. I simply don't believe it's as 
> clear-cut as described.

It is.  Perhaps one day you’ll be experienced enough to understand 
why.

> > They’ll have to do worse if they expect to function correctly based on
> > the current behavior.  You could perhaps raise it as an exception if you
> > prefer, but it’s just plain *wrong* to return a number that wasn’t given
> > to you.  
> 
> Garbage in, garbage out.  It's no more wrong to do this than to supply a 
> function that needs a non-empty list with an empty one.  I assume that 
> you would rather throw in this case or to return `null` or `undefined`.  

I would seek to define a consistent behavior.  The *way* garbage 
comes out is important.  That’s the entire issue of why an infinity 
is the wrong result.

> To my mind, either of these is significantly worse.  By returning a 
> number, you allow the user to proceed with numeric calculations, 
> including, most importantly, using this result in a further max or min 
> calculation.  (This is very much related to the arguments that Stefan Ram 
> has made.)

Compounded errors are not the better solution.  I want to know when 
and where something went wrong, not just *guess* at when the final 
result looks a bit off.

> > That’s why this behavior makes for a suitable trick question,
> > but a terrible one for finding a JavaScript developer that actually
> > thinks about the work they’re doing.
> 
> But remember the context of this question: I've already determined that 
> the candidate has reasonably strong skills in Javascript.

I doubt you objectively have.

> This is not a trick question in the sense that I'm asking the candidate 
> about the esoterica of the language; I'm not asking her to explore 
> obscure corners of the spec.

But that’s exactly what you’re doing.  You’re asking them about a 
hack that has, unfortunately, remained in the Math object for far 
too long.  If you legitimately want them to think, you’d do 
something like I have done, and explore ways to provide a min/max 
function for abstract collections of any type.  My bet is that none 
but the *least* qualified candidates will come up with solutions 
that fabricate results the way Math does for numbers.

-- 
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly

[toc] | [prev] | [next] | [standalone]

#31254

From	Gene Wirchenko <genew@telus.net>
Date	2016-09-06 09:50 -0700
Message-ID	<9cstsb1uddjiltlflrdiks2ha2u3msi1ao@4ax.com>
In reply to	#31250

On Tue, 6 Sep 2016 16:02:24 -0000 (UTC), Doc O'Leary
<droleary@2015usenet1.subsume.com> wrote:

>For your reference, records indicate that 
>Scott Sauyet <scott@sauyet.com> wrote:
>
>> I disagree.  The realistic choices are
>> 
>>   (A) Return something of the correct type, even though it's not 
>>       in the (empty) input list.
>> 
>>   (B) Return some semaphore of a different type that signals that 
>>       things have gone wrong: `undefined` or `null` are most likely.
>> 
>>   (C) Throw an error.
>> 
>> None of these choices is ideal, but we have to choose between them.  I'd
>> say that the best ordering is A > C > B.

     Depending on language, I would go with either B or C with both of
them >> A.  A is horrible.  It gives the opportunity to proceed with
garbage.

>Then I wonder if you’ve ever done any sort of sophisticated 
>programming.  There is a *reason* why languages developed mechanisms 
>other than “return a valid value and let the programmer figure out 
>if it’s *actually* a good result, or just some kind of error”.

     One of the things that I did not like about Microsoft BASIC was
how the VAL() function worked on garbage input.  It ignored input
after the first bad character.  So:
          val("34junk")=34
          val("junk")=0
It meant that I had to write a strong-to-number conversion when I
needed robust conversion.

     MTS BASIC was better.  Its STN()(String To Number) function
returned 0 for invalid strings, but it also had a function ISN() to
check Is the String Numeric?

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#31264

From	Scott Sauyet <scott@sauyet.com>
Date	2016-09-07 01:36 +0000
Message-ID	<nqnqu2$a4v$1@dont-email.me>
In reply to	#31254

Gene Wirchenko wrote:
>> Scott Sauyet wrote:

>>> I disagree.  The realistic choices are
>>> 
>>>   (A) Return something of the correct type, even though it's not
>>>       in the (empty) input list.
>>> 
>>>   (B) Return some semaphore of a different type that signals that
>>>       things have gone wrong: `undefined` or `null` are most likely.
>>> 
>>>   (C) Throw an error.
>>> 
>>> None of these choices is ideal, but we have to choose between them. 
>>> I'd say that the best ordering is A > C > B.
> 
>      Depending on language, I would go with either B or C with both of
> them >> A.  A is horrible.  It gives the opportunity to proceed with
> garbage. [ ... ]

I probably shouldn't have used "garbage in, garbage out" earlier.  This 
is really not a case of that.

Stefan Ram was trying to explain this earlier in the thread.  I think 
it's easiest to argue this through some analogies:  A function such as 
`all` is straightforward:

    // all :: (a -> Bool) -> [a] -> Bool
    const all = (predicate, list) => list.reduce(
        (current, val) => current && predicate(val), 
        true
    );
    // all(n => n > 3, [8, 6, 7, 5]); //=> true
    // all(n => n > 3, [8, 6, 7, 5, 3, 0, 9]); //=> false

Note that 

    // all([]); //=> true

This is proper.  (If there's any doubt, read up on vacuous truths [1].)

But of course in this case, there is no entry, `val`, in the list for 
which `predicate(val)` returns true.  Although some people who don't 
understand vacuous truths are confused by this, generally this is easily 
accepted.  It's not only convenient, it's quite important, because it 
allows `all` to follow some useful laws, such as:

    all(p, list1) && all(p, list2) === all(p, concat(list1, list2))

We could also discuss the additive identity of 0 or multiplicative 
identity of 1, which have similar laws:

    sum(list1) + sum(list2) === sum(concat(list1, list2))
    product(list1) * product(list2) === product(concat(list1, list2))

These hold for any lists of numbers, even empty ones because 

    sum([]); //=> 0
    product([]); //=> 1

Of course we need suitable definitions of `concat`, `sum`, and `product` 
here, but it should be clear enough what those would entail.

So is there a reasonable equivalent law for `max`?  I say yes:

    max([max(list1), max(list2)]) === max(concat(list1, list2))

To make this true, `max([])` *must* be no greater than every valid 
number.  Javascript offers only one such value, `-Infinity`.

This is not simply an implementation convenience.  It goes to the heart 
of how the function is considered.  If we try to define it in some hand-
waving manner that implies that the result of `max` is specifically one 
of the inputs in the list, then we end up with a function less useful 
than it could be.

  [1]: <https://en.wikipedia.org/wiki/Vacuous_truth>

  -- Scott

[toc] | [prev] | [next] | [standalone]

#31269

From	Gene Wirchenko <genew@telus.net>
Date	2016-09-07 10:07 -0700
Message-ID	<f4i0tbtk1d2sgoqenh8cm8tl6itpk6prqk@4ax.com>
In reply to	#31264

On Wed, 7 Sep 2016 01:36:02 -0000 (UTC), Scott Sauyet
<scott@sauyet.com> wrote:

[snip]

>So is there a reasonable equivalent law for `max`?  I say yes:
>
>    max([max(list1), max(list2)]) === max(concat(list1, list2))
>
>To make this true, `max([])` *must* be no greater than every valid 
>number.  Javascript offers only one such value, `-Infinity`.

     The problem with this is that -Infinity is a valid numeric value.
If max() returns that, then I have to check why it was returned.

     What about using NaN?

>This is not simply an implementation convenience.  It goes to the heart 
>of how the function is considered.  If we try to define it in some hand-
>waving manner that implies that the result of `max` is specifically one 
>of the inputs in the list, then we end up with a function less useful 
>than it could be.

     This is on the edge of my mathematical knowledge.  I see your
point, but I also see some ugliness.  I suspect others who know less
math are seeing only the ugliness.

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#31293

From	Scott Sauyet <scott@sauyet.com>
Date	2016-09-10 00:03 +0000
Message-ID	<nqvilf$a4r$1@dont-email.me>
In reply to	#31269

Gene Wirchenko wrote:
> Scott Sauyet wrote:

>> So is there a reasonable equivalent law for `max`?  I say yes:
>>
>>    max([max(list1), max(list2)]) === max(concat(list1, list2))
>>
>> To make this true, `max([])` *must* be no greater than every valid
>> number.  Javascript offers only one such value, `-Infinity`.

>      The problem with this is that -Infinity is a valid numeric value.
> If max() returns that, then I have to check why it was returned.

I can't think of many places where I use `max` where I would need to 
check this.  Can you think of examples?  I would generally proceed on my 
merry way with this value.  In fact, that's the whole point.

>      What about using NaN?

    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.  This 
would be quite unfortunate, especially if we partition it via some 
filtering mechanism that might easily leave some empty groups.

>> This is not simply an implementation convenience.  It goes to the heart
>> of how the function is considered.  If we try to define it in some 
>> hand-waving manner that implies that the result of `max` is 
>> specifically one of the inputs in the list, then we end up with a 
>> function less useful than it could be.
> 
>      This is on the edge of my mathematical knowledge.  I see your
> point, but I also see some ugliness.  I suspect others who know less
> math are seeing only the ugliness.

To me the only real ugliness, and it is a significant one, is the one Doc 
O'Leary is stressing:  This works well for numbers.  But it does not 
abstract gracefully to all possible types.  That leaves us with a choice 
to make: do we write a more abstract function, useful on more types but 
less true to numbers or do we leave this as a function only on numbers 
and assume that other types would have their own mechanisms for 
determining maxima/minima?

Doc O'Leary strongly suggests the former.  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 partly because I believe there are some inherent 
problems trying to do that sort of generic programming in such a 
dynamically typed language.

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. But there is a simple definition that captures the 
meaning explicitly without trying to select an element:  "The maximum is 
the smallest value that is no smaller than any element in the list."  
That clearly works for any non-empty lists, and it implies -Infinity for 
an empty list, which also works for the law I suggested above.

This is just cleaner all around.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#31294

From	Scott Sauyet <scott@sauyet.com>
Date	2016-09-10 00:12 +0000
Message-ID	<nqvj6b$a4r$2@dont-email.me>
In reply to	#31293

Scott Sauyet wrote:

Something poorly formatted.  (Not sure why.)  I hope this comes through 
better:

|     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

  -- Scott

[toc] | [prev] | [next] | [standalone]

#31305

From	Doc O'Leary <droleary@2015usenet1.subsume.com>
Date	2016-09-10 15:34 +0000
Message-ID	<nr1965$6qh$1@dont-email.me>
In reply to	#31293

For your reference, records indicate that 
Scott Sauyet <scott@sauyet.com> 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.  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 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.

> 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.

-- 
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly

[toc] | [prev] | [next] | [standalone]

#31312

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2016-09-11 01:32 +0100
Message-ID	<87d1kbtgxn.fsf@bsb.me.uk>
In reply to	#31305

Doc O'Leary  <droleary@2015usenet1.subsume.com> writes:

> For your reference, records indicate that 
> Scott Sauyet <scott@sauyet.com> 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.

That function in question is, quite reasonably, variadic and the above
is just shorthand to simplify making the point.  The max function shown
is just

  var max = list => Math.max.apply(null, list)

Being able to apply Math.max to a list is one reason it is variadic.

Given that, you don't want the partitioning a list to affect the result;
you want the maximum height of a class to be the larger of the maximum
of the heights of the boys and that of the girls.

<snip>
>> 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 sure there *are* some inconsistencies, but max and min are, in this
regard, consistent with every and some and Math.pow is unavoidably
different from them all.  That's not an inconsistency in the design.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#31344

From	Doc O'Leary <droleary@2015usenet1.subsume.com>
Date	2016-09-12 19:26 +0000
Message-ID	<nr6vhe$lka$3@dont-email.me>
In reply to	#31312

For your reference, records indicate that 
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> Being able to apply Math.max to a list is one reason it is variadic.

Which has nothing to do with the *validity* of such functions under 
certain input conditions.  The whole question is whether or not the 
results are *meaningful* for (some) multi-variable functions with 
fewer arguments than are naturally expected.

> Given that, you don't want the partitioning a list to affect the result;

I don’t give a damn what your internal implementation is.  I want a 
result that doesn’t fabricate values that screw up future 
calculations.  If you can’t do that, you should indicate an error.

> I'm sure there *are* some inconsistencies, but max and min are, in this
> regard, consistent with every and some and Math.pow is unavoidably
> different from them all.  That's not an inconsistency in the design.

And what of the inconsistency in the root max() < min() comparison?  
I consider *that* relationship to be more fundamental than how Math 
was most conveniently implemented.

-- 
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly

[toc] | [prev] | [next] | [standalone]

#31349

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2016-09-13 01:02 +0100
Message-ID	<87mvjcr7jg.fsf@bsb.me.uk>
In reply to	#31344

Doc O'Leary  <droleary@2015usenet1.subsume.com> writes:

> For your reference, records indicate that 
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> Being able to apply Math.max to a list is one reason it is variadic.
>
> Which has nothing to do with the *validity* of such functions under 
> certain input conditions.  The whole question is whether or not the 
> results are *meaningful* for (some) multi-variable functions with 
> fewer arguments than are naturally expected.

You've cut the context.  I suspect that's deliberate.

You were objecting to a rule which only makes sense about lists (well,
arrays in ECMAScript) so it's important to explain why max might be
called with zero arguments.  You are unlikely to write Math.max() in
your code, but you might apply max to an array.

>> Given that, you don't want the partitioning a list to affect the result;
>
> I don’t give a damn what your internal implementation is.

What?  I'm not saying anything about the implementation.

> I want a 
> result that doesn’t fabricate values that screw up future 
> calculations.
>
> If you can’t do that, you should indicate an error.

Everything you do when you apply max to an empty array will be able to
screw up some calculations.  An exception needs to be handled and all
the so-called 'fabricated' values -- null, undefined and NaN -- will be
inappropriate in some situations.  The point being made is that
returning -Infinity is both useful and consistent, and not surprising to
people used to other similar functions like 'some' and 'every'.

>> I'm sure there *are* some inconsistencies, but max and min are, in this
>> regard, consistent with every and some and Math.pow is unavoidably
>> different from them all.  That's not an inconsistency in the design.
>
> And what of the inconsistency in the root max() < min() comparison?
> I consider *that* relationship to be more fundamental

What relationship should they have?  (This is a serious question -- I'm
not sure what you aould have done had you been in charge.)

> than how Math 
> was most conveniently implemented.

I think you've misunderstood the case being made.  It may well be
convenient to implement it this way, but my interest is in making the
function convenient to use.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#31362

From	Doc O'Leary <droleary@2015usenet1.subsume.com>
Date	2016-09-13 21:38 +0000
Message-ID	<nr9rjq$22i$2@dont-email.me>
In reply to	#31349

For your reference, records indicate that 
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> You've cut the context.  I suspect that's deliberate.

It is, in that this discussion has gotten longer without any new 
information being added.

> You were objecting to a rule which only makes sense about lists (well,
> arrays in ECMAScript) so it's important to explain why max might be
> called with zero arguments.  You are unlikely to write Math.max() in
> your code, but you might apply max to an array.

Again, *irrelevant* to whether or not valid result can be obtained.  
The only question that matters is what a reasonable result *should* 
be for a function called with 0, 1, 2, or however many arguments are 
or are not given.

> >> Given that, you don't want the partitioning a list to affect the result;
> >
> > I don’t give a damn what your internal implementation is.
> 
> What?  I'm not saying anything about the implementation.

You are.  You introduced “partitioning” into the discussion.  That 
(i.e., being a recursive call) is an implementation detail.  And 
one, I suspect, that has *nothing* to do with the actual code that 
is used to compute the result in most JavaScript implementations 
of these Math functions.

> Everything you do when you apply max to an empty array will be able to
> screw up some calculations.

Indeed.  And that’s why it’s best if we screw things up in a *good* 
way, and not by returning a result that fabricates a falsely 
“correct” value.

> returning -Infinity is both useful and consistent, and not surprising to
> people used to other similar functions like 'some' and 'every'.

The reality is exactly the opposite of what you claim.  Again, I 
encourage you to go talk to actual humans and ask them what makes 
sense in these cases, since *they* are the ones who are going to 
suffer trying to use your buggy code.  I would still wage large 
sums of money that none of them want the behavior you describe.

> > And what of the inconsistency in the root max() < min() comparison?
> > I consider *that* relationship to be more fundamental
> 
> What relationship should they have?  (This is a serious question -- I'm
> not sure what you aould have done had you been in charge.)

They should have a “useful and consistent, and not surprising” 
relationship.  Again, talk to a human if you are unable to figure 
out what that would be.

> I think you've misunderstood the case being made.  It may well be
> convenient to implement it this way, but my interest is in making the
> function convenient to use.

It’d be damn convenient if it didn’t fabricate results that screw 
up future calculations wouldn’t it?  What’s the average maximum 
daily temperate for a month where hourly data couldn’t be collected 
one day?  If you say -Infinity, you should never be allowed to work 
at a job that uses numbers again.

-- 
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly

[toc] | [prev] | [next] | [standalone]

#31363

From	"Christoph M. Becker" <cmbecker69@arcor.de>
Date	2016-09-14 00:56 +0200
Message-ID	<nra05j$qc5$1@solani.org>
In reply to	#31362

On 13.09.2016 at 23:38, Doc O'Leary wrote:

> For your reference, records indicate that 
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> 
>> I think you've misunderstood the case being made.  It may well be
>> convenient to implement it this way, but my interest is in making the
>> function convenient to use.
> 
> It’d be damn convenient if it didn’t fabricate results that screw 
> up future calculations wouldn’t it?  What’s the average maximum 
> daily temperate for a month where hourly data couldn’t be collected 
> one day?  If you say -Infinity, you should never be allowed to work 
> at a job that uses numbers again.

Why should this result in -Inf?  If the data for one day would be
missing, there still would be data left for the other days.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#31379

From	Doc O'Leary <droleary@2015usenet1.subsume.com>
Date	2016-09-15 15:09 +0000
Message-ID	<nredje$ikp$2@dont-email.me>
In reply to	#31363

For your reference, records indicate that 
"Christoph M. Becker" <cmbecker69@arcor.de> wrote:

> On 13.09.2016 at 23:38, Doc O'Leary wrote:
> 
> > It’d be damn convenient if it didn’t fabricate results that screw 
> > up future calculations wouldn’t it?  What’s the average maximum 
> > daily temperate for a month where hourly data couldn’t be collected 
> > one day?  If you say -Infinity, you should never be allowed to work 
> > at a job that uses numbers again.
> 
> Why should this result in -Inf?  If the data for one day would be
> missing, there still would be data left for the other days.

Because their argument is that the maximum temperature for the missing 
day should be -Infinity.  Averaging that in with the valid maximums is 
still going to leave you with -Infinity.

-- 
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly

[toc] | [prev] | [next] | [standalone]

#31365

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2016-09-14 00:47 +0100
Message-ID	<87y42vnyza.fsf@bsb.me.uk>
In reply to	#31362

Doc O'Leary  <droleary@2015usenet1.subsume.com> writes:

> For your reference, records indicate that 
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> You've cut the context.  I suspect that's deliberate.
>
> It is, in that this discussion has gotten longer without any new 
> information being added.
>
>> You were objecting to a rule which only makes sense about lists (well,
>> arrays in ECMAScript) so it's important to explain why max might be
>> called with zero arguments.  You are unlikely to write Math.max() in
>> your code, but you might apply max to an array.
>
> Again, *irrelevant* to whether or not valid result can be obtained.  
> The only question that matters is what a reasonable result *should* 
> be for a function called with 0, 1, 2, or however many arguments are 
> or are not given.

Yes, we both agree on that, but you've misunderstood what's being said
about partitioning a list -- you think it has something to do with
recursion and implementing max.  It doesn't.  The partitioning argument
is entirely about what result should be returned for 0, 1, 2 or more
arguments, but I don't think you've grasped that because you keep saying
it's about recursion.

>> >> Given that, you don't want the partitioning a list to affect the result;
>> >
>> > I don’t give a damn what your internal implementation is.
>> 
>> What?  I'm not saying anything about the implementation.
>
> You are.  You introduced “partitioning” into the discussion.  That 
> (i.e., being a recursive call) is an implementation detail.

No, not at all.  I think you simply have got hold of the wrong end of
the stick.  The fact that you think the partitioning argument has to do
with recursion and implementing max would explain why you keep saying
it's irrelevant.

<snip>
>> > And what of the inconsistency in the root max() < min() comparison?
>> > I consider *that* relationship to be more fundamental
>> 
>> What relationship should they have?  (This is a serious question -- I'm
>> not sure what you aould have done had you been in charge.)
>
> They should have a “useful and consistent, and not surprising” 
> relationship.  Again, talk to a human if you are unable to figure 
> out what that would be.

Are you not a human?  I am actually asking you for your answer.  I can
pop round to the neighbour, or ask at the dog club, but they won't even
know what I'm talking about.  My best bet for getting to what you think
a “useful and consistent, and not surprising” relationship is simply to
ask you.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#31380

From	Doc O'Leary <droleary@2015usenet1.subsume.com>
Date	2016-09-15 15:34 +0000
Message-ID	<nref25$ikp$3@dont-email.me>
In reply to	#31365

For your reference, records indicate that 
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> Yes, we both agree on that, but you've misunderstood what's being said
> about partitioning a list -- you think it has something to do with
> recursion and implementing max.  It doesn't.  The partitioning argument
> is entirely about what result should be returned for 0, 1, 2 or more
> arguments, but I don't think you've grasped that because you keep saying
> it's about recursion.

No, I don’t think that *you* have grasped that I *still* don’t care 
about how you implement your function.  I care about its definition, 
which I want you to *think* about before you jump right to a 
“solution” that involves partitioning/recursion/whatever.

There is *nothing* about the definition of a set maximum that 
defines what the results should be for 0 elements, save for the 
fact that it *explicitly* states the result *must* be a member of 
the input set.  -Infinity is *not* a member of the empty set, so 
*regardless* of any implementation choices you make, it is *wrong* 
to return -Infinity.

This case is closed from both a mathematical standpoint and a 
computer science standpoint.  JavaScript’s Math is buggy and should 
be fixed.  To continue to argue otherwise only reflects poorly on 
you.

> No, not at all.  I think you simply have got hold of the wrong end of
> the stick.  The fact that you think the partitioning argument has to do
> with recursion and implementing max would explain why you keep saying
> it's irrelevant.

No, the people who keep holding the “wrong end of the stick” are the 
ones who keep trying to argue that a function’s identity represents 
a valid *external* value for calling that function.

> > They should have a “useful and consistent, and not surprising” 
> > relationship.  Again, talk to a human if you are unable to figure 
> > out what that would be.
> 
> Are you not a human?  I am actually asking you for your answer.  I can
> pop round to the neighbour, or ask at the dog club, but they won't even
> know what I'm talking about.

I think they would; we’re not talking about high level math here.  
Every high school graduate (and, indeed, most grade school children) 
would likely give you the correct answer to what “less than” means, 
what “max” and “min” mean, and what the valid relationships between 
them all should be.

But you shouldn’t even need to talk to them or me.  I expect that 
*you* are also a human who correctly knows the answer to this 
problem.  So answer it properly.  If you do, you’ll come to the 
same conclusion I have.

-- 
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly

[toc] | [prev] | [next] | [standalone]

#31313

From	Scott Sauyet <scott@sauyet.com>
Date	2016-09-11 02:45 +0000
Message-ID	<nr2gft$esh$1@dont-email.me>
In reply to	#31305

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

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →

csiph-web

How would you prepare for javascripting interview?

Contents

#31281

#31245

#31246

#31247

#31250

#31254

#31264

#31269

#31293

#31294

#31305

#31312

#31344

#31349

#31362

#31363

#31379

#31365

#31380

#31313