[CaPpuCcino 0]

посоветуйте, пожалуйста, как можно перевести выражение corner-case

спасибо

[iosifk 3]

посоветуйте, пожалуйста, как можно перевести выражение corner-case

спасибо

То, что Вы делаете статью - это неплохо. Но только учтите, что если Ваши тексты появятся на чьих-то сайтах или в каких либо журналах под другими фамилиями, то Вы в этом случае уже ничего сделать не сможете. Вот такое небольшое предупреждение.

[jb83 0]

corner-case - http://en.wikipedia.org/wiki/Corner_case

что-то типа "критического случая" ?? (т.е. случай, наступающий при возникновении критических условий - по аналогии с гран.условиями и граничным случаем)

Изменено 11 июня, 2010 пользователем jb83

[Maverick_ 15]

к CaPpuCcino

 

Каким Вы видите себя в теме данного топика:

1. Тонким философом.

2. Прожженным практиком.

3. Переводчиком-профессионалом.

4. Кем-то иным, но не этими.

 

Поднятая Вами тема сама по себе очень интересна, но в качестве кого и как Вы ее будете раскрывать?

Смысл данного вопроса? Что Вы хотите узнать, задав такой вопрос?

 

посоветуйте, пожалуйста, как можно перевести выражение corner-case

спасибо

перевод может быть

крайний случай

или

угловой случай

[andrew_b 16]

угловой случай

По-русски так не говорят.

[lexus.mephi 0]

посоветуйте, пожалуйста, как можно перевести выражение corner-case

спасибо

Встречал такой перевод: "граничное условие".

[Vadim 0]

посоветуйте, пожалуйста, как можно перевести выражение corner-case

Вырожденный случай. Не?

 

Встречал такой перевод: "граничное условие".

Это скорее подходит для edge case.

[Maverick_ 15]

По-русски так не говорят.

A on-line переводчики от Google и Promt так перевели :)

[jb83 0]

Встречал такой перевод: "граничное условие".

 

 

нее... :unsure:

буржуйская википедия про это специально говорит: "Contrast a corner case with an edge case, an issue that occurs only at a (single) maximum or minimum parameter..."

 

тут что-то более хитрое - а конкретно, одновременное достижение всеми параметрами своих граничных значений

Изменено 11 июня, 2010 пользователем jb83

[andrew_b 16]

A on-line переводчики от Google и Promt так перевели :)

И что? Дословный перевод не значит правильный. Идиомы, например, вообще переводить дословно нельзя.

 

Посмотрите, как Гугл переводит на английский словосочетание "спина человека".

[Des333 0]

ну, а если так попробовать: утверждения (assertions), которые вешаются на внутрисистемный интерфейс - это верификация или отладка?

ведь, утверждения помогают локализовать ошибку, т.е. исправить её

 

И то, и другое.

 

 

в логике которую использую я ответ будет следующим: на каждом уровне абстракции спецификация на систему различна -

если изначально от системы требовалось например обработать картинку таким-то образом за такое-то время - это спецификация уровня функциональной модели. в процессе разработки вы постепенно снижаете уровень абстракции уточняя модель. и например на уровне РТЛ у вас система состоит уже из n блоков, выполняющих каждый свою функцию, соединённых интерфейсами. так вот на уровне РТЛ вы в спецификацию заносите уже требования к протоколам этих интерфейсов и какие-то мат. функции блоков. и в процессе верификации должны проверить, что эти низкоуровневые требования исполняются. но с точки зрения спецификации на уровне функциональности всей системы это будет уже отлов ошибок, а с точки зрения каждого блока - верификация его функциональности.

такие дела

С логикой рассуждения согласен полностью. 

Верификация с точки зрения блока будет одновременно выполнять функции локализации ошибок с точки зрения всей системы, но из этого не следует, что локализация ошибок является частью верификации.

 

Просто одно и тоже действие (как и один и тот же инструмент) могут выполнять разные функции для разный уровней абстракции. Но сами эти функции при этом не пересекаются.

