Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #59213 > unrolled thread

code for 32/64 bit strtoul strtol strtoull strtoll

Back to article view | Back to comp.lang.c

Contents

  code for 32/64 bit strtoul strtol strtoull strtoll jacob navia <jacob@jacob.remcomp.fr> - 2015-03-29 17:33 +0200
    code for 32/64 bit strtoul strtol strtoull strtoll asetofsymbols@gmail.com - 2015-03-29 09:22 -0700
      Re: code for 32/64 bit strtoul strtol strtoull strtoll Barry Schwarz <schwarzb@dqel.com> - 2015-03-29 15:12 -0700
        Re: code for 32/64 bit strtoul strtol strtoull strtoll asetofsymbols@gmail.com - 2015-03-29 23:07 -0700
    Re: code for 32/64 bit strtoul strtol strtoull strtoll Barry Schwarz <schwarzb@dqel.com> - 2015-03-29 09:44 -0700
      Re: code for 32/64 bit strtoul strtol strtoull strtoll jacob navia <jacob@jacob.remcomp.fr> - 2015-03-29 19:05 +0200
        Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-29 12:15 -0700
    Re: code for 32/64 bit strtoul strtol strtoull strtoll Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-30 02:01 +0100
      Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-29 19:48 -0700
        Re: code for 32/64 bit strtoul strtol strtoull strtoll Barry Schwarz <schwarzb@dqel.com> - 2015-03-29 22:08 -0700
          Re: code for 32/64 bit strtoul strtol strtoull strtoll Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-30 12:44 +0100
            Re: code for 32/64 bit strtoul strtol strtoull strtoll Barry Schwarz <schwarzb@dqel.com> - 2015-03-30 09:04 -0700
              Re: code for 32/64 bit strtoul strtol strtoull strtoll Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-30 21:00 +0100
          Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-30 08:24 -0700
        Re: code for 32/64 bit strtoul strtol strtoull strtoll Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-30 07:21 -0700
    Re: code for 32/64 bit strtoul strtol strtoull strtoll Ian Collins <ian-news@hotmail.com> - 2015-03-30 18:02 +1300
      Re: code for 32/64 bit strtoul strtol strtoull strtoll Richard Heathfield <rjh@cpax.org.uk> - 2015-03-30 08:03 +0100
        Re: code for 32/64 bit strtoul strtol strtoull strtoll Ian Collins <ian-news@hotmail.com> - 2015-03-30 20:33 +1300
          Re: code for 32/64 bit strtoul strtol strtoull strtoll Ian Collins <ian-news@hotmail.com> - 2015-03-30 20:35 +1300
    Re: code for 32/64 bit strtoul strtol strtoull strtoll Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-30 07:27 -0700
    Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-30 09:08 -0700
    Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-30 09:29 -0700
    Re: code for 32/64 bit strtoul strtol strtoull strtoll Robert Wessel <robertwessel2@yahoo.com> - 2015-03-30 15:16 -0500
      Re: code for 32/64 bit strtoul strtol strtoull strtoll jacob navia <jacob@jacob.remcomp.fr> - 2015-03-31 00:15 +0200
        Re: code for 32/64 bit strtoul strtol strtoull strtoll Robert Wessel <robertwessel2@yahoo.com> - 2015-03-31 01:42 -0500
      Re: code for 32/64 bit strtoul strtol strtoull strtoll Bartc <bc@freeuk.com> - 2015-03-30 23:39 +0100
        Re: code for 32/64 bit strtoul strtol strtoull strtoll Robert Wessel <robertwessel2@yahoo.com> - 2015-03-31 01:44 -0500
          Re: code for 32/64 bit strtoul strtol strtoull strtoll Bartc <bc@freeuk.com> - 2015-03-31 13:01 +0100
            Re: code for 32/64 bit strtoul strtol strtoull strtoll Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-31 05:13 -0700
            Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-31 08:06 -0700
              Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-31 08:26 -0700
              Re: code for 32/64 bit strtoul strtol strtoull strtoll Richard Heathfield <rjh@cpax.org.uk> - 2015-03-31 16:40 +0100
                Re: code for 32/64 bit strtoul strtol strtoull strtoll Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-31 09:39 -0700
                Re: code for 32/64 bit strtoul strtol strtoull strtoll Kaz Kylheku <kaz@kylheku.com> - 2015-03-31 18:22 +0000
                  Re: code for 32/64 bit strtoul strtol strtoull strtoll Richard Heathfield <rjh@cpax.org.uk> - 2015-03-31 19:36 +0100
                    Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-31 12:11 -0700
                    Re: code for 32/64 bit strtoul strtol strtoull strtoll Kaz Kylheku <kaz@kylheku.com> - 2015-03-31 19:23 +0000
              Re: code for 32/64 bit strtoul strtol strtoull strtoll Bartc <bc@freeuk.com> - 2015-03-31 16:52 +0100
                Re: code for 32/64 bit strtoul strtol strtoull strtoll glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-31 17:54 +0000
                  Re: code for 32/64 bit strtoul strtol strtoull strtoll raltbos@xs4all.nl (Richard Bos) - 2015-03-31 18:51 +0000
                    Re: code for 32/64 bit strtoul strtol strtoull strtoll Richard Heathfield <rjh@cpax.org.uk> - 2015-03-31 20:05 +0100
                      Re: code for 32/64 bit strtoul strtol strtoull strtoll James Kuyper <jameskuyper@verizon.net> - 2015-03-31 15:18 -0400
                        Re: code for 32/64 bit strtoul strtol strtoull strtoll Richard Heathfield <rjh@cpax.org.uk> - 2015-03-31 20:49 +0100
                          Re: code for 32/64 bit strtoul strtol strtoull strtoll Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-31 13:06 -0700
                          Re: code for 32/64 bit strtoul strtol strtoull strtoll raltbos@xs4all.nl (Richard Bos) - 2015-04-06 13:03 +0000
                            Re: code for 32/64 bit strtoul strtol strtoull strtoll Bartc <bc@freeuk.com> - 2015-04-06 14:27 +0100
                            Re: code for 32/64 bit strtoul strtol strtoull strtoll Richard Heathfield <rjh@cpax.org.uk> - 2015-04-06 17:01 +0100
                              Re: code for 32/64 bit strtoul strtol strtoull strtoll Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-06 11:25 -0700
                              Re: code for 32/64 bit strtoul strtol strtoull strtoll James Kuyper <jameskuyper@verizon.net> - 2015-04-06 23:34 -0400
                                Re: code for 32/64 bit strtoul strtol strtoull strtoll glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-07 03:46 +0000
                                  Re: code for 32/64 bit strtoul strtol strtoull strtoll James Kuyper <jameskuyper@verizon.net> - 2015-04-08 11:05 -0400
                                    Re: code for 32/64 bit strtoul strtol strtoull strtoll Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-08 08:31 -0700
                        Re: code for 32/64 bit strtoul strtol strtoull strtoll glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-31 19:54 +0000
                          Re: code for 32/64 bit strtoul strtol strtoull strtoll James Kuyper <jameskuyper@verizon.net> - 2015-03-31 16:55 -0400
                            Re: code for 32/64 bit strtoul strtol strtoull strtoll Bartc <bc@freeuk.com> - 2015-03-31 22:20 +0100
                            Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-31 14:36 -0700
                            Re: code for 32/64 bit strtoul strtol strtoull strtoll Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-31 14:55 -0700
                              Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-31 17:00 -0700
                                Re: code for 32/64 bit strtoul strtol strtoull strtoll Bartc <bc@freeuk.com> - 2015-04-01 01:24 +0100
                                Re: code for 32/64 bit strtoul strtol strtoull strtoll James Kuyper <jameskuyper@verizon.net> - 2015-03-31 23:33 -0400
                                  Re: code for 32/64 bit strtoul strtol strtoull strtoll Richard Heathfield <rjh@cpax.org.uk> - 2015-04-01 04:42 +0100
                  Re: code for 32/64 bit strtoul strtol strtoull strtoll Bartc <bc@freeuk.com> - 2015-03-31 20:26 +0100
              Re: code for 32/64 bit strtoul strtol strtoull strtoll Ian Collins <ian-news@hotmail.com> - 2015-04-01 10:33 +1300
                Re: code for 32/64 bit strtoul strtol strtoull strtoll Robert Wessel <robertwessel2@yahoo.com> - 2015-04-01 04:33 -0500
                  Re: code for 32/64 bit strtoul strtol strtoull strtoll Bartc <bc@freeuk.com> - 2015-04-01 12:43 +0100
                    Re: code for 32/64 bit strtoul strtol strtoull strtoll Robert Wessel <robertwessel2@yahoo.com> - 2015-04-02 01:02 -0500
                      Re: code for 32/64 bit strtoul strtol strtoull strtoll asetofsymbols@gmail.com - 2015-04-01 23:57 -0700
                        Re: code for 32/64 bit strtoul strtol strtoull strtoll Robert Wessel <robertwessel2@yahoo.com> - 2015-04-03 00:29 -0500
                      Re: code for 32/64 bit strtoul strtol strtoull strtoll Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-02 09:01 -0700
                        Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-04-02 14:30 -0700
                        Re: code for 32/64 bit strtoul strtol strtoull strtoll Robert Wessel <robertwessel2@yahoo.com> - 2015-04-03 00:39 -0500
                  Re: code for 32/64 bit strtoul strtol strtoull strtoll glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-01 15:55 +0000

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#59355

