А я и не спорю... Если никто не приведет убедительных контраргументов -- пусть так и будет. Как мне кажется.

BTW: мне кажется, что вместо динамических массивов проще использовать TList... Как минимум, нет проблем с написанием собственного Insert.
Для real можно использовать два последовательных элемента TList.
А два Find-а ("деление пополам" для Integer и Real) надо просто написать ручками по аналогии.

Вот и все "сворачивание гор".
Конечно же, некоторого времени это потребует....

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

--- Добавлено в 2017-12-30 02:44:00

Galkov, ты не пойми меня не правильно, у меня претензия не к тому, что ты выдвигаешь какие-то плохие идеи. У меня претензия к твоему методу ведения работ: не надо учить людей плохо работать. Если уж зашла речь о хаках ради производительности, то стоило сразу пояснить, что их лучше вынести в отдельные функции, чтобы читающий твой код не чесал репу, разбираясь, зачем ты тут бинарно распилил число надвое да еще и привел к указателю.
То же касается и разработки по шагам, а не всего и сразу. Когда правок за один раз много, в них сложно разобраться и, как следствие, найти возможную проблему. Будь ты хоть трижды матерый профессионал, а ошибиться может каждый. А из твоих слов можно подумать, что все это чушь и не нужно в реальных проектах. Мол "лишь бы работало и быстро".
Не хочу принижать знания 3042, но он мог об этом не знать, а ведь это довольно важные моменты.

Редактировалось 2 раз(а), последний 2017-12-30 02:44:00

Народ! А че это вы тут предновогоднее бла-бла-бла устроили? Пока все это безобразие не достигло окончательного местоположения говорить вообще не о чем, все это останется на уровне экспериментов.

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

Я понял все правильно.
Сам еще работать не научился. А вот претензии выдвигать к методу ведения работ - уже запросто.

--- Добавлено в 2017-12-30 12:20:15

Спасибо конечно, но я это все проходил. Практически. На этом же проекте.
И поставил себе в труд подумать о причинах, по которым внесение 286-й фичи конфликтует с 143-й (а обнаруживается это через месяц работы).

А имеете ли Вы аналогичный опыт, Assasin

Редактировалось 3 раз(а), последний 2017-12-30 12:21:20

Да, и не однократно. На основе личного опыта я писал свой пост.

Хех....
Мне случалось видеть Ваши коды. Не все конечно. Но MathParseEx - видел.
Там, кажется, Вы мне свою концепцию "якобы правильности" и изложили первый раз.

Так вот, сотворенное Вами тогда не является легко читаемым -- КАТЕГОРИЧЕСКИ.
То, что Вы называете хаками (которые я Вам тогда и привел, фундаментально повышающие быстродействие) - читается и понимается в пределах пяти-десяти строк.
А для понимания Вашего кода, мне пришлось шелестеть по всему файлу. Внимание: не Вам, а мне!
Какой-то персональный тип - смотри его определение где-то в начале. Он тоже определен исходя неких новых абстракций. Которые тоже где-то надо искать
Да, Вам искать не надо, и Вам все это понятно. А как иначе -- это Вы эти абстракции и придумали.
А вот нафига мне (читай - другому кодеру) все это тряхомудие, спрашивается.
Если во всем можно было бы разобраться в пределах одной страницы.
И я Вам показывал как. Предположим, что это было не понятно для Вас.
Вопрос: почему это мои проблемы, а не Ваши. В конце концов, некоторое образование следует иметь, как и понимание "чего стоит" каждая строка Вашего кода.

Если коротко, из того что я видел, Ваше понимание "ПРАВИЛЬНОСТИ" представляется мне пока мнением "недоучившегося студента".
А если Ваше понимание поддерживают еще и ваши преподаватели - плюньте им в лицо. От моего имени.

---

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

Вас, Assasin, интересовал именно процесс. Ах, ах, ах -- а вдруг я не пойму, потому что написано "неправильно" (еще не глядя в коды).
А вот ТС интересовал результат, судя по названию темы.
Можете себе представить, Assasin, у кода существуют еще и иные характеристики, кроме мифического "работает".
И Инженер стремится достигнуть компромисса между всеми характеристиками своего изделия. И зародилась сия практика задолго понятия "программирование", IT, и т.п..
Это способ мышления такой...
У меня были беседы на эту тему на Обероне... Мне пришлось им сказать, что перед использованием термина "инженерное программирование" - нужно было бы у Инженеров разрешение спросить.