[des00 25]

хрена себе упомянул - там целый раздел про него написан.

да, написан целый раздел, с примером, а пояснения к этому примеру (например объяснение термина динамическая верификация) дается много позднее.

притом формальная методика его выработки полностью оригинальная - я пока более чёткого формализованного подхода в лит-ре не нашёл (если кто знает источник, плз, укажите)

Где то у меня была книга, как составить верификационный план по уму. поискать надо.

можно про с ног на голову поподробней?

Давать материал нужно последовательно, по мере необходимости. А сейчас вы сначала погружаетесь в детали, потом резко от них переходите к основам.

 

голден референс суть то, что у вас есть заранее посчитанный результат, которому все сказали "одобрям". как правило то, что было написато программерами, до идеи воплотить это в железе, хотя может быть и на любой стадии моделирования до верификации.

У вас очень ограниченное понятие эталонной модели. Т.е. под эталонной моделью может пониматься всё что угодно, что используется для однозначной проверки функциональности модуля. И это не обязательно предварительно рассчитанный результат, что ему мешает вычисляться на лету? Т.е. стоит отлаженная идеалка какой либо системы и верифицируемый модуль должен давать точно такой ответ, идеалка в вашей системе терминов это не эталонная модель, тогда как это в корне не так.

 

А scoreboard есть всегда и везде, в любом автоматическом тестбенче, хоть с моделью, хоть без оной. И в нем рано или поздно, будет главный if вида if (pipa != popa) begin err_cnt++; bla bla bla end

тож функциональное покрытие так же может быть описано с помощью процедурных языков

те же яйца, только в профиль. Измерение покрытия используется для определения меры полноты верификации, а через что оно будет реализовано дело десятое.

 

ну пока не за что, мож не пригодится никому - вон Денис уже критикует :)

критика она всегда полезна, меня тоже часто критикуют, даже кто-то сжечь на костре собирался %)

 

Я бы зашел все таки не с таких дебрей, с которых идете вы, а последовательно раскрывал бы вопрос: что такое верификация, зачем нужна, ее цели, виды, возможные результаты (знаменитый квадрат результатов верификации) и т.д. и т.п. и только потом уже стал углубляться в детали этой темы

[ViKo 1]

corner case - неловкое положение, затруднение. Надо по контексту смотреть.

 

Верификация - когда я что-то записал в память, потом прочитал, сравнил и убедился, что записанное верно.

"Хитрый" тест - когда я в память записал нечто специальное, "бегающую единицу", например, потом прочитал, сравнил, и убедился, что память работает.

Примерно так понимаю я, на истину не претендую.

 

для des00

Кто-то обещал описать свою "битву" с Aprox в своем блоге, во всех подробностях, по-шагам...

[des00 25]

Кто-то обещал описать свою "битву" с Aprox в своем блоге, во всех подробностях, по-шагам...

да помню, даже заготовку в блоге сделал, но времени на всё не хватает %(

[CaPpuCcino 0]

критика она всегда полезна, меня тоже часто критикуют, даже кто-то сжечь на костре собирался %)

конечно полезна, о ней я и просил. в спорах рождается истина(правда у каждого спорящего своя как правило :) )

даже если я не согласен идеалогически с постулатами выдвигаемыми критикуемым, это даёт мне знание того, что в своих рассуждениях я должен быть более основателен и тщательнее подойти к обсуждению данного вопроса о статье

а последовательно раскрывал бы вопрос: что такое верификация, зачем нужна, ее цели, виды, возможные результаты (знаменитый квадрат результатов верификации) и т.д. и т.п. и только потом уже стал углубляться в детали этой темы

оно от части так и есть - там есть введение, которое я надеюсь расставит более-менее на места.

