Интерпретация АККОМПАНЕМЕНТА 3 Поля Упакованного десятичного числа в числовые значения
Ну, это можно сделать разными способами. Итак, у вас есть коробка, а внутри коробки есть имя. Это то, что я бы попробовал сначала: вы можете разделить изображение на две горизонтальные стороны:
Затем возьмите верхнюю половину и получите самый левый пиксель, который соответствует цвету, отличному от фона, который вы можете получить, используя imagecolorat() .
Это даст вам следующие очки:
Что я считаю более реалистичным, чем присоединение цепочки к K, так как это было бы неуравновешенным.
Я не знаю, будет ли это работать в каждом отдельном случае, но вы можете настроить фазу разделения, чтобы получить более высокие или более низкие баллы. Дайте мне знать, что вы думаете.
Нужно придумать хороший способ проверить цвета пикселей, не проверяя каждый из них.
5 ответов
Вот немного другая попытка ответить на ваши вопросы.
PIC S9 (15) V9 (3) COMP-3 выглядит так в файле:
00 00 00 00 00 00 00 00 00 0F
Если значение было -4568248.323, это было бы:
00 00 00 00 04 56 82 48 32 3D
Это не поможет вам, но может помочь другим. Распакованное предыдущее значение будет выглядеть следующим образом:
F0 F0 F0 F0 F0 F0 F0 F0 F0 F4 F5 F6 F8 F2 F4 F8 F3 F2 D3 (or F3 as the last byte, therefore losing the sign)
Это поле имеет 15 (фактически 16) цифр перед десятичной запятой и 3 после.
Хотя оно запрашивает только 18 цифр (15 + 3), оно получает 19, чтобы сделать его поле четной длины со знаком (одна цифра добавляется впереди, чтобы длина файла составляла 10 байт). Лучше всего всегда делать упакованные поля нечетной длины, чтобы избежать этой путаницы.
** Последняя буква обозначает знак, C & F положительные, D отрицательный. Для вашей программы проверьте отрицательный (D) и, если нет, обработайте как положительный.
** «V» - подразумеваемая десятичная точка. его нет в файле, но COBOL знает, что он существует для округления и тому подобного. Вы должны программно учесть это. В этом файле нет ничего, что помогло бы вам определить, где оно находится, и существует ли оно вообще.
Два других поля уже имеют нечетную длину, поэтому при упаковке со знаком они могут быть сохранены в пространстве с четной длиной.
Любые другие вопросы, отредактируйте ваш вопрос или задайте его в комментариях, и кто-то постарается ответить на них за вас.
Обычно поля COMP-3 состоят из BCD цифр, упакованных в два байта за раз, каждая цифра использует полубайт (4 бита). Последняя цифра идет в верхнем клочке последнего байта. Нижний кусок последнего байта имеет 13, если число отрицательное, и что-то еще (обычно 12), если положительное. Десятичная точка подразумевается.
Например, -1,2 выглядит в шестнадцатеричном виде, конечный D - отрицательный знак.
01 2D
12.345:
12 34 5C
Здесь мы идем:
PIC - это «картинка»
S9 (15) означает 15-значное числовое поле со знаком: S для знака, 9 для чисел, (15) для длины.
V - десятичная позиция
9 (3) - это трехзначное число
, а COMP-3 - десятичное число в кодировке BCD. Каждый nybble (полубайт) поля является десятичным значением в двоичном формате, поэтому
0b01110110 (duh)
равно "76".
18 цифр требуется 9 байтов, знак - младший nybble байт младшего разряда.
Что меня беспокоит, те должны требовать 10 байт.
Вот хорошая хорошая статья об этом .
См. Метод getMainframePackedDecimal в http://jrecord.cvs.sourceforge.net/viewvc/jrecord/jrecord/src/net/sf/JRecord/Common/Conversion.java?revision. = 1.2 & view = markup
для примера преобразования упакованного десятичного числа в java (это часть проекта jrecord jrecord.sf.net)
COMP-3 fields length is calculated as number of digits that we need to store + 1 divided by 2. For example to store an numeric field of value 987 we would required 3 +1 divided by 2 = 2 Hence an Comp-3 field of length 2 bytes can store a value of +999 to -999 as the limit.
15 would stored as 01 5C. So the last four bits of the number is used to store the sign of the number that is C or D so "C" represents the positive number and "D" represents the negative number. And each numeric number takes 4 bits to represents themself.
So an 7 digit numeric number would require 7 +1 = 8 / 2 = 4 byte in size. So the comp-3 field of size 4 bytes can store an numeric digits of +999,9999 to -999,9999 digits.
In case of the above question to move the decimal portion of the number need to define an variable which can store only the decimal portion and move the value to that field which would hold just the decimal portion.
like FIELD-NAME-3 PIC S9(3)V9(6) COMP-3.
we need to define a decimal field like DEC-PORTION V9(6) comp-3 and then move the FIELD-NAME-3 to DEC-PORTION to retain the decimal part of the value.
This way we can have the decimal portion of the number separated from the full number.