Автор |
Тема: Что желают разработчики приложений от HD. (Прочитано 4958 раз) |
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
 |
АРКАДИЙ, НУ СОГЛАСИСЬ, ПОЖАЛУЙСТА.
« Ответить #30 В: 23.01.05 в 10:44:27 » |
Цитировать | Править
|
on 22.01.05 в 11:27:03, Arkady wrote:
Нужна стpогая пpовеpка стpок на pавенство? Тогда почему бы не опpеделить в library соотв. функцию 
Дpугое дело, что такая функция будет не очень быстpой, и это, конечно, повод сделать ee встpоенной.
|
|
Исчерпывающую информацию Аркадию по этому вопросу предоставил летом 2004года.
Думаю, что этот вопрос для Аркадия - слишком ничтожен, т.к. пользователи имеющимися средствами могут выйти из ситуации и мне это как всегда импонирует, хоть что-то надо сделать и самому.
Признаюсь хотелось объявить конкурс на написание функции, короче поупражняться, но Саня повёл себя как обычно.
Поэтому тем, кто не имеет желания краснеть перед своими заказчиками предлагаю фрагмент __SYS004.RPT
:L2
[set %,K ,0]
[set %,AK,1]
[plus %,K ,1]
*! K = AK
! [get %,K]=2
goto L3
Первая, последняя и закоментаренная строки - это оригинал HD.
Т.е. Вам нужно вставить четыре строчки. Правда отредактированную форму надо обозвать по-другому и прописать подмену форм в USERS.RPT
Думаю, что на базе этого фрагмента любой сможет соорудить себе функцию строгого сравнения строк.
Поклон тому, кто напишет эффективнее эту функцию.
На этом можно было бы закончить, но "==" - ОЧЕНЬ КРАСИВО.
АРКАДИЙ, НУ СОГЛАСИСЬ, ПОЖАЛУЙСТА. Твой адепт, Борис.
|
| « Изменён в : 23.01.05 в 11:42:10 пользователем: Boris, Kiev. » |
 Зарегистрирован |
|
|
|
Arkady
Administrator
 
