another note: it is common practice in go to put the if present check all on one line.

  if _, present := m[w]; present {
    return false
  }

you can look at my solution for a full example

small typo in description:
At exactly end time should be At exactly exit time

did you try using Math.floor on the final value? (javascript)

Wow, this is an excellent and thorough assessment. Thanks.

I think the biggest issue is the input parameters. They should be reformulated so they are more cohesive (as per #1 and #3). Second issue I noticed was #4. That should be as an explicit instruction in the "Task" section.

I think the instructions should be more explicit about the orientation of function parameters:
The pipeline() calls function parameters from left to right
The compose() calls function parameters from right to left

However, IS there any practical reason why the compose() should call function parameters from right to left?
This interface seems quite odd and has no benefit over a left to right interface.

Nice modification!

Thanks

Thanks matt c. I misunderstood. So this example would be:

group 1 + 2 {
  mary: 10,
  shaun: 113,
  santa: 38,
  morgan: 93,
  frog: 191,
  joel: 151,
  god: 42,
  john: 24
}
highest -> { frog: 191 }

I have issues with the javascript version for random test cases.
I wrote my own algorithm and I believe the test algorithm may not be adding up or comparing the ages according to its specification?

group 1: [ 
  { name: 'frog', age: 94 }, 
  { name: 'joel', age: 83 }, 
  { name: 'master', age: 55 } 
]

group 2: [ 
  { name: 'mary', age: 10 }, 
  { name: 'shaun', age: 49 }, 
  { name: 'santa', age: 38 }, 
  { name: 'morgan', age: 93 }, 
  { name: 'frog', age: 4 }, 
  { name: 'frog', age: 93 }, 
  { name: 'joel', age: 68 }, 
  { name: 'god', age: 42 },
  { name: 'shaun', age: 64 }, 
  { name: 'john', age: 24 } 
] 

group 1: { 
  frog: 94, 
  joel: 83, 
  master: 55 
} 
highest -> { frog: 94 }

group 2: { 
  mary: 10, 
  shaun: 113, 
  santa: 38, 
  morgan: 93, 
  frog: 97, 
  joel: 68, 
  god: 42, 
  john: 24 
}
highest -> { shaun: 113 }

shaun clearly has the greater number.
The kata says
"Expected: frog, instead got: shaun"

Since the methods are the same for all Vector instances, the methods should be attached to the Vector prototype. Attaching them on the prototype means there will only be ONE copy in memory.

When you assign the methods inside the constructor using this (like you have done here), the methods are copied for every new object instance, which equals no bueno. Therefore, this solution is not a best practice.

I agree. This is not a best practice. The instance should be protected from direct modification by declaring it as a variable inside a closure.

Repeating this: Example test cases don't work. assertEqual should be changed to assertEquals

n%1!=0 will evaluate to true for n = Infinity || -Infinity.
So the expression !isFinite(n) in your if statement is not needed.