On 31/03/15 19:51, Richard Bos wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>
>> Bartc <bc@freeuk.com> wrote:
>>
>> > I meant 2, 8, 10 and 16, which are in the range 2 to 16. Although I did
>> > make use of base 4 the other week (meaning I use base 4 more than base 8).
>>
>> There is a lot of work done in base 4, if you use A, C, T, and G
>> instead of 0, 1, 2, 3 for the digits.
>
> Well, no. Those are strings. Nobody is going to multiply your DNA with
> that of another creature, except maybe David Cronenberg.

Unlike my lame joke about days of the week, there is actually some point 
in being able to assign an arithmetic number to a gene - for example, in 
a mathematical analysis of the behaviour of viruses. And base 4 would be 
eminently suitable for the purpose.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#59357

On 03/31/2015 03:05 PM, Richard Heathfield wrote:
> On 31/03/15 19:51, Richard Bos wrote:
>> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
...
>>> There is a lot of work done in base 4, if you use A, C, T, and G
>>> instead of 0, 1, 2, 3 for the digits.
>>
>> Well, no. Those are strings. Nobody is going to multiply your DNA with
>> that of another creature, except maybe David Cronenberg.
> 
> Unlike my lame joke about days of the week, there is actually some point 
> in being able to assign an arithmetic number to a gene - for example, in 
> a mathematical analysis of the behaviour of viruses. And base 4 would be 
> eminently suitable for the purpose.

