Характерная длина - это именно порядок цифр, а не точное значение. Если запись занимает сотню-другую байт - это одно. Для мегабайтных записей алгоритм придется строить немного иначе.

erl
Зачем, не проще ли и быстрее сразу в буфере заменить все значения ff32 и ff34 на соответствующие тэги и потоv выбрать все теги в массив.

И вы еще удивляетесь тормозам? Наводящий вопрос - откуда в буфере возьмется место под тег?

asv13

Isem
А если метка находится на нечетной позиции? uint16 уже не прокатит.

Я же общий принцип указал, остальное мелочи

from numpy import *
a = memmap(r'c:\test\W1_RB.EGRID', uint8)
c = where(a==0xff)[0]					      # позиции всех элементов со значением ff
d = where((a[c+1]>0x31) & (a[c+1]<0x35))[0]    # позиции всех элементов со значениями ff32-ff34
# проверка найденных индексов
print a[c[d]] # -> [255 255 255 255 255 ...
print a[c[d]+1] # -> [51 51 51 51 51 51 51 ...

Последовательность из двух символов это просто. Хуже выполнять поиск чего-то более длинного и более сложного чем куча нолей. Тут в отличие от некоторых других языков у библиотеки numpy прямого средства нету :(, а очень жаль, по крайней мере в рассылке советуют использовать стандартный поиск в строке (вот зачем массив в строки перегонять?)

erl
хоть кусок этого файла выложить можешь? Что-то тяжеловато твой код воспринимается, проще начисто переписать. В С# тоже данные перегонял в HEX-строки ? Непойму зачем так усложнять, только для split-ов чтоли…

Кстате можно не перегонять, понимаешь в этом вся гадость этой структуры, что она переменна и у нее на каждой позиции свои поля, но ни длинны поля нет ни какоолибо идентификатора, эти поля следуют один за другим, если поле отсутствует то вместо него пишеться один байт нулей. т.о. получаеться в файле может возникнуть структура следующего вида: (давай уже в hex буду писать) 32 00 ff 34 65 a4 e4 b5 55 45 91 ff ff ff ff ff ff 56 67 ff 34 ff 32 00 ff 35 ab cb 54 66 ff ff 91 3f ff ff ff 32 …. после 32 идет некая структура и вот что бы не ошибиться преходится ее пропускать например 3 первых байта не анализировать и только потом искать ff как конец записи и проверять конец ли это тем, что смотреть следующий байт, если он равен 32 или 34 или 33(последняя запись) то обозначать ео как конец записи …
Понимаю что файл был бы полезен, но не могу его дать , а помошь требуется, понимаю что руки крявые, поэтому и спрашиваю … понимаю что структура файла мягко говоря не очнь располагает к программе в три строки, все понимаю …но что есть то есть

pyuser
erl я не совсем понял ваш алгоритм обработки :( попробуйте:

import os
import binascii
import time as _time

from io import StringIO

попробую на днях … спасибо.

PooH

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

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

минимальная длинна записи чуть меньше 50 байт, максимальная не более 500.

erl, пишите разборчиво. Ваш поток сознания нелегко читать. Наводящий вопрос: почему текст принято делить на предложения? И почему эти самые предложения в русском языке обязаны следовать правилам (простые, сложносочиненные и сложноподчиненные, причастные и деепричастные обороты)?

Андрей Светлов
erl, пишите разборчиво. Ваш поток сознания нелегко читать. Наводящий вопрос: почему текст принято делить на предложения? И почему эти самые предложения в русском языке обязаны следовать правилам (простые, сложносочиненные и сложноподчиненные, причастные и деепричастные обороты)?

Извиняюсь. Постараюсь.

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

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

Пример записи:
32 00 ff 34 65 a4 e4 b5 55 45 91 ff ff ff ff ff ff 56 67 ff 34 ff 32 00 ff 35 ab cb 54 66 ff ff 91 3f ff ff ff 32 00 ff 36 01 05 0a aa 0f ff 00 ac ff33 00 00 00 00 00 00 00 00 00 00

внутри три записи 32
одна 34
одна 33

32 00 ff 34 65 a4 e4 b5 55 45 91 ff ff ff ff ff ff 56 67 ff
34 ff
32 00 ff 35 ab cb 54 66 ff ff 91 3f ff ff ff
32 00 ff 36 01 05 0a aa 0f ff 00 ac ff
33 00 00 00 00 00 00 00 00 00 00

Первый бай тип записи, за ним три байта номер записи типа 32, ff - конец записи.
Запись типа 34 не имеет номера записи и ее длина может изменяться от 1 байта (ff - т.е пустая запись) до 300 байт.
Запись типа 33 единственная, после нее нули до конца файла.
Запись типа 34 всегда следует за 32, после 32 может быть 32, 34 или 33 записи.