Теоретически можно брать байты из файла и выполнять как код?

← →
AV © (2012-10-03 13:01) [40]

> Rouse_ © (03.10.12 12:49) [39]

Конечно, помню. И еще раз, спасибо

Ну ты, еще кто-то - таких немного :)

К Студенту я придрался, к словам "прекрасно видно". Не прекрасно. Нужен опыт, который у единиц.
В целом, и я сам это говорю, сломать можно все. Я про
Да, ладно, уже ни про что, проехали :) Показалось, что -то немного новое придумал (за несколько минут :))

← →
Дмитрий С © (2012-10-03 13:46) [41]

> AV © (03.10.12 13:01) [40]

Ни что не мешает сдампить склеенный EXE-шник с памяти. Думаю так это и сломается, если не проще.

>
> Давай, генерация кода в динамике - это кошерно. Байткод
> генерил или через асмпрепроцессор?

Не думал что тебя это может заинтересовать.

unit FunctionBind; interface uses Windows; type PStdcallFunctionBind_TFunction = ^TStdcallFunctionBind_TFunction; TStdcallFunctionBind_TFunction = packed record { Добавление еще одного параметра к вызову функции pop eax 58 push LParam 68 push eax 50 push JmpAddress 68 ret c3 } i1, i2: byte; // 58 68 LParam: DWord; i3, i4: Byte; // 50 68 Proc: DWord; i5: Byte; // c3 end platform; TStdcallFunctionBind=class(TObject) private FBindedProc: PStdcallFunctionBind_TFunction; function GetBindedProc: Pointer; public constructor Create(Proc: Pointer; LParam: Pointer); destructor Destroy; override; property BindedProc: Pointer read GetBindedProc; end platform; procedure TStdcallFunctionBind_TFunction_Init(P: PStdcallFunctionBind_TFunction); implementation { TFunctionBind.TFunction } procedure TStdcallFunctionBind_TFunction_Init; begin with P^ do begin i1 := $58; i2 := $68; i3 := $50; i4 := $68; i5 := $c3; end; end; { TStdcallFunctionBind } constructor TStdcallFunctionBind.Create(Proc, LParam: Pointer); begin FBindedProc := VirtualAlloc(nil, SizeOf(FBindedProc^), MEM_COMMIT or MEM_RESERVE, PAGE_EXECUTE_READWRITE); TStdcallFunctionBind_TFunction_Init(FBindedProc); FBindedProc^.LParam := DWord(LParam); FBindedProc^.Proc := DWord(Proc); end; destructor TStdcallFunctionBind.Destroy; begin VirtualFree(FBindedProc, 0, MEM_RELEASE); inherited; end; function TStdcallFunctionBind.GetBindedProc: Pointer; begin Result := FBindedProc; end; end.

← →
Дмитрий С © (2012-10-03 13:50) [42]

> Rouse_ © (02.10.12 20:42) [20]

Работая у вас я хотел сделать калькулятор, который компилирует формулу и выполняет ее на процессоре, но тот факт что оперировать нужно было с extended-ом меня спугнул и я не стал этого делать.

← →
Rouse_ © (2012-10-03 19:42) [43]

> Ну ты, еще кто-то - таких немного :)

Гораздо больше, чем ты думаешь :) Не каждый второй, конечно, но гораздо больше...

> Дмитрий С © (03.10.12 13:46) [41]

Понятно, байткод, а зачем кстати? И как потом стек выравниваешь?

> Работая у вас я хотел сделать калькулятор, который компилирует
> формулу и выполняет ее на процессоре

А это еще зачем? :) У нас вроде таких задач не было ни тогда ни сейчас. Кстати именно такая задача как раз достаточно просто решается, главное чтобы парсер не сбойнул, а потом пробегаем по вектору (стеку/дереву - смотря какой парсер выражений) генерируя соответствующие инструкции в нужно порядке.

← →
Rouse_ © (2012-10-03 19:46) [44]

ЗЫ: забыл...