I would expect genetic work to treat DNA as a nucleotide string, not a
number. Is there any specifically numeric operation that it would be
reasonable to perform on nucleotide strings, one that doesn't correspond
to a generic string operation?

[toc] | [prev] | [next] | [standalone]

#59360

On 31/03/15 20:18, James Kuyper wrote:
> On 03/31/2015 03:05 PM, Richard Heathfield wrote:
>> On 31/03/15 19:51, Richard Bos wrote:
>>> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> ...
>>>> There is a lot of work done in base 4, if you use A, C, T, and G
>>>> instead of 0, 1, 2, 3 for the digits.
>>>
>>> Well, no. Those are strings. Nobody is going to multiply your DNA with
>>> that of another creature, except maybe David Cronenberg.
>>
>> Unlike my lame joke about days of the week, there is actually some point
>> in being able to assign an arithmetic number to a gene - for example, in
>> a mathematical analysis of the behaviour of viruses. And base 4 would be
>> eminently suitable for the purpose.
>
> I would expect genetic work to treat DNA as a nucleotide string, not a
> number. Is there any specifically numeric operation that it would be
> reasonable to perform on nucleotide strings, one that doesn't correspond
> to a generic string operation?

I'm not a genetic scientist, so I don't know the answer to your 
question. I'm just saying it's not an inherently unreasonable thing to 
want to do. If I were a genetic scientist, I think I'd want the 
flexibility of being able to think of genes as numbers. (Of course, this 
may merely explain why I'm not a genetic scientist!)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#59362

On Tuesday, March 31, 2015 at 8:49:26 PM UTC+1, Richard Heathfield wrote:
> On 31/03/15 20:18, James Kuyper wrote:
> 
> > I would expect genetic work to treat DNA as a nucleotide string, not a
> > number. Is there any specifically numeric operation that it would be
> > reasonable to perform on nucleotide strings, one that doesn't correspond
> > to a generic string operation?
> 
> I'm not a genetic scientist, so I don't know the answer to your 
> question. I'm just saying it's not an inherently unreasonable thing to 
> want to do. If I were a genetic scientist, I think I'd want the 
> flexibility of being able to think of genes as numbers. (Of course, this 
> may merely explain why I'm not a genetic scientist!)
> 
DNA is physically more like a string. It's helical, of course, but the
helix is unwound when the DNA is actually needed. The protein-coding
part of the DNA codes for DNA in units of three bases, or six bits, 
generally you know which frame you are in because the sequence ATG
is the "start coding" signal. 
So a function that took 6 bits and performed a look-up would be a
reasonable thing to write, and would be a numerical rather than a
generic string operation.

[toc] | [prev] | [next] | [standalone]

#59686

Richard Heathfield <rjh@cpax.org.uk> wrote:

> On 31/03/15 20:18, James Kuyper wrote:

> > I would expect genetic work to treat DNA as a nucleotide string, not a
> > number. Is there any specifically numeric operation that it would be
> > reasonable to perform on nucleotide strings, one that doesn't correspond
> > to a generic string operation?
> 
> I'm not a genetic scientist, so I don't know the answer to your 
> question. I'm just saying it's not an inherently unreasonable thing to 
> want to do. If I were a genetic scientist, I think I'd want the 
> flexibility of being able to think of genes as numbers. (Of course, this 
> may merely explain why I'm not a genetic scientist!)

I'm not a genetic scientist, either, but if you think it makes sense to
add guanine to cytosine and expect adenosine as a result, you need to
re-read your GEB. Which, to begin with, would be the null elements? And
would genes be signed, or unsigned?

Richard

[toc] | [prev] | [next] | [standalone]

#59687

On 06/04/2015 14:03, Richard Bos wrote:
> Richard Heathfield <rjh@cpax.org.uk> wrote:
>
>> On 31/03/15 20:18, James Kuyper wrote:
>
>>> I would expect genetic work to treat DNA as a nucleotide string, not a
>>> number. Is there any specifically numeric operation that it would be
>>> reasonable to perform on nucleotide strings, one that doesn't correspond
>>> to a generic string operation?
>>
>> I'm not a genetic scientist, so I don't know the answer to your
>> question. I'm just saying it's not an inherently unreasonable thing to
>> want to do. If I were a genetic scientist, I think I'd want the
>> flexibility of being able to think of genes as numbers. (Of course, this
>> may merely explain why I'm not a genetic scientist!)
>
> I'm not a genetic scientist, either, but if you think it makes sense to
> add guanine to cytosine and expect adenosine as a result, you need to
> re-read your GEB. Which, to begin with, would be the null elements? And
> would genes be signed, or unsigned?

You do realise you're not mixing real substances? These are just numeric 
codes which represent the different elements.

Then all sorts of operations can make sense (for example, working out 
some hash function or doing some data compression).

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#59693

On 06/04/15 14:03, Richard Bos wrote:
> Richard Heathfield <rjh@cpax.org.uk> wrote:
>
>> On 31/03/15 20:18, James Kuyper wrote:
>
>> > I would expect genetic work to treat DNA as a nucleotide string, not a
>> > number. Is there any specifically numeric operation that it would be
>> > reasonable to perform on nucleotide strings, one that doesn't correspond
>> > to a generic string operation?
>>
>> I'm not a genetic scientist, so I don't know the answer to your
>> question. I'm just saying it's not an inherently unreasonable thing to
>> want to do. If I were a genetic scientist, I think I'd want the
>> flexibility of being able to think of genes as numbers. (Of course, this
>> may merely explain why I'm not a genetic scientist!)
>
> I'm not a genetic scientist, either, but if you think it makes sense to
> add guanine to cytosine and expect adenosine as a result, you need to
> re-read your GEB. Which, to begin with, would be the null elements?

I continue not to be a genetic scientist, but I was under the impression 
that genes are occasionally treated arithmetically. Not being a genetic 
scientist, I am not even remotely qualified to offer an opinion on 
results from a search for 'genome arithmetic', such as the following 
paper by Andrei Grigoriev (I don't even know whether he's a reputable 
scientist):
http://www.sciencemag.org/content/281/5385/1923.full

I'm just saying it's not inherently impossible that it might be useful. 
Probably nothing as crass as addition, but perhaps polynomial wossnames 
might one day become les objets mathematique du jour for genetic science?

> And would genes be signed, or unsigned?

I think that depends on whether they're designer genes.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#59699

On Monday, April 6, 2015 at 5:01:49 PM UTC+1, Richard Heathfield wrote:
>
> I continue not to be a genetic scientist, but I was under the impression 
> that genes are occasionally treated arithmetically. Not being a genetic 
> scientist, I am not even remotely qualified to offer an opinion on 
> results from a search for 'genome arithmetic', such as the following 
> paper by Andrei Grigoriev (I don't even know whether he's a reputable 
> scientist):
> http://www.sciencemag.org/content/281/5385/1923.full
> 
Chargaff discovered that the amount of adenosine in DNA always equals
the amount of thymine, and the amount of guanine always equals the
amount of cytosine. That was an important clue to the structure of
DNA - the famous double helix.
However the bases aren't distributed entirely randomly. Organisms
that live in high temperature environments have more GC in their
genomes, because the bonds are stronger and so the DNA is more
stable. You can also tell interesting things by looking at GC
skews - and excess of G over C on one strand (matched of course
by the mirror image on the other). AT skews aren't quite as 
interesting.
Generally, the skews aren't sufficiently extreme to be visible to
the eye on a casual examination of the data. But the're very obvious
when you apply simple statistical tests.

[toc] | [prev] | [next] | [standalone]

#59725

On 04/06/2015 12:01 PM, Richard Heathfield wrote:
...
> I continue not to be a genetic scientist, but I was under the impression 
> that genes are occasionally treated arithmetically. Not being a genetic 
> scientist, I am not even remotely qualified to offer an opinion on 
> results from a search for 'genome arithmetic', such as the following 
> paper by Andrei Grigoriev (I don't even know whether he's a reputable 
> scientist):
> http://www.sciencemag.org/content/281/5385/1923.full

The arithmetic he's talking about in that article is arithmetic
performed on numbers describing statistical properties of the a DNA
sequence, which is entirely reasonable. It is NOT arithmetic performed
on the DNA sequence, treated as a number, which would make no sense.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#59727

James Kuyper <jameskuyper@verizon.net> wrote:
> On 04/06/2015 12:01 PM, Richard Heathfield wrote:

>> I continue not to be a genetic scientist, but I was under the impression 
>> that genes are occasionally treated arithmetically. Not being a genetic 
>> scientist, I am not even remotely qualified to offer an opinion on 
>> results from a search for 'genome arithmetic', such as the following 
>> paper by Andrei Grigoriev (I don't even know whether he's a reputable 
>> scientist):
>> http://www.sciencemag.org/content/281/5385/1923.full
 
> The arithmetic he's talking about in that article is arithmetic
> performed on numbers describing statistical properties of the a DNA
> sequence, which is entirely reasonable. It is NOT arithmetic performed
> on the DNA sequence, treated as a number, which would make no sense.

It is not unusual to apply hash functions to short DNA subsequences,
often with numerical hash functions.  In that case, it is aritmetic
peformed on the sequence, but it would work just as well with a
different numerical representation of the sequence.

If you hold 16 or 32 bases in a 32 or 64 bit register, and then ask
what operations you can do efficiently on those values, often they
are numerical.

-- glen

[toc] | [prev] | [next] | [standalone]

#59825

On 04/06/2015 11:46 PM, glen herrmannsfeldt wrote:
> James Kuyper <jameskuyper@verizon.net> wrote:
...
>> The arithmetic he's talking about in that article is arithmetic
>> performed on numbers describing statistical properties of the a DNA
>> sequence, which is entirely reasonable. It is NOT arithmetic performed
>> on the DNA sequence, treated as a number, which would make no sense.
> 
> It is not unusual to apply hash functions to short DNA subsequences,
> often with numerical hash functions.  In that case, it is aritmetic
> peformed on the sequence, but it would work just as well with a
> different numerical representation of the sequence.

I was very specifically asked (earlier in this thread) "Is there any
specifically numeric operation that it would be reasonable to perform on
nucleotide strings, one that doesn't correspond to a generic string
operation?"  The hashing you're talking about can be done equally easily
on any generic string (and often is).

> If you hold 16 or 32 bases in a 32 or 64 bit register, and then ask
> what operations you can do efficiently on those values, often they
> are numerical.

I'm waiting for an example, because I can't imagine any reason why that
would apply to a nucleotide string (namely "[a] specifically  numeric
operation ... that doesn't compare to a generic string operation").

[toc] | [prev] | [next] | [standalone]

#59828

On Wednesday, April 8, 2015 at 4:05:14 PM UTC+1, James Kuyper wrote:
> 
> I was very specifically asked (earlier in this thread) "Is there any
> specifically numeric operation that it would be reasonable to perform on
> nucleotide strings, one that doesn't correspond to a generic string
> operation?"  The hashing you're talking about can be done equally easily
> on any generic string (and often is).
> 
DNA has exactly four bases, so we can represent a sequence as a binary
string with no spare or rarely used values. That could have implications
for hashing, though in reality you'd probably just use a general-purpose
ascii or binary hash, unless you're really optimising the system.

Three bases code for an amino acid. So it's reasonable to take sub-sequences of
three bases, treat them as an integer 0-63, and do lookup. However, whilst 
the code isn't in fact arbitrary (it's actually very interesting), for most
purposes it makes sense to treat it as arbitrary. In fact the third base, conventionally
the least significant two bits, is also biochemically the least significant base,
and a mutation is less likely to affect the protein product than in the other
two bases. However it doesn't really make much biochemical sense to
think of the codon (three bases) as a digital number, at least as far as we
know.

[toc] | [prev] | [next] | [standalone]

#59361

James Kuyper <jameskuyper@verizon.net> wrote:

(snip on base 4 and DNA)

> I would expect genetic work to treat DNA as a nucleotide string, not a
> number. Is there any specifically numeric operation that it would be
> reasonable to perform on nucleotide strings, one that doesn't correspond
> to a generic string operation?

Much is done using character strings, but, as with many other problems,
when you want to speed it up, you look for other ways of doing it.

Often enough, they are stored in integer variables, and operated on
as one would base 4 numbers.

Current sequencing machines generate hundreds of gigabases of
sequence data per day, which needs to be compared with
(aligned to) a reference genome.

-- glen

[toc] | [prev] | [next] | [standalone]

#59363

On 03/31/2015 03:54 PM, glen herrmannsfeldt wrote:
> James Kuyper <jameskuyper@verizon.net> wrote:
> 
> (snip on base 4 and DNA)
> 
>> I would expect genetic work to treat DNA as a nucleotide string, not a
>> number. Is there any specifically numeric operation that it would be
>> reasonable to perform on nucleotide strings, one that doesn't correspond
>> to a generic string operation?
> 
> Much is done using character strings, but, as with many other problems,
> when you want to speed it up, you look for other ways of doing it.
> 
> Often enough, they are stored in integer variables, and operated on
> as one would base 4 numbers.

I can imagine storing four base codes per byte, and I can imagine
displaying them as strings with each pair of bits displayed as the
corresponding element of "ACTG".

Given that ribosomes translate base pair triplets into amino acids,
there might be some value in wasting a little space encoding only three
base pairs per byte. On the other hand, since a triplet can start with
any given base pair, depending upon where the ribosome starts reading,
that might not be worthwhile (there are particular base pair sequences
that serve to align the ribosomes to the "correct" starting point for a
given gene - there's also some cases where those alignment clues are
missing, where  multiple different proteins are encoded by the same DNA
sequence, depending upon where you start).

What I can't imagine is any meaningful use of addition, subtraction,
multiplication or division on those "numbers". Except, of course,
insofar as multiplication or division by powers of 2 would correspond to
truncation or padding of the strings representing those base pairs. But
that is NOT an example of a "numeric operation ... that doesn't
correspond to a generic string operation".

[toc] | [prev] | [next] | [standalone]

#59364

On 31/03/2015 21:55, James Kuyper wrote:
> On 03/31/2015 03:54 PM, glen herrmannsfeldt wrote:
>> James Kuyper <jameskuyper@verizon.net> wrote:
>>
>> (snip on base 4 and DNA)
>>
>>> I would expect genetic work to treat DNA as a nucleotide string, not a
>>> number. Is there any specifically numeric operation that it would be
>>> reasonable to perform on nucleotide strings, one that doesn't correspond
>>> to a generic string operation?
>>
>> Much is done using character strings, but, as with many other problems,
>> when you want to speed it up, you look for other ways of doing it.
>>
>> Often enough, they are stored in integer variables, and operated on
>> as one would base 4 numbers.
>
> I can imagine storing four base codes per byte, and I can imagine
> displaying them as strings with each pair of bits displayed as the
> corresponding element of "ACTG".
<snip>
> What I can't imagine is any meaningful use of addition, subtraction,
> multiplication or division on those "numbers". Except, of course,
> insofar as multiplication or division by powers of 2 would correspond to
> truncation or padding of the strings representing those base pairs. But
> that is NOT an example of a "numeric operation ... that doesn't
> correspond to a generic string operation".

Surely base-4-ness is only to do with printing or reading such integers 
as base 4? (So that the decimal value 123456 is printed as 132021000; 9 
2-bit base-4 digits, but which is still stored internally as the binary 
value 11110001001000000.)

You can then do all the normal operations on such binary values, even if 
some might have no meaning if this value did represent an ACGT sequence 
fragment. But many could: compare, shift and perhaps masking and or-ing. 
But as I said, base-4 doesn't really come into it.

It's not like working with base-10 (superimposed on the underlying 
binary, so effectively BCD) where many arithmetic ops will not work. But 
most of the time we do use base-10 to convert to/from textual 
representations without working /in/ base-10.

Or am I misunderstanding the whole thing?

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#59366

James Kuyper <jameskuyper@verizon.net> writes:
[...]
> I can imagine storing four base codes per byte, and I can imagine
> displaying them as strings with each pair of bits displayed as the
> corresponding element of "ACTG".
>
[...]
>
> What I can't imagine is any meaningful use of addition, subtraction,
> multiplication or division on those "numbers". Except, of course,
> insofar as multiplication or division by powers of 2 would correspond to
> truncation or padding of the strings representing those base pairs. But
> that is NOT an example of a "numeric operation ... that doesn't
> correspond to a generic string operation".

Don't underestimate the power of numeric operations on DNA sequences.
After all, French fries were created by taking the square root of a potato.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#59367

On Tuesday, March 31, 2015 at 9:55:38 PM UTC+1, James Kuyper wrote:
> 
> Given that ribosomes translate base pair triplets into amino acids,
> there might be some value in wasting a little space encoding only three
> base pairs per byte. On the other hand, since a triplet can start with
> any given base pair, depending upon where the ribosome starts reading,
> that might not be worthwhile (there are particular base pair sequences
> that serve to align the ribosomes to the "correct" starting point for a
> given gene - there's also some cases where those alignment clues are
> missing, where  multiple different proteins are encoded by the same DNA
> sequence, depending upon where you start).
> 
There might be a case of an overlapping gene with a different frame
somewhere, but it's extremely rare.
If you start transcribing RNA out of frame, it's like taking ascii
text and shifting everything along by two bits - the result has to
be nonsense, it won't form a functional protein but just a blob
with no particular secondary or tertiary structure.

[toc] | [prev] | [next] | [standalone]

#59369

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Tuesday, March 31, 2015 at 9:55:38 PM UTC+1, James Kuyper wrote:
>> Given that ribosomes translate base pair triplets into amino acids,
>> there might be some value in wasting a little space encoding only three
>> base pairs per byte. On the other hand, since a triplet can start with
>> any given base pair, depending upon where the ribosome starts reading,
>> that might not be worthwhile (there are particular base pair sequences
>> that serve to align the ribosomes to the "correct" starting point for a
>> given gene - there's also some cases where those alignment clues are
>> missing, where  multiple different proteins are encoded by the same DNA
>> sequence, depending upon where you start).
>> 
> There might be a case of an overlapping gene with a different frame
> somewhere, but it's extremely rare.
> If you start transcribing RNA out of frame, it's like taking ascii
> text and shifting everything along by two bits - the result has to
> be nonsense, it won't form a functional protein but just a blob
> with no particular secondary or tertiary structure.

According to
    http://www.pandasthumb.org/archives/2007/10/konstantin-b-ze.html
these are called "alternate reading frames".

Relevance to C (or at least to programming): This could imply that a
base-64 representation of DNA sequences, using 6 bits for each sequence
of 3 base pairs, is not always adequate.  You need base 4 to allow for
1- or 2-base offsets.  Even without alternate reading frames, you still
need to figure out one of three possible offsets (and one of two
directions) to determine where the boundaries are and what, if anything,
the gene encodes.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#59370

On 01/04/2015 01:00, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> On Tuesday, March 31, 2015 at 9:55:38 PM UTC+1, James Kuyper wrote:
>>> Given that ribosomes translate base pair triplets into amino acids,
>>> there might be some value in wasting a little space encoding only three
>>> base pairs per byte. On the other hand, since a triplet can start with
>>> any given base pair, depending upon where the ribosome starts reading,
>>> that might not be worthwhile (there are particular base pair sequences
>>> that serve to align the ribosomes to the "correct" starting point for a
>>> given gene - there's also some cases where those alignment clues are
>>> missing, where  multiple different proteins are encoded by the same DNA
>>> sequence, depending upon where you start).
>>>
>> There might be a case of an overlapping gene with a different frame
>> somewhere, but it's extremely rare.
>> If you start transcribing RNA out of frame, it's like taking ascii
>> text and shifting everything along by two bits - the result has to
>> be nonsense, it won't form a functional protein but just a blob
>> with no particular secondary or tertiary structure.
>
> According to
>      http://www.pandasthumb.org/archives/2007/10/konstantin-b-ze.html
> these are called "alternate reading frames".
>
> Relevance to C (or at least to programming): This could imply that a
> base-64 representation of DNA sequences, using 6 bits for each sequence
> of 3 base pairs, is not always adequate.  You need base 4 to allow for
> 1- or 2-base offsets.  Even without alternate reading frames, you still
> need to figure out one of three possible offsets (and one of two
> directions) to determine where the boundaries are and what, if anything,
> the gene encodes.

I'm struggling to see where 'base-4' fits into this.

If that complicated link is a typical example, then ACGT sequences tend 
to be described using characters, and are likely stored and manipulated 
as sequences of bytes or characters, which is the simplest method. But 
that takes four times as much memory as needed.

The data itself is naturally consists of a sequence of 2-bit values.

If this is stored in C using packed sets of 2-bit elements (4 per byte 
or 16/32 per int) then the only time base-4 comes into it is if an 
individual byte or int section of a sequence is printed in base 4 
(coming out as 01022033...) or is converted from 01022033... into a byte 
or int.

Since ACAGGATT... is preferred, even that use of base-4 is not that 
helpful. Custom conversion to/from textual representation is needed, and 
that is little to do with 'base', and more to do with the exact 
implementation of this highly specialised data.

(Probably, something like Ada could deal with this properly, having a 
type consisting of the set (A,C,G,T), and which can most likely be 
coerced into having an efficient packed implementation.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#59373

On 03/31/2015 08:00 PM, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> On Tuesday, March 31, 2015 at 9:55:38 PM UTC+1, James Kuyper wrote:
>>> Given that ribosomes translate base pair triplets into amino acids,
>>> there might be some value in wasting a little space encoding only three
>>> base pairs per byte. On the other hand, since a triplet can start with
>>> any given base pair, depending upon where the ribosome starts reading,
>>> that might not be worthwhile (there are particular base pair sequences
>>> that serve to align the ribosomes to the "correct" starting point for a
>>> given gene - there's also some cases where those alignment clues are
>>> missing, where  multiple different proteins are encoded by the same DNA
>>> sequence, depending upon where you start).
>>>
>> There might be a case of an overlapping gene with a different frame
>> somewhere, but it's extremely rare.

Yes, it is, and correspondingly interesting when it happens. I first
read about it in connection with a virus which was carried around in a
structure that was made of a fixed and relatively small number of
protein units arranged in a strict geometric shape. The central part
looked like a geodesic dome, plus there were "legs" and an an injector
that was used to penetrate cell walls. There was only a tiny amount of
room inside that structure for any genetic material, and the structure
was not scalable - any change in it's size would require radical change
to the structure of the proteins that made it up. As a result, there was
strong evolutionary pressure to keep the genetic payload as small as
possible. I believe it was a plasmid - a short circle of RNA. Unlikely
typical human DNA, almost every base pair was used in at least one gene,
and most of them were involved in two, as a result of using an alternate
reading frame. I was very impressed, which is why I still remember the
concept.
The name of virus - that's another matter - that's not nearly as
interesting, and I no longer remember it.

>> If you start transcribing RNA out of frame, it's like taking ascii
>> text and shifting everything along by two bits - the result has to
>> be nonsense, it won't form a functional protein but just a blob
>> with no particular secondary or tertiary structure.

That's what you'd normally expect, which why normal DNA has special
"start" sequences that tell the ribosomes the correct reading frame to
use. The fact that the plasmid I'm talking about made efficient use of
alternate reading frames to encode multiple working genes was what made
it so impressive.
It was only possible because of the redundancy of the genetic code.
There's 64 possible sequences of 3 consecutive base pairs, and only 21
different amino acids that they code for. There's multiple different
encodings for the same amino acid. As a result, the protein encoded when
you use one reading frame does not uniquely determine which protein is
encoded if you use a different reading frame. Without that freedom,
there's no way the plasmid I described would have had any reasonable
chance of evolving.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web