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

Groups > sci.physics > #611294 > unrolled thread

#define came from God himself, it's sacred.

Back to article view | Back to sci.physics

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  #define came from God himself, it's sacred. Jeff-Relf.Me <@.> - 2017-01-01 23:51 -0800
    #define came from God himself, it's sacred. Jeff-Relf.Me <@..yep> - 2017-01-02 08:00 +0000
      Re: #define came from God himself, it's sacred. moroney@world.std.spaamtrap.com (Michael Moroney) - 2017-01-03 03:58 +0000
        I completely reWrote it, of course. Jeff-Relf.Me <@.> - 2017-01-03 00:46 -0800
          I completely reWrote it, of course. Jeff-Relf.Me <@..sour> - 2017-01-03 08:51 +0000
            Re: I completely reWrote it, of course. Double-A <double-a3@hush.com> - 2017-01-05 16:12 -0800
          Re: I completely reWrote it, of course. Peter Köhlmann <peter-koehlmann@t-online.de> - 2017-01-03 12:13 +0100
            Re: I completely reWrote it, of course. Melzzzzz <mel@zzzzz.com> - 2017-01-03 12:28 +0100
            Re: I completely reWrote it, of course. chrisv <chrisv@nospam.invalid> - 2017-01-03 07:32 -0600
              Ezekiel lives in your head RENT FREE!!  LOL!!! GreyCloud <mist@cumulus.com> - 2017-01-03 12:16 -0700
              With "warnings as errors", turn off these warnings. Jeff-Relf.Me <@.> - 2017-01-03 13:00 -0800
            Re: I completely reWrote it, of course. GreyCloud <mist@cumulus.com> - 2017-01-03 12:16 -0700
              Re: I completely reWrote it, of course. red floyd <dont.bother@its.invalid> - 2017-01-03 12:30 -0800
                If you're retarded then, yes, _Loop() is "undefined". Jeff-Relf.Me <@.> - 2017-01-16 11:06 -0800
              Re: I completely reWrote it, of course. scott@slp53.sl.home (Scott Lurndal) - 2017-01-04 13:33 +0000
                Re: I completely reWrote it, of course. chrisv <chrisv@nospam.invalid> - 2017-01-04 07:45 -0600
                  Re: I completely reWrote it, of course. scott@slp53.sl.home (Scott Lurndal) - 2017-01-04 14:54 +0000
                    The Longest Common Sequence ( NonContiguous ) algorithm ( recursive ). Jeff-Relf.Me <@.> - 2017-01-04 10:17 -0800
                      Re: The Longest Common Sequence ( NonContiguous ) algorithm ( recursive ). Peter Köhlmann <peter-koehlmann@t-online.de> - 2017-01-04 19:19 +0100
                        Re: The Longest Common Sequence ( NonContiguous ) algorithm ( recursive ). noTthaTguY <abu.kuanysh05@gmail.com> - 2017-01-04 16:33 -0800
                          Re: The Longest Common Sequence ( NonContiguous ) algorithm ( recursive ). noTthaTguY <abu.kuanysh05@gmail.com> - 2017-01-09 16:23 -0800
                      Re: The Longest Common Sequence ( NonContiguous ) algorithm ( recursive ). moroney@world.std.spaamtrap.com (Michael Moroney) - 2017-01-05 03:34 +0000
                        The Longest Common Sequence ( NonContiguous ) algorithm ( recursive ). Jeff-Relf.Me <@.> - 2017-01-04 22:26 -0800
                          Re: The Longest Common Sequence ( NonContiguous ) algorithm ( recursive ). Anonymous <anonymous@invalid.tld> - 2017-01-05 08:18 +0000
                            Re: The Longest Common Sequence ( NonContiguous ) algorithm ( recursive ). Peter Köhlmann <peter-koehlmann@t-online.de> - 2017-01-05 09:24 +0100
                            PostScript is my thing. Jeff-Relf.Me <@.> - 2017-01-05 01:08 -0800
                          My diffs now _perfectly match MicroSoft's WinMerge. Jeff-Relf.Me <@.> - 2017-01-07 03:56 -0800
                            Re: My diffs now _perfectly match MicroSoft's WinMerge. Peter Köhlmann <peter-koehlmann@t-online.de> - 2017-01-07 13:09 +0100
                            Re: My diffs now _perfectly match MicroSoft's WinMerge. moroney@world.std.spaamtrap.com (Michael Moroney) - 2017-01-07 20:25 +0000
                              Like a compiler that compiles itself, my Diff app diffs itself. Jeff-Relf.Me <@.> - 2017-01-07 17:53 -0800
                              Re: My diffs now _perfectly match MicroSoft's WinMerge. Christian Gollwitzer <auriocus@gmx.de> - 2017-01-10 22:15 +0100
                                Text file comparison is essential. Jeff-Relf.Me <@.> - 2017-01-16 11:23 -0800
                                  Re: Text file comparison is essential. noTthaTguY <abu.kuanysh05@gmail.com> - 2017-01-17 11:22 -0800
                                  Nothing to compare, left and right, old and new. Jeff-Relf.Me <@.> - 2017-01-19 04:12 -0800
                      Re: The Longest Common Sequence ( NonContiguous ) algorithm ( recursive ). jmfbahciv <See.above@aol.com> - 2017-01-05 14:08 +0000
                      Re: The Longest Common Sequence ( NonContiguous ) algorithm ( recursive ). Vir Campestris <vir.campestris@invalid.invalid> - 2017-01-05 21:09 +0000
                        Re: The Longest Common Sequence ( NonContiguous ) algorithm ( recursive ). legalize+jeeves@mail.xmission.com (Richard) - 2017-01-05 21:19 +0000
                          "Functional" programming is "Tree Crawling". Jeff-Relf.Me <@.> - 2017-01-05 14:53 -0800
                      Re: The Longest Common Sequence ( NonContiguous ) algorithm ( recursive ). Lofty Goat <rlwatkins@gmail.com> - 2017-01-05 17:43 -0600
                    Re: I completely reWrote it, of course. jmfbahciv <See.above@aol.com> - 2017-01-05 14:08 +0000
              What about you, GreyCloud ? Jeff-Relf.Me <@.> - 2017-01-16 11:02 -0800
                Re: What about you, GreyCloud ? GreyCloud <mist@cumulus.com> - 2017-01-16 19:46 -0700
                  Health issues ? Jeff-Relf.Me <@.> - 2017-01-16 20:39 -0800
                    Re: Health issues ? GreyCloud <mist@cumulus.com> - 2017-01-17 11:50 -0700
                      Re: Health issues ? noTthaTguY <abu.kuanysh05@gmail.com> - 2017-01-17 14:19 -0800
                        Re: Health issues ? noTthaTguY <abu.kuanysh05@gmail.com> - 2017-01-17 18:44 -0800
                      Negative Interest Rates. Jeff-Relf.Me <@.> - 2017-01-19 04:25 -0800
                        Re: Negative Interest Rates. GreyCloud <mist@cumulus.com> - 2017-01-19 11:47 -0700
                          Negative Interest Rates "rips off" rich people, not the poor. Jeff-Relf.Me <@.> - 2017-01-19 19:23 -0800
                            Re: Negative Interest Rates "rips off" rich people, not the poor. GreyCloud <mist@cumulus.com> - 2017-01-20 16:17 -0700
                Tons of people have reviewed the code, source and object. Jeff-Relf.Me <@.> - 2017-01-19 04:02 -0800
                Building a complex system can't be done when you're drunk and horny. Jeff-Relf.Me <@.> - 2017-01-19 04:17 -0800
                  Re: Building a complex system can't be done when you're drunk and horny. David Brown <david.brown@hesbynett.no> - 2017-01-19 13:59 +0100
                    No one is here to learn at your feet, sorry. Jeff-Relf.Me <@.> - 2017-01-19 05:30 -0800
                    Re: Building a complex system can't be done when you're drunk and horny. chrisv <chrisv@nospam.invalid> - 2017-01-19 07:37 -0600
                      Building a complex system can't be done when you're drunk and horny. Jeff-Relf.Me <@.> - 2017-01-19 05:43 -0800
                        Re: Building a complex system can't be done when you're drunk and horny. noTthaTguY <abu.kuanysh05@gmail.com> - 2017-01-19 10:06 -0800
                    Re: Building a complex system can't be done when you're drunk and horny. moroney@world.std.spaamtrap.com (Michael Moroney) - 2017-01-20 04:32 +0000
                      Usenet isn't WikiPedia; here, it's all play and no work, anything goes. Jeff-Relf.Me <@.> - 2017-01-19 21:02 -0800
                        yeah, you can always prefer your preferred header noTthaTguY <abu.kuanysh05@gmail.com> - 2017-01-19 21:22 -0800
          The "Least Longest" diffs. Jeff-Relf.Me <@.> - 2017-01-03 03:04 -0800

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

