Mrrl

Как-то так stackoverflow.com/questions/15362117/find-as-many-...

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

Я думаю искомая точка будет вычисляться исходя из min(PA, PN, PB), где PA - расстояние от точки P до точки А (начала дуги), PB - расстояние от точки P до точки B (конца дуги), PN - расстояние от точки P до дуги по нормали (перпендикуляра, опущенного из точки P на дугу), если он существует

Для примера если у вас число является маской, и вам нужно сбросить(установить в ноль) только третий бит, то можно применить так ( ~4 & mask )

Можно так:

for(int x = 0; x < 100; x = x + 2)
{
    if(x % 4) cout << x;
}

Или так:

for(int x = 0; x < 100; x = x + 2)
{
    if(x % 4 == 0) continue;
    cout << x;
}

Суть в том, что в условии ноль приводится к false, а любое другое число - к true.

Ну и вообще, есть более оптимальный способ:

for(int x = 2; x <= 100; x += 4)
{
    cout << x;
}

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

но давайте я вам расскажу как я решаю свои задачи которые мне приходится решать даже если они мне не нравятся
1) надо определиться с тем что должно быть на выходе ( если я не понимаю что я должен получить я не могу этого сделать) по этому, чем точнее описание результата работы, тем она будет быстрее и качественнее выполнена.
2)Надо определиться с тем что на входе( инструменты и материалы- в случае программирования данные)
2,1)Вуаля! мы уже имеем чёрный ящик. У нас есть вход и выход, но нет наполнения.
2,2)Проще всего когда это типовая задача - всё решено до нас и не один раз - можно загуглить, а иногда даже и скопипастить.-> конец
3)После некоторого времени вопрашаний гугла выясняется что задача не такая и простая. Вот тут начинается самое весёлое - процесс творчества который сложно описать, но я попробую.
3.1)Для начала, раз уж не получилось сразу заполнить наш чёрный ящик одной фигурой, разбиваем его на два поменьше, в результате мы имеем уже два чёрных ящика с неизвестным входом и известным выходом и на оборот.
3.2)Пытаемся их состыковать поисками аналогичных решений в голове или интернэтах, ну... грубо говоря может кто-то уже делал что либо подобное, но с другими материалами или инструментами, и что можно сделать с имеющимися инструментами и материалами. (копать можно с любого конца или с двух сразу) находим кучу чёрных ящиков.
4)Проверяем как стыкуются наши наборы чёрных ящиков поменьше, сошлось?-> конец,
4,1)не складываются? Берём наиболее подходящий набор чёрных ящиков смотрим их содержимое
4,2)находим причину нестыковки , пытаемся убрать лишнее или ищём ещё один чёрный ящик который позволит первые два достыковать, переходим к пункту 4

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

Основное отличие - в декларативном языке описывается набор правил, каким должен быть результат без описания того как этот результат получается (например html, css, prolog), в императивном описывается как получить результат в виде последовательности действий.

Встал вопрос о перезаписи кластеров где находится файл.

Если проблема только в этом, то можно же перезаписывать содержимое самого файла.
Это не сработает на Copy-on-write файловых системах, но под windows, вроде, таких нет.

Варианты.
1. Если граф циклический, максимальный путь — ∞.
2. Если циклический, но путь обязан быть несамопересекающимся — Дейкстра не подойдёт. Подобную олимпиадную задачу я решал и там решением был перебор с кэшированием (вершин вроде до 15).
3. Если граф циклический, но есть отрицательные веса, которые в определённых случаях дают-таки точный максимум — меняем знак, применяем модификацию Дейкстры для отрицательных весов. Он либо скажет, что есть цикл, позволяющий сколь угодно уменьшить сумму, либо даст точный минимум.
4. Если ациклический ненаправленный — то либо один, либо нет вообще (т.н. лес);
5. Если ациклический направленный — должен работать совсем другой алгоритм: отсортировать в топологическом порядке, убрать те элементы, которые перед началом и за концом, а на оставшихся пустить динамическое программирование.

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

На будущее, на случай, если кто-то не силен в тернарном операторе переписал для if...else

public static String moveLetters(String s) {
        int L = s.length();
        char[] chars = new char[L];
        int i = 0;
        for (int x = 0; x < L; x++) {
            if (x % 2 == 0) {
                i = x;
            } else {
                if (x == 1) {
                    i = L - L % 2 - 1;
                } else {
                    i = x - 2;
                }
            }
            chars[x] = s.toCharArray()[i];
        }
        return new String(chars);
    }

* для тех кто в C# не разбирается код из предыдущего ответа, только для Java

public static String moveLetters(String str) {
        int L = str.length();
        char[] chars = new char[L];
        for (int x = 0; x < L; x++) {
            chars[x] = str.toCharArray()[(x % 2 == 0) ? (x) : (x == 1) ? (L - L % 2 - 1) : (x - 2)];
        }
        return new String(chars);
    }

ИМХО, надежность у Lenovo, Asus, HP - приблизительно одинаковая. Находите понравившуюся модель, и смотрите отзывы конкретно по ней.

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

