M>1. парсер , токенайзер , обработка ошибок входных данных.
Парсер и токенайзер в даном случае избыточны — одна строка представляет собой один элемент — "токен", а парсинг отдельной строки задача тривиально решаемая либо strtok и аналогами, либо применением простейшей либы регулярных выражений.
M>2. для каждой единицы измерения заводим объект. M>3. для каждой связи между единицами измерения заводим связь, предлагаю adjustency list.
Google на adjustency выдает ровно один документ, я про такие личты не слышал. Слово какое-то корявое и термин тоже.
M>4. для каждой единицы измерения заводим ее пересчет для неких слонов , но слоны общме для всех , например 1 секунда это 1 секунда , 1 минута это 60 секунд , 1 час это 3600 секунд и т.д. Тут слоны равны секундам.
Логичное и простое решение, вероятно наилучшее из всех предложенных.
M>5. Поиском в ширину проходим по получившемуся графу и расчитываем наших слонов.
Да тут граф избыточен — переводим единицу1 в слонов, слонов в единицу2, можно конечно назвать это "графом"
M>Алгоритм выполняется за линейное время.
Согласен, красивое и простое решение. Задачка правда, несколько исскуственная
Здравствуйте, alzt, Вы писали:
A>На мой взгляд — не хорошо отмалчиваться, словно письма не получили.
Абсолютно согласен.
Кстати — я тут недавно поднимал в одной теме вопрос об обязательных ответах кандидату. К ужасу своему выяснил что практически всех устраивает ситуация когда работодатель не пишет ответ при принятии отрицательного решения. Мне лично всегда кажется в этих случаях что ко мне просто проявили неуважение. И работать к этому работодателю я уж точно в будущем не пойду — даже если он сам сделает достаточно распологающее предложение.
A>Никто не требует ответа с детальным пояснением всех ошибок, достаточно сухого "в настоящий момент эта должность уже занята.".
Вот хотя бы так! А то это молчание — оно тяготит очень. А если человек ищет работу что называется аврально и у него элементарно денег нет — то такое молчание вообще убийственно.
Здравствуйте, De-Bill, Вы писали:
AZ>>Google на adjustency выдает ровно один документ, я про такие личты не слышал. Слово какое-то корявое и термин тоже.
DB>Попробуй adjacency.
Здравствуйте, AntZ, Вы писали:
M>>1. парсер , токенайзер , обработка ошибок входных данных. AZ>Парсер и токенайзер в даном случае избыточны — одна строка представляет собой один элемент — "токен", а парсинг отдельной строки задача тривиально решаемая либо strtok и аналогами, либо применением простейшей либы регулярных выражений.
Имелось ввиду, вынести это отдельным блоком, а не писать свои токенайзеры и парсеры. Хотя если есть готовые ...
M>>2. для каждой единицы измерения заводим объект. M>>3. для каждой связи между единицами измерения заводим связь, предлагаю adjustency list.
AZ>Google на adjustency выдает ровно один документ, я про такие личты не слышал. Слово какое-то корявое и термин тоже.
Прошк прощения за корявость , конечно "Adjacency list", список связанности. http://en.wikipedia.org/wiki/Adjacency_list
M>>4. для каждой единицы измерения заводим ее пересчет для неких слонов , но слоны общме для всех , например 1 секунда это 1 секунда , 1 минута это 60 секунд , 1 час это 3600 секунд и т.д. Тут слоны равны секундам.
AZ>Логичное и простое решение, вероятно наилучшее из всех предложенных.
M>>5. Поиском в ширину проходим по получившемуся графу и расчитываем наших слонов.
AZ>Да тут граф избыточен — переводим единицу1 в слонов, слонов в единицу2, можно конечно назвать это "графом"
M>>Алгоритм выполняется за линейное время.
AZ>Согласен, красивое и простое решение. Задачка правда, несколько исскуственная
Здравствуйте, minorlogic, Вы писали:
M>1. парсер , токенайзер ,
Из пушки по воробьям.
M> обработка ошибок входных данных.
Там есть. Но, вообще, на вводе-выводе я особо не заморачивался, решив что он играет второстепенную роль.
M>2. для каждой единицы измерения заводим объект.
Заводим.
M>3. для каждой связи между единицами измерения заводим связь, предлагаю adjustency list.
Я все необходимые связи оставил в самом объекте. При этом некоторые объекты могут служить для связи, не являясь единицами измерения, как таковыми. Структура данных разработана так, чтобы свести к минимуму число выделяемых из памяти объектов, поскольку в C++ оператор "new" крайне нерасторопен.
M>4. для каждой единицы измерения заводим ее пересчет для неких слонов , но слоны общме для всех , например 1 секунда это 1 секунда , 1 минута это 60 секунд , 1 час это 3600 секунд и т.д. Тут слоны равны секундам.
У меня для этого есть "base_unit" и "weight". Если у двух единиц одинаковый "base_unit", они конвертируются путём умножения на "weight" результирующей и деления на "weight" исходной единицы.
M>5. Поиском в ширину проходим по получившемуся графу и расчитываем наших слонов.
Я стараюсь, по возможности, расчитать "weight" при вставке. Когда это требует пересчёта весов, связи между единицами помещаются в ориентированный граф (дерево циклических списков). Пересчёт весов осуществляется после добавления всех правил конвертации проходом сверху вниз по дереву. После этого все узлы дерева, кроме самих единиц измерения, могут быть удалены.
M>6. пересчеты единиц друг в друга теперь можно делать опираясь на слонов, например например 1 секунда это 1 секунда , 1 минута это 60 секунд , 1 час это 3600 секунд , тогда
M>Алгоритм выполняется за линейное время.
В общем, всё очень похоже. Я просто купился на фразу в вакансии об обязательном знании real-time оптимизации и, похоже, переборщил.
Здравствуйте, machine3000, Вы писали:
M>В общем, всё очень похоже. Я просто купился на фразу в вакансии об обязательном знании real-time оптимизации и, похоже, переборщил.
Да нет .... просто код нечитабельный , тренируйтесь. Самая лучшая тренировка это peer code review. Давайте свой код читать другим и прислушивайтесь к замечаниям.
Здравствуйте, BackstreetCat, Вы писали:
BC>Ты просто гений
Так это или нет, не имеет никакого практического значения.
BC>не понятый современниками
Само по себе это меня тоже не очень волнует. Однако для достижения своих целей очень часто требуется именно "быть понятым современниками"
BC> так что не теряй духа.
Упущенную выгоду нужно воспринимать как упущенную выгоду. Отсутствие отрицательных эмоций лишает стимула работать над лучшением условий содержания бренного тела, что, в конечном итоге, может привести к его преждевременному разрушению.
To machine3000:
1. is_equal_values реализована неверно. Работа ведётся в ограниченной разрядной сетке, поэтому сравнивать нужно с учётом порядка.
2. В код въехал, но полотна в методах неприемлемы.
3. +1 к вышесказанному.
Расширяема ли схема, предложенная minorlogic, до обработки правил и вопросов перевода следующего типа:
<v1> <u1> = <v2> <u2>
<x> <u1>^n = ? <u2>^n
?
^ — возведение в степень
n — действительное.
x — задано, действительное.
Если расширяема, то как?
Что делать в этом случае с матрицей перевода, предложенной mossy?
Например, требуется переводить квадратные и кубические сантиметры в соотв. метры, для чего достаточно лишь правила
1 м = 100 см.
Как будет обрабатываться вопрос
35 см^2 = ? м^2
?
Здравствуйте, machine3000, Вы писали:
M>здесь
Глобальные функции это вообще жесть.
Ну максимум я бы выносил их в какой-нибудь класс типа *Utils (Например GrafUtils, хотя по-моему все операции с графами можно в этом графе и оставить )
По-моему какое-то сложное решение простой задачи.
Мне кажется задача сводиться к построению дерева, которое задается классом типа:
public class Unit {
private Unit subUnit;
private Integer subUnitCount;
private String name;
public Integer getUnitCount(String unitName) {
if(name.equals(unitName))
return 1;
if(subUnit == null)
throw new IllegalArgumentException();
return subUnitCount * subUnit.getUnitCount(unitName);
}
}
В начальном условии нет определений типа 1 hour = 3600 second , поэтому дерево можно в лоб построить
Здравствуйте, Worad, Вы писали:
W>To machine3000: W>1. is_equal_values реализована неверно. Работа ведётся в ограниченной разрядной сетке, поэтому сравнивать нужно с учётом порядка.
В ЖЖ с учётом сравнивается.
W>Расширяема ли схема, предложенная minorlogic, до обработки правил и вопросов перевода следующего типа: W><v1> <u1> = <v2> <u2> W><x> <u1>^n = ? <u2>^n W>? W>^ — возведение в степень W>n — действительное. W>x — задано, действительное. W>Если расширяема, то как?
W>Что делать в этом случае с матрицей перевода, предложенной mossy?
W>Например, требуется переводить квадратные и кубические сантиметры в соотв. метры, для чего достаточно лишь правила W>1 м = 100 см. W>Как будет обрабатываться вопрос W>35 см^2 = ? м^2 W>?
А что тут вообще меняется, кроме добавления операции возведения в степень? Вот если бы "x1 <u1>^n1 = x2 <u2>^n2"...
ДВ>Глобальные функции это вообще жесть. ДВ>Ну максимум я бы выносил их в какой-нибудь класс типа *Utils (Например GrafUtils, хотя по-моему все операции с графами можно в этом графе и оставить ) ДВ>По-моему какое-то сложное решение простой задачи. ДВ>Мне кажется задача сводиться к построению дерева, которое задается классом типа:
Глобальные функции, если они без статических переменных и с понятными названиями никакой проблемы не составляют. В С++ их можно внести в пространство имен, в чистом С обычно стараются как-то минимизировать кофликты имен обзывая функции типа MylibFunc1, MyLibFunc2
Куда страшнее использование глобальных переменных, особенно когда они маскируются под вызовы функций.
Да код просто перемешан и усложнен — нечитабельный он.
Здравствуйте, minorlogic, Вы писали:
M>4. для каждой единицы измерения заводим ее пересчет для неких слонов , но слоны общме для всех , например 1 секунда это 1 секунда , 1 минута это 60 секунд , 1 час это 3600 секунд и т.д. Тут слоны равны секундам.
В задаче не только время
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, alzt, Вы писали:
П>>P.S. Публиковать решение не всегда хорошо для компании (придется менять задание), но раз уж ты начал... A>Менять задание — это их проблемы.
Врядли прийдется менять задание, не настолько оно сложно. Скорее тут было важно написать хороший код.
A>На мой взгляд — не хорошо отмалчиваться, словно письма не получили. A>Никто не требует ответа с детальным пояснением всех ошибок, достаточно сухого "в настоящий момент эта должность уже занята.".
Может автор поспешил? Народ в компании мог все майские выходные бухать и до его решения еще нее добрались
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, AntZ, Вы писали:
AZ>Глобальные функции, если они без статических переменных и с понятными названиями никакой проблемы не составляют. В С++ их можно внести в пространство имен, в чистом С обычно стараются как-то минимизировать кофликты имен обзывая функции типа MylibFunc1, MyLibFunc2
AZ>Куда страшнее использование глобальных переменных,
Для паттерна "singleton" это самое очевидное решение.
AZ>особенно когда они маскируются под вызовы функций.
На самом деле кроме случаев создания функторов такого не разу не делал. Но тут решил показать, что умею так делать.
AZ>Да код просто перемешан и усложнен — нечитабельный он.
Да, мне очень тяжело писать код для людей. В основном стараюсь для машин подоходчивее.
Здравствуйте, AndrewJD, Вы писали:
AJD>Здравствуйте, minorlogic, Вы писали:
M>>4. для каждой единицы измерения заводим ее пересчет для неких слонов , но слоны общме для всех , например 1 секунда это 1 секунда , 1 минута это 60 секунд , 1 час это 3600 секунд и т.д. Тут слоны равны секундам.
AJD>В задаче не только время
Это не имеет значения. Даже если граф будет не связанным.
Вот действительно задачу усложнит если мы считаем курсы валют. И обмен долара на гривну и гривну на долар не равны. Тогда существует множество решений из которых видимо надо выбирать ...
Здравствуйте, machine3000, Вы писали:
AZ>>Да код просто перемешан и усложнен — нечитабельный он. M>Да, мне очень тяжело писать код для людей. В основном стараюсь для машин подоходчивее.
Для машин можно и в машинных кодах, а для людей это самое тяжелое в программировании. Недаром же самые ценные сотрудники — архитекторы , которые умеют сложные вещи сделать простыми.
Здравствуйте, minorlogic, Вы писали:
M>>Да, мне очень тяжело писать код для людей. В основном стараюсь для машин подоходчивее.
M>Для машин можно и в машинных кодах, а для людей это самое тяжелое в программировании. Недаром же самые ценные сотрудники — архитекторы , которые умеют сложные вещи сделать простыми.
Современные языки программирования находятся на такой стадии, что на них нельзя выразить суть задачи ни оптимальным для человека, ни оптимальным для машины образом. Так или иначе всегда приходится искать некоторый компромисс между этими взаимоисключающими критериями. Хорошо, когда есть хотя бы какой-то "corporate coding style". А то ещё у каждого разработчика могут быть свои предпочтения.
AZ>>Куда страшнее использование глобальных переменных, M>Для паттерна "singleton" это самое очевидное решение.
Вы начитались много умных книг и выучили много умных слов, но поняли все через одно место. Синглтон реализуется через приватный конструктор, соответственно вызывается из статических методов. У синглтона нет экземляров класса — все данные класса — статические, так-же как и методы. Для синглтона нет obj1.method() и obj2.method(). У Вас же name_checker — совсем не синглтон. У класса name_checker (он-же объект check_name) конструктор публичный, проперти не статические — ничто не мешает иметь хоть тысячу объектов этого класса. Это просто класс написаный не головой, а другим местом.
AZ>>особенно когда они маскируются под вызовы функций. M>На самом деле кроме случаев создания функторов такого не разу не делал. Но тут решил показать, что умею так делать.
Я умею писать ***x = *(*(y+0x2376)).DoCalculate(*(___cx++)+24)->I_am_krutoi++;
Вот как я умею делать, при правильных типах это все даже скомпилится и будет что-то делать.
AZ>>Да код просто перемешан и усложнен — нечитабельный он. M>Да, мне очень тяжело писать код для людей. В основном стараюсь для машин подоходчивее.
А я пишу код для людей. Меня больше волнует какие чувства испытает человек, которому придется код сопровождать или изменять, чем компилятор (хотя о компиляторе тоже думаю, правда меньше) которому этот код компилировать
)