#612299 — Re: The Longest Common Sequence ( NonContiguous ) algorithm ( recursive ).

raspberry pi\arduino etc.;
lowest common sequence sounds interesting, t00

> any way, most folks use those little what-you-call'ems,
> the makers, what ever language they use a lot

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

#611714 — Re: The Longest Common Sequence ( NonContiguous ) algorithm ( recursive ).

Jeff-Relf.Me <@.> writes:

>All the code that I posted here has been _trashed already.

Yay! Relfie did something right for once!

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

#611725 — The Longest Common Sequence ( NonContiguous ) algorithm ( recursive ).

You ( MichaelMoroney ) replied ( to me ):
> > All the code that I posted here has been _trashed already.
> 
> Yay! Relfie did something right for once!

Thanks, but it's just a refinement, not a big deal.

My guide:

  " Dynamic Programming | Set 4 (Longest Common Subsequence) "
  http://www.geeksforgeeks.org/dynamic-programming-set-4-longest-common-subsequence/

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

#611728 — Re: The Longest Common Sequence ( NonContiguous ) algorithm ( recursive ).

Jeff-Relf.Me <@.> in <Jeff-Relf.Me@Jan.4--10.26P.Seattle.2017> writes:

> You ( MichaelMoroney ) replied ( to me ):
>> > All the code that I posted here has been _trashed already.
>> 
>> Yay! Relfie did something right for once!
>
> Thanks, but it's just a refinement, not a big deal.
>
> My guide:
>
>   " Dynamic Programming | Set 4 (Longest Common Subsequence) "
>   http://www.geeksforgeeks.org/dynamic-programming-set-4-longest-common-subsequence/

