Виктория писал(а):
Мне не совсем понятно назначение тестов в преподавании программирования. Почему бы не использовать лишь задачи на "придумать алгоритм и реализовать его в программе"?
Мы одним словом ("тесты") называем разные вещи.
Вы возмущаетесь тестами типа когда показывают готовый фрагмент кода:
И где спрашивается в вопросе:
- Ах, деточка, попробуй
угадать чему после всего этого станет равно X:
1. 0
2. 3
3. -1
Так меня не менее вашего достали
такие тесты!
Я же говорю о тесте (может его по-другому нужно называть?), когда я говорю:
- Вот есть такой фрагмент (это из архива выше взято):
Код: Выделить всё
void test02( void ) { // "неточность" вещественных данных
printf( "все вещественные типы - это только приближённые данные:\n" );
double rd = 3.14159265358979323846264338327950288419716939937510;
float rf = rd;
#define FMT "%15.12f"
printf( FMT" - "FMT" = "FMT"\n", rd, rf, rd - rf );
#undef FMT
}
- Его результат может оказаться не очевидным ... хотя мы из числа (M_PI <math.h>) вычитаем его же и вправе ожидать 0
:
Код: Выделить всё
olej@notebook:~/2013_WORK/AntonG/examples$ ./type 1
01 ---------------------------------------
все вещественные типы - это только приближённые данные:
3.141592653590 - 3.141592741013 = -0.000000087423
------------------------------------------
- И вопрос состоит не в том, чтобы
угадать результат (что невозможно в принципе), а звучит так: попробуй понять почему так происходит + попытаться сделать отсюда
несколько (как можно больше) выводов, предугадать последствий...
А последствий из этого
простейшего примера можно сделать немало:
- вещественные значения - это всегда только
приближённые представления значений (с некоторой погрешностью);
-
никогда нельзя использовать вещественные значения для управления логикой алгоритма (условиями if, условиями циклов и все др.) - результаты могут быть катастрофическими, такими как бесконечные циклы на ровном месте
- результат вещественных вычислений будет зависеть от
архитектуры (от железа: x86, ARM, ...) на его неизменность нельзя рассчитывать ...
- результат вещественных вычислений может зависеть от компилятора (то, в каком виде он представляет float, double ...), от опций компиляции (-O уровень оптимизации и т.п.)
- хуже того, результат вещественных вычислений может задействовать стандартную библиотеку математических функций (sin(), cos(), ...), и тогда результат вычислений может зависеть даже от
версии одного и того же компилятора...
- в случаях плохой численной определённости выражений даже результаты решения элементарного квадратного уравнения могут "разбегаться"
в разы в зависимости от выбранной точности представления...
И я думаю, что это ещё далеко не все выводы, которые можно сделать, если задуматься над результатом "теста" в 4 строки кода
.