> antonn © (03.10.12 00:48) [26]
> например хеширующая функция без глобальных переменных, почему
> бы нет?

Ну да - если она выполнена в виде базонезависимого кода, то почему-бы и нет? :)

← →
Дмитрий С © (2012-10-03 21:21) [45]

> Понятно, байткод, а зачем кстати? И как потом стек выравниваешь?

добавляет к вызову параметр self. чтобы в качестве обычной процедуры передать метод класса с указание экземпляра. Стек выравнивает сам метод.

> А это еще зачем? :) У нас вроде таких задач не было ни тогда
> ни сейчас.

Оптимизировал калькулятор (вычислитель формул), чтобы быстрее работал.

← →
Rouse_ © (2012-10-03 21:41) [46]

> добавляет к вызову параметр self

А ясно - ну... ненаказуемо :)

> Оптимизировал калькулятор (вычислитель формул), чтобы быстрее
> работал.

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

← →
Дмитрий С © (2012-10-03 21:46) [47]

> А, оть ты про что, понятно - это щас Олегыча задача :)

Любопытно узнать что он оптимизировал после меня:)

← →
Rouse_ © (2012-10-03 21:53) [48]

> Любопытно узнать что он оптимизировал после меня:)

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

← →
Ega23 © (2012-10-03 22:31) [49]

Я пшероше прощеня, но внятно я смогу ответить только завтра.
Так получилось... :)

← →
Rouse_ © (2012-10-03 22:35) [50]

> Ega23 © (03.10.12 22:31) [49]
> Я пшероше прощеня,

:)))))))))))))
Ну короче Дим ты понял, оптимизации подверглось все, как-то так :)

← →
Дмитрий С © (2012-10-04 00:18) [51]

> Ну короче Дим ты понял, оптимизации подверглось все, как-
> то так :)

Насколько я помню, я там живого места для оптимизации не оставил :) И мне правда интересно, ну для саморазвития.

← →
Германн © (2012-10-04 01:54) [52]

> И мне правда интересно, ну для саморазвития.

И мне тоже, пожалуйста.
:)

← →
Юрий Зотов © (2012-10-04 02:04) [53]

> хотел сделать калькулятор, который компилирует
> формулу и выполняет ее на процессоре

Зачем изобретать велосипед, если точно такие есть готовые?

> Оптимизировал калькулятор ... чтобы быстрее работал.

Зачем, если он и так срабатывает практически мгновенно?

← →
Германн © (2012-10-04 02:22) [54]

> Юрий Зотов © (04.10.12 02:04) [53]
>
> > хотел сделать калькулятор, который компилирует
> > формулу и выполняет ее на процессоре
>
> Зачем изобретать велосипед, если точно такие есть готовые?
>
>

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

← →
Inovet © (2012-10-04 02:44) [55]

> [53] Юрий Зотов © (04.10.12 02:04)
> > Оптимизировал калькулятор ... чтобы быстрее работал.
>
> Зачем, если он и так срабатывает практически мгновенно?

Там же наверняка наворочанные расчёты прописаны, а не пользователь тычет кнопки.

← →
Ega23 © (2012-10-04 08:26) [56]

Да не оптимизировал я там ничего, скорость вполне устраивает. Дорабатывал, скорее.

← →
palva © (2012-10-04 08:55) [57]

Когда нас учили программированию (делфи не было, ассемблера тоже) нам рассказывали как писать циклы. У нас было формирование и переадресация. Формирование, это когда к заготовке команды прибавляется счетчик цикла, получается команда, которая записывается в тело цикла. Переадресация, это когда в рабочей команде наращивается адрес прибавлением шага цикла. Еще было много премудростей типа, где лучше делать проверку выхода из цикла. Разве теперь, когда учат программированию, не с этого начинают?

← →
Юрий Зотов © (2012-10-04 09:55) [58]

> Германн © (04.10.12 02:22) [54]
> Ну ясен пень, Юр, что они между собой говорят отнюдь не
> о том калькуляторе, который от MS.