Jeff, just out of curiosity: did you ever tried programming in Lisp or Forth?

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

#611729 — Re: The Longest Common Sequence ( NonContiguous ) algorithm ( recursive ).

Anonymous wrote:

> Jeff-Relf.Me <@.> in <Jeff-Relf.Me@Jan.4--10.26P.Seattle.2017> writes:
> 
>> You ( MichaelMoroney ) replied ( to me ):
>>> > All the code that I posted here has been _trashed already.
>>> 
>>> Yay! Relfie did something right for once!
>>
>> Thanks, but it's just a refinement, not a big deal.
>>
>> My guide:
>>
>>   " Dynamic Programming | Set 4 (Longest Common Subsequence) "
>>   http://www.geeksforgeeks.org/dynamic-programming-set-4-longest-common-subsequence/
> 
> Jeff, just out of curiosity: did you ever tried programming in Lisp or
> Forth?

Relf programmes in "Shit". And naturally writes shitty code

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

#611730 — PostScript is my thing.

You ( Anonymous ) asked me:
//  Jeff, just out of curiosity: did you ever tried programming in Lisp or Forth?

Lisp no ( not seriously ).  Forth/PostScript yes, -- big time.

PostScript is my thing.  WikiPedia says: ＜＜

  PostScript is an interpreted, stack-based language 
  similar to Forth but with strong dynamic typing, 
  data structures inspired by those found in Lisp, 
  scoped memory and, since language level 2, garbage collection.  ＞＞

  https://en.wikipedia.org/wiki/PostScript#The_language

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