однако вот видите какая штука - вы когда про квадрат говорите, я знаю о каком квадрате идёт речь, и вы естественно тоже. и мы знаем где на него можно полюбоваться. будет ли людям которые также знают о его существовании прочитать о нём ещё раз в статье? мне было бы не интересно такую статью читать(хотя конечно можно сказать, что повторение мать учения, но мне что-то репетиторством заниматься скучно). цель материала я вижу в том, чтобы привнести какое-то новое видение проблемы, чтоб было над чем поразмыслить, пусть даже читатель не будет с чем-то согласен (главное, чтоб откровенную пургу не писать - для этого, кстати, и нужна критика)

 

Давать материал нужно последовательно, по мере необходимости. А сейчас вы сначала погружаетесь в детали, потом резко от них переходите к основам.

я учту

У вас очень ограниченное понятие эталонной модели. Т.е. под эталонной моделью может пониматься всё что угодно, что используется для однозначной проверки функциональности модуля. И это не обязательно предварительно рассчитанный результат, что ему мешает вычисляться на лету? Т.е. стоит отлаженная идеалка какой либо системы и верифицируемый модуль должен давать точно такой ответ, идеалка в вашей системе терминов это не эталонная модель, тогда как это в корне не так.

 

А scoreboard есть всегда и везде, в любом автоматическом тестбенче, хоть с моделью, хоть без оной. И в нем рано или поздно, будет главный if вида if (pipa != popa) begin err_cnt++; bla bla bla end

а у вас слишком широкое, чё делать будем? :) и я как раз утверждаю что это обязательно предварительно рассчитанный результат и по этому критерию и делю 2 типа проверок (одна до рантайма вычисляет правильный ответ, а другая во время - это как раз прямо в материале и указано)

а то что в любой модели есть (на практике!) scorboarding это тоже верно, но только это просто гибридные модели, которые повышают наблюдаемость проекта и локализацию ошибок, однако существуют тесты, которые чисто основаны на предвычесленными результатами - пример пожалуйста: когда вы уже отладили какой-то кодек и хотите посмотреть его на предмет качества для картинок разной природы, вы отключаете все внутренние тесты для экономии машинного вр.(получаете полный блек-бокс), и гоняете через него набор картинок, а потом глазками сравниваете качество с эталонными (если у вас нет какой-нить метрики для автоматизации. это всё называется экспертная оценка.) при обнаружение симптомов сбоя., вы снова вкл. все внутренние чекеры и отлавливаете баг, но это только в случае обнаружения.

те же яйца, только в профиль. Измерение покрытия используется для определения меры полноты верификации, а через что оно будет реализовано дело десятое.

4. "Таким образом динамическая верификация строится на трёх основных понятиях: стимул, отклик и покрытие." Последнее это больше предмет assertion based верификации.

вот и я про что, поэтому относить coverage это к assertion based verification как вы (на сколько я понял предложили в предыдущем посте) я не стану

 

Просто одно и тоже действие (как и один и тот же инструмент) могут выполнять разные функции для разный уровней абстракции.

ну вот я их и объединил - потому как это двуликий Янус. не писать же мне ещё один раздел по отладке :) тем более, что я считаю их всё-таки одним процессом(сл. большая степень интеграции одного в др.)

 

Вырожденный случай. Не?

мне этот вариант больше всего нр.

спасибо

 

То, что Вы делаете статью - это неплохо. Но только учтите, что если Ваши тексты появятся на чьих-то сайтах или в каких либо журналах под другими фамилиями, то Вы в этом случае уже ничего сделать не сможете. Вот такое небольшое предупреждение.

спасибо за предупреждение. однако на англ. языке материал уже зарегистрирован и находится в печати. ну а если кому-то захочется выдать дословную публикацию отсюда, не за вольный перевод моей статьи, а за собственные мысли, то пожалуйста, я же с этого в любом случае ничего не имею. так можно и за посты на форуме деньги брать или боятся что их кто-нибудь перепечатает(кстати и такое уже случалось) :)

главное чтоб совесть не мучила, ну, и боязнь возможного судебного преследования. а то вдруг я обижусь. :)