SQL-сервер 2008 - Различие между типами сопоставления
Есть некоторые проблемы с вашим подходом.
Для начала вам, конечно, не нужно добавлять данные вручную один за другим в вашей тренировке & amp; проверочные списки (т. е. ваши 2 внутренних цикла for); простая индексация сделает эту работу.
Кроме того, мы обычно никогда не вычисляем & amp; сообщить об ошибке тренировочных сгибов резюме - только ошибка на проверочных сгибах.
Имея это в виду и переключая терминологию на «валидация» вместо «тест», вот простой воспроизводимый пример с использованием данных Бостона, который должен быть простым для адаптации к вашему случаю:
from sklearn.model_selection import KFold
from sklearn.datasets import load_boston
from sklearn.metrics import mean_absolute_error
from sklearn.tree import DecisionTreeRegressor
X, y = load_boston(return_X_y=True)
n_splits = 5
kf = KFold(n_splits=n_splits, shuffle=True)
model = DecisionTreeRegressor(criterion='mae')
cv_mae = []
for train_index, val_index in kf.split(X):
model.fit(X[train_index], y[train_index])
pred = model.predict(X[val_index])
err = mean_absolute_error(y[val_index], pred)
cv_mae.append(err)
[ 1118], после чего ваш cv_mae должен выглядеть примерно так (детали будут отличаться из-за случайного характера резюме):
[3.5294117647058827,
3.3039603960396042,
3.5306930693069307,
2.6910891089108913,
3.0663366336633664]
Конечно, все эти явные вещи не нужны; Вы можете сделать работу намного проще с cross_val_score . Однако есть небольшой улов:
from sklearn.model_selection import cross_val_score
cv_mae2 =cross_val_score(model, X, y, cv=n_splits, scoring="neg_mean_absolute_error")
cv_mae2
# result
array([-2.94019608, -3.71980198, -4.92673267, -4.5990099 , -4.22574257])
Помимо отрицательного знака, который на самом деле не является проблемой, вы заметите, что дисперсия результатов выглядит значительно выше по сравнению с нашими cv_mae выше; и причина в том, что мы не перемешали наши данные. К сожалению, cross_val_score не предоставляет возможность тасования, поэтому мы должны сделать это вручную, используя shuffle. Таким образом, наш окончательный код должен быть:
from sklearn.model_selection import cross_val_score
from sklearn.utils import shuffle
X_s, y_s =shuffle(X, y)
cv_mae3 =cross_val_score(model, X_s, y_s, cv=n_splits, scoring="neg_mean_absolute_error")
cv_mae3
# result:
array([-3.24117647, -3.57029703, -3.10891089, -3.45940594, -2.78316832])
, который значительно меньше дисперсии между сгибами и намного ближе к нашему начальному cv_mae ...
7 ответов
Эти _100 указывают на сортирующую последовательность, новую в SQL Server 2008, те, которые имеют _90, на 2005 и _100 без суффикса, 2000. Я не знаю то, что различия и не могут найти документацию. Если Вы не делаете запросы связанного сервера к другому SQL-серверу другой версии, я испытал бы желание пойти с _100 один. Извините я не могу помочь с различиями.
Рассматривать вопрос 3 (информация, снятая MSDN; формулируя их, шахту формата):
Двоичный файл (_BIN):
- Виды и сравнивают данные в таблицах SQL Server на основе комбинаций двоичных разрядов, определенных для каждого символа.
- Двоичный порядок сортировки чувствителен к регистру и чувствителен к диакритическим знакам.
- Двоичный файл является также самым быстрым порядком сортировки.
- Если эта опция не выбрана, SQL Server следует за сортировкой и правилами сравнения, как определено в словарях для связанного языка или алфавита.
Точка двоичного кода (_BIN2):
- Для данных Unicode: Виды и сравнивают данные в таблицах SQL Server на основе кодовых точек Unicode.
- Для данных не-Unicode: будет использовать сравнения, идентичные двоичным видам.
Преимущество использования Двоичного кода указывает, что порядок сортировки - то, что никакие данные, обращающиеся, не требуются в приложениях, которые сравнивают отсортированные данные SQL Server. В результате порядок сортировки точки Двоичного кода обеспечивает более простую разработку приложений и возможные увеличения производительности.
Для получения дополнительной информации см. Инструкции для Использования МУСОРНОГО ВЕДРА и Сопоставлений BIN2.
Адресовать Ваш вопрос 1. Чувствительный к диакритическим знакам хорошая вещь включить для финско-шведского. Иначе Ваш "å" s и "ä" s будут отсортированы как "a" s и "ö" s как "o" s. (Принятие Вас будет использовать подобные международные символы).
Больше здесь: http://msdn.microsoft.com/en-us/library/ms143515.aspx (обсуждает и двоичную кодовую точку и чувствительность диакритического знака),
Обратиться к qestion 2:
Да, если диакритический знак требуется grammer для данного языка.
По вопросам 2 и 3
Чувствительность диакритического знака - что-то, что я предложил бы выключить, если Вы принимаете пользовательские данные, и НА ТОМ, если у Вас есть чистые, санированные данные. Не будучи финном самостоятельно, я не знаю, сколько там слова, это отличается в зависимости от ó ô õ или ö, который они имеют в них. Но если существуют пользователи, вводящие данные, можно быть уверены, что они НЕ будут последовательны в своем использовании, и Вы хотите смочь соответствовать им. При сборе данных из набора данных, из которого Вы знаете содержание и знаете непротиворечивость, то Вы захотите включить Чувствительность Диакритического знака, потому что Вы знаете, что различия целеустремленны.
Те же вопросы применяются при рассмотрении Вопроса 3. (Я главным образом получаю это из ссылки обеспеченный Tomalak), Если данные являются случаем и чувствительный к диакритическим знакам, то Вы хотите _BIN, потому что это отсортирует быстрее. Если данные будут неправильны, и не случай / чувствительны к диакритическим знакам, то Вы захотите _BIN2, потому что это разработано для данных Unicode.
Буквы ÅÄÖ / åäö не смешиваются с A и O, просто установив параметры сортировки на AI (без акцента). Однако это верно для â и других «комбинаций», не входящих в шведский алфавит как отдельные буквы. â будет смешиваться или не смешиваться в зависимости от рассматриваемого параметра.
Поскольку у меня есть много старых баз данных, с которыми мне все еще нужно общаться, в том числе с использованием связанных серверов, я выбрал ФИНСКИЙ _SWEDISH _CI _AS теперь, когда устанавливаю SQL2008. Это было настройкой по умолчанию для FINNISH _SWEDISH, когда параметры сортировки Windows впервые появились в SQL Server.
Воспользуйтесь приведенным ниже запросом, чтобы попробовать его самостоятельно.
Как видите, å, ä и т. Д. Не считаются символами с диакритическими знаками и сортируются в соответствии со шведским алфавитом, когда с использованием сопоставления финский / шведский.
Однако акценты учитываются только при использовании сопоставления AS . Для параметров сортировки AI их порядок не изменяется, как будто вообще не было акцента.
CREATE TABLE #Test (
Number int identity,
Value nvarchar(20) NOT NULL
);
GO
INSERT INTO #Test VALUES ('àá');
INSERT INTO #Test VALUES ('áa');
INSERT INTO #Test VALUES ('aa');
INSERT INTO #Test VALUES ('aà');
INSERT INTO #Test VALUES ('áb');
INSERT INTO #Test VALUES ('ab');
-- w is considered an accented version of v
INSERT INTO #Test VALUES ('wa');
INSERT INTO #Test VALUES ('va');
INSERT INTO #Test VALUES ('zz');
INSERT INTO #Test VALUES ('åä');
GO
SELECT Number, Value FROM #Test ORDER BY Value COLLATE Finnish_Swedish_CI_AS;
SELECT Number, Value FROM #Test ORDER BY Value COLLATE Finnish_Swedish_CI_AI;
GO
DROP TABLE #Test;
GO