#612073 — My diffs now _perfectly match MicroSoft's WinMerge.

I wrote:
> My guide: " Dynamic Programming | Set 4 (Longest Common Subsequence) "
>   http://www.geeksforgeeks.org/dynamic-programming-set-4-longest-common-subsequence/

As is turns out, the The Longest Common Sequence ( NonContiguous ) algorithm,
outlined above, works better than what I was using before.
It uses a table, not recursion; recursion overflows the stack.

My diffs now _perfectly match MicroSoft's WinMerge.
Now _any whitspace change, including blank lines, is flaged.
Now, certain odd cases produce smaller diffs, which is _nice.
Before, my sequence of LeftOlder diffs was slightly different from RightNewer.

The code:

  //  ScreenShot:  http://Jeff-Relf.Me/Diff.PNG
  //  Help/Settings:  http://Jeff-Relf.Me/X.HTM

  //  _FileCmp(), below, records thousands of matching lines ( text ),
  //  LeftOlder vs RightNewer, using the "LongestCommonSequence"
  //  ( shortest diffs ) algorithm.
  //  
  //  BB is a pointer to the start of 
  //  a dynamic array of ( contiguous ) pointers ( lines );
  //  PP points to the end of the array.
  //  
  //   BB and  PP are from the LeftOlder file.
  //  _BB and _PP are from the RightNewer file.

  _FileCmp( LnA BB, LnA _BB, LnA PP, LnA _PP, LnT &Ln ) { 

    int Rows = PP - BB + 1, Cols = _PP - _BB + 1 ;  u64 Row = Rows, Col = Cols ;

    //  Allocate a " LeftOlderLines * RightNewerLines " table of 32 bit integers
    //  to store all LongestCommonSequence Lengths.
 
    pInt _Table = (pInt)MallocTmp( Rows * Cols * szInt );
    { LoopRow( Rows ) { LoopCol( Cols ) { 

        if ( !Row || !Col ) { Table( Row, Col ) = 0 ;  continue ;  }
        if ( aMatch ) Table( Row, Col ) = Table( Row - 1, Col - 1 ) + 1 ; 
        else Table( Row, Col ) = ER( Table( Row, Col - 1 ), Table( Row - 1, Col ) );  } } }

    //  " Ln " is a dynamic array of thousands of ( contiguous ) 64 bit pointers,
    //  repurosed to store two 32 bit intergers ( Row and Col ) in a pointer.
    //  If both files are the same, with X Lines, it'll store X RowCol pairs.
    //  
    //  The first " StoreRowColumn ", below, stores the end of the files;
    //  the last is first, and vice versa; it's reversed.

    Zero( Ln ), StoreRowColumn;  
    while ( Row > 0 && Col > 0 ) 
      if ( aMatch ) StoreRowColumn ;
      else Table( Row, Col - 1 ) > Table( Row - 1, Col ) ? Col-- : Row-- ;  }


Near Globals:

  //  Access " _Table ", a One Dimensional array, as if it were Two Dimensional.
  #define  Table( i, j )  _Table[ ( j ) * Rows + i ]

  //  F[-1] is the ( 16 bit ) length of the leading whitespace.
  #define  aMatch  ( F = BB[ Row - 1 ], _F = _BB[ Col - 1 ], F[-1] == _F[-1] && Eq( F, _F ) )

  //  Store the matching lines as line numbers from LeftOlder and RightNewer 
  #define  StoreRowColumn  ( Inc( Ln ) = LnP( Row - 1 << 32 | Col - 1 ), Row--, Col-- )

  LnP  F, _F ;

