比较适合lstm处理的情况_如何处理比较极端的情况

比较适合lstm处理的情况

重点 (Top highlight)

JavaScript算法可能是“不可预测的”！ (JavaScript algorithm can be “unpredictable”!)

“Any sufficiently advanced technology is indistinguishable from magic.”

“任何足够先进的技术都无法与魔术区分开。”

— Arthur C. Clarke (3rd Clarke’s law)

-亚瑟·克拉克(第三克拉克定律)

Before we start to get familiar with JavaScript corner cases, I’d like to make a distinction between Corner Case and Edge Case.

在我们开始熟悉JavaScript极端案例之前，我想先区分一下Corner Case和Edge Case 。

We can say that Edge Case is an issue that can occur only at minimum or maximum parameters. Predicting it can be a significant task since those situations may be neglected or underestimated. For example, a PC at full power can overheat, and its performance may deteriorate a little.

我们可以说Edge Case是仅在最小或最大参数下才可能出现的问题 。 预测这可能是一项重要的任务，因为这些情况可能被忽略或低估了。 例如，满功率的PC可能会过热，并且其性能可能会略有下降。

I’d love to introduce a Boundary Case also (a subject of the doubt too). It can occur if one of the parameters is beyond the minimum or maximum limits.

我也想介绍一个边界案例 (也是一个疑问的主题)。 如果其中一个参数超出最小或最大限制，则会发生这种情况。

What about Corner Cases? I won’t give any definition since you’ll be able to do by yourself after you take a look at the next examples.

那角落柜呢？ 我不会给出任何定义，因为您可以在查看下一个示例之后自行完成。

你不会相信的！ (You won’t believe this!)

If I ask you can something be coercive equal to the negation of itself, what would be your answer? You’d probably said that is a nonsense question, but:

如果我问你可以强迫自己做些等于否定的事情，那你的答案是什么？ 您可能会说这是一个胡说八道的问题，但是：

var arr1 = [];
var arr2 = [];




if (arr1 == !arr2) {
    console.log("Yes, it's true!");
}


if (arr1 != arr2) {
    console.log("It's true again!");
}

You may think that JS is a crazy language, and this should not happen for a popular language like JS. This example is silly because you will never compare value to the negation of itself in a real example. But this is a great example to help you clarify and adopt the right mental model!

您可能会认为JS是一种疯狂的语言，而对于像JS这样的流行语言则不应发生这种情况。 这个例子很愚蠢，因为在一个真实的例子中，您永远不会将价值与否定价值进行比较。 但这是一个很好的例子，可以帮助您阐明和采用正确的思维模式！

You won’t ever have a situation where are you comparing array with negative arrays. You won’t ever design code on this way. That is an excellent example of how you don’t want to manage the codebase.

您永远不会遇到要比较负数组和负数组的情况。 您将永远不会以这种方式设计代码。 这是您不想管理代码库的一个很好的例子。

In the next example, I’ll explain what happens in great details, so you can have a clear image of what an algorithm is doing:

在下一个示例中，我将详细解释发生的情况，因此您可以清晰地了解算法的作用：

var arr1 = [];
var arr2 = [];




//1. arr1 == !arr2
//2. [] == false 
//3. "" == false
//4. "" == 0
//5. 0 == 0 
//6. 0 === 0 
if (true) console.log("Yes, it's true!");

Firstly, I’ll refer to the documentation. On line 6, we have a comparison of primitive and non-primitive value. In this case, the rule №11 applied. The result of this algorithm is an empty string.

首先，我将参考文档 。 在第6行，我们比较了原始值和非原始值。 在这种情况下，将应用规则№11。 该算法的结果是一个空字符串。

In the next step, we’re comparing an empty string with false. According to the algorithm, rule №9 applied. The next step (line 8) is to apply rule №5. The 5th step is to compare two numbers. Since we’re using equality comparison, we’re going to call strict equality comparison algorithm.

在下一步中，我们将比较一个空字符串和false 。 根据该算法，应用第№9号规则。 下一步(第8行)是应用规则№5。 第五步是比较两个数字。 由于我们使用的是相等比较，因此我们将称之为严格的相等比较算法 。

The last step is to return a true from the strict equality comparison. The second example is a bit more practical because we’re using not equals (double equality negation) - checking if is not coercively equal:

最后一步是从严格相等比较中返回true 。 第二个示例更实际一些，因为我们使用的是不等于(双重相等否定)- 检查是否不强制等于 ：

var arr1 = [];
var arr2 = [];




//1. arr1 != arr2
//2. (!(arr1 == arr2))
//3. (!(false))
if (true) console.log("It's true again!");

As we are comparing two non-primitive types, it means that we’re going to perform an identity comparison. The same applies when using strict equality comparison.

当我们比较两种非基本类型时，这意味着我们将要进行身份比较。 使用严格相等比较时也是如此。

不要惹布尔 (Don’t mess with Booleans)

Let’s talk about booleans and their connections to abstract equality. That is something you work with a lot. We should take a look at corner cases that can occur:

让我们谈谈布尔值及其与抽象相等性的联系。 那是您经常处理的事情。 我们应该看一下可能发生的极端情况：

var students = [];




if (students) {
    console.log("You can see this message!");
}


if (students == true) {
    console.log("You can't see this message!");
}


if (students == false) {
    console.log("Working!");
}

Being explicit can sometimes produce unnecessary problems. In the second if-clause, we compare array with boolean. You may have thought that the result of this operation is boolean true, but it isn’t. The same effect will be with strict equality.

露骨有时会产生不必要的问题。 在第二个if子句中，我们将array与boolean进行比较。 您可能以为此操作的结果为boolean true ，但事实并非如此。 严格的平等将带来相同的效果。

