Вверх ↑
Этот топик читают: Гость
Администрация
Ответов: 15295
Рейтинг: 1519
#16: 2007-09-09 21:19:38 ЛС | профиль | цитата
3042 писал(а):
При чём тут команды HiAsm?

поясняю:
Galkov писал(а):
А работать мозгами - это понять, что из твоих 500 алгоритмических веток, только 5 принципиально разные.

при том, что если пронумеровать все команды, то получится 96 алгоритмических веток, покрывающих все задачи среды(пример приведен в качестве сравнения)

Просьбы разработчиков:
Dilma писал(а):
Куда же нужно 300 штук


Dilma писал(а):
Если будет приведен пример реальной задачи


Galkov писал(а):
Конкретную задачу в студию.


вместо этого имеем:
3042 писал(а):
Но, по-моему, смысла ограничивать число точек сотней не было смыла.

несмотря на написанное выше:
Galkov писал(а):
Заставляет использовать мозги а не руки.


Dilma писал(а):
Ограничение на 100 точек сделано умышленно, чтобы не появилось желание составлять схемы из таких нечитабельных элементов.


Предлагается закрыть тему ввиду отсутсвия задач(во всяком случая таковых представленно не было), чья реализация потребовала бы предложенного дополнения в среде.
карма: 27
0
Ответов: 1946
Рейтинг: 174
#17: 2007-09-13 17:25:05 ЛС | профиль | цитата
Ок.
карма: 10
0
Ответов: 3851
Рейтинг: 159
#18: 2007-09-13 22:28:59 ЛС | профиль | цитата
Наверное всё таки расскажу свою задачу, она уже решена, в ней требовалость меньше 100 точек у FormatStr, но не намного. Задача не "бытовая", сама схема большая, посему приводить её здесь считаю нецелесообразным, но на пальцах - объясню - просто в доказательство того, что "в жизни бывает всякое".
Имеется файл, структура блочная (2 уровня, если можно так сказать). Цель - трансформация в другой формат, с добавлением новой информации. Строка, формируемая в FormatStr имеет меньше 100 DataCount, хотя в результате она получается больше 100 символов. Записи состоят из полей, обрабатываемых по разным алгоритмам, всего их меньше, чем полей, но для ускорения работы используются идентичные куски схемы. Риал-тайм не требуется, но ~7минут/22МБайта на P3-750МГц, несмотря на сознательное избегание всякого каскадирования и прочих тормозов, меня напрягает..
Этот вариант не первый, сначала я пытался использовать переключатели для одинаковых алгоритмов, да и привычка минимизировать кол-во элементов постоянно напоминала о себе. В итоге только третий из принципиально отличающихся вариантов, оказался таким "шустрым".
В заключение хочется сказать - рано или поздно, у кого-то возникнет задача, которую здесь можно будет выложить в качестве запрошенного примера. Понятно, что ему сразу предложат каскадировать, а если человек "спешит"? Я видел как задачу, сродни моей, решают программисты и на другом языке (секунд~20). Поэтому: очень хочется Delphi2 - надеюсь с его гибкостью, само слово "ограничение", не будет иметь столь категоричное для пользователя значение..
карма: 0
начавший
0
Администрация
Ответов: 15295
Рейтинг: 1519
#19: 2007-09-13 23:14:07 ЛС | профиль | цитата
перегонять такие данные через FormatStr крайне не рационально. Формирование строки по маске обычно делают примерно для 10-20 значений максимум. При большем количестве слишком много времени начинает уходить на пересоздание строки.


карма: 27
0
Ответов: 3851
Рейтинг: 159
#20: 2007-09-14 08:22:47 ЛС | профиль | цитата
Dilma писал(а):
перегонять такие данные через FormatStr крайне не рационально

А как надо?
У меня как раз, строка задвигается в таблицу после подготовки всех значений, и это должна быть именно строка.
карма: 0
начавший
0
Ответов: 2125
Рейтинг: 159
#21: 2007-09-14 10:53:49 ЛС | профиль | цитата
Андрей. писал(а):
после подготовки всех значений

Может всё-таки именно этот этап тормозит, а не FormatStr, который можно было бы и каскадировать?
карма: 1

0
Администрация
Ответов: 15295
Рейтинг: 1519
#22: 2007-09-14 13:45:56 ЛС | профиль | цитата
В таблицу из почти 100 колонок?
карма: 27
0
Ответов: 3851
Рейтинг: 159
#23: 2007-09-14 13:53:15 ЛС | профиль | цитата
tsdima писал(а):
Может всё-таки именно этот этап тормозит, а не FormatStr, который можно было бы и каскадировать?

этот этап я оптимизировал как мог, и рад что не пришлось каскадировать FormatStr.

Dilma писал(а):
В таблицу из почти 100 колонок?

колонок там не много, а вот DataCount у FormatStr предостаточно..
карма: 0
начавший
0
Ответов: 1946
Рейтинг: 174
#24: 2007-09-14 16:55:40 ЛС | профиль | цитата
В общем, если больше 100, то придётся http://hiasm.1gb.ru/xf//getfile/7058
карма: 10
0
Ответов: 9906
Рейтинг: 351
#25: 2007-09-14 16:59:52 ЛС | профиль | цитата
3042 писал(а):
В общем, если больше 100, то придётся

На что поспорим
карма: 9

0
Администрация
Ответов: 15295
Рейтинг: 1519
#26: 2007-09-14 17:26:37 ЛС | профиль | цитата
3042 писал(а):
В общем, если больше 100, то придётся

спорный момент уже потому, что сам код в IC данного примера организован худшим из всех возможных способов.
карма: 27
0
Ответов: 1946
Рейтинг: 174
#27: 2007-09-14 19:37:54 ЛС | профиль | цитата
А можно как-то лучше? Я хотел сделать так, чтобы, например, если на вход подано "1", то данные шли на e1 посредством добавления к "e" цифры "1" и прописывания реультата в _hi_OnEvent(e1); но почему-то не получилось...
карма: 10
0
Администрация
Ответов: 15295
Рейтинг: 1519
#28: 2007-09-14 21:01:24 ЛС | профиль | цитата
хотя бы поставить условную цепь из else if <> then. Еще лучше сделать хотя бы несколько каскадов с разбиением диапозонов по 10-20 значений. Собственно это классическая задача оптимального поиска при котором решение в лоб(одна входная точка и несколько сотен выходных) является худшим.
карма: 27
0
Ответов: 1946
Рейтинг: 174
#29: 2007-09-15 12:05:05 ЛС | профиль | цитата
Ок, спасибо за разъяснение.
карма: 10
0
29
Сообщение
...
Прикрепленные файлы
(файлы не залиты)