7335 replies to this topic

[Ugo Fantozzi]

Как?
___________
Сильно не паря мозг и аппетит, обнаружил, что ответы на убывание идут, поэтому 6)))

[Kraftwerk]

Как?
___________
Сильно не паря мозг и аппетит, обнаружил, что ответы на убывание идут, поэтому 6)))

11 в двоичной будет 3  но... там по 0.5... можно говорить  про итог - 1.5

Edited by Kraftwerk, 24 September 2021 - 09:07.

[gawab]

Как?
___________
Сильно не паря мозг и аппетит, обнаружил, что ответы на убывание идут, поэтому 6)))

Как сейчас выражаются в инете - "Эта-пять!" 

   

[gawab]

Отвлекитесь от будничных забот на минутку.

 

[Kraftwerk]

042

[Ieroglif]

Найдите Ж, если одинаковые цифры равны одинаковым буквам:

 

ПЧЁЛКА*7 = ЖЖЖЖЖЖ

[gawab]

Найдите Ж, если одинаковые цифры равны одинаковым буквам:

 

ПЧЁЛКА*7 = Ж Ж Ж Ж Ж Ж

Ну, сразу на поверхности лежит неправильный ответ: Ж = 7, однако это приводит к тому, что п=ч=ё=л=к=а=1, то есть, 111111*7=777777, не айс!

пчёлка*7 = ж*111111

пчёлка = ж*(111111/7)=ж*15873, ну, а дальше - "метод тыка", это уже не интересно, подставляем разные ж, хотя...

 

При ж=5 Пчёлка получится 79365, можно, конечно, натянуть сову на глобус, посчитав П=0, но возникает противоречие, что Ж=А, то есть, скажем так, жопа...

При Ж=6 Пчёлка получится 95238, если принять, что П=0, - вполне себе правильный ответ 095238 (в условии задачи ничего не сказано о том, что буква не может означать ноль, и что в многоцифренном числе не может быть ведущих нулей)!

Ж=7 мы уже проверили выше,

Ж=8  Пчёлка получится 126984, но в этом случае К=Ж, совсем нехорошо.

Ж=9 ПЧЁЛКА = 142857 - вполне подходящий результат.

А теперь - поехали вниз от 5, в предположении, что П= 0:

Ж=4 ПЧЁЛКА = 063492 - увы, тут Ж=Л.

Ж=3 ПЧЁЛКА = 047619 - Подходит!

Ж=2 ПЧЁЛКА = 031746 - Гыыыыы!

Ж=1 ПЧЁЛКА = 015873 увы, Ж=Ч...

 

Итого Ж может быть 2, 3, 6, 9! Ну, конечно, если отсутствует условие об отсутствии ведущих нулей     

[Kraftwerk]

142857*7=999999

 

гаваб, там слегка по другому перебирать надо, тогда практически сразу отсеивается все, что ниже 8, ну и так далее уже просто делением этого числа жжжжжж (8 или 9) на 7.

8 не прокатывает, значит - 9

Edited by Kraftwerk, 26 October 2021 - 19:56.

[gawab]

142857*7=999999

 

гаваб, там слегка по другому перебирать надо, тогда практически сразу отсеивается все, что ниже 8, ну и так далее уже просто делением этого числа жжжжжж (8 или 9) на 7.

8 не прокатывает, значит - 9

Уболтал! Но почему ты в своих рассуждениях опускаешь вариант, что П=0? В условиях об этом ограничении нет ни слова!

 

Так что 095238*7 = 666666;

047619*7 = 333333;

031746*7 = 222222!

   

 

ПыСы: Наш Иероглиф все время укоряет всех, что не обращают внимания на детали.

 

ПыПыСы: Ташта... исходя из неконкретных условий получаем не менее неконкретный ответ.     

 

Самое интересное, что сегодня разгребал очень интересный глюк в одной из своих систем, примерно на эту же тему - а глюк такой, начиная с 10 числа каждого месяца и до конца месяца глюков нет, а с первого числа и до 23:59 - глюк есть! Вопрос - почему? Если есть идеи - пишите, хотя вопрос мы уже решили.

Edited by gawab, 26 October 2021 - 22:02.

[Ieroglif]

Правильно. Даже те, кто выкладывает эту задачу с решением часто забывает про ноль...

 

Погрешу на то, что день месяца определяется одним символом или идет какое-то деление на число десятков...

[gawab]

Погрешу на то, что день месяца определяется одним символом или идет какое-то деление на число десятков...

Ну, скажем так, мысль в абсолютно правильном направлении.

 

Давайте не будем считать это угадайкой, тут меряться ничем особо не надо, это реальный случай...

 

Еще даю маленькую вводную, ну, чтобы еще на подумать, кому не лень - моя система берет ряд данных из внешних формально одинаковых по структуре БД нескольких, скажем так, удаленных объектов, в том числе, дату-время неких событий. Так вот, с данными с одних объектов такие глюки не случаются вообще, а с данными других - да, причем глюки до 10 числа происходили не круглосуточно, а совершенно странным образом, на первый взгляд, бессистемно.

 