Если задача - это часть заказа, то задача выполняется строго по ТЗ и чем быстрее, тем лучше. Заказчик заказывал правильную архитектуру приложения? Если нет, значит решение с найденным алгоритмом себя оправдывает. Любая работа должна быть оплачена.

Если задача без ограничений, то разбираться в зависимости от сути задачи и времени на изучение:
- как правильно обойти массив и найти нужный элемент на страницы - это базовые задачи, которые необходимо уметь делать не задумываясь
- реализация анимации элементов может занять много времени, но хотя бы разок выполнить на чистом JS надо
- написание своей версии jQuery не рекомендуется

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

Oxoron ну что тут сказать навскидку...
Я всегда считал .net допиленной java-платформой. Не то, чтобы в дотнете прям нереальные невероятные новшества, но все же некоторые вещи были обдуманы еще раз. Например, очень важным считаю разделение на reference и value типы. Правда, ИМХО, MS не довела идею до победного конца (слишком много технических вопросов нужно учитывать при выборе struct vs class), но все равно шаг очень правильный.
Плюс, считаю важным отсутствие корреляции между логическим структурированием библиотек (по неймспейсам) и физическим (по сборкам). На каждом уровне должны приниматься отдельные решения насчет того, что куда класть.
Еще одним преимуществом (нивелированным на данный момент) была изначальная ориентация .net на мультиязычную поддержку. Сейчас конечно JVM-языков навалом, но раньше это все-таки смотрелось киллер-фичей .net. Особенно поддержка "склеивающих" языков, таких как C++/CLI, которые позволяли интегрировать уже существующие компоненты с .net-приложениями. Дотнет изначально не был платформой в себе, разработчикам давали массу инструментов для интеграцией с COM и native-кодом. Ну и само собой managed-языки в приличном количестве, вон F# уже довольно давно подтянулся как официально (!!) поддерживаемый.

А вообще конечно изначальным преимуществом .net были именно языки. Я думаю даже самые ярые джависты со мной согласятся, что с момента выпуска C#, язык Java развивается догоняющим образом. Можно опять сказать, что есть Scala, но тогда нужно учесть, что C# изначально был визитной карточкой платформы с момента ее появления. Ну и самое главное - инструменты. В мире Java достаточно хороших IDE, но уровень взаимоподдержки Студии и .net насколько мне известно пока не достигнут.

И тут мы выходим на стандартное основное преимущество решений от MS - максимальная "готовность" и интеграция продуктов. К сожалению последние года 3 в Джаву не совался, но знакомые не раз говорили, что с отсутствием знаний об обеих платформах им гораздо легче было поднять hello-world веб-сайт (!) на asp.net в студии, нежели на том же Spring. Так или иначе, это фактор.

Теперь библиотеки. Конечно, в мире джава их огромное количество. Я думаю и сегодня их значительно больше, чем в дотнет. Две либы в моем текущем проекте - NHibernate и NetTopologySuite - это порты с джавовских либ. Джава рулит на сервере. Про..аная Майкрософтом настоящая кроссплатформенность .net не давала ему потеснить джаву. Сейчас конечно это усиленно исправляется - в дотнете уже наступило перерождение после массовых релизов в open-source, переделанного asp.net, и появления DNX. По сути теперь .net официально поддерживается на *nix - системах. Это конечно надо было сделать намного раньше, но и сейчас этому рады.
NuGet прекрасно справляется со своими задачами, более тесная интеграция в билд-процесс в DNX только улучшит процесс взаимодействия с ним.

Ну и последнее - разработка UI. Все что есть в Java-мире (JavaFX, Java3D, Swing) это совсем не то. Windows Forms был отличным аналогом Дельфийских компонентов для UI, WPF в свое время вышиб немало дверей своим появлением. Если б он еще и развивался как подобает... Да, конечно, на джавовских технологиях вы напишите кроссплатформенную вещь, но она будет одинаково чужеродно смотреться и на винде, и в линуксовых desktop-средах. А людям в enterprise не особо нужна кроссплатформенность в UI - им намного важнее аккуратный привычный интерфейс, в том числе на Винде. Сейчас WPF может потеснить только современный Qt. Выбирая сегодня UI для десктопа, я бы выбирал между WPF и Qt, про джаву бы даже не подумал (да, я считаю что сегодня далеко не все можно и нужно пихать в браузер на тормозной JS. Весь новомодный неповоротливый софт, написанный с использованием Atom-а, меня удручает).
ПРАВКА: посмотрел последние демки по JavaFX. В общем-то неплохо, осталось только дождаться хорошего роста коммьюнити и надеяться что не будет проблем с производительностью в сложных приложениях.

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

P.S. Да, тут кстати пишут что игродельство на C# достигло серьезного уровня. Я 3d делал и делаю на C++, поэтому тут пусть кто-нибудь другой прокомментирует.

Решение логических, комбинаторных задач. Возможно в больших кол-вах. Правда, это лучше делать до того, как вырос.

У процессора очень много входов/выводов, ну или просто контактов. Они сейчас и так еле умещаются на "переходнике" - посмотрите снизу процессора. Если его уменьшить - соответственно уменьшится площадь самих контактов, что черевато тонной проблем: от повышенной вероятности механического повреждения, до ненадежности соединения.