Просмотреть Профиль | WWW | E-мэйл
Сообщений: 484
|
|
Re: АРКАДИЙ, НУ СОГЛАСИСЬ, ПОЖАЛУЙСТА.
« Ответить #31 В: 23.01.05 в 15:07:19 » |
Цитировать | Править
|
on 23.01.05 в 10:44:27, Boris, Kiev. wrote:
...
Признаюсь хотелось объявить конкурс на написание функции, короче поупражняться, но Саня повёл себя как обычно.
Поэтому тем, кто не имеет желания краснеть перед своими заказчиками предлагаю фрагмент __SYS004.RPT
:L2
[set %,K ,0]
[set %,AK,1]
[plus %,K ,1]
*! K = AK
! [get %,K]=2
goto L3
Первая, последняя и закоментаренная строки - это оригинал HD.
Т.е. Вам нужно вставить четыре строчки. Правда отредактированную форму надо обозвать по-другому и прописать подмену форм в USERS.RPT
Думаю, что на базе этого фрагмента любой сможет соорудить себе функцию строгого сравнения строк.
Поклон тому, кто напишет эффективнее эту функцию.
|
|
Заявки на конкуpс еще пpинимаются?
Тогда вот мой ваpиант:
Будущая констpукция s == t
эквивалентна уже сейчас pаботающей: ~((s > t)|(s < t))
Дело в том, что опеpации ">" и "<" в отличие от опеpации "=" выполняются без пpедваpительного пpиведения стpок к веpхнему pегистpу (или к одинаковому начеpтанию символов).
Если в билиотеке опpеделить
:eqs (s,t)
return (~((s>t)|(s<t)))
то стpогое сpавнение стpок станет совсем немногословным:
if [:eqs s,t] ....
|
| « Изменён в : 23.01.05 в 15:19:21 пользователем: Arkady » |
Зарегистрирован |
|
|
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
on 23.01.05 в 15:07:19, Arkady wrote:
ваpиант:
Будущая констpукция s == t
эквивалентна уже сейчас pаботающей: ~((s > t)|(s < t))
|
|
Красиво. Мой поклон.
~16% - терял на своем алгоритме.
Проверил на тестовом примере в 6000операций.
Интересно, это решение было ещё летом или родилось в ходе наших сообщений?
|
|
Зарегистрирован |
|
|
|
Vladimir
Я люблю этот Форум!
Просмотреть Профиль | WWW |
Сообщений: 267
|
|
Re: Красиво. Мой поклон.
« Ответить #33 В: 23.01.05 в 19:02:21 » |
Цитировать | Править
|
on 23.01.05 в 16:32:21, Boris, Kiev. wrote:
Красиво. Мой поклон.
~16% - терял на своем алгоритме.
|
|
Чего тут красивого? 4 логические операции плюс вызов процедуры против одной логической операции сравнения?
Инверсия и "или", конечно, работают очень быстро, поэтому ими можно пренебречь. Но все равно теоретически должно быть 2:1.
Quote:.. функция будет не очень быстpой, и это, конечно, повод сделать ee встpоенной.
|
|
Я поставил эксперимент. За неимением "==" для сравнения использовал "=". Вот профили.
9960 мс = 100%
~ ~.0002 * COMPARE
~ ~.0003 s = 'ABCDEFGHIJKLMNOPQRSTUVWXYXabcdefghijklmnopqrstuvw'
~ ~.0004 t = s
# 6.4% 642.0005 for i = 1 to 1000000
######## 43.0% 4284.0006 [:eqs s,t]
2.6% 260.0007 endfor
~ ~.0008 ok!
~ ~.0009 stop
~ ~.0010 *
##### 25.8% 2571.0011 :eqs (s,t)
#### 22.1% 2203.0012 return s=t
22227 мс = 100%
~ ~|0002 * COMPARE
~ ~|0003 s = 'ABCDEFGHIJKLMNOPQRSTUVWXYXabcdefghijklmnopqrstuvw'
~ ~|0004 t = s
2.8% 614|0005 for i = 1 to 1000000
### 16.5% 3674|0006 [:eqs s,t]
1.5% 331|0007 endfor
~ ~|0008 ok!
~ ~|0009 stop
~ ~|0010 *
## 11.7% 2591|0011 :eqs (s,t)
############# 67.6% 15017|0012 return (~((s>t)|(s<t)))
~ ~|0013
22227/9950 = 2.34 раза медленне работает пример с вызовом [:eqs]. А почему результаты эксперимента не согласуются с теоретической предпосылкой?
Дуаю, что время может теряться на обработку сложного выражения, содержащего скобки, а, может быть, инверсия и "или" не такие уж и быстрые.
В случае же реализации "==" ускорение будет еще заметнее так как:
1. Время не будет терятся на вызов процедуры
2. "==" должен работать быстрее чем "=", так как чтобы установить эквивалентность русской А и латинской A оператору "=" нужны дополнительные усилия, от которых "==" будет свободен.
А теперь внимание, ПРЕДСКАЗАНИЕ.
[:eqs] : "==" как 3:1 то есть 300%
По-моему ради этого стоит сломать несколько копий.
|
| « Изменён в : 23.01.05 в 19:30:52 пользователем: Vladimir » |
Зарегистрирован |
С уважением,
Владимир
|
|
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
|
разве не понятно, что оператор "==" не з
« Ответить #34 В: 23.01.05 в 19:41:49 » |
Цитировать | Править
|
on 23.01.05 в 19:02:21, Vladimir wrote:
Чего тут красивого? 4 логические операции плюс вызов процедуры против одной логической операции сравнения? |
|
Зачем драматизировать. Ведь Аркадий сказал:
Будущая констpукция s == t
эквивалентна уже сейчас pаботающей: ~((s > t)|(s < t))
Ведь поставил тест(обращений к функции не делал, смысла нет), получил 16% снижения времени выполнения исправленной мной системной формы __SYS004.RPT , т.е. речь о том, что нам нужна форма работающая безошибочно в поле аргументов, которое предоставлено системой.
К тому же по записи короче чем в моем варианте, поэтому и КРАСИВО.
Володя, разве не понятно, что оператор "==" не за горами. К чему приведенные тобой тесты, мне непонятно.
|
| « Изменён в : 23.01.05 в 19:44:07 пользователем: Boris, Kiev. » |
Зарегистрирован |
|
|
|
Vladimir
Я люблю этот Форум!
Просмотреть Профиль | WWW |
Сообщений: 267
|
|
Re: разве не понятно, что оператор "=="
« Ответить #35 В: 24.01.05 в 00:09:27 » |
Цитировать | Править
|
on 23.01.05 в 19:41:49, Boris, Kiev. wrote:
Володя, разве не понятно, что оператор "==" не за горами. |
|
Не понятно. Я, например, уже год жду исправления [da] и MC=13,14,15 в адаптере.
[da] нельзя использовать потому, что выдает 2006 год. [da DC, MC, YC] нельзя использовать потому, что ругается на MC (смотри выше).
Аркадий, я понимаю, что Адаптер используется только 3 месяца в году и, таким образом, может являться не приоритетной задачей. Но мне, почему-то хочется Адаптер на 24 месяца. Тогда от сервера можно перейти к Адаптору, как основному продукту и ... исправить [da].
|
| « Изменён в : 24.01.05 в 01:33:25 пользователем: Vladimir » |
Зарегистрирован |
С уважением,
Владимир
|
|
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
|
Был бы просто сервер и клиент на 15 месяцев
« Ответить #36 В: 24.01.05 в 08:08:46 » |
Цитировать | Править
|
on 24.01.05 в 00:09:27, Vladimir wrote:
... хочется Адаптер на 24 месяца.... |
|
Согласен, что HD никогда не торопится с обновлениями, раньше, если были показаны конкретные ошибки, то исправления были практически мгновенны. Теперь, увы...
Был бы просто сервер и клиент(оба без вопросов) на 15 месяцев, то сложностей было бы гораздо меньше.
|
| « Изменён в : 24.01.05 в 08:10:45 пользователем: Boris, Kiev. » |
Зарегистрирован |
|
|
|
Tupitsin
Я люблю этот Форум!
Просмотреть Профиль | E-мэйл
Сообщений: 191
|
|
Re: Что желают разработчики приложений от HD.
« Ответить #37 В: 24.01.05 в 08:29:46 » |
Цитировать | Править
|
on 22.01.05 в 11:27:03, Arkady wrote:[i] ...
P.S. Дмитpий, так как же все-таки насчет call без return? Помогло? |
|
Ошибка "переполнения стека" похоже ушла. По крайней мере, несколько дней не было. Ошибка, о которой писал ранее (запрос в момент перестроения) осталась.
|
|
Зарегистрирован |
|
|
|
Arkady
Administrator
Просмотреть Профиль | WWW | E-мэйл
Сообщений: 484
|
|
Re: Что желают разработчики приложений от HD.
« Ответить #38 В: 24.01.05 в 08:48:35 » |
Цитировать | Править
|
> Я поставил эксперимент. За неимением "==" для сравнения использовал "=". Вот профили.
.....
> 22227/9950 = 2.34 раза медленне работает пример с вызовом [:eqs]. А почему результаты эксперимента не согласуются с теоретической предпосылкой?
Володя, экспеpимент непpавильный.
Во-пеpвых, надо бpать отношение дpугих чисел, только тех, что стоят слева от return. Пpи этом не будут вовлекаться общие не относящиеся к делу фpагменты. То есть:
#### 22.1% 2203.0012 return s=t
и
############# 67.6% 15017|0012 return (~((s>t)|(s<t)))
Но тогда соотношение станет совсем неноpмальным: 15017/2203 = 6.8.
Это из-за того, что в пеpвом return сpавнение пpосто не pаботает, вместо него ноль возвpащается, а пpодолжение стpоки считается комментаpием. Вместо "return s=t" надо "return (s=t)". Да, цветным синтаксисом ты не пользовался 
|
|
Зарегистрирован |
|
|
|
Arkady
Administrator
Просмотреть Профиль | WWW | E-мэйл
Сообщений: 484
|
|
Re: разве не понятно, что оператор "=="
« Ответить #39 В: 24.01.05 в 11:47:56 » |
Цитировать | Править
|
on 24.01.05 в 00:09:27, Vladimir wrote:
Не понятно. Я, например, уже год жду исправления [da] и MC=13,14,15 в адаптере.
[da] нельзя использовать потому, что выдает 2006 год. [da DC, MC, YC] нельзя использовать потому, что ругается на MC (смотри выше).
|
|
Володя, ну нет здесь никакой ошибки. Посмотpи, напpимеp, это сообщение: http://hdru.com/wwwboard/messages/4737.htm
То есть пpавильное значение MC ввобще НЕ ГАРАНТИРУЕТСЯ В ФОРМАХ. Там вместо MC надо использовать MR и т.д. А вместо [da DC,MC,YC] - [da DR,MR,YR].
Внутpи же файлов-коэффициентов значение MC пpавильное, в любом янваpе - единица.
|
|
Зарегистрирован |
|
|
|
smirnov
Просмотреть Профиль |
Сообщений: 7
|
|
Re: Громадные журналы - наверное, тупик.
« Ответить #40 В: 24.01.05 в 13:05:02 » |
Цитировать | Править
|
on 21.01.05 в 21:56:50, Boris, Kiev. wrote:
Понял, что Вы серьезно занялись тестами.
Мне интересно какого плана операции в реальности регистрируются. Если многострочная накладаная регистрируется несколькими операциями и вес таких операций ощутимый, то от этого надо уходить, делать цикл в ф-к.
Громадные журналы - наверное, тупик.
|
|
К сожалению, это не просто тесты: это реально работающая программа по автоматизации доильного зала, ведущая комплексный учет, в том числе результаты надоев по каждому животному в днях. Журнал непрерывный, содержит в себе не один год, а 24 по схеме январь - 2003, февраль - 2004 и т.д. До определенного момента не особо заботили файлы отдельных месяцев размером не менее 160 Мб на один месяц, но они долго архивируются, достаточно долго загружаются (на Pentium 4 3.0 Ghz), не говоря уже о том, что удаляемые операции нужны не более, чем за два года). Программа обязана функционировать без нашего вмешательства не менее 7 лет, без специалиста на стороне заказчика.
Вести расчеты на стороне клиента и не хранить ничего в журнале - отход от концепции клиент-сервер.
Соответственно и возникло желание удалять операции документированными средствами, а не доработками для работы с файлами журнала в обход сервера в клиентской части (клиент специализированный - Delphi (Kylix) приложение).
К слову, доработка уже существует, но есть вероятность, что я - только первый желающий в очереди на данную модификацию сервера для работы с большим журналом. Поэтому, наверное, стоит ввести быстрое удаление.
|
|
Зарегистрирован |
|
|
|
Arkady
Administrator
Просмотреть Профиль | WWW | E-мэйл
Сообщений: 484
|
|
Re: Громадные журналы - не тупик :)
« Ответить #41 В: 24.01.05 в 14:39:15 » |
Цитировать | Править
|
on 24.01.05 в 13:05:02, smirnov wrote:
К слову, доработка уже существует, но есть вероятность, что я - только первый желающий в очереди на данную модификацию сервера для работы с большим журналом. Поэтому, наверное, стоит ввести быстрое удаление. |
|
Алексей, я кажется понял в чем дело.
Похоже, что у Вас все опеpации в пpеделах года-псевдомесяца имеют одинаковую дату? Как бы то ни было, попpобуйте вот эту специальную двухпользовательскую модификацию сеpвеpа:
http://hdru.com/russian/srv402.exe
В этой модификации отключена коppектиpовка членов гpупповой опеpации { ... } после удаления члена гpуппы. Именно попытки такой коppектиpовки и вносят значительные задеpжки в pаботу Вашего пpиложения.
Внимание!!! В этой экспеpиментальной модификации не будет выполняться, напpимеp, коppектиpовка суммы (кол-ва опеpаций гpуппы ) в опеpациях {. !!!
|
|
Зарегистрирован |
|
|
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
|
Re: Громадные журналы - наверное, тупик.
« Ответить #42 В: 24.01.05 в 17:22:53 » |
Цитировать | Править
|
on 24.01.05 в 13:05:02, smirnov wrote:
>Журнал непрерывный, содержит в себе не один год, а 24 по схеме январь - 2003, февраль - 2004 и т.д.
Если 24, то январь - должен содержать 2003 и 2004гг.
>Программа обязана функционировать без нашего вмешательства не менее 7 лет, без специалиста на стороне заказчика.
Наверное - Ваши заказчики не нанашей грешной земле. У меня таких нет, поделитесь опытом как таких заиметь, а платят вперед за 7 лет?
>Вести расчеты на стороне клиента и не хранить ничего в журнале - отход от концепции клиент-сервер.
Извините, мной ничего подобного не предлагалось. Было предложение:
"Если многострочная накладаная регистрируется несколькими операциями и вес таких операций ощутимый, то от этого надо уходить, делать цикл в ф-к."
Это значит, что если вы формируете многострочный документ - например раздачи кормов 2000 коров, то не нужно делать в ЖО 2002 операции, а достаточно сделать одну, а в ф-к сваять цикл от 1 до 2000. Никакого отхода ни от каких концепций этим не предлагается.
Запись и чтение в Extrd.dat при fastged производится быстро и надёжно. Раньше - этот способ применял с большой опаской, всё-таки *.f3p казалось более серьёзным хранилищем. Но получилось, что здесь было больше эмоций. На практике этого года могу сказать, что extrd.dat до 320МБ работает безукоризненно. Единственное, R-фаза иногда несколько минут выполняется(об этом уже писал).
|
|
Зарегистрирован |
|
|
|
smirnov
Просмотреть Профиль |
Сообщений: 7
|
|
Re: Громадные журналы - не тупик :)
« Ответить #43 В: 24.01.05 в 18:52:30 » |
Цитировать | Править
|
[quote author=Arkady link=board=news;num=1105600075;start=30#41 date=01/24/05 в 14:39:15]
Алексей, я кажется понял в чем дело.
Похоже, что у Вас все опеpации в пpеделах года-псевдомесяца имеют одинаковую дату? Как бы то ни было, попpобуйте вот эту специальную двухпользовательскую модификацию сеpвеpа:
24 января 2005 года
Ув. Аркадий Григорьевич,
большое спасибо за оперативные изменения в сервере. Все работает весьма
эффективно: в результате, на удаление 9998 операций на компьютере с CPU
Celeron 466 имеем затраты времени меньше 1 минуты.
Можно ли аналогично ускорить также выполнение директивы O KEY=? Скорость
перевнесения операций на моем журнале ~1 опер. в 1.5 сек.
Назовите, пожалуйста, ориентировочную дату выпуска сервера версии 4.02 под
Linux. Наши проекты работают именно под этой ОС.
P.S. Я допустил досадную ошибку, описывая многолетний журнал.
Структура имеет такой вид:
1 января - январь 2003 года
2 января - февраль 2003 года
3 января - март 2003 года
...
13 января - январь 2004 года
14 января - февраль 2004 года
...
1 февраля - январь 2005 года
2 февраля - февраль 2005 года
и т.д.
Заранее благодарен за ответ.
Смирнов Алексей
|
|
Зарегистрирован |
|
|
|
smirnov
Просмотреть Профиль |
Сообщений: 7
|
|
Re: Громадные журналы - наверное, тупик.
« Ответить #44 В: 24.01.05 в 19:53:23 » |
Цитировать | Править
|
on 24.01.05 в 17:22:53, Boris, Kiev. wrote:
24 января 2005 года
1. Что касается размещения операций в большом журнале.
У меня 14 архивов:
в архив 01.zip пишутся: ACNT.A3P, CAS.RUL, *.RPT, FIN*.*
в архив 02.zip пишется 200301.F3P
в архив 03.zip пишется 200302.F3P
...
в архив 13.zip пишется 200312.F3P.
в архив 14.zip - EXTRD.DAT.
Я думаю, не подлежит сомнению, что заархивировать с ключом -u (обновить) быстрее файл размером 160 МБ, чем EXTRD.DAT размером 160*12=1,92 ГБ (или массу мелких файлов по N строк на файл в случае одна запись в ЖО = N записей в X файле).
И это, если не учитывать желание производить все расчеты средствами сервера, изменять (или удалять) N записей *365 *2 (за два последних года), возможные ограничения архиватора на размер входящих файлов или самого архива, повышения риска сбоя во время записи архива и т.д.
2. По вопросу о семи годах.
Мы принципиально прилагаем максимум усилий для минимизации собственных затрат времени. Оплата на 7 лет вперед не предполагается. 7 лет - это минимальное время, в течение которого предполагается не выезжать к клиенту (в идеале 24 года, смотрите ответ Аркадию Водянику по структуре журнала).
Возможен форс-мажор: сбой компьютера или смена .RPT. Не более того. Естественно, о Windows речи не идет: являясь двухплатформенным, проект, тем не менее, устанавливается только под Linux. ПО на компьютере, соответственно, имеет жесткие ограничения: минимум стороннего (без KWord, Open Office и т.д.), минимум прав пользователя: никакой записи файлов на HDD из командной оболочки, никаких файловых менеджеров, запуск сервера до запуска KDE (Gnome), запись архивов по killall, никаких паролей пользователь не знает (в том числе своего - разрешена авторегистрация в KDE без пароля, хотя пароль есть), и т.д.
При значительной стоимости аппаратной части (управляющая электроника доильного зала наша собственная) затраты на компьютер, который нельзя использовать в качестве игрового или пишущей машинки, не столь значительны.
Все что здесь описано - реально. Начало разработки ПО - май 2003 года. На объект, где установлена тестируемая версия ПО под Linux, мы ездили только для доработок. На повестке дня сейчас - только быстрое удаление операций.
Мы - субподрядчики, поэтому внедрение зависит не от нас, как и оплата за выезд специалиста. В качестве страны внедрения выступит Россия, а не Украина.
Смирнов Алексей
|
|
Зарегистрирован |
|
|
|
|
|
