On 07/30/2026 06:20 AM, Johann 'Myrkraverk' Oskarsson wrote:https://github.com/mailund/stralgOn 30/07/2026 4:47 AM, Ross Finlayson wrote:>
>>>
Thanks for writing. Good luck with that.
>
Now, if we attain to some decorum, that would be refreshing.
Yes, that indeed would be refreshing. I'll refresh myself with some
Pepsi
before continuing this followup, hold on.
>>>
>
I "know" Java and am familiar with C/C++, and computer engineering.
I just claim I know nothing, and do things anyway. I didn't know how
to parse the Intel Hex file format, before I added a "binary" loader
to the Mars MIPS emulator. You know, the one written in Java.
>
It's not finished, but I have the basics down, and should be able to
load and run "binaries" with it soon. I'll probably post screenshots
and they'll be hosted on Dropbox, so some of the other regulars won't
look. That's on them.
>Then, here the "Viswath & Charmaigne" is for the idea that there>
are generous, usual sorts of algorithms, here "findings" and
"matchings", that can be implemented vector-wise scalar-word,
then that for things like: libc, POSIX tools, parsers, and
so on, or as among "text-utils", and for character handling,
that much like many of the distributions like Linux, FreeBSD,
and so on, have developed and released and made in their tree
the vectorized versions of string functions, that, there are
abstract models of regular "text algos" that make sense for
all modern commodity architectures in their default configuration,
for the system libraries and default toolset. For example, most
all of "text-utils" involves "findings" and "matchings", in a sense,
then as with regards to "sorting" and "translation" or "transformation",
which is not addressed.
>
So I gather you're interested in algorithms that "parallel" with SIMD
and other vector machinery? And you mention "text-utils." Have you
read /String Algorithms in C/ by Mailund? He goes into the nitty gritty
details of string matching -- and you can trivially translate the code
to any other programming language as you learn from the book -- in the
context of DNA matching. At least that's how I remember the book. The
/about the author/ blurb at the start mentions he's a professor of bio-
informatics so that seems like a true memory. I'll want to read the
book again soon.
>
In any case, there are algorithms, string search amongst them, that seem
eminently serial, and I'm not quite sure SIMD and related extensions are
immediately applicable. And now I'm sure there are people -- and LLMs
-- just itching to "correct me" about that. Let them, they don't bother
me.
>>>
The mentioned initialisms are, or were, awful sci.math trolls.
In the mean time, I've gathered a few names here in comp.lang.c that I'll
probably never reply to ever again. They know who they are.
>
>
>
>
Thanks for the book reference, I'll look to it.
>
>
Decades ago when at the university I had a job working
for the biology department and what it was was making a graphical
front-end in Java to launch BLAST gene-sequence search on what
had as about 48 units / 96 cores Sun Silicon Grid Engine MPI cluster,
of Apple pizza boxes with PowerPC cores, then that also I wrote some
code for matching sequences with splitting the input and running the
cluster on the input files and chewing that up, sequences of human DNA
about 9 gigabytes, "seq-reader".
>
I made a simple dialog with making the command line arguments
for BLAST to launch, then added a features to increase or decrease
the font, that really blew their mind, these days it's often found
with "Shift-plus and Shift-minus".
>
Java's my main, if I know anything, that's what I know.
>
Mailund's string algorithm routines for FASTA files,
it's something to comprehend.
More recently the data files were often the old COBOL
or mainframe output, line-data pipe-delimited, then
having a facility with mmap and then figuring out how
to chunk it up and detect lines and then make for
processing the chunks, for example sorting the rows
of a group according to composite keys, in-place,
these are usual sorts of accounts.
The way I like to deal with columnar and tabular data
in text data files is as of a sort of "Tractable TSV",
since the data mostly never includes tab, the control
character and also horizontal whitespace, that TSV is
easier than CSV, then furthermore for nulls in the database
to emit at-sign, and for empty strings in the database to
emit tilde, since those are never the values to make for
"reserved characters" vis-a-vis "escape characters",
then Tractable-TSV or TSV is a nice simple ad-hoc format,
for text-data files on the order of gigabytes.
Which is as large as they get, ....
ETL workflows and so on.
It's remarkable that most all the data is ASCII,
or as about ISO 8859-15 <-> Microsoft CP-1252, being
ubiquitous, then as with regards to "UTF-8 everywhere",
that FASTA files have (mostly) four letters in their alphabet.
Writing a JSON and YAML parser is about the same thing,
and it's been done before, and a fast one, also.
XML is considered a bit more mature.
Then, making for "composable grammars" or these days
I suppose they call them the "polyglot" parsers,
it's not unusual. Yet, the usual descriptions for
grammars, with all the usual guarantees about the
formal automata, has that there's a layer between
the syntactical and semantical as it were that's
permeable in the accounts of, for example, balanced
pairs of parentheses and the like, optional together,
that are syntactical.
Les messages affichés proviennent d'usenet.