Ясен пень, я тоже не о нем. Еще в 1999г. в одном из проектов мы использовали сторонний компонент Delphi, который именно это и делал - один раз компилировал формулу (записанную в виде строки) в машинный код, а затем сколько угодно раз этот код выполнял.

> Inovet © (04.10.12 02:44) [55]
> Там же наверняка наворочанные расчёты прописаны, а не пользователь
> тычет кнопки.

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

← →
Inovet © (2012-10-04 10:14) [59]

> [58] Юрий Зотов © (04.10.12 09:55)

Формулы может и простые, но их много и расчёт в цикле по многим объектам.

← →
Юрий Зотов © (2012-10-04 10:35) [60]

> Inovet © (04.10.12 10:14) [59]

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

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

← →
Inovet © (2012-10-04 12:40) [61]

> [60] Юрий Зотов © (04.10.12 10:35)
> Для таких случаев тоже нужна подпрограмма, а не калькулятор

Ну так мы тут калькулятором назвыаем то, что выполняет эту подпрограмму. А чем не реальная задача, когда расчёт вынесен в настройки программы? Зарвнее неизвестно, что там будет.

← →
Юрий Зотов © (2012-10-04 13:24) [62]

> Inovet © (04.10.12 12:40) [61]
> Ну так мы тут калькулятором назвыаем то, что выполняет эту
> подпрограмму. А чем не реальная задача, когда расчёт вынесен
> в настройки программы? Зарвнее неизвестно, что там будет.

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

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

← →
Inovet © (2012-10-04 13:35) [63]

> [62] Юрий Зотов © (04.10.12 13:24)
> либо они откуда-то считываются (и тогда не нужен никакой
> калькулятор, все вычислит сама программа).

Вот о том и речь - в каком коде они выполнятся: в нативном или в каком-то другом. Не пойму, с чем ты не согласен.

← →
Юрий Зотов © (2012-10-04 13:50) [64]

> Inovet © (04.10.12 13:35) [63]
> Не пойму, с чем ты не согласен.

С тем, что от калькулятора требуется максимально высокая скорость.

← →
Rouse_ © (2012-10-04 14:06) [65]

> Юрий Зотов © (04.10.12 13:50) [64]
> С тем, что от калькулятора требуется максимально высокая
> скорость.

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

← →
Дмитрий С © (2012-10-04 14:09) [66]

> одного числа приводит к двух/трехсекундной заморозке приложения,
> что категорически не удобно при работе...

а у вас сколько?

интересно, а как быстро excel считает.

← →
картман © (2012-10-04 14:18) [67]

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

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

← →
Rouse_ © (2012-10-04 14:19) [68]

> а у вас сколько?

Ну тыж помнишь - практически мгновенно.
Тормоза можно конечно получить, но сметы такого объема никто не делает :)

> Ты явно где-то ошибаешся в своих предположениях :)

знаю - иначе бы и не спрашивал

> картман © (04.10.12 14:18) [67]

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

Да и математика у сметчиков достаточно странная, не как у всех, до сих пор ей удивляюсь :)
Ну например в одной из методик есть понятие округление до N значащих цифр, как это выглядит на практике, например мы округляем до двух значащих, и вот такую картинку получим:

123456 = 120000
0.0123 = 0.012

А это реально применяется при расчетах :)

> Т.е. грубо числа в каждой позиции это результат последовательного
> вычисления цепочки формул...

ну ничего себе, обалдеть! (прости, не удержался)

> раньше приходилось писать новую смету

т.е. раньше тоже ручками проводили миллионы вычислений из-за изменений одного числа в смете с парой сотен позиций?

> Ну например в одной из методик есть понятие округление до
> N значащих цифр, как это выглядит на практике, например
> мы округляем до двух значащих, и вот такую картинку получим:
>
>
> 123456 = 120000
> 0.0123 = 0.012

я когда проектировщиком работал всегда округлял в большую сторону))

Rouse_ ©
> 123456 = 120000
> 0.0123 = 0.012

