UWB измерения подчиняются нормальному распределению. Если Вас этот результат устраивает, что UWB Вам подойдет.
Не подчиняются. Даже на глаз видно, что распределение несимметричное. Впрочем, центральную предельную теорему никто не отменял, поэтому со средним и соответствующими асимптотическими доверительными интервалами все неплохо.
Подразумевать можно все, что угодно. Весь вопрос в том, можем ли мы предъявить вероятность нашей ошибки (и ошибочных выводов) при подобного рода заблуждениях. Если можем, то все хорошо, если нет… то вылезают всевозможного рода эффекты.
t-критерий как раз очень сильно «неробастен». При маленьких объемах выборки и толстых хвостах / несимметричных распределениях распределение нулевой гипотезы может очень сильно отличаться от распределения Стьюдента. Ну и говорить о «робастности» применительно к критерию с простой гипотезой как-то вообще странно. Он был бы «робастным», если бы сохранял вероятность ошибки первого рода при отклонении распределения от нормального. А это не так. Применения на практике обычно обосновываются тем, что «ну давайте получим доверительные интервалы пошире», естественно сильно проигрывая в мощности за счет занижения вероятности ошибки первого рода критерия.
Все начинает быть не так грустно, когда объем выборки становится сколько-нибудь нетривиальным (say, n > 50), и тогда в силу ЦПТ критерий становится асимптотическим (возможно, именно это Анатолий и имел в виду под неизвестным мне «z-распределением» выше, которое там на самом деле стандартное нормально).
И как бы на самом деле нас не интересует распределение роста. Нас интересует гипотеза относительно значения среднего. Зачем нам тогда точный критерий с дополнительными (сильными) предположениями? Может быть лучше рассмотреть выборку побольше, взять асимптотический критерий и получить то, что надо. Если же у нас только 10 человек, то надо правильно выбирать инструмент — можно, например, попробовать непараметрические тесты (правда, тогда гипотеза будет о медиане) или же воспользоваться перестановочным критерием и вычислить распределение статистики критерия явно.
И, кстати, ровно поэтому формула (\bar(x) — \mu) / sd / \sqrt(n) выше не верна. Т.к. нам нужно или же чтобы тут было не обычное стандартное отклонение, а корень из несмещенной оценки дисперсии («подправленное стандартное отклонение»), или же sqrt(n-1).
Никакой «магии» в степенях свободы нет, и никакого физического смысла это название не несет. Просто такое название, ага.
Ну и использовать t-критерий для проверки гипотезы о росте нельзя, т.к. ключевое предположение t-критерия о том, что у нас выборка из нормального распределения, не выполняется. Поэтому вероятность ошибки первого рода такого критерия будет отличаться от заданного уровня значимости, мощность будет непонятно какой, а полученным p-значениями верить нельзя. Разница будет особенно заметна на малых объемах выборки, ага.
Это верно только для выборки из нормального распределения. И если у нас выборка из нормального распределения, то можно показать, что выборочное среднее и выборочная дисперсия будут независимыми, а выборочная дисперсия будет иметь \chi^2 распределение с n-1 степенью свободы.
Насколько я знаю, никто сейчас не работает и не собирается. Что касается «патчей со стороны», то такого понятия нет :) Any patches are more than welcome. Некоторое количество полезной информации есть вот тут: llvm.org/docs/DeveloperPolicy.html#making-and-submitting-a-patch
Собственно, да. Cross-language взаимодействие — это одна из немногих причин, почему все реализовано именно так, а не иначе. Исключения в разных языках разный, и тут нужен был некоторый «общий знаменатель».
В бекенде (по сравнению с middle-end'ом) больших оптимизаций почти нет. Если кому-то интересны детали реализации sjlj в LLVM, то цепочка следующая (только для arm/darwin, sjlj больше нет нигде):
1. Интринсик превращается в SelectionDAG node EH_SJLJ_SETJMP (общий код в target independent backend)
2. Дальше, EH_SJLJ_SETJMP превращается в ARM-specific EH_SJLJ_SETJMP node'у (код в ARM backend'е)
3. Ну а эта node'а превращается в псевдо-инструкцию, которая раскрывается в большой код, который одновременно сохраняет все регистры в буфер определенного формата и еще выводит кучу другого кода.
Штука вся в том, что обычно это происходит до назначения регистров. Это нужно как раз из-за того, что код сохранения может быть достаточно нетривиален и вызвать пару-тройку spill'ов, вообщем, вообще говоря, изменить аллокацию регистров. И если делать все после, то было бы очень неприятно «патчить» уже готовое распределение так, чтобы его не испортить.
В действительности же, компилятор поступает весьма рационально. Он разворачивает setjmp, причем, сохраняет только полезные регистры (уж эта информация у него есть). Автор сомневается, что издержки на setjmp так уж высоки.
В действительности же setjump как правило реализован с помощью большого макроса с inline assembler'ом внутри. И у компилятора почти нет никакой возможности сохранить только полезные регистры. Конечно, компилятор не вызывает setjmp (по крайней мере, ни gcc, ни clang) напрямую. У него есть своя внутренняя реализация, которая по сути аналогична вызовам setjmp / longjmp. Правда в том, что «раскрутка» этих внутренних реализаций в реальный код осуществляется уже в backend'е, где почти нет никаких оптимизации. Так что тут тоже пролет. sjlj исключения очень тяжелы на каких-нибудь SPARC'ах с их огромным регистровым набор (и регистровыми окнами).
Тип исключений — часть platform ABI, т.к. нам, очевидно, нужно уметь ловить внешние исключения. Поэтому там sjlj для arm/darwin (сугубо по историческим причинам) и dw2 везде дальше. Стоит, кстати, отметить, что 32-битные SEH-based (используемые на msvc под win32) исключения запатентованы Borland (http://www.google.com/patents/US5628016), что препятствует реализации их где бы то ни было «за так». Хорошие новости состоят в том, что патент заканчивается в июле этого года :)
Это внутренние «маркетинговые» версии Apple. Которые ничего не имеют общего с версиями с llvm.org. Apple LLVM Compiler != clang / llvm с llvm.org. Apple LLVM Compiler 3.1 — это версия где-то «посредине» LLVM 3.0 и 3.1.
Последний официальный релиз gccxml был в 2004 году, неофициальный (как раз by Roman Yakovenko & co) — в 2007, и разработка не просто «идет не слишком активно», а фактически остановлена.
Что только люди не делают, лишь бы не читать доки. :)
Итак, правильный ответ: в C/C++ значение этого выражения не определено. Например, в C99 об этом сказано в параграфе 6.5:
2 Between the previous and next sequence point an object shall have its stored value
modified at most once by the evaluation of an expression. Furthermore, the prior value
shall be read only to determine the value to be stored.
В переводе на русский это означает, что неопределенными являются все выражения типа (sequence point у оператора присваивания только одна!):
i = ++i + 1;
a[i++] = i;
Соответственно, вы можете получить абсолютно произвольный результат как на разных компиляторах, так и на одном и том же компиляторе с разными ключами оптимизации. :)
Не подчиняются. Даже на глаз видно, что распределение несимметричное. Впрочем, центральную предельную теорему никто не отменял, поэтому со средним и соответствующими асимптотическими доверительными интервалами все неплохо.
t-критерий как раз очень сильно «неробастен». При маленьких объемах выборки и толстых хвостах / несимметричных распределениях распределение нулевой гипотезы может очень сильно отличаться от распределения Стьюдента. Ну и говорить о «робастности» применительно к критерию с простой гипотезой как-то вообще странно. Он был бы «робастным», если бы сохранял вероятность ошибки первого рода при отклонении распределения от нормального. А это не так. Применения на практике обычно обосновываются тем, что «ну давайте получим доверительные интервалы пошире», естественно сильно проигрывая в мощности за счет занижения вероятности ошибки первого рода критерия.
Все начинает быть не так грустно, когда объем выборки становится сколько-нибудь нетривиальным (say, n > 50), и тогда в силу ЦПТ критерий становится асимптотическим (возможно, именно это Анатолий и имел в виду под неизвестным мне «z-распределением» выше, которое там на самом деле стандартное нормально).
И как бы на самом деле нас не интересует распределение роста. Нас интересует гипотеза относительно значения среднего. Зачем нам тогда точный критерий с дополнительными (сильными) предположениями? Может быть лучше рассмотреть выборку побольше, взять асимптотический критерий и получить то, что надо. Если же у нас только 10 человек, то надо правильно выбирать инструмент — можно, например, попробовать непараметрические тесты (правда, тогда гипотеза будет о медиане) или же воспользоваться перестановочным критерием и вычислить распределение статистики критерия явно.
Ну и использовать t-критерий для проверки гипотезы о росте нельзя, т.к. ключевое предположение t-критерия о том, что у нас выборка из нормального распределения, не выполняется. Поэтому вероятность ошибки первого рода такого критерия будет отличаться от заданного уровня значимости, мощность будет непонятно какой, а полученным p-значениями верить нельзя. Разница будет особенно заметна на малых объемах выборки, ага.
В бекенде (по сравнению с middle-end'ом) больших оптимизаций почти нет. Если кому-то интересны детали реализации sjlj в LLVM, то цепочка следующая (только для arm/darwin, sjlj больше нет нигде):
1. Интринсик превращается в SelectionDAG node EH_SJLJ_SETJMP (общий код в target independent backend)
2. Дальше, EH_SJLJ_SETJMP превращается в ARM-specific EH_SJLJ_SETJMP node'у (код в ARM backend'е)
3. Ну а эта node'а превращается в псевдо-инструкцию, которая раскрывается в большой код, который одновременно сохраняет все регистры в буфер определенного формата и еще выводит кучу другого кода.
wearing my llvm developer hat off
В действительности же setjump как правило реализован с помощью большого макроса с inline assembler'ом внутри. И у компилятора почти нет никакой возможности сохранить только полезные регистры. Конечно, компилятор не вызывает setjmp (по крайней мере, ни gcc, ни clang) напрямую. У него есть своя внутренняя реализация, которая по сути аналогична вызовам setjmp / longjmp. Правда в том, что «раскрутка» этих внутренних реализаций в реальный код осуществляется уже в backend'е, где почти нет никаких оптимизации. Так что тут тоже пролет. sjlj исключения очень тяжелы на каких-нибудь SPARC'ах с их огромным регистровым набор (и регистровыми окнами).
Вы не пробовали посмотреть в сторону clang'а? Кстати, это ровно то, что рекомендует автор gccxml: www.gccxml.org/pipermail/gccxml/2012-February/001485.html :)
Кроме того, откуда был взят LLVM IR? Написан руками? Или за основу был взять вывод, скажем, llvm-gcc -S -O3 -emit-llvm?
Человека, занявшего 4 место, зовут Виталий Вальтман, и он студент не мехмата МГУ, а матмеха СПбГУ.
Итак, правильный ответ: в C/C++ значение этого выражения не определено. Например, в C99 об этом сказано в параграфе 6.5:
2 Between the previous and next sequence point an object shall have its stored value
modified at most once by the evaluation of an expression. Furthermore, the prior value
shall be read only to determine the value to be stored.
В переводе на русский это означает, что неопределенными являются все выражения типа (sequence point у оператора присваивания только одна!):
i = ++i + 1;
a[i++] = i;
Соответственно, вы можете получить абсолютно произвольный результат как на разных компиляторах, так и на одном и том же компиляторе с разными ключами оптимизации. :)