Так вот, если исходить из того, что мозги у Вас все-таки есть, то направлено их действие совсем в другое место. А вовсе на достижение результата.
Ибо, если бы Вы думали о Результате, то могли бы заметить, что я был не совсем прав в утверждении об асимптотике O(N*ln(N)).
Дело в том, что асимптотика Insert -- O(N). Хотя и с очень маленьким коэффициентом. Грубо говоря, это всего одна строчная команда проца - быстрее на данном железе невозможно. И заметить ее непросто...
Это несложно, надо просто думать О НУЖНОМ. А не крутить пальцы веером про "важность инкапсуляции".
((кстати говоря, а Вас в школе не учили, что логарифмическую асимптотику без деревьев не получить ??? меня то - не учили, только самообразование...))

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

---

Третья часть Марлизонского балета.
Мои коды выглядят примерно так... Ну как бы, это еще одно отличие Инженера от IT-шника.

2nesco: я позволил себе начать перечисление для Real с нуля, а не с единицы... И изменил способ "внедрения множественности"
Без обсуждения. Посмотри внимательней....




--- Добавлено в 2017-12-31 20:34:17

Ах да, С НОВЫМ ГОДОМ ВСЕХ
((у нас -- УЖЕ ))

Редактировалось 13 раз(а), последний 2018-01-01 22:49:00

   Ну, 6 лет назад, конечно, я мог писать гораздо хуже, не спорю. Однако, раз уж о том речь зашла, замечу: как раз после того случая с MathParseEx у меня и сложилось впечатление, что Вы не решаете задачу поэтапно, а пытаетесь свернуть горы за один раз.
   Я тогда намеревался ускорить работу MathParse, и я получил результат, который хотел (заметьте, мне уже тогда был важен результат, и я его достиг). Однако Вы, безусловно, обладаете куда бОльшим опытом, чем я, поэтому когда Вы начали говорить, что надо сразу реализовать оптимизацию MT, оптимизацию байт-кода и прочее - я Вам доверился и стал пытаться все это сделать сразу. Потом у меня возникли продолжительные проблемы в жизни, и как итог - результат, которого я тогда достиг, а это, прошу заметить, увеличение производительности MathParse в разы (а может даже на порядок, не помню уже), - результат просто канул в лету. Если бы мы внедряли это по шагам (сначала уже готовое решение, а потом дополнительные оптимизации всего и вся) - то все эти 6 лет MathParse успешно служил бы обществу.
Примерно через полгода-год я понял, что тогда с MathParse поступил неправильно и признал Ваш подход неэффективным.


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


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


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


   С ходу могу процитировать вас же:

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

   Все это мое ИМХО, конечно, и я Вас тоже ни к чему не призываю, и тем более не хочу ругаться. А за подробный анализ меня, как профессионала, и поучительные примеры большое спасибо.
   Кстати, как я пишу код сейчас, можно посмотреть на моем GitHub. Там, конечно, тоже не везде все хорошо, но, по моему мнению, заметный прогресс за 6 лет у меня есть.

---

   И Вас тоже с Новым Годом! Добра, здоровья и всех благ!

Редактировалось 4 раз(а), последний 2017-12-31 22:29:59

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

Опять гон....
Оказалось, что это я виноват, что Assasin не доделал MathParseEx.
Да, идея была продуктивная.
Только ее еще довести надо было. А это несколько сложнее, чем понты про правильность кидать.
Работать головой всегда сложнее, чем языком.

Да, Ваш первый вариант давал некоторые разы.
А у меня хватило ума показать Вам как из этого выжать ЕЩЕ (к Вашему выигрышу) порядок по быстродействию.
Выжать из идеи все, на что она способна.
Вы подумали-подумали, и признали это "неправильным". И отказались от продолжения проекта.
Вот так было на самом деле.
И все это написано здесь (и не 6 лет, 3.5 года назад)

А виноват оказался я.
Assasin, кончай гнать пургу. Твоя цель была - быстродействие. Ты отказался от ее достижения.
А я просто пользуюсь своей версией (которую законченной не считаю).
Нет, не 6 лет. Но больше 3-х.
И также не считаю, что к ней можно прийти от твоей "методом добавления фич".
Сравни два кода, и покажи последовательность этих фич.
НЕ ПОКАЖЕШЬ.