а не
123456 = 123456.000
0.0123 = 0.012
?

где логика.. :)

>> palva © (04.10.12 08:55) [57]
нет, нас не так, к сожалению

>
> где логика.. :)

> Ну например в одной из методик есть понятие округление до
> N значащих цифр

> т.е. раньше тоже ручками проводили миллионы вычислений из-
> за изменений одного числа в смете с парой сотен позиций?

Зачем? Как ты будешь формулы на листе бумаги то хранить?
Туда помещаются уже результаты того, что насчитали на калькуляторе.
А с использованием ПО появилась возможность автоматизировать процесс рассчета.

Например вот тебе с форума сметчиков цитата:

а я иногда, когда смету под сумму приходится подгонять, пользуюсь идентификаторами и объемы по связанным позициям задаю формулами... меняю один объем - меняются все объемы по связанным позициям - и нет угрозы пропустить что-нибудь... допустим есть объем монтажа трубы 50 - 10м, задаем Т50 идентификатор, в объеме демонтажа ставим Т50, объем гидравлики Т50, объем огрунтовки например 0,31*Т50, окраски то же... поставив вместо 10 м 12 м нет нужды вручную пересчитывать объемы

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

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

Во, нашел примерчик. В свое время нам прислали смету с проектного института и пожаловались на то что в некоторых позициях округление плывет (как раз после этого запроса я и написал вот этот набор функций): http://rouse.drkb.ru/other.php#round

Начал проверять - вроде округляет правильно если само число вводить, а если передавать на алгоритм то что начитал по позиции калькулятор - ошибка.
Пришлось отключать калькулятор и проводить все манипуляции ручками.
И получился вот такой код - это то что происходит в данной смете при рассчете только одной ячейка в позиции, т.к. используется куча пользовательских формул. а что они означают я не знаю! (в коде все формулы обозначены так-же как они были в смете, т.е. Fxxx, результат в переменной Ex)