Ну и вторая вводная: в БД, из которых моя система берет данные, из-за настроек этих локальных БД выдает информация о дате-времени хранится одним параметром, не отделяя дату от времени, ну, примерно вот так: 

2021-11-1112:04:56, то есть, год-месяц-деньчас:минута:секунда

 

Теперь есть идеи, что произошло? И чем отличались локальные настройки БД глючных объектов от локальных БД нормальных? Ну и уж совсем коварный вопрос - в какое время глючных дней возникали глюки?

 

Если идей до конца сегодняшнего дня не будет - завтра (28 октября) расскажу причину, тем более, что сегодня будем ее устранять с утра в Самаре удаленно.

[Kraftwerk]

Правильно. Даже те, кто выкладывает эту задачу с решением часто забывает про ноль...

 

Погрешу на то, что день месяца определяется одним символом или идет какое-то деление на число десятков...

Ведущий ноль не участвует в нормальных арифметических расчетах.... Ну так то...

[Kraftwerk]

Уболтал! Но почему ты в своих рассуждениях опускаешь вариант, что П=0? 

Не спорю, не говориться, но.... Говорим про ЧИСЛА, а не пароли из чисел (символьная информация), не базы данных с ячейками формата с ведущими нулями. Разговор шел про числа и... арифметические телодвижения с оными, а именно - умножение

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

Edited by Kraftwerk, 27 October 2021 - 17:47.

[Kraftwerk]

....

 

Самое интересное, что сегодня разгребал очень интересный глюк в одной из своих систем, примерно на эту же тему - а глюк такой, начиная с 10 числа каждого месяца и до конца месяца глюков нет, а с первого числа и до 23:59 - глюк есть! Вопрос - почему? Если есть идеи - пишите, хотя вопрос мы уже решили.

Дата (дата, время) может забиваться в базу (или...) НЕ в общепринятом формате, а именно числом (десятичным). Даже в экселе есть функции работы с временными и датными форматами туда-обратно в десятичное. Иногда нужно такое (даже мне, помню, нужно было такое на SQL, давно было, не помню, конкретно зачем). Соответственно, при переводе в десятичное и обратно той же даты 12.2.2021 и 12.02.2021 - будут разные результаты.....

 

Предположение полнейшего дилетанта

Edited by Kraftwerk, 27 October 2021 - 18:01.

[Ieroglif]

Ведущий ноль не участвует в нормальных арифметических расчетах.... Ну так то...

Эх, тЭоретик! В природе вряд ли существует хотя бы одна система с "нормальными арифметическими расчетами". Везде надо проверять формат данных, и прочая, и прочая.

 

Пробуй для интереса запустить в SQL запрос со временем, вида: "11:001:12". Результат будет совсем с ненормальным расчетом.

[Kraftwerk]

Эх, тЭоретик! В природе вряд ли существует хотя бы одна система с "нормальными арифметическими расчетами". Везде надо проверять формат данных, и прочая, и прочая.

 

Пробуй для интереса запустить в SQL запрос со временем, вида: "11:001:12". Результат будет совсем с ненормальным расчетом.

...тут как бы, тебе делать не хрен в офисе (или на удаленке), "запускай", "интересуйся", "проверяй форматы" ..... Практик ты наш эскуэльный

Мне это неинтересно уже лет 10-15:)

 

PS если ты еще не разучился читать, проверяя форматы, то должен был заметить, что я  именно предположил про скл и датные-временные форматы (в том числе в десятичной форме)... И разные выходы от разного представления... Ты чем то недоволен? Говоря то же самое от своего имени? Ну так это твои проблемы.... Мне так же неинтересные от слова "совсем"

Edited by Kraftwerk, 28 October 2021 - 14:07.

[gawab]

Не ссорьтесь!

 

В итоге данный конкретный глюк (не в моей системе, а в той, данные из БД которой мы берем) получился из-за того, что в смежной производственной системе одного из объектов, контролируемых моей системой (а таких объектов 8, и глюк наблюдался только на одном!) оказались чуточку другие региональные настройки, причем не в винде, а в MS SQL, в общем, из-за того, что не был указан разделитель даты-времени при односимвольном дне или односимвольном часе могли получаться 25 и более часов, потому и выходил глюк. Исправили, введя дополнительный входной контроль данных. Попутно был выявлен забавный факт, что записываемые в БД значения даты-времени начала процесса и даты-времени конца процесса формировались в системе вызовом двух разных функций, формат результата которых - тоже разный!

 

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

[gawab]

- Что одновременно мужского, женского  и среднего рода?
- Музей-усадьба Коломенское!

 

Шютка!

[gawab]

Юные арифметики! Звездочка к звездочке, косточки в ряд!

 

А сколько было в отряде уток?

Attached Files

•  Ducks.jpg   62.42KB   0 downloads

Edited by gawab, 15 January 2022 - 11:48.

[Kraftwerk]

15 вроде...  не считая одной, нарисованной на крыле и "написанных" (одна в вопросе и одна в названии файла-картинки)

Edited by Kraftwerk, 15 January 2022 - 19:36.

[Ieroglif]

16 + слова.