Надоело уже, блин......
Про тип PArray все понятно в пределах одной процедуры (например, в _work_doFilter0 это PStrList).
Про твой тип я уже сказал - он понятен только для тебя, потому что ты его придумал.
Получается, что твоя читаемость - крайне субъективна. И вот ради этого субъективного качества ты готов жертвовать быстродействием.
Т.е., потребности себя любимого ты ставишь выше потребности пользователя. Это ему, а не тебе - нужно быстродействие.
Поставить приоритеты наоборот -- это ведь не для IT-шника.
Да, читаемость - очень важное качество. Только: сначала пользователь, а потом ты, любимый.

---

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

А когда работаешь без плана, или еще интересней: план меняется в процессе добавления под нужды очередной фичи -- это будет Шанхай.
Горячо Вами любимый. И который рано или поздно упадет.
И Вы сделали вывод, что это шанхаестроение - самый эффективный метод. Из того, что не справились с MathParseEx.
А мой метод (планирование работы) - это "сворачивание гор" по Вашему.
И на основании этой шизы в Вашей голове Вы мне претензии выставляете.

DIXI

Редактировалось 2 раз(а), последний 2018-01-01 11:10:58

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

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

Да, тут ошибся, прошу прощения, в 12-ом году я только в универ поступил.
Нет. Все понятно только после PStrList(PArray)., а после этого выражения информация снова теряется, и нужно проверять таки все. Это просто Вам все понятно и четко известны границы контекста. А мне, например, нет. Считаю, что Вы попали в свою же ловушку.

Для меня и всех, кто его изучил. Так же, как и Ваш код с PArray в каждом месте использования, только проще.

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

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

Нет. Выше уже писал, что мог неправильно Вас понять.

--- Добавлено в 2018-01-01 02:36:09

По поводу кода: сейчас сравнить не могу - не дома.

Редактировалось 2 раз(а), последний 2018-01-01 02:40:40

Ну неймется "Разработчику"... Аж устал я весь

Даже в этом топике я просто изложил план (добавления фич - по Вашему):

Его можно было обсуждать и/или предлагать свой.
А Вы вместо этого начали зудеть про "сворачивание гор".
А дел было часа на три работы...
Можете себе представить: план взяли, и реализовали.

Весь топик про MathParseEx я пытался Вам вклеить именно план работы. Поэтому и кодов-то особо не было. Чтобы добавление первой фичи не конфликтовало с добавлением последней (для которой, кстати говоря, я запланировал выкидывание св-ва DebugMode нафиг). А пример реализации этого плана я Вам привел постом выше (реализация неполная - тоже руки не доходят, да и я ничего никому не обещал).
И что мы видим:
Извините, но для того, чтобы что-то увидеть, надо сначала научиться смотреть.
Отсутствие этого умения Вы продемонстрировали и в этом топике. Случай на много-много более простой, чем MathParse.

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

Вот у меня хоть и получилось быстрее, чем в оригинале, но асимптотика все-таки осталась "пузырьковой".
Где, спрашивается, идеи об ее улучшении
Их не просто нет, а даже мыслей таких не возникает
И не говорите мне, после этого, что Вы думаете о качестве выходного продукта.
НЕ ДУМАЕТЕ. Весь пар в гудок уходит...

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

---

btw: про планы

Редактировалось 3 раз(а), последний 2018-01-01 12:19:22

Значит либо я чрезмерно тупой, либо Вы не умеете объяснять (а может и то, и то сразу).


На "слабо", пожалуйста, не надо брать. Те, кто хотел писать код, уже занялись этим. А у меня были свои мысли и я постарался их изложить, кому нужно, из нашего разговора вынесли свои выводы. (Я надеюсь, разговор и правда получился полезным для остальных).
У каждого пользователя свое понятие о "правильно", а разработчики - не экстрасенсы. Ну, по крайней мере, большинство из них. Если вы научились такому за время своей работы, то я тоже хотел бы перенять этот навык.

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

Galkov, отлично! Я, правда, по-другому собирался сделать, вот так:

Но это медленнее, чем Ваш вариант.

Я только одного у Вас не понял: зачем там локальная переменная P создаётся, если есть PArray?

Можно, навреное, сразу с PArray работать:
?

Можно. Без проблем.
Просто все время надо писать приведение к нужному типу.
Не более, чем вопросы удобства... Из серии нравится/не нравится.

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

---del

Редактировалось 1 раз(а), последний 2018-01-01 23:58:09