How to disregard the first match of a loop?

Discussion in 'Perl Misc' started by Nene, Aug 9, 2011.

  1. Nene

    Nene Guest

    Hi,
    I want to disregard the first match of the 'm/State : (\S+)/'
    which would be the string 'Availability' because the first match is
    meaningless, the other matches of Availability are important. So how I
    do disregard/omit the first capture of a loop?

    ####

    #!/usr/bin/perl -w
    use strict;

    while ( my $line = <DATA> ) {


    if ($line =~ m/Ltm::pool Member: \S+ (\S+)/) {
    $a = $1;
    }
    if ($line =~ m/State : (\S+)/) {
    $b = $1;
    print "$a $b\n";
    }
    }

    __DATA__
    Ltm::pool: TEST_POOL
    --------------------------------------
    Status
    Availability : available
    State : enabled
    Reason : The pool is available
    ^M
    Traffic ServerSide
    Bits In 4.1G
    Bits Out 0
    Packets In 4.8M
    Packets Out 0
    Current Connections 0
    Maximum Connections 153
    Total Connections 723.4K

    Ltm::pool Member: TEST_POOL 10.10.10.10:7502
    -------------------------------------------------
    tatus
    Availability : available
    State : enabled
    Reason : Pool member is available

    Traffic ServerSide General
    Bits In 522.8M -
    Bits Out 0 -
    Packets In 614.2K -
    Packets Out 0 -
    Current Connections 0 -
    Maximum Connections 20 -
    Total Connections 90.9K -
    Total Requests - 0

    Ltm::pool Member: TEST_POOL 10.10.10.10:7502
    Nene, Aug 9, 2011
    #1
    1. Advertising

  2. Nene wrote:
    > Hi,
    > I want to disregard the first match of the 'm/State : (\S+)/'
    > which would be the string 'Availability' because the first match is
    > meaningless, the other matches of Availability are important. So how I
    > do disregard/omit the first capture of a loop?
    >
    > ####
    >
    > #!/usr/bin/perl -w
    > use strict;
    >
    > while ( my $line =<DATA> ) {
    >
    >
    > if ($line =~ m/Ltm::pool Member: \S+ (\S+)/) {
    > $a = $1;
    > }
    > if ($line =~ m/State : (\S+)/) {
    > $b = $1;
    > print "$a $b\n";
    > }
    > }



    #!/usr/bin/perl
    use warnings;
    use strict;

    my $pool_member;
    while ( my $line = <DATA> ) {

    if ( $line =~ /Ltm::pool Member: \S+ (\S+)/ ) {
    $pool_member = $1;
    }
    elsif ( defined $pool_member && $line =~ /State\s+:\s+(\S+)/) {
    print "$pool_member $1\n";
    }
    }




    John
    --
    Any intelligent fool can make things bigger and
    more complex... It takes a touch of genius -
    and a lot of courage to move in the opposite
    direction. -- Albert Einstein
    John W. Krahn, Aug 9, 2011
    #2
    1. Advertising

  3. Nene

    Guest

    On Mon, 8 Aug 2011 17:41:32 -0700 (PDT), Nene <> wrote:

    >Hi,
    >I want to disregard the first match of the 'm/State : (\S+)/'
    >which would be the string 'Availability' because the first match is
    >meaningless, the other matches of Availability are important. So how I
    >do disregard/omit the first capture of a loop?
    >

    [snip bad formatted code]
    >__DATA__
    >Ltm::pool: TEST_POOL
    >--------------------------------------
    >Status
    > Availability : available
    > State : enabled
    > Reason : The pool is available
    > ^M
    >Traffic ServerSide
    > Bits In 4.1G
    > Bits Out 0
    > Packets In 4.8M
    > Packets Out 0
    > Current Connections 0
    > Maximum Connections 153
    > Total Connections 723.4K
    >
    >Ltm::pool Member: TEST_POOL 10.10.10.10:7502
    >-------------------------------------------------
    >tatus
    > Availability : available
    > State : enabled
    > Reason : Pool member is available
    >
    >Traffic ServerSide General
    > Bits In 522.8M -
    > Bits Out 0 -
    > Packets In 614.2K -
    > Packets Out 0 -
    > Current Connections 0 -
    > Maximum Connections 20 -
    > Total Connections 90.9K -
    > Total Requests - 0
    >
    >Ltm::pool Member: TEST_POOL 10.10.10.10:7502


    You have a lot of state stuff going on there.
    Without modifying your sample too much, this is the way
    I would do it:

    use strict;
    use warnings;

    my ($pool_member, $state);

    while ( my $line = <DATA> )
    {
    if ( $line =~ /Ltm::pool( Member: \S+ (\S+)|)/ ) {
    $state = 0;
    if ($1) {
    $pool_member = $2;
    $state = 1;
    }
    next;
    }
    if ( $state && $line =~ /State : (\S+)/ ) {
    print "$pool_member $1\n";
    $state = 0;
    }
    }
    , Aug 9, 2011
    #3
  4. 09-08-2011, Nene <> ÐÉÛÅÔ:
    > Hi,
    > I want to disregard the first match of the 'm/State : (\S+)/'


    I use the following "idiom":

    my $first_seen;
    LOOP: (...) {
    next unless $first_seen++;
    DO_SOMETHING:
    }

    Hope this helps,
    Ilya
    Ilya Zakharevich, Aug 10, 2011
    #4
  5. Ilya Zakharevich <> writes:
    > 09-08-2011, Nene <> ÐÉÛÅÔ:
    >> Hi,
    >> I want to disregard the first match of the 'm/State : (\S+)/'

    >
    > I use the following "idiom":
    >
    > my $first_seen;
    > LOOP: (...) {
    > next unless $first_seen++;
    > DO_SOMETHING:
    > }


    An optimizing compiler would/ should kill this in the course of
    'invariant code motion'. This is (AFAIK) something the Perl compiler
    cannot do and therefore, the programmer should try to keep 'one-off'
    statements of this type out of loops manually.
    Rainer Weikusat, Aug 10, 2011
    #5
  6. bugbear <bugbear@trim_papermule.co.uk_trim> writes:
    > Rainer Weikusat wrote:
    >> Ilya Zakharevich<> writes:
    >>> 09-08-2011, Nene<> ÐÉÛÅÔ:
    >>>> Hi,
    >>>> I want to disregard the first match of the 'm/State : (\S+)/'
    >>>
    >>> I use the following "idiom":
    >>>
    >>> my $first_seen;
    >>> LOOP: (...) {
    >>> next unless $first_seen++;
    >>> DO_SOMETHING:
    >>> }

    >>
    >> An optimizing compiler would/ should kill this in the course of
    >> 'invariant code motion'. This is (AFAIK) something the Perl compiler
    >> cannot do and therefore, the programmer should try to keep 'one-off'
    >> statements of this type out of loops manually.

    >
    > Surely that only applies if you're up against performance issues?
    >
    > "Programmers waste enormous amounts of time thinking
    > about, or worrying about, the speed
    > of noncritical parts of their programs..."
    >
    > -- Knuth.


    Provided you are writing mnemonic machine code aka 'assembly', what
    Knuth's statement was referring to, I'd agree with that: There's no
    use in trying to write 'an optimal machine code program' in every
    little detail since there are way too much details in such a program
    to ever get anything reasonably complex done when trying to do so
    (or so, cf http://www.pbm.com/~lindahl/mel.html). But I assume that
    this is only very rarely done nowadays and Perl isn't machine. It's a
    fairly heavyweight 'very high-level language' with a compiler whose
    'self-defense against mindless code churning' features are rather weak
    and consequently, some intelligence is required to use it sensibly and
    since there is so much which doesn't need to be done manually, thanks
    to the 'very high level', that's usually not overly time consuming[*].

    [*] In Germany, people whose main problem is "how do I get
    this done at all" are called apprentices and treated and paid
    as such, except if they have a degree in math and what they
    are trying to do is 'programming' ...
    Rainer Weikusat, Aug 10, 2011
    #6
  7. >>>>> "RW" == Rainer Weikusat <> writes:

    RW> Ilya Zakharevich <> writes:
    >> 09-08-2011, Nene <> ÃÉÛÅÔ:
    >>> Hi, I want to disregard the first match of the 'm/State :
    >>> (\S+)/'

    >>
    >> I use the following "idiom":
    >>
    >> my $first_seen; LOOP: (...) { next unless $first_seen++;
    >> DO_SOMETHING:
    >> }


    RW> An optimizing compiler would/ should kill this in the course of
    RW> 'invariant code motion'.

    If an optimizing compiler changes the meaning of the code in the course
    of its optimizations, it is a seriously flawed compiler.

    Charlton



    --
    Charlton Wilbur
    Charlton Wilbur, Aug 10, 2011
    #7
  8. Charlton Wilbur <> writes:
    >>>>>> "RW" == Rainer Weikusat <> writes:

    > RW> Ilya Zakharevich <> writes:
    > >> 09-08-2011, Nene <> ÐÉÛÅÔ:
    > >>> Hi, I want to disregard the first match of the 'm/State :
    > >>> (\S+)/'
    > >>
    > >> I use the following "idiom":
    > >>
    > >> my $first_seen; LOOP: (...) { next unless $first_seen++;
    > >> DO_SOMETHING:
    > >> }

    >
    > RW> An optimizing compiler would/ should kill this in the course of
    > RW> 'invariant code motion'.
    >
    > If an optimizing compiler changes the meaning of the code in the course
    > of its optimizations, it is a seriously flawed compiler.


    The condition checked by the unless will be true when its encountered
    first and will always remain false afterwards. Consequently, it can be
    moved out of the loop without affecting the meaning of anything and
    very likely, considering the problem this was supposed to apply to,
    the $first_seen variable and the pointless per-iteration increment
    could also be eliminated altogether.
    Rainer Weikusat, Aug 10, 2011
    #8
  9. Nene

    Uri Guttman Guest

    >>>>> "RW" == Rainer Weikusat <> writes:

    RW> Charlton Wilbur <> writes:
    >>>>>>> "RW" == Rainer Weikusat <> writes:

    RW> Ilya Zakharevich <> writes:
    >> >> 09-08-2011, Nene <> ÐÉÛÅÔ:
    >> >>> Hi, I want to disregard the first match of the 'm/State :
    >> >>> (\S+)/'
    >> >>
    >> >> I use the following "idiom":
    >> >>
    >> >> my $first_seen; LOOP: (...) { next unless $first_seen++;
    >> >> DO_SOMETHING:
    >> >> }

    >>

    RW> An optimizing compiler would/ should kill this in the course of
    RW> 'invariant code motion'.
    >>
    >> If an optimizing compiler changes the meaning of the code in the course
    >> of its optimizations, it is a seriously flawed compiler.


    RW> The condition checked by the unless will be true when its encountered
    RW> first and will always remain false afterwards. Consequently, it can be
    RW> moved out of the loop without affecting the meaning of anything and
    RW> very likely, considering the problem this was supposed to apply to,
    RW> the $first_seen variable and the pointless per-iteration increment
    RW> could also be eliminated altogether.

    again you are very wrong. any variable could be tied and therefore
    have dynamic behavior that no compiler could predict. perl doesn't do
    invariant code removal because it can't. and don't say something like
    the code can be analyzed to make sure that isn't tied. other code could
    tie it later on or even core perl funcs can be overridden to do
    that. the work required to track all possiblities down would make the
    compiler ridiculously large and slow.

    did you really think after all these years that no one has EVER thought
    about invariant code removal? it is a technique dating from the late
    50's and p5p is well aware of it and has NEVER addressed it knowing it
    can't be done in perl.

    uri

    --
    Uri Guttman -- uri AT perlhunter DOT com --- http://www.perlhunter.com --
    ------------ Perl Developer Recruiting and Placement Services -------------
    ----- Perl Code Review, Architecture, Development, Training, Support -------
    Uri Guttman, Aug 10, 2011
    #9
  10. "Uri Guttman" <> writes:
    >>>>>> "RW" == Rainer Weikusat <> writes:

    >
    > RW> Charlton Wilbur <> writes:
    > >>>>>>> "RW" == Rainer Weikusat <> writes:

    > RW> Ilya Zakharevich <> writes:
    > >> >> 09-08-2011, Nene <> ÐÉÛÅÔ:
    > >> >>> Hi, I want to disregard the first match of the 'm/State :
    > >> >>> (\S+)/'
    > >> >>
    > >> >> I use the following "idiom":
    > >> >>
    > >> >> my $first_seen; LOOP: (...) { next unless $first_seen++;
    > >> >> DO_SOMETHING:
    > >> >> }
    > >>

    > RW> An optimizing compiler would/ should kill this in the course of
    > RW> 'invariant code motion'.
    > >>
    > >> If an optimizing compiler changes the meaning of the code in the course
    > >> of its optimizations, it is a seriously flawed compiler.

    >
    > RW> The condition checked by the unless will be true when its encountered
    > RW> first and will always remain false afterwards. Consequently, it can be
    > RW> moved out of the loop without affecting the meaning of anything and
    > RW> very likely, considering the problem this was supposed to apply to,
    > RW> the $first_seen variable and the pointless per-iteration increment
    > RW> could also be eliminated altogether.
    >
    > again you are very wrong. any variable could be tied and therefore
    > have dynamic behavior that no compiler could predict.


    You are completely ignoring both the purpose of the example 'code
    idiom' ("disregard the first match of a loop") and the 'idiom' code
    which was actually posted (that declared $first_seen via my
    immediately in front of the code block). After having thus changed the
    topic of the thread completely, you 'conclude' that my statement
    would be 'again very wrong'.

    ROTFL.
    Rainer Weikusat, Aug 10, 2011
    #10
  11. Nene

    Uri Guttman Guest

    >>>>> "RW" == Rainer Weikusat <> writes:

    RW> "Uri Guttman" <> writes:

    RW> An optimizing compiler would/ should kill this in the course of
    RW> 'invariant code motion'.

    >> again you are very wrong. any variable could be tied and therefore
    >> have dynamic behavior that no compiler could predict.


    RW> You are completely ignoring both the purpose of the example 'code
    RW> idiom' ("disregard the first match of a loop") and the 'idiom' code
    RW> which was actually posted (that declared $first_seen via my
    RW> immediately in front of the code block). After having thus changed the
    RW> topic of the thread completely, you 'conclude' that my statement
    RW> would be 'again very wrong'.

    you said an optimizing compiler would remove this. perl can't have
    one. so what is your point of even bringing it up? that is your flaw
    here.

    again, you are not making any friends here. do you like doing this? why
    are you even here if you don't care to be part of a community? do you
    even get what community is?

    uri

    --
    Uri Guttman -- uri AT perlhunter DOT com --- http://www.perlhunter.com --
    ------------ Perl Developer Recruiting and Placement Services -------------
    ----- Perl Code Review, Architecture, Development, Training, Support -------
    Uri Guttman, Aug 10, 2011
    #11
  12. "Uri Guttman" <> writes:
    >>>>>> "RW" == Rainer Weikusat <> writes:

    >
    > RW> "Uri Guttman" <> writes:
    >
    > RW> An optimizing compiler would/ should kill this in the course of
    > RW> 'invariant code motion'.
    >
    > >> again you are very wrong. any variable could be tied and therefore
    > >> have dynamic behavior that no compiler could predict.

    >
    > RW> You are completely ignoring both the purpose of the example 'code
    > RW> idiom' ("disregard the first match of a loop") and the 'idiom' code
    > RW> which was actually posted (that declared $first_seen via my
    > RW> immediately in front of the code block). After having thus changed the
    > RW> topic of the thread completely, you 'conclude' that my statement
    > RW> would be 'again very wrong'.
    >
    > you said an optimizing compiler would remove this.


    Killing the context you have chosen to disregard in order to change
    the meaning of my statement such that it doesn't make sense anymore
    doesn't improve anything here: I wrote that a compiler which could do
    invariant code motion would/ should move a part of the specific
    statement in question, next unless $first_seen++, out of the loop
    because, taking the purpose ('disregard the first match of a loop')
    and context ('my $first_seen; while (... ) { next unless ...; }') of
    it into account, doing so wouldn't change 'the meaning of the code',
    only improve its execution speed. I also wrote that the lexical
    variable and the per-iteration increment could very likely also be
    killed because - again recurring to the purpose of the construction -
    neither the variable nor its final value would likely be used by other
    code executing after the loop.

    > perl can't have one.


    I didn't claim that it could.

    [...]

    > again, you are not making any friends here. do you like doing this?
    > why are you even here if you don't care to be part of a community?
    > do you even get what community is?


    I get that - to you - 'community' is what I shouldn't be allowed to
    be part of.
    Rainer Weikusat, Aug 10, 2011
    #12
  13. >>>>> "RW" == Rainer Weikusat <> writes:

    RW> I wrote that a compiler which could do invariant code motion
    RW> would/ should move a part of the specific statement in question,

    No, actually, you wrote this:

    RW> An optimizing compiler would/ should kill this in the course of
    RW> 'invariant code motion'.

    Perhaps in your idiolect "move" and "kill" are synonymous.

    Charlton




    --
    Charlton Wilbur
    Charlton Wilbur, Aug 10, 2011
    #13
  14. Nene

    Uri Guttman Guest

    >>>>> "CW" == Charlton Wilbur <> writes:

    >>>>> "RW" == Rainer Weikusat <> writes:

    RW> I wrote that a compiler which could do invariant code motion
    RW> would/ should move a part of the specific statement in question,

    CW> No, actually, you wrote this:

    RW> An optimizing compiler would/ should kill this in the course of
    RW> 'invariant code motion'.

    CW> Perhaps in your idiolect "move" and "kill" are synonymous.

    and regardless of move or kill, you can never do that with perl due to
    possible dynamic behavior due to tie and overload and overriding of
    builtins. no compiler can detect those before they happen.

    but our dear rainer will win out in his mind as he always does. must be
    nice to live in a castle in the clouds.

    uri

    --
    Uri Guttman -- uri AT perlhunter DOT com --- http://www.perlhunter.com --
    ------------ Perl Developer Recruiting and Placement Services -------------
    ----- Perl Code Review, Architecture, Development, Training, Support -------
    Uri Guttman, Aug 11, 2011
    #14
  15. Nene

    Ted Zlatanov Guest

    On Wed, 10 Aug 2011 14:04:11 +0100 Rainer Weikusat <> wrote:

    RW> Ilya Zakharevich <> writes:
    >> 09-08-2011, Nene <> ÐÉÛÅÔ:
    >>> Hi,
    >>> I want to disregard the first match of the 'm/State : (\S+)/'

    >>
    >> I use the following "idiom":
    >>
    >> my $first_seen;
    >> LOOP: (...) {
    >> next unless $first_seen++;
    >> DO_SOMETHING:
    >> }


    RW> An optimizing compiler would/ should kill this in the course of
    RW> 'invariant code motion'. This is (AFAIK) something the Perl compiler
    RW> cannot do and therefore, the programmer should try to keep 'one-off'
    RW> statements of this type out of loops manually.

    $var++ is effectively a free operation in Perl, unless you're in a tight
    loop, and even then it's very unlikely to matter.

    The DO_SOMETHING and loop condition are likely to be much, much heavier
    in terms of workload. For instance the m/State.../ call that's done on
    every loop cycle will tie up the processor much more. So I would
    optimize that piece first if optimization was warranted at all.

    Ted
    Ted Zlatanov, Aug 11, 2011
    #15
  16. "Uri Guttman" <> writes:
    >>>>>> "CW" == Charlton Wilbur <> writes:

    >
    >>>>>> "RW" == Rainer Weikusat <> writes:

    > RW> I wrote that a compiler which could do invariant code motion
    > RW> would/ should move a part of the specific statement in question,
    >
    > CW> No, actually, you wrote this:
    >
    > RW> An optimizing compiler would/ should kill this in the course of
    > RW> 'invariant code motion'.
    >
    > CW> Perhaps in your idiolect "move" and "kill" are synonymous.
    >
    > and regardless of move or kill, you can never do that with perl due to
    > possible dynamic behavior due to tie and overload and overriding of
    > builtins.


    Neither 'tie' nor 'overload' nor 'overriding of builtins' were
    applicable to this specific example.

    > but our dear rainer will win out in his mind as he always does.


    To quote Snoopy: "Poor, sweet baby" ...
    Rainer Weikusat, Aug 11, 2011
    #16
  17. Charlton Wilbur <> writes:
    >>>>>> "RW" == Rainer Weikusat <> writes:

    >
    > RW> I wrote that a compiler which could do invariant code motion
    > RW> would/ should move a part of the specific statement in question,
    >
    > No, actually, you wrote this:
    >
    > RW> An optimizing compiler would/ should kill this in the course of
    > RW> 'invariant code motion'.
    >
    > Perhaps in your idiolect "move" and "kill" are synonymous.


    No, actually, I didn't put RW> in front of it.
    Rainer Weikusat, Aug 11, 2011
    #17
  18. Nene

    Uri Guttman Guest

    >>>>> "RW" == Rainer Weikusat <> writes:

    RW> "Uri Guttman" <> writes:
    >>>>>>> "CW" == Charlton Wilbur <> writes:

    >>
    >>>>>>> "RW" == Rainer Weikusat <> writes:

    RW> I wrote that a compiler which could do invariant code motion
    RW> would/ should move a part of the specific statement in question,
    >>

    CW> No, actually, you wrote this:
    >>

    RW> An optimizing compiler would/ should kill this in the course of
    RW> 'invariant code motion'.
    >>

    CW> Perhaps in your idiolect "move" and "kill" are synonymous.
    >>
    >> and regardless of move or kill, you can never do that with perl due to
    >> possible dynamic behavior due to tie and overload and overriding of
    >> builtins.


    RW> Neither 'tie' nor 'overload' nor 'overriding of builtins' were
    RW> applicable to this specific example.

    and how do you know that? or how would an optimizing compiler know
    that? your predictions of what code will do is amazing.

    >> but our dear rainer will win out in his mind as he always does.


    RW> To quote Snoopy: "Poor, sweet baby" ...

    just as i PREDICTED. never listen, never will. are you ever wrong on
    anything? a rhetorical question, that.

    uri

    --
    Uri Guttman -- uri AT perlhunter DOT com --- http://www.perlhunter.com --
    ------------ Perl Developer Recruiting and Placement Services -------------
    ----- Perl Code Review, Architecture, Development, Training, Support -------
    Uri Guttman, Aug 12, 2011
    #18
  19. "Uri Guttman" <> writes:
    >>>>>> "RW" == Rainer Weikusat <> writes:

    >
    > RW> "Uri Guttman" <> writes:
    > >>>>>>> "CW" == Charlton Wilbur <> writes:
    > >>
    > >>>>>>> "RW" == Rainer Weikusat <> writes:

    > RW> I wrote that a compiler which could do invariant code motion
    > RW> would/ should move a part of the specific statement in question,
    > >>

    > CW> No, actually, you wrote this:
    > >>

    > RW> An optimizing compiler would/ should kill this in the course of
    > RW> 'invariant code motion'.
    > >>

    > CW> Perhaps in your idiolect "move" and "kill" are synonymous.
    > >>
    > >> and regardless of move or kill, you can never do that with perl due to
    > >> possible dynamic behavior due to tie and overload and overriding of
    > >> builtins.

    >
    > RW> Neither 'tie' nor 'overload' nor 'overriding of builtins' were
    > RW> applicable to this specific example.
    >
    > and how do you know that?


    "Re: How to disregard the first match of a loop?"?

    > or how would an optimizing compiler know
    > that? your predictions of what code will do is amazing.
    >
    > >> but our dear rainer will win out in his mind as he always does.

    >
    > RW> To quote Snoopy: "Poor, sweet baby" ...
    >
    > just as i PREDICTED. never listen, never will. are you ever wrong on
    > anything? a rhetorical question, that.


    As I already wrote in the indirect reply to 'Ted 0.5" (safely resting
    in my killfile until he either posts something sensible or kingdom
    come, me expecting rather the latter than the former), I'm am not a bad
    caricature of you. Consequently, I admit when I'm wrong.
    Rainer Weikusat, Aug 12, 2011
    #19
  20. Nene

    Ted Zlatanov Guest

    On Fri, 12 Aug 2011 00:05:44 +0100 Rainer Weikusat <> wrote:

    RW> As I already wrote in the indirect reply to 'Ted 0.5" (safely resting
    RW> in my killfile until he either posts something sensible or kingdom
    RW> come, me expecting rather the latter than the former), I'm am not a bad
    RW> caricature of you. Consequently, I admit when I'm wrong.

    Heh heh, I'm honored to be killfiled parenthetically.

    Ted
    Ted Zlatanov, Aug 12, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Steve Richter

    Why printing disregard <table width="100%">?

    Steve Richter, May 4, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    457
    =?Utf-8?B?bGF0aGEgdmFsbGluYXlhZ2Ft?=
    May 5, 2005
  2. D R E
    Replies:
    0
    Views:
    295
    D R E
    Jul 13, 2004
  3. Pallav

    disregard post on sine table lookup

    Pallav, Jun 30, 2004, in forum: C Programming
    Replies:
    0
    Views:
    296
    Pallav
    Jun 30, 2004
  4. Sean
    Replies:
    1
    Views:
    389
    Jack Klein
    Aug 21, 2004
  5. Isaac Won
    Replies:
    9
    Views:
    372
    Ulrich Eckhardt
    Mar 4, 2013
Loading...

Share This Page