Far Globals:

  #define  Zero( X )  memset( & X, 0, sizeof X )
  #define  Eq  !strCmp

  #define  LoopRows( N )  int  Row = -1, eRow = ( N ) - 1 ; while ( ++Row <= eRow )
  #define  LoopCols( N )  int  Col = -1, eCol = ( N ) - 1 ; while ( ++Col <= eCol )

  typedef wchar_t  wchar ;  typedef wchar  *LnP ;  typedef  LnP  *LnA ; 
  typedef int  *pInt ;  typedef void  *Void_P ;  typedef unsigned __int64  u64 ;
  const int  szInt = sizeof( int );

  struct  LnT { LnA  BB, PP, maxPP ;  };  LnT  Ln ;

  //  " Inc() ", below, dynamically allocates thousands of ( contiguous ) pointers.
  //  When diff is done, " Temp_Heap " is simply destroyed.

  template < typename TyT, typename TyA, typename TyP >
  TyP & Inc( TyT  & Xx, int N ) {  int I_PP, I_PP_New, I_maxPP, rv, Sz, Temp_Heap = N >= 0 ;  if ( !Temp_Heap ) N = 1 ;
    I_PP = !Xx.PP ? -1 : Xx.PP - Xx.BB, I_maxPP = !Xx.maxPP ? 0 : Xx.maxPP - Xx.BB, I_PP_New = I_PP + N ;  if( I_maxPP < 0 ) exit(1);
    if ( I_PP_New < I_maxPP ) {    OK:    return  Xx.PP = Xx.BB + I_PP_New, *Xx.PP ;  }
    rv = ER( 1024, 3 * I_PP_New ), Sz = 16 + rv * szPtr ; 
    Xx.maxPP = Xx.BB = TyA( Temp_Heap ? ReAllocTmp( Xx.BB, ++I_PP * szPtr, Sz ) : realloc( Xx.BB, Sz ) ), Xx.maxPP += rv ;
    if( !Xx.BB ) exit(1);  goto OK ;    }

  LnP &Inc( LnT &Ln ) { return Inc< LnT, LnA, LnP>( Ln,  1 ) ;  }

  LnP ReAllocTmp( Void_P B⁰, int Sz⁰, int Sz ) { Void_P  B = B⁰ ; if ( Sz > 0 && Sz > Sz⁰ ) B = MallocTmp( Sz );
    if ( B⁰ && Sz⁰ > 0 ) memmove( B, B⁰, Sz⁰ );  return LnP( B );  }

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

#612074 — Re: My diffs now _perfectly match MicroSoft's WinMerge.

 wrote:

> I wrote:
>> My guide: " Dynamic Programming | Set 4 (Longest Common Subsequence) "
>>   http://www.geeksforgeeks.org/dynamic-programming-set-4-longest-common-subsequence/
> 

< snip shitty code >

Just leave us alone with your shite. That garbage is not worth to be pissed 
on

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

#612099 — Re: My diffs now _perfectly match MicroSoft's WinMerge.

Jeff-Relf.Me <@.> writes:

>My diffs now _perfectly match MicroSoft's WinMerge.
>Now _any whitspace change, including blank lines, is flaged.

While you continue to struggle getting your differences going, I
will continue using the differences code I have, which, although
ancient (but updated for modern computer advances), is based on a rather 
sophisticated algorithm.  It's recursive, but with memory measured in
gigabytes these days and efficient use of the stack, this is not a
problem.

It can turn on or off whether spaces/whitespace, character case, the
number of matching lines before a section after a mismatch is considered
matching, and how far to look ahead to look for a match etc.  It can even
produce editing output to produce merged sources so that if Person A makes
some source code changes implementing Change X, and Person B makes changes
to the same original code implementing Change Y, and Person C makes his
own changes Z to the same original code, I can easily produce code with
all three changes X, Y and Z in it.  Of course any changes to the same
area are flagged for special consideration, and there is never any
guarantee all changes are even compatible with each other, but it is a
huge headstart when the goal is to produce new code with changes X, Y and
Z in it.

