Я записал программу, которые позволяют двум классам “бороться”. По любой причине всегда побеждает C#. Что случилось с VB.NET?
Спасибо @Ranga Vure. Я проверил вашу функцию по сравнению с исходной функцией best_fit (с вашими значениями, конечно) и получил разные значения для наклона. Это то, что дает функция best_fit (значения y_vals выглядят округленными, но это не так):
x_vals y_vals slope_py
0 -0.0562623 NaN
1 1.06266 NaN
2 -0.188706 NaN
3 1.71062 NaN
4 1.93986 NaN
5 2.3632 0.464019
6 1.72645 0.472965
7 3.29871 0.448290
8 4.31794 0.296278
9 4.00691 0.569167
10 6.08579 0.587891
11 7.27267 0.942689
12 8.70598 0.971577
13 10.1416 1.204185
14 11.1705 1.488952
15 11.9999 1.303836
16 14.8629 1.191893
17 16.699 1.417222
18 18.7195 1.680720
19 20.4281 1.979709
Я перевел функцию best_fit в sqlContext, и это дало мне те же значения в качестве исходной функции best_fit:
spark_df.createOrReplaceTempView('tempsql')
df_sql = sqlContext.sql("""
SELECT *,
(((sum(x_vals*y_vals) over (order by x_vals rows between 5 preceding and 1 preceding)) - 5 * (sum(x_vals) over (order by x_vals rows between 5 preceding and 1 preceding))/5 * (sum(y_vals) over (order by x_vals rows between 5 preceding and 1 preceding))/5) /
((sum(x_vals*x_vals) over (order by x_vals rows between 5 preceding and 1 preceding)) - 5 * (sum(x_vals) over (order by x_vals rows between 5 preceding and 1 preceding))/5 * (sum(x_vals) over (order by x_vals rows between 5 preceding and 1 preceding))/5)) as slope_sql
from tempsql
""")
Это дает те же значения, что и исходная функция best_fit, за исключением точек 3-5, когда она рассчитывает наклон до предполагаемого начала (то есть 6-й точки ) - небольшая причуда, но я могу жить с ней:
+------+-------------------+-------------------+--------------------+
|x_vals| y_vals| slope_py| slope_sql|
+------+-------------------+-------------------+--------------------+
| 0|-0.0562623219433051| NaN| null|
| 1| 1.06266136541879| NaN| null|
| 2| -0.188706224212385| NaN| 1.0767269459046163|
| 3| 1.71061721050011| NaN|0.060822882948800006|
| 4| 1.93985712722581| NaN| 0.4092836048203674|
| 5| 2.36320221243084| 0.4640194743419549| 0.4640194743419549|
| 6| 1.72644937319218| 0.4729645045462295| 0.4729645045462295|
| 7| 3.29871227845221|0.44828961967398656| 0.4482896196739862|
| 8| 4.31793822807643| 0.2962782381870575| 0.29627823818705823|
| 9| 4.00691449276564| 0.569167226772261| 0.5691672267722595|
4 ответа
Проблема здесь - то, что VB вызывает основного конструктора прежде, чем установить ее значение поля. Таким образом, основной класс Плеера хранит нуль.
.method public specialname rtspecialname
instance void .ctor() cil managed
{
// Code size 15 (0xf)
.maxstack 8
IL_0000: ldarg.0
IL_0001: call instance void [base]Player::.ctor()
IL_0006: ldarg.0
IL_0007: ldc.i4.s 100
IL_0009: stfld int32 B::desiredPower
IL_000e: ret
} // end of method B::.ctor
Продвижение моих комментариев к ответу:
Я:
Попытайтесь писать каждое "питание" в консоль также
Шутник:
C#: 100 VB.NET: 0
Я:
Поскольку я подозревал. Похож на VB.Net, вызывает Основного конструктора перед наследованным конструктором, и поэтому desiredPower переменная VB все еще 0, тогда как C# делает это наоборот (помните, литеральная инициализация происходит в конце конструктора).
Обновление:
Я хотел найти некоторую документацию относительно поведения (иначе, Вы смотрите на поведение, которое могло бы измениться из-под Вас с любым новым выпуском .NET). Из ссылки:
Конструктор производного класса неявно вызывает конструктора для базового класса
и
Объекты базового класса всегда создаются перед любым классом получения. Таким образом конструктор для базового класса выполняется перед конструктором производного класса.
Это находится на той же странице и, казалось бы, было бы взаимоисключающим, но я беру ее, чтобы означать, что конструктор производного класса вызывается сначала, но она, как предполагается, сама вызывает основного конструктора прежде, чем сделать любую другую работу. Поэтому это не порядок конструктора, настолько важный, но способ, которым инициализируются литералы.
Я также нашел эту ссылку, которая ясно говорит, что порядок является полученными полями экземпляра, затем основной конструктор, затем конструктор порожденного класса.
К тому времени, когда конструктор на B завершается, у обоих плееров будет теоретическое значение 100 в их членах парламента, не занимающих официального поста.
Однако из-за превосходящих внутренностей C#, CLI обычно считает целые числа и другие примитивные значения значений скомпилированными с того языка для верхнего уровня, и те, которые из VB.NET для минимума, даже когда они содержат те же биты.
Это происходит потому, что C # сначала инициализирует поля класса, а затем вызывает базовые конструкторы. VB вместо этого делает противоположное, поэтому, когда в VB вы присваиваете свое значение Power, частное поле еще не инициализировано и его значение равно 0.