Update

[Planeshifter]

According to todo + accessor fun support

• accessor function support
• validate.io modules
• dotfiles
• LICENSE, README.md
• removed IIFE + preamble
• strict mode for examples, tests

Resolves compute-io/todo#4

[coveralls]

Coverage remained the same at 100.0% when pulling 300cc08 on develop into a101363 on master.

[coveralls]

Coverage remained the same at 100.0% when pulling 9578b2a on develop into a101363 on master.

[coveralls]

Coverage remained the same at 100.0% when pulling 9578b2a on develop into a101363 on master.

[Planeshifter]

Shall we return null in case of an empty input array or instead return an empty array?

[kgryte]

What is the argument for returning an empty array?

[Planeshifter]

V8 deoptimizes the function if its return type changes when function is executed repeatedly. An empty array would still signal that there are no modes, and the user could always rely on the return value being an array and so e.g. map over it. Yet, I do think that having a consistent API for all functions would be preferable, so let's stick with null?

[kgryte]

Interesting. Do you have a reference for this V8 behavior? I am aware of monomorphic versus polymorphic function input optimization behavior. I was not aware of de-optimization for polymorphic return values; e.g., array versus null.

Although, upon consideration, even if not this function is not deoptimized, a consumer may be, as the JIT cannot make type inferences about the consumer's internal variables.

This said, the consumer would only be deoptimized and possibly sent to deoptimization hell if some mixture of numeric and empty arrays were repeatedly provided to, e.g., this module. As long as a consumer only provides one or the other, the function and the consumer can be optimized.

My thinking re: null versus [] versus NaN is that each output type carries particular meaning. null when no computation could be performed. NaN when a computation expecting numeric values encounters a non-numeric value. [] when, e.g., filtering and not finding any results. Might be worth considering if this reasoning is reasonable.

We could also write some documentation at some point regarding how to create fast computational code and discuss how to avoid having code deoptimized. In this case, ensure that no empty arrays are provided to the function.

Your thoughts?

[Planeshifter]

I have to backtrack: I implemented a benchmark test and it seems as if there is no performance penalty arising from returning null instead of []. So there is good reason why you had not been aware of any de-optimization: It simply does not exist. My memory must have tricked me, thought I read about it - but I guess it must have been only about function inputs. So in this case, passing empty arrays as parameters of the function does not cause the code to be de-optimized.

Agree with your reasoning re: different return types.