Another nice feature is it doesn't run on Windows.

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

#612142 — Like a compiler that compiles itself, my Diff app diffs itself.

You ( Michael Moroney ) replied ( to me ):
> > My diffs now _perfectly match WinMerge's.
> > Now _any whitspace change, including blank lines, is flaged.
> 
> While you continue to struggle [[ with your Diff utility ]]

Like a compiler that compiles itself, my Diff app diffs itself;
I use it all day, everyday, year after year; for me, and only me,
there's nothing better; see:  http://Jeff-Relf.Me/Diff.PNG

> I will continue using the differences code I have, which, 
> although ancient ( but updated for modern computer advances ), 
> is based on a rather sophisticated algorithm.  
> 
> It's recursive, but with memory measured in gigabytes these days
> and efficient use of the stack, this is not a problem.

Cool, I _should try that; I'd have to up my stack limits, somehow;
if both files were the same, with X Lines, it'd recurse X times.
Oh great ! more work, thanks a lot.  ha ha

> It can turn on or off whether spaces/whitespace, character case, the
> number of matching lines before a section after a mismatch is considered
> matching, and how far to look ahead to look for a match etc.  

Interesting options, Thanks, but I'm not so sure I'd need them.

> It can even [[ compare/merge 3 versions ]]
> so that if Person A makes some source code changes implementing Change X, 
> and Person B makes changes to the same original code 
> implementing Change Y, and Person C makes his own changes, Z,
> to the same original code, I can easily produce code with
> all three changes X, Y and Z in it.
> 
> Of course any changes to the same area 
> are flagged for special consideration [...] 

Flagging/HighLighting what version ( not what author )
made what change, would be cool... nice idea, thanks.
More work !  I need to get outside more often, seriously.

> Another nice feature: it doesn't run on Windows.

The right tool for the right job, no ?

My Diff code ( posted ) is just a tool ( one of many ) in X.EXE/.CPP;
I run multiple copies of X.EXE all day, everyday, year after year; 
-- for me, and only me, there's nothing better.

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

#612398 — Re: My diffs now _perfectly match MicroSoft's WinMerge.

Am 07.01.17 um 21:25 schrieb Michael Moroney:
> It can turn on or off whether spaces/whitespace, character case, the
> number of matching lines before a section after a mismatch is considered
> matching, and how far to look ahead to look for a match etc.  It can even
> produce editing output to produce merged sources so that if Person A makes
> some source code changes implementing Change X, and Person B makes changes
> to the same original code implementing Change Y, and Person C makes his
> own changes Z to the same original code, I can easily produce code with
> all three changes X, Y and Z in it.  Of course any changes to the same
> area are flagged for special consideration, and there is never any
> guarantee all changes are even compatible with each other, but it is a
> huge headstart when the goal is to produce new code with changes X, Y and
> Z in it.


Sounds good.

> Another nice feature is it doesn't run on Windows.
>

what, git and GNU textutils don't run on Windows?

	Christian (has never felt the urge to reimplement diff algorithms)

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

#613396 — Text file comparison is essential.

Christian Gollwitzer wrote:
> I've never felt the urge to reimplement diff algorithms

The best code ( for me, and only me ) 
is the code I designed and wrote myself.

As a programmer, text file comparison is essential, like water;
so I wrote my own diff routines.

ScreenShot:  http://Jeff-Relf.Me/Diff.PNG
Help/Settings:  http://Jeff-Relf.Me/X.HTM

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

#613612 — Re: Text file comparison is essential.

thankyou, mcaba

> As a programmer, text file comparison is essential, like water;
> so I wrote my own diff routines.
> 
> ScreenShot:  http://Jeff-Relf.Me/Diff.PNG
> Help/Settings:  http://Jeff-Relf.Me/X.HTM

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

