на низкоур. языках, таких как си или ассемблер, не используя внешние библиотеки, написать код, который генерирует например скажем изображение с красным пикселем в x:0 y:0 ? а можно ли также на высокоур языках ?
Возможно я не понял вопроса. Что значит "изображение с красным пикселем в х:0, у:0"? Создать файл изображения с одним пикселем только?
с одним пикселем на координате x:0 y:0, это просто пример, чтобы понять, можно ли манипулировать пикселями изображения как душе удобно.
Конечно можно. Но есть нюанс, какой формат изображения?
Ты же тут достаточно давно, не видел что-ли, как мы изображения дизерили?
Ну bmp конечно будет легко, поэтому например .png, вот гопота смогла лишь создать .bmp изображение, и то не факт, ибо я код не потестировал, я вот думаю что неважно на каком языке ты пишешь, если этот язык умеет создавать, изменять и удалять данные, то можно практический любой доступный формат обработать и создать.
Вот именно. Вопрос только в том, как много времени ты готов убить, чтобы написать редактор PNG-шек на ассемблере
Видел, только не факт что без сторонних библиотек, по этому навсякий спросил.
Ну я точно сторонние либы не использовал
Инженер должен распределять усилия. Формат png достаточно сложный. Посмотри исходники libpng. Они на сях. И прикинь сколько кода тебе надо будет написать. Вобщем если рисовать множество Мандельброта - то оптимально на асме, а если сохранить его в файл, то просто используй чортов libpng.
На ассемблере уже есть библиотеки декодирования png
Ну так вопрос изначально был - без использования внешних библиотек
оттуда код выдрать можно, не изобретая велосипед
Существует такая категория людей, которая любит изобретать велосипеды) я из таких например)
опять стройка встала, на стройке паралич, прораб изобретает свой собственный кирпич а какой в этом смысл, если качество велосипеда не дотянет в большинстве случаев до "заводского" уровня?
Я перфекционист - я изобретаю тогда, когда вижу, что иные реализации отвратительны и что я могу лучше.
Завод часто добавляет в велосипед совсем не то, чего хочет велосипедист.
для этого существует рынок(опенсорс), где есть куча запчастей, из которых хоть танк собрать можно вместо велосипеда. А новую шестерню и колесо изобретать на миллиметровке, без сильного отличия от завода, уже странно
Ну просто чтобы понимать в общих чертях, как оно работает. Потом заводское использовать никто не мешает
Это как зачем учить алгоритмы если в стандартной библиотеке большинства языков куча встроенных. Вызови метод и готово.
Поддерживаю. Алгоритмы учить не нужно. Чем меньше людей в состоянии составлять сложные алгоритмы, тем меньше у меня конкурентов, тем выше моя зп
ты алгоритмистом работаешь?
Не знаю, что такое "алгоритмист", но понаписал алгоритмов более, чем достаточно
а реализовываешь их?
Алгоритмист – это специалист, который занимается алгоритмизацией. Алгоритмизация – это преобразование исходной информации к алгоритмическому виду
Написать == реализовать. В большинстве случаев, если мы к физике не начинаем приближаться. Там немного по-другому бывает
Эммм, а можно посмотреть, откуда это определение? А то мне не очень понятно, что имеется ввиду под преобразованием информации в последовательность действий
Гугл - это не источник. Мне вот такое определение предлагают на вики: специалист, разрабатывающий алгоритмы
Программи́ст[1] — специалист, занимающийся программированием, то есть созданием компьютерных программ. если дальше рассуждать то программа состоит из некого алгоритма действия, которое реализуется на ЯП программером
Получается написание кода на языке программирования это только один из возможных способов создать программу
У меня возник тут прогноз на ближайшее будущее. Мне кажется что следующие лет 5 мы будкем исправлять ошибки в коде которые писал ИИ. И диалога у нас на эту тему ни с кем не выйдет. Просто нас заказчик будет чаще ставить перед фактом что вот мол так и так. Код писал ChatGPT. Ошибся. Сам исправить не может. Нужен человек. Утилизатор. Чистильщик.
мне кажется что все поймут бесполезность ИИ в плане написания кода помогать программисту да но писать полностью сам код не сможет ещё так лет 30 точно
о, таки как раз моё направление)
он сейчас еле еле справляется с задачами простыми и то ошибочно
Основные алгоритмы написаны в 20м веке Дейкстрой, Кнутом, Хаффменом. Мы никаких алгоритмов не пишем. Мы делаем реализации бизнес-логики на базе того что есть. Это как закон Ньютона или закон Ома. Мы - его пользователи.
Ну... он и должен ошибаться. Fuzzy logic. Иначе бы модель не работала. Там не if-else как на Прологе. Поэтому у него 1+1 = 2 условно с какой-то вероятностью. И земля у него круглая с вероятностью. Вдруг плоскоземельщики тоже в учебный сет попадали.
Сам алгоритм ещё не значит эффективной его реализации для конкретной задачи
Ну да. Вот теория говорит что связный список (Linked-List) эффективнее массива на вставках в голову и хвост. Но практика применения в языке Java например показала что в 99% вы можете брать массив и все нормик работает. Просто наши массивы маленькие (строки символов которые по сути char[]) и если - бы мы их представляли всегда как связные списки то наша память бы драматически пострадала от оверхеда а полезный эффект был бы настолько слаб что лучше вернуться обратно на массивы. И размер строк в среднем не большй. По 16-32 символа в среднем. Вот это тот случай когда теория и практика разошлись в разные стороны.
Скажем у тебя отобрали из рук библиотеку, как ты будешь выкручиваться, что будет если тебе не хватает того функционала что предоставляет библиотека, что если тебе нужно будет написать что-то новое ? именно для таких случаев и нужно изобретать "велoсипеды".
Не надо себя принижать, термин "велосипед" вообще сильно раздут.
напишу своё, свою библиотеку совместимую с тем что есть
Вот кстати да. Писал я как-то на шарпе программу для контеста, которая включала в себя сортировку массива. Со встроенной функцией снижали баллы за время, а когда заменил на модифицированный самописный пузырёк, то списание баллов за время прекратилось
Так оно обычно и бывает. Обычно встроенные функции и коллекции это золотая середина между обобщенностью производительностью и потреблением ресурсов.
Ну блин, не пузырь же. Он же вроде как чисто учебный
Ну тут я согласен. Но если честно пока что яне встречал в стандартной библиотеке какого либо языка бабл сорт.
Конечно, алгоритм-то учебный
как ты напишешь свою если до этого не писал ?
Так тыж говоришь, зачем писать свое если есть уже чужое, вот я и дал неудобные вопросы, которые и отвечают на вопрос "зачем писать свое, если есть чужое"
зачем писать своё для готового продукта, когда есть либа. Для себя можно хоть свою анализатор трафика сети написать
Я вас прошу. Изобретение велосипеда - это попытка поставить под сомнение то что уже создано. А сомнения - это хорошее качество ума. Умный - всегда сомневается. Дурак - во всем уверен. Все философы древности заканчивали свои труды тем что признавали как мало они знают. Ломоносов, Леонардо-Да-Винчи .. все расписывались в своем невежестве перед бесконечностью и космосом.
Очень зависит от конкретной области. В сайтостроении - да. В более сложных инженерных областях - нет. Там ии тлже повлияет, но другими способами
Я там выше ссылку приводил, и из них алгоритмов, написанных дедами-основателями не то, чтобы очень много. А так даже просто сортировку сделать быстрой не всегда просто
Для бизнес-кейсов сортировка - на 80% задача решенная в рамках БД. Там индексы и прочее. Все остальные кейсы где вам на вход пришел Гиг текстовой информации и вдруг (!) внезапно вы хотите сортировать - я отвергаю. Я по ним спорю и доказываю что этот кейс - синтетический и в реальности таких задач не существует. Вы хотите гиг сортировать за 3 секунды. Отлично. А как он вообще в память к вам попал. Да его загружать надо 5 минут. И о чем задание? Я просто считаю что сортировка - это перегретая и гипертрофированная тема которой пугают на собеседовании в Microsoft/Google. В реальности все прозаично.
Я же говорю, зависит от конкретной области. Для меня сортировка гига текста - задача не то, чтобы типичная, но весьма тривиальная. А вот обход графа на несколько миллионов узлов - пожалуйста. У кого-то и сортировки гигабайт данных - задача повседневная. Про гугл - да, но там тоже есть отделы, в которых это весьма актуально
Да. Граф - это самая противная в этом смысле структура данных. В ней плохо применяется partitioning. Трудно придумать схему при которой вершины и ребра попадают в независимые узлы partitions. А это - ключевой момент для обработки в bigdata.
Обсуждают сегодня