Comparison of an array and a boolean value will go throughout lots of corner cases. Before we take a look at examples, I’ll give you a hint: Don’t ever use double equals with boolean (true and false). Let’s analyze how the algorithm works:

数组和布尔值的比较将在很多情况下进行。 在我们看示例之前，我会给您一个提示： 永远不要对boolean(true和false)使用double equals 。 让我们分析一下算法的工作原理：

var students = [];




//** if(students) **//
// 1. students 
// 2. Boolean(students)
if (true) console.log("You can see this message!");


//** if(students == true) **//
// 1. "" == true
// 2. "" == 1
// 3. 0 === 1
if (false) console.log("You can't see this message!");


//** if(students == false) **//
// 1. "" == false
// 2. "" == 0
// 3. 0 === 0
if (true) console.log("Working!");

The first if-clause is self-explanatory, so I won’t waste time explaining. Like in the previous example, I refer to the documentation. Comparing array and boolean is going to invoke ToPrimitive() abstract operation (rule №11) as one of the compared values is a non-primitive type.

第一个if子句是不言自明的，因此我不会浪费时间解释。 像前面的示例一样， 我参考 文档 。 比较数组和布尔值将调用ToPrimitive()抽象操作(第11号规则)，因为比较值之一是非基本类型。

Next three steps are straight forward. Firstly, we convert a boolean to a number (rule №9: ToNumber(true)), in the next step the string becomes number (rule №5: ToNumber(“”)), and the last step is to perform a strict equality comparison. The third clause is the same as the previous.

接下来的三个步骤很简单。 首先，我们将布尔值转换为数字(第9号规则： ToNumber(true) )，在下一步中，字符串变为数字(第5号规则： ToNumber(“”) )，最后一步是执行严格的相等比较。 第三条款与前面的条款相同。

One of the downsides of the coercion is an abstract operation ToNumber(). I’m not sure that converting an empty string to a number should return 0. It would be much better to return NaN since NaN is representing an invalid number.

强制的缺点之一是抽象操作ToNumber() 。 我不确定将空字符串转换为数字应该返回0 。 返回NaN会更好，因为NaN代表一个无效数字。

Conclusion: Senseless input will always produce senseless output. We don’t have to be explicit all time. Implicitly can sometimes be better than explicitly.

结论： 无意义的输入将始终产生无意义的输出。 我们不必一直露骨。 隐式有时比显式更好。

The best thing you could do when you’re checking the existence of the values in the array is to be more explicit and check the presence of .length to make sure it’s a string or an array:

当检查数组中值的存在时，您可以做的最好的事情是更加明确，并检查.length的存在以确保它是字符串或数组：

const arr1 = [1, 2, 3];
const arr2 = [];




if (arr1) {
    console.log("You should see this message!");
}


if (arr1.length) {
    console.log("Array is not empty!");
}




if (arr2) {
    console.log("You should not see this message!");
}


if (arr2.length) {
    console.log("You can't see this message!");
}

Deep checking is more reliable. As you can see, an empty array is going to return true (after boolean coercion). The same thing adopts for objects - always do deep checking. When we make sure that the type is a string or an array, we’ll use the typeof operator (or Array.isArray() method).

深度检查更可靠。 如您所见，一个空数组将返回true (在布尔强制之后)。 对象采用相同的方法- 始终进行深度检查 。 当我们确保类型是字符串或数组时，我们将使用typeof运算符(或Array.isArray()方法)。

澄清度 (Clarification)

There are guidelines you have to follow to avoid falling into the traps of corner cases. Using double equals everywhere can be a two-edged sword. Have on mind that using double equals when either side of compared values is 0, an empty string or string with only white-space is a bad practice.

您必须遵循一些准则，以免掉入极端情况的陷阱。 在所有地方使用双等于可以是一把两刃剑。 请记住，当比较值的任一边为0时，使用double等于时，空字符串或仅包含空格的字符串是不好的做法。

The next big thing to memorise is to avoid using double equals with non-primitive types. The only time you can use it is for identity comparison. I cannot say that this is 100% safe as it’s close enough to corner case that it’s not worth it.

要记住的下一件大事是避免对非原始类型使用双等于。 唯一可以使用它的是用于身份比较。 我不能说这是100％安全的，因为它足够接近不值得的极端情况。

ECMAScript 6 introduced a new utility Object.is(). With this method, we can finally perform identity comparison without the risk of side effects. In the end, we can say that using double equals is only safe with primitive types, but not with non-primitives.

ECMAScript 6引入了一个新的实用程序Object.is() 。 使用这种方法，我们最终可以进行身份​​比较，而没有副作用的风险。 最后，我们可以说使用double equals仅对于基本类型是安全的，而对于非基本类型则不安全。

Last but not least is to avoid using double equals with booleans (true and false). It’s much better to allow implicit boolean coercion (invoke ToBoolean() abstract operation). If you cannot enable implicit coercion, and you’re limited to use double equals with booleans (true and false), then use triple equals.

最后但并非最不重要的一点是避免对布尔值( true和false )使用double equals。 最好允许隐式布尔强制(调用ToBoolean()抽象操作)。 如果您无法启用隐式强制，并且只能使用带布尔值的双精度等于( true和false )，则应使用三重等于 。

Conclusion: Most of the corner case can be avoided by refactoring our codebase.

结论： 重构我们的代码库可以避免大多数情况。

翻译自: https://medium.com/javascript-in-plain-english/how-to-handle-comparison-corner-cases-c96ae9a17d4a

比较适合lstm处理的情况