var F30, F32, F50, F52, F60, F62, F70, F72, F90, F92, F120, F122, F100, F102, F203, F213, F223, F233, F301, F305, F306, F307, F308, F600, F601, F602, F603, F604, F605, F606, F607, F608, F609, F610, F611, F3001, F5001, F6001, F162, F16001, F160, F7001, F132, F130, F17001, F232, F23001, F230, F6080, F172, F170, F192, F19001, F190, F33, F43, F53, F63, F73, F83, F93, F103, F113, F123, F133, F143, F153, F163, F173, F183, F193, F9001, F11001, F12001, F13001: Double; Ex: Extended; I: Integer; begin F30 := GsSimpleRoundTo((24.86 + 24.79 + 25.13 + 25.47 + 25.41 + 25.46 + 25.56 + 25.33 + 24.49 + 24.82 + 26.07 + 26.92 + 26.98 + 26.13 + 24.19 + 23.6 + 23.21 + 22.51) / 18, -3); F32 := 9.25 + 38.1 + 23.88 + 34.75 + 6.59 + 22.81 + 37.96 + 18.95 + 56.61 + 31.58 + 55.45 + 42.68 + 32.81 + 50.49 + 24.9 + 27.41 + 52.0; F50 := GsSimpleRoundTo((21.23 + 21.26 + 21.82 + 22.37 + 21.94 + 21.66 + 21.85 + 22.22 + 22.15 + 22.26 + 22.15 + 22.33 + 22.03 + 22.07 + 21.93 + 21.93 + 22.03 + 22.19 + 22.14 + 22.51 + 22.08) / 21, -3); F52 := 18.0 + 34.58 + 27.0 + 38.93 + 41.63 + 40.24 + 32.9 + 22.62 + 8.48 + 17.96 + 20.13 + 14.1 + 19.48 + 26.83 + 13.0 + 8.2 + 27.0 + 18.81 + 16.62 + 33.46; F60 := GsSimpleRoundTo((24.3 + 24.39 + 24.32 + 24.16 + 24.03 + 23.94 + 23.66 + 23.51 + 23.08 + 22.82 + 22.58 + 22.19 + 22.15) / 13, -3); F62 := 13.67 + 51.61 + 41.63 + 65.53 + 23.61 + 26.52 + 19.73 + 43.14 + 20.53 + 24.47 + 18.85 + 25.15; F70 := (24.68 + 24.6 + 24.82 + 25.0 + 25.47 + 24.8 + 24.79 + 23.95 + 25.92 + 26.13) / 10; F72 := 2.56 + 39 + 16.11 + 5.71 + 9.79 + 8.19; F90 := GsSimpleRoundTo((18.95+19.1+20.20+22.06+21.9+22.15+22.05+21.66)/8, -3); F92 := 21.13+65.0+49.21+21.59+57.9+22.0; F100 := GsSimpleRoundTo((21.81+22.09+23.12+22.45+22.17+22.37+22.81+22.67+21.85+21.94+22.15+22.18+22.22)/13, -3); F102 := 18.4+17.26+36.34+49.46+28.78+5.33+41.84+9.06+8.00; F120 := GsSimpleRoundTo((25.49+24.84+24.97+24.83+25.02+25.28+25.56+24.85+24.83+25.0+25.02+25.19+25.28+24.8+24.97)/15, -3); F122 := 24.45+42.66+15.34+21.61+11.62+17.73+3.87+7.21+2.5+20.51; F33 := 8829.05; F43 := 763.27; F53 := 10243.41; F63 := 5293.07; F73 := 578.34; F83 := 1641.62; F93 := 1981.41; F103 := 2595.95; F113 := 1427.34; F123 := 918.8; F133 := 1106.77; F143 := 594.33; F153 := 178.44; F163 := 2703.64; F173 := 557.95; F183 := 222.78; F193 := 3036.38; F203 := 748.78; F213 := 3074.18; F223 := 1607.2; F233 := 277.51; F301 := F33+F43+F53+F63+F73+F83+F93+F103+F113+F123+F133+F143+F153+F163+F173+F183+F193+F203+F213+F223+F233; F305 := 309.45 + 15.44 + 55.74; F306 := GsSimpleRoundTo(620.0+0.785*0.16*0.16*193.9+0.785*0.25*0.25*66.9+0.785*0.315*0.315*869.1+0.785*0.4*0.4*2317.8+0.785*0.5*0.5*345.4+0.785*0.6*0.6*33.5, -2); F307 := F305 + F306; F308 := F301 - F307; F3001 := GsSimpleRoundTo((25.5 + 25.51 + 25.34 + 25.74 + 25.52 + 25.62 + 25.48 + 25.78 + 25.6 + 24.85 + 26.17 + 26.1 + 27.17 + 25.65 + 23.52 + 23.19 + 22.8 + 22.11) / 18, -3); F600 := F32 * 7.938 * (F3001 - F30); F5001 := GsSimpleRoundTo((21.26 + 21.73 + 22.22 + 22.61 + 22.43 + 22.27 + 22.1 + 22.25 + 22.34 + 22.31 + 22.23 + 22.13 + 22.19 + 21.88 + 22.13 + 22.10 + 22.15 + 22.29 + 22.3 + 22.11 + 22.15) / 21, -3); F601 := F52 * 9.274 * (F5001 - F50); F6001 := GsSimpleRoundTo((24.23 + 24.35 + 24.49 + 24.42 + 24.09 + 23.85 + 23.59 + 23.40 + 23.05 + 22.73 + 22.6 + 22.40 + 22.34) / 13, -3); F602 := F62 * 7.562 * (F6001 - F60); F7001 := (25.21 + 25.38 + 24.85 + 25.4 + 25.74 + 25.45 + 25.51 + 23.82 + 24.94 + 25.65) / 10; F603 := F72 * 5.392 * (F7001 - F70); F9001 := GsSimpleRoundTo((19.5+19.8+20.87+22.19+22.1+22.23+22.40+22.27)/8, -3); F604 := F92 * 5.84 * (F9001 - F90); F11001 := GsSimpleRoundTo((22.95+22.9+22.6+22.13+22.13)/5, -3); F605 := F102 * 7.004 * (F11001 - F100); F12001 := GsSimpleRoundTo((24.81+25.1+24.93+25.09+25.22+25.13+25.48+25.1+25.09+25.25+25.22+25.14+25.13+24.57+24.93)/15, -3); F606 := F122 * 4.752 * (F12001 - F120); F132 := 8.9+21.09+24.83+36.94+14.0+18.11+7.81+7.76+12.35+9.96+17.19+6.15+6.75; F13001 := GsSimpleRoundTo((24.62+25.02+25.14+24.9+24.7+24.65+24.49+24.16+24.42+23.89+24.09+25.14+25.02+24.74+24.9+24.79+24.65+24.52+24.65+23.09+23.03)/21, -3); F130 := GsSimpleRoundTo((24.25+24.26+23.38+23.38+24.21+24.14+24.32+24.23+24.16+24.01+24.03+24.36+24.26+24.35+23.38+24.13+24.14+24.12+24.14+23.03+22.99)/21, -3); F607 := F132 * 4.87 * (F13001 - F130); F172 := 8.44+16.02+3.59+11.43+13.1; F17001 := (23.98+23.88+23.54+23.88+23.88+23.78+23.33+22.05+22.1)/9; F170 := (24.0+23.82+23.52+23.82+23.82+23.77+23.68+22.0+21.9)/9; F608 := F172 * 6.564 * (F17001 - F170); F192 := 5.3+6.33+2.05+12.68+22.8+31.74+15.21+10.91+9.32+8.51+12.13+6.86+3.86+15.82+23.61+8.2+8.65+2.07+28.3+10.69+12.5+11.03+11.92+10.49; F19001 := GsSimpleRoundTo((22.25+22.15+22.3+22.31+22.1+22.1+21.95+22.27+21.79+22.10+21.71+22.1+22.37+22.61+22.75+22.85+21.81+22.13+21.95+21.79+21.88+21.89+22.10+22.22+22.29+22.85+22.9+21.88+22.1+22.25+22.19+20.85+20.87+22.63+22.60+22.3+22.13+21.23+20.87+22.85+22.6+22.3+22.19+23.5+23.15)/43, -3); F190 := GsSimpleRoundTo((22.2+22.03+22.3+22.26+22.1+22.02+21.97+21.66+22.01+21.85+21.78+21.85+22.19+22.37+22.52+22.45+21.76+22.23+21.84+22.06+22.07+21.86+21.93+22.34+22.19+23.28+22.95+21.77+21.9+21.65+22.06+20.13+20.2+22.45+22.67+22.3+22.41+20.57+20.2+22.5+22.58+22.25+22.03+23.25+22.67)/45, -3); F609 := F192 * 6.51 * (F19001 - F190); F232 := 25.47; F23001 := (21.89+22.19)/2; F230 := (21.84+22.06)/2; F610 := F232 * 6.65 * (F23001 - F230); F162 := 18.78+45.84+10.08+60.0+65.6+7.75; F16001 := GsSimpleRoundTo((22.12+22.68+22.05+20.66+20.55+22.05+22.3+22.45+22.3)/9, -3); F160 := GsSimpleRoundTo((21.9+22.06+22.05+20.68+20.55+22.05+22.14+22.4+22.14)/9, -3); F6080 := F162 * 7.254 * (F16001 - F160); F611 := GsSimpleRoundTo(F600 + F601 + F602 + F603 + F604 + F605 + F606 + F607 + F608 + F609 + F610 + F6080, 0); Ex := (F308 + F611) * 0.1 * 0.01;

Как тебе картинка? :)

> Rouse_ © (04.10.12 14:06) [65]
> при изменении одного единственного числа или формулы в большинстве
> случаев приходится пересчитывать практически все

То есть, смету фактически считает калькулятор, а не сама программа?

Теоретически можно брать байты из файла и выполнять как код? Найти похожие ветки