#614055 — Nothing to compare, left and right, old and new.

You ( MrDFS ) asked me:
> > ScreenShot:  http://Jeff-Relf.Me/Diff.PNG
> > Help/Settings:  http://Jeff-Relf.Me/X.HTM
> 
> What are those green and red boxes/lines for?

They group lines of code together; red for old, green for new.

Fact is, most of my changes are a _huge blur of green and red;
nothing to compare, left and right, old and new.

Using the standard algorithm (WinMerge) didn't help.
Weak as it is, I use it to review changes.

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

#611737 — Re: The Longest Common Sequence ( NonContiguous ) algorithm ( recursive ).

Jeff-Relf.Me wrote:
> You ( Scott Lurndal ) replied:
>> > > > He doesn't work for anybody needing code.
>> > > > That much is certain.  Otherwise, he'd have been fired.
>> > >
>> > > I dunno - I've seen similar code in shipping products:
>> > > For example (Product: ADSINP, language: BPL circa 1977):
>> >
>> > I suppose that there are some clueless managers
>> > who are "impressed" by impenetrable code.
>>
>> to be fair, in the 1970's, there were limits on pretty
>> much everything, including number of lines that a compiler could
>> handle in a reasonable amount of time given memory constraints.
>>
>> Compact (dense) code was more the rule
>> than the exception in those days.
>
> My C++ is dense, 236 columns wide, and I'm running:

Oh, goodfuckinggrief.  That's not the definition of dense code.
It's called human-unreadable code.  White space helps the
maintainer and gives one margins to scribble notes.

Now everything you wrote about this subject makes sense.

[embarassed emotiocn here for not thinking of his definition]

You are a newbie.

/BAH

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

#611799 — Re: The Longest Common Sequence ( NonContiguous ) algorithm ( recursive ).

On 04/01/2017 18:17, Jeff-Relf.Me wrote:
> When I see sparse code, with lots of whitespace and comments,
> I _immediately know the programmer is struggling.

If whitespace is bad how come APL is unreadable?

Andy

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

#611801 — Re: The Longest Common Sequence ( NonContiguous ) algorithm ( recursive ).

[Please do not mail me a copy of your followup]

Vir Campestris <vir.campestris@invalid.invalid> spake the secret code
<_JKdnVUjT6pyKPPFnZ2dnUU78b-dnZ2d@brightview.co.uk> thusly:

>On 04/01/2017 18:17, Jeff-Relf.Me wrote:
>> When I see sparse code, with lots of whitespace and comments,
>> I _immediately know the programmer is struggling.
>
>If whitespace is bad how come APL is unreadable?

APL is unreadable in the sense that Chinese or Arabic is unreadable to
someone who only knows latin/european languages.  It uses unfamiliar
symbols and it reads right to left.  Sometimes Chinese is typeset top
to bottom and sometimes (particularly in modern text) it is typeset
left to right.  These things make it very foreign to a new reader, but
once oriented on the symbols (APL is much easier to grasp than Chinese
in this regard!) and the proper direction in which to read the code,
it's not that bad.

The bigger mind-twist for a conventional procedurally oriented thinker
is the switch to functional oriented thinking.
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
            The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://computergraphicsmuseum.org>
  Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

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

#611829 — "Functional" programming is "Tree Crawling".

Speaking of Chinese, you ( Direct3D Richard ) wrote:
> The bigger mind-twist for a conventional procedurally oriented thinker
> is the switch to functional oriented thinking.

"Functional" programming is "Tree Crawling"; 
i.e. you spend all your time crawling on trees, like an ant.

Mostly, it's used in academia, not the market place.
When you see a lot of WhiteSpace and comments,
you know, _right _away, that there's a problem.

Dense PostScript ( .PDF ), on the other hand, is ubiquitous.
I use C++, instead of C, because it's basically C,
but with nice extras.  I've C++ code that generates .PDF files.

C++ also has paths/lines/arcs, like PostScript; to wit:

  ScreenShot: Jeff-Relf.Me/Chess.PNG

  ID2D1PathGeometry *Path ;  ID2D1GeometrySink *pSink ;

  r = Prev ? D/2 : W/2, x = MvX( From ), y = MvY( From ); 
  X = MvX( To ), Y = MvY( To ), dx = X - x, dy = Y - y ;
  Compass = atan2( dy, dx ); 

  Tangent = Pi/2 - asin( r/sqrt( dx*dx + dy*dy ) ); 
  Start = Compass + Tangent, End = Compass - Tangent ;
  Direct2D->CreatePathGeometry( &Path ); 

  Path->Open( &pSink ), pSink->SetFillMode( D2D1_FILL_MODE_WINDING );
  pSink->BeginFigure( Pnt( X, Y ), D2D1_FIGURE_BEGIN_FILLED );
  dx = r*cos( Start ), dy = r*sin( Start );
 
  pSink->AddLine( Pnt( x + dx, y + dy ) ), dx = r*cos( End ), dy = r*sin( End );

  D2D1_ARC_SEGMENT  Arc = { 
     { x + dx, y + dy }, { r, r }, 0, D2D1_SWEEP_DIRECTION_CLOCKWISE, 
     fmod( _360 + End - Start, _360 ) > Pi ? D2D1_ARC_SIZE_LARGE : D2D1_ARC_SIZE_SMALL };

  pSink->AddArc( Arc ); 
  pSink->EndFigure( D2D1_FIGURE_END_CLOSED ); 
  pSink->Close(), Trash( pSink );
  dxWin->SetTarget( WinSur ), dxWin->DrawGeometry( Path, C, LnW );
  dxWin->FillGeometry( Path, TransBlush );

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

#611846 — Re: The Longest Common Sequence ( NonContiguous ) algorithm ( recursive ).

On Wed, 04 Jan 2017 10:17:59 -0800 (Seattle), Jeff-Relf.Me <@.> wrote:

>When I see sparse code, with lots of whitespace and comments,
>I _immediately know the programmer is struggling.

No, you don't know that.  That's an expression of desperate bravado on
your part, not of experience or wisdom.

I've been programming for 45 years.  I've seen your code.  You're a
terrible programmer.

Why do I say so?

You play with language features like a tiny child randomly plugging
tinkertoy parts together, rather than using them as they were intended,
to construct useful, maintainable processes.

You're pretty smart, but apparently lack the confidence to do anything
that's both useful and complex.

Stop fucking around and try it.  You  might succeed.  What you're doing
now is deliberate, and elaborate and therefore obscure, failure.

-- 
Goat

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

#611738 — Re: I completely reWrote it, of course.

Scott Lurndal wrote:
> chrisv <chrisv@nospam.invalid> writes:
>>Scott Lurndal wrote:
>>
>>> some POS that calls itself "GreyCloud" wrote:
>>>>
>>>>He doesn't work for anybody needing code.  That much is certain.
>>>>Otherwise, he'd have been fired.
>>>
>>>I dunno - I've seen similar code in shipping products:
>>>
>>>For example (Product: ADSINP, language: BPL circa 1977):
>>
>>I suppose that there are some clueless managers who are "impressed" by
>>impenetrable code.
>
> to be fair, in the 1970's, there were limits on pretty
> much everything, including number of lines that a compiler could
> handle in a reasonable amount of time given memory constraints.
>
> Compact (dense) code was more the rule than the exception in those
> days.

Another reason is having been on a firefight, fixing the installation's
code so it can run, then carrying back the changes and taking 2 months
to figure out why the new fixes worked.  However, the end result is
"if it ain't broke, don't fix it" so the impenetrable code stays
with lots of comments including "thar be dragons".

/BAH

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

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

Back to top | Article view | sci.physics

csiph-web