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

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

primitive instruction for programming

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

Contents

  primitive instruction for programming asetofsymbols@gmail.com - 2015-04-13 00:56 -0700
    Re: primitive instruction for programming Richard Heathfield <rjh@cpax.org.uk> - 2015-04-13 09:24 +0100
      Re: primitive instruction for programming asetofsymbols@gmail.com - 2015-04-13 01:59 -0700
        Re: primitive instruction for programming Richard Heathfield <rjh@cpax.org.uk> - 2015-04-13 10:32 +0100
          Re: primitive instruction for programming asetofsymbols@gmail.com - 2015-04-13 02:53 -0700
            Re: primitive instruction for programming Bartc <bc@freeuk.com> - 2015-04-13 11:04 +0100
            Re: primitive instruction for programming David Brown <david.brown@hesbynett.no> - 2015-04-13 14:10 +0200
              Re: primitive instruction for programming Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-20 14:27 -0700
                Re: primitive instruction for programming Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-20 15:12 -0700
                  Re: primitive instruction for programming Bartc <bc@freeuk.com> - 2015-04-21 00:17 +0100
                    Re: primitive instruction for programming Emiliano Gomes Padilha <egpadilha@gmail.com> - 2015-04-22 11:07 -0700
                Re: primitive instruction for programming David Brown <david.brown@hesbynett.no> - 2015-04-21 09:04 +0200
                  Re: primitive instruction for programming Robert Wessel <robertwessel2@yahoo.com> - 2015-04-21 03:02 -0500
                  Re: primitive instruction for programming asetofsymbols@gmail.com - 2015-04-21 01:34 -0700
                    Re: primitive instruction for programming David Brown <david.brown@hesbynett.no> - 2015-04-21 11:34 +0200
                      Re: primitive instruction for programming Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-21 11:48 +0100
                        Re: primitive instruction for programming David Brown <david.brown@hesbynett.no> - 2015-04-21 13:10 +0200
                    Re: primitive instruction for programming Bartc <bc@freeuk.com> - 2015-04-21 10:53 +0100
      Re: primitive instruction for programming Bartc <bc@freeuk.com> - 2015-04-13 20:09 +0100
        Re: primitive instruction for programming asetofsymbols@gmail.com - 2015-04-13 12:48 -0700
        Re: primitive instruction for programming David Brown <david.brown@hesbynett.no> - 2015-04-14 09:40 +0200
          Re: primitive instruction for programming Bartc <bc@freeuk.com> - 2015-04-14 11:24 +0100
            Re: primitive instruction for programming Robert Wessel <robertwessel2@yahoo.com> - 2015-04-14 05:39 -0500
            Re: primitive instruction for programming David Brown <david.brown@hesbynett.no> - 2015-04-14 13:29 +0200
    Re: primitive instruction for programming Bartc <bc@freeuk.com> - 2015-04-13 10:59 +0100
      Re: primitive instruction for programming asetofsymbols@gmail.com - 2015-04-13 03:28 -0700
        Re: primitive instruction for programming asetofsymbols@gmail.com - 2015-04-13 03:33 -0700
          Re: primitive instruction for programming asetofsymbols@gmail.com - 2015-04-13 03:59 -0700
            Re: primitive instruction for programming asetofsymbols@gmail.com - 2015-04-13 04:23 -0700
        Re: primitive instruction for programming Bartc <bc@freeuk.com> - 2015-04-13 11:36 +0100
          Re: primitive instruction for programming asetofsymbols@gmail.com - 2015-04-13 04:26 -0700
            Re: primitive instruction for programming Bartc <bc@freeuk.com> - 2015-04-13 12:41 +0100
              Re: primitive instruction for programming asetofsymbols@gmail.com - 2015-04-13 06:26 -0700
                Re: primitive instruction for programming David Brown <david.brown@hesbynett.no> - 2015-04-13 15:33 +0200
                  Re: primitive instruction for programming asetofsymbols@gmail.com - 2015-04-13 06:44 -0700
                    Re: primitive instruction for programming David Brown <david.brown@hesbynett.no> - 2015-04-13 16:30 +0200
                      Re: primitive instruction for programming Ian Collins <ian-news@hotmail.com> - 2015-04-14 07:52 +1200
                        Re: primitive instruction for programming David Brown <david.brown@hesbynett.no> - 2015-04-14 09:47 +0200
                          Re: primitive instruction for programming raltbos@xs4all.nl (Richard Bos) - 2015-04-14 08:10 +0000
                            Re: primitive instruction for programming David Brown <david.brown@hesbynett.no> - 2015-04-14 10:40 +0200
          Re: primitive instruction for programming Steve Thompson <stevet810@gmail.com> - 2015-04-13 17:52 +0000
            Re: primitive instruction for programming Robert Wessel <robertwessel2@yahoo.com> - 2015-04-13 18:20 -0500
              Re: primitive instruction for programming Robert Wessel <robertwessel2@yahoo.com> - 2015-04-13 18:33 -0500
                Re: primitive instruction for programming Steve Thompson <stevet810@gmail.com> - 2015-04-14 19:51 +0000
            Re: primitive instruction for programming Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-16 09:04 -0700
              Re: primitive instruction for programming Steve Thompson <stevet810@gmail.com> - 2015-04-17 02:25 +0000
                Re: primitive instruction for programming Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-17 08:34 -0700
                  Re: primitive instruction for programming Bartc <bc@freeuk.com> - 2015-04-17 17:49 +0100
                  Re: primitive instruction for programming Steve Thompson <stevet810@gmail.com> - 2015-04-17 19:06 +0000
                    Re: primitive instruction for programming Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-17 20:45 -0700
                      Re: primitive instruction for programming Steve Thompson <stevet810@gmail.com> - 2015-04-18 16:43 +0000
                        Re: primitive instruction for programming Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-18 09:56 -0700
                  Re: primitive instruction for programming Stephen Sprunk <stephen@sprunk.org> - 2015-04-17 17:52 -0500
                    Re: primitive instruction for programming Morris Dovey <mrdovey@iedu.com> - 2015-04-17 18:02 -0500
                      Re: primitive instruction for programming Stephen Sprunk <stephen@sprunk.org> - 2015-04-17 19:26 -0500
                        Re: primitive instruction for programming Morris Dovey <mrdovey@iedu.com> - 2015-04-17 20:04 -0500
                    Re: primitive instruction for programming Michael Angelo Ravera <maravera@prodigy.net> - 2015-04-19 14:59 -0700
                      Re: primitive instruction for programming Richard Heathfield <rjh@cpax.org.uk> - 2015-04-20 00:19 +0100
                        Re: primitive instruction for programming Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-20 02:06 +0100
                          Re: primitive instruction for programming Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-20 02:26 +0100
                          Re: primitive instruction for programming Richard Heathfield <rjh@cpax.org.uk> - 2015-04-20 02:18 +0100
                Re: primitive instruction for programming Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-18 18:59 -0700
                  Re: primitive instruction for programming Steve Thompson <stevet810@gmail.com> - 2015-04-19 16:28 +0000
                    Re: primitive instruction for programming Richard Damon <Richard@Damon-Family.org> - 2015-04-19 17:16 -0400
                    Re: primitive instruction for programming Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-22 15:28 -0700
            Re: primitive instruction for programming John Bode <jfbode1029@gmail.com> - 2015-04-23 07:20 -0700
    Re: primitive instruction for programming fmassei@gmail.com - 2015-04-13 03:07 -0700
      Re: primitive instruction for programming asetofsymbols@gmail.com - 2015-04-13 09:47 -0700
        Re: primitive instruction for programming fmassei@gmail.com - 2015-04-13 11:09 -0700
          Re: primitive instruction for programming Noob <root@127.0.0.1> - 2015-04-13 20:43 +0200
            Re: primitive instruction for programming fmassei@gmail.com - 2015-04-13 12:09 -0700
              Re: primitive instruction for programming Xcott Craver <xcottcraver@gmail.com> - 2015-04-14 07:11 -0700
                Re: primitive instruction for programming fmassei@gmail.com - 2015-04-14 07:28 -0700
                  Re: primitive instruction for programming Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-14 15:57 +0100
                    Re: primitive instruction for programming fmassei@gmail.com - 2015-04-14 08:13 -0700
        Re: primitive instruction for programming fir <profesor.fir@gmail.com> - 2015-04-13 14:02 -0700
          Re: primitive instruction for programming asetofsymbols@gmail.com - 2015-04-13 14:28 -0700
            Re: primitive instruction for programming Bartc <bc@freeuk.com> - 2015-04-13 22:51 +0100
              Re: primitive instruction for programming fmassei@gmail.com - 2015-04-13 14:58 -0700
                Re: primitive instruction for programming Bartc <bc@freeuk.com> - 2015-04-13 23:25 +0100
                  Re: primitive instruction for programming fmassei@gmail.com - 2015-04-13 15:37 -0700
                    Re: primitive instruction for programming James Kuyper <jameskuyper@verizon.net> - 2015-04-13 19:09 -0400
                      Re: primitive instruction for programming fmassei@gmail.com - 2015-04-13 16:20 -0700
                  Re: primitive instruction for programming Robert Wessel <robertwessel2@yahoo.com> - 2015-04-13 18:03 -0500
              Re: primitive instruction for programming asetofsymbols@gmail.com - 2015-04-13 20:58 -0700
            Re: primitive instruction for programming fir <profesor.fir@gmail.com> - 2015-04-13 15:02 -0700

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

#60486

On 20/04/15 02:06, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
<snip>

>>
>> With a simple main() and binary search, we quickly establish (by
>> determining when the population was 2, give or take a rib) that Adam
>> and Eve lived about 1500 years ago.
>
> I applaud your attempt to shoe-horn some C into this thread, but binary
> search?  Seriously?

It's been a long day.

-- 
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]

#60358

Steve Thompson <stevet810@gmail.com> writes:
> On Thu, Apr 16, 2015 at 09:04:34AM -0700, Tim Rentsch wrote:
>> Steve Thompson <stevet810@gmail.com> writes:
>>
>>> On Mon, Apr 13, 2015 at 11:36:56AM +0100, Bartc wrote:
>>>> On 13/04/2015 11:28, asetofsymbols@gmail.com wrote:
>>>>> Bartc wrote:
>>>>> [code example that uses labels and goto's]
>>>>
>>>> This style of code is more error-prone.  It's not even obvious
>>>> where l1 needs to go;  I can put it in several places and it
>>>> would still compile, but the program won't work.
>>>>
>>>> This is something that just isn't a problem when using
>>>> conventional control structures;  why do you want to introduce
>>>> a new source of bugs?
>>>
>>> One of the things I've been trying to do is an inorder traversal
>>> of a binary tree without using recursion.  With normal control
>>> structures it doesn't seem possible without using goto.
>>
>> This is an interesting problem.  It has a solution that is
>> fairly simple but not immediately obvious.  The key idea is
>> to keep track of two different kinds of state - a (pointer to
>> a) tree which represents a completely unprocessed subtree,
>> and a stack of (pointers to) trees which represent subtrees
>> that have had their left sides taken care of but still need
>> their value processed and their right side done;  loop over
>> processing those as long as the unprocessed subtree is
>> non-empty or the stack is non-empty, always processing an
>> unprocessed subtree first.  Here is a function to illustrate
>> that does inorder printing (the Index type is just an
>> ordinary integer type;  note that the type Tree is a pointer
>> type, so the 'stack' variable is a pointer to an array of
>> pointers):
>
> That is a succint description.  As I wrote in a followup I should
> have clarified that I found an algorithm, but it is rather goto
> oriented.

I saw that.  I find code like that very difficult to understand.
Perhaps not completely impenetrable, but enough so to raise at
least a couple of red flags in a code review.

>>     void
>>     inorder_print( Tree root ){
>>         Tree *stack = malloc( 100 * sizeof *stack );
>
> A balanced binary tree with a depth of 90 will easily exceed the
> number of nodes one might hope to address with a 64-bit address
> space.

That depends on how good the balancing is.  In any case, the
number chosen was meant only to be sufficient, not minimal.

> If the tree is unbalanced you should guard against stack overflow
> or make sure that your insert/delete functions catch this.

Of course.  I didn't think it was important to mention this,
since any decent binary tree package will do some sort of
balancing.

>>         Index next = 0;
>>         Tree tree = root;
>>
>>         while(  tree  ||  next > 0  ){
>>             if(  tree  ){
>>                 stack[ next++ ] = tree;
>>                 tree = tree->left;
>>             } else {
>>                 tree = stack[ --next ];
>>                 printf( " %d", tree->value );
>>                 tree = tree->right;
>>             }
>>         } 
>>         printf( "\n" );
>>
>>         free( stack );
>>     }
>
> I think one of the lessons here is that parent pointers are pretty
> much superfluous to binary tree algorithms, and that recursion is
> mostly avoidable.

Whether parent pointers are useful depends I think on what
operations need to be supported.  As for recursion, I think
that's the wrong takeaway - binary trees are one area where
recursion is an excellent fit in terms of both ease of coding
and performance.

I'm wondering why you didn't have any comments on the function
shown, after your earlier comments about finding a solution
without goto.

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

#60451

On Sat, Apr 18, 2015 at 06:59:14PM -0700, Tim Rentsch wrote:
> Steve Thompson <stevet810@gmail.com> writes:
> > On Thu, Apr 16, 2015 at 09:04:34AM -0700, Tim Rentsch wrote:
> >> Steve Thompson <stevet810@gmail.com> writes:
> >>
> >>> On Mon, Apr 13, 2015 at 11:36:56AM +0100, Bartc wrote:
> >>>> On 13/04/2015 11:28, asetofsymbols@gmail.com wrote:
> >>>>> Bartc wrote:
> >>>>> [code example that uses labels and goto's]
> >>>>
> >>>> This style of code is more error-prone.  It's not even obvious
> >>>> where l1 needs to go;  I can put it in several places and it
> >>>> would still compile, but the program won't work.
> >>>>
> >>>> This is something that just isn't a problem when using
> >>>> conventional control structures;  why do you want to introduce
> >>>> a new source of bugs?
> >>>
> >>> One of the things I've been trying to do is an inorder traversal
> >>> of a binary tree without using recursion.  With normal control
> >>> structures it doesn't seem possible without using goto.
> >>
> >> This is an interesting problem.  It has a solution that is
> >> fairly simple but not immediately obvious.  The key idea is
> >> to keep track of two different kinds of state - a (pointer to
> >> a) tree which represents a completely unprocessed subtree,
> >> and a stack of (pointers to) trees which represent subtrees
> >> that have had their left sides taken care of but still need
> >> their value processed and their right side done;  loop over
> >> processing those as long as the unprocessed subtree is
> >> non-empty or the stack is non-empty, always processing an
> >> unprocessed subtree first.  Here is a function to illustrate
> >> that does inorder printing (the Index type is just an
> >> ordinary integer type;  note that the type Tree is a pointer
> >> type, so the 'stack' variable is a pointer to an array of
> >> pointers):
> >
> > That is a succint description.  As I wrote in a followup I should
> > have clarified that I found an algorithm, but it is rather goto
> > oriented.
> 
> I saw that.  I find code like that very difficult to understand.
> Perhaps not completely impenetrable, but enough so to raise at
> least a couple of red flags in a code review.

It is one of those examples that straddles the line.  Some programmers
will understand what it does without much difficulty, wheras
intermediate/beginners may be instantly confused.  Fortunately it is
my project and coding standard, and not subject to third-party
constraints.

> >>     void
> >>     inorder_print( Tree root ){
> >>         Tree *stack = malloc( 100 * sizeof *stack );
> >
> > A balanced binary tree with a depth of 90 will easily exceed the
> > number of nodes one might hope to address with a 64-bit address
> > space.
> 
> That depends on how good the balancing is.  In any case, the
> number chosen was meant only to be sufficient, not minimal.

I understood that the number was somewhat arbitrary, but I wanted to
point out the potential risk since we are not discussing a particular
C implementation of a known binary tree algorithm.

> > If the tree is unbalanced you should guard against stack overflow
> > or make sure that your insert/delete functions catch this.
> 
> Of course.  I didn't think it was important to mention this,
> since any decent binary tree package will do some sort of
> balancing.
> 
> >>         Index next = 0;
> >>         Tree tree = root;
> >>
> >>         while(  tree  ||  next > 0  ){
> >>             if(  tree  ){
> >>                 stack[ next++ ] = tree;
> >>                 tree = tree->left;
> >>             } else {
> >>                 tree = stack[ --next ];
> >>                 printf( " %d", tree->value );
> >>                 tree = tree->right;
> >>             }
> >>         } 
> >>         printf( "\n" );
> >>
> >>         free( stack );
> >>     }
> >
> > I think one of the lessons here is that parent pointers are pretty
> > much superfluous to binary tree algorithms, and that recursion is
> > mostly avoidable.
> 
> Whether parent pointers are useful depends I think on what
> operations need to be supported.  As for recursion, I think
> that's the wrong takeaway - binary trees are one area where
> recursion is an excellent fit in terms of both ease of coding
> and performance.

I think you are probably correct.  My binary tree package suffers from
the defect that it depends on a descriptor which identifies the tree
root (and describes tree properties), and therfore treating a subtree
as a tree introduces additional complexity.
 
> I'm wondering why you didn't have any comments on the function
> shown, after your earlier comments about finding a solution
> without goto.

Ah, but I did not find a solution without goto, only the one I posted.
Actually, nearly all loops use 'goto' but it is hidden by the
C compiler.

At any rate, I will concede that your algorithm is clearer and more
compact.



Regards,

Steve Thompson

-- 
"If I had a nickel for every time some idiot called me about a
computer problem that turned out to be user error, I would be able to
retire and spend the rest of my days cultivating clues in my backyard
hillside garden."  -- MysteryDog in 24hoursupport.helpdesk.

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

#60461

On 4/19/15 12:28 PM, Steve Thompson wrote:
> I think you are probably correct.  My binary tree package suffers from
> the defect that it depends on a descriptor which identifies the tree
> root (and describes tree properties), and therfore treating a subtree
> as a tree introduces additional complexity.
>
>
> Regards,
>
> Steve Thompson
>

My usual solution for something like that is to have a "front" function 
that is called that takes a full tree, and that function isn't 
recursive, but calls a (private) helper function that takes the 
"sub-tree" root and the identifier block as two separate parameters, 
that is.

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

#60816

Steve Thompson <stevet810@gmail.com> writes:
> On Sat, Apr 18, 2015 at 06:59:14PM -0700, Tim Rentsch wrote:
>> Steve Thompson <stevet810@gmail.com> writes:
>>> On Thu, Apr 16, 2015 at 09:04:34AM -0700, Tim Rentsch wrote:
>>>> Steve Thompson <stevet810@gmail.com> writes:
>>>>
>>>>> On Mon, Apr 13, 2015 at 11:36:56AM +0100, Bartc wrote:
>>>>>> On 13/04/2015 11:28, asetofsymbols@gmail.com wrote:
>>>>>>> Bartc wrote:
>>>>>>> [code example that uses labels and goto's]
>>>>>>
>>>>>> This style of code is more error-prone.  It's not even obvious
>>>>>> where l1 needs to go;  I can put it in several places and it
>>>>>> would still compile, but the program won't work.
>>>>>>
>>>>>> This is something that just isn't a problem when using
>>>>>> conventional control structures;  why do you want to introduce
>>>>>> a new source of bugs?
>>>>>
>>>>> One of the things I've been trying to do is an inorder traversal
>>>>> of a binary tree without using recursion.  With normal control
>>>>> structures it doesn't seem possible without using goto.
>>>>
>>>> This is an interesting problem.  It has a solution that is
>>>> fairly simple but not immediately obvious.  The key idea is
>>>> to keep track of two different kinds of state - a (pointer to
>>>> a) tree which represents a completely unprocessed subtree,
>>>> and a stack of (pointers to) trees which represent subtrees
>>>> that have had their left sides taken care of but still need
>>>> their value processed and their right side done;  loop over
>>>> processing those as long as the unprocessed subtree is
>>>> non-empty or the stack is non-empty, always processing an
>>>> unprocessed subtree first.  Here is a function to illustrate
>>>> that does inorder printing (the Index type is just an
>>>> ordinary integer type;  note that the type Tree is a pointer
>>>> type, so the 'stack' variable is a pointer to an array of
>>>> pointers):
>>>
>>> That is a succint description.  As I wrote in a followup I
>>> should have clarified that I found an algorithm, but it is
>>> rather goto oriented.
>>
>> I saw that.  I find code like that very difficult to understand.
>> Perhaps not completely impenetrable, but enough so to raise at
>> least a couple of red flags in a code review.
>
> It is one of those examples that straddles the line.  Some
> programmers will understand what it does without much difficulty,
> wheras intermediate/beginners may be instantly confused.

I should amend my earlier statement.  It's not too hard to
understand what it is you're trying to do (or more accurately,
what I think it is you're trying to do - it's hard to be sure
because the code you posted is incomplete).  What is hard is
producing the reasoning that the code is correct.  When you
say "understand" I think you are talking only about the first
part, not the second part, which is usually what I mean when
I say I understand some piece of code.

> Fortunately it is my project and coding standard, and not
> subject to third-party constraints.

I never meant to imply otherwise.  OTOH, I believe I am more
accepting than many in range of code structural style, including
use of goto, so you may want to consider the comments further
in that light.  In any case, I was just relaying my impression,
nothing more.

>>>>     void
>>>>     inorder_print( Tree root ){
>>>>         Tree *stack = malloc( 100 * sizeof *stack );
>>>
>>> A balanced binary tree with a depth of 90 will easily exceed the
>>> number of nodes one might hope to address with a 64-bit address
>>> space.
>>
>> That depends on how good the balancing is.  In any case, the
>> number chosen was meant only to be sufficient, not minimal.
>
> I understood that the number was somewhat arbitrary, but I wanted
> to point out the potential risk since we are not discussing a
> particular C implementation of a known binary tree algorithm.

I don't know what risk you're talking about.  There is
essentially no risk in using a slightly larger number, like 100,
as opposed to a rather smaller number, like 20 or 30.  Certainly
100 should be enough to suffice for any tree that is anywhere
close to balanced.

>>> If the tree is unbalanced you should guard against stack overflow
>>> or make sure that your insert/delete functions catch this.
>>
>> Of course.  I didn't think it was important to mention this,
>> since any decent binary tree package will do some sort of
>> balancing.
>>
>>>>         Index next = 0;
>>>>         Tree tree = root;
>>>>
>>>>         while(  tree  ||  next > 0  ){
>>>>             if(  tree  ){
>>>>                 stack[ next++ ] = tree;
>>>>                 tree = tree->left;
>>>>             } else {
>>>>                 tree = stack[ --next ];
>>>>                 printf( " %d", tree->value );
>>>>                 tree = tree->right;
>>>>             }
>>>>         } 
>>>>         printf( "\n" );
>>>>
>>>>         free( stack );
>>>>     }
>>>
>>> I think one of the lessons here is that parent pointers are pretty
>>> much superfluous to binary tree algorithms, and that recursion is
>>> mostly avoidable.
>>
>> Whether parent pointers are useful depends I think on what
>> operations need to be supported.  As for recursion, I think
>> that's the wrong takeaway - binary trees are one area where
>> recursion is an excellent fit in terms of both ease of coding
>> and performance.
>
> I think you are probably correct.  My binary tree package suffers
> from the defect that it depends on a descriptor which identifies
> the tree root (and describes tree properties), and therfore
> treating a subtree as a tree introduces additional complexity.

There was another followup that described how to handle this
problem.  Actually it's a fairly common problem, and the
approach mentioned is a fairly common solution, so it's
worth knowing.

>> I'm wondering why you didn't have any comments on the function
>> shown, after your earlier comments about finding a solution
>> without goto.
>
> Ah, but I did not find a solution without goto, only the one I
> posted.  Actually, nearly all loops use 'goto' but it is hidden by
> the C compiler.

Sorry, when I said "your earlier comments about finding a solution
without goto" what I was referring to was your statement about
/not/ finding one.  Apologies for the lack of clarity.

> At any rate, I will concede that your algorithm is clearer and
> more compact.

I didn't mean to ask for a comparison.  What I was trying to get
at is do you find the algorithm comprehensible, or perhaps that
should be asked as how comprehensible was it?  A short algorithm
is often easier to read, but not always easier to understand.

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

#60894

On Monday, April 13, 2015 at 12:54:57 PM UTC-5, Steve Thompson wrote:

[snip]

> 
> One of the things I've been trying to do is an inorder traversal of a
> binary tree without using recursion.  With normal control structures
> it doesn't seem possible without using goto.
>

How about a threaded tree?  Shouldn't require either recursion or
gotos.

Downside is that insertions and deletions get more painful since
you have to maintain the threading.  

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

#59952

On Monday, April 13, 2015 at 9:56:35 AM UTC+2, asetof...@gmail.com wrote:
> The primitive instruction for
> programming wrote in C
>  it would be defined as:
> 
> #define G(a,b) if(a)goto b
> 
> With that and using labels
> each if() or loops 
> can be made.
> There is not need other control
> path structure...
> Goto win 🏆:)
> G(1,m) would be goto
> 
> If it is better than loop we can
> try... Post some C code and I 
> would translate that in 
> code use that macro...

Teoretically, you can also also drop if/goto, and use no control structure
at all.
+1 if you guess how, another +1 if you find out how to do it ;)

Ciao!

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

#59970

Fma wrote ...

Yes one can write C programs
using just && and || operator
No goto, no while(  ) for() if()
etc

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

#59974

On Monday, April 13, 2015 at 6:48:15 PM UTC+2, asetof...@gmail.com wrote:
> Fma wrote ...
> 
> Yes one can write C programs
> using just && and || operator
> No goto, no while(  ) for() if()
>

Nope.
No +1 for you today.
With what you listed you don't even manage to have a touring complete language,
let alone translate a C program.

I'd say that the question is open to anyone else who wants to try, but
almost certainly most of the readers already knows the answer :)

Ciao!

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

#59976

fmassei wrote:

> I'd say that the question is open to anyone else who wants to try

https://en.wikipedia.org/wiki/One_instruction_set_computer
https://en.wikipedia.org/wiki/Turing_machine_equivalents

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

#59981

On Monday, April 13, 2015 at 8:43:30 PM UTC+2, Noob wrote:
> fmassei wrote:
> 
> > I'd say that the question is open to anyone else who wants to try
> 
> https://en.wikipedia.org/wiki/One_instruction_set_computer
> https://en.wikipedia.org/wiki/Turing_machine_equivalents
>

True, but a little bit drastic :) We are trying to do it in C, and it's very
possible.

An hint: there is a common, widespread C pattern, used in many occasions,
that can actually change the program flow without the use of any control or
loop keyword.
Well, now it should be much easier to guess :D

Ciao!

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

#60033

On Monday, April 13, 2015 at 3:10:07 PM UTC-4, fma...@gmail.com wrote:
>
> An hint: there is a common, widespread C pattern, used in many occasions,
> that can actually change the program flow without the use of any control or
> loop keyword.

Stack smashing?

(ducks)

--S

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

#60035

On Tuesday, April 14, 2015 at 4:11:11 PM UTC+2, Xcott Craver wrote:
> On Monday, April 13, 2015 at 3:10:07 PM UTC-4, fma...@gmail.com wrote:
> >
> > An hint: there is a common, widespread C pattern, used in many occasions,
> > that can actually change the program flow without the use of any control or
> > loop keyword.
> 
> Stack smashing?
> 

Nope.

Ok, I tell you: array of function pointers :)

'if' for example:

if (i>0) a();
else b();

can be written as:
void(*f[2])(void) = { a, b };
f[i<=0]();


'for' loops are trickier (but funnier):
for (i=0; i<3; ++i) a();

becomes:
int i=0;
void b();
void c();
void(*f[2])(void) = { b, c };
void b() { a(); ++i; f[i>=3](); }
void c() {}
f[0]();

and so on. :)


Ciao!

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

#60036

fmassei@gmail.com writes:

> On Tuesday, April 14, 2015 at 4:11:11 PM UTC+2, Xcott Craver wrote:
>> On Monday, April 13, 2015 at 3:10:07 PM UTC-4, fma...@gmail.com wrote:
>> >
>> > An hint: there is a common, widespread C pattern, used in many occasions,
>> > that can actually change the program flow without the use of any control or
>> > loop keyword.
>> 
>> Stack smashing?
>
> Nope.
>
> Ok, I tell you: array of function pointers :)

Why then (if you are permitting function call) did you say "no" to the
&& and || idea?

> 'if' for example:
>
> if (i>0) a();
> else b();
>
> can be written as:
> void(*f[2])(void) = { a, b };
> f[i<=0]();

... and also as the deliciously obscure (void (*[])(void)){a, b}[i<=0]();

Which is

   i>0 && (a(), 1) || (b(), 1)

which can be simplified if these "block functions" are not required to
be void.

<snip>
-- 
Ben.

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

#60040

On Tuesday, April 14, 2015 at 4:57:28 PM UTC+2, Ben Bacarisse wrote:
> fmassei@gmail.com writes:
> 
> > Ok, I tell you: array of function pointers :)
> 
> Why then (if you are permitting function call) did you say "no" to the
> && and || idea?
> 

The statement was "one can write C programs using just && and || operator",
which is of course false. Ok, if you allow function calls it could somehow
work, but you still need some more operators :)

> > 'if' for example:
> >
> > if (i>0) a();
> > else b();
> >
> > can be written as:
> > void(*f[2])(void) = { a, b };
> > f[i<=0]();
> 
> ... and also as the deliciously obscure (void (*[])(void)){a, b}[i<=0]();
> 

Cute.

> Which is
> 
>    i>0 && (a(), 1) || (b(), 1)
> 
> which can be simplified if these "block functions" are not required to
> be void.
> 

Of course, it's just a funny exercise to remember the old IOCCC days :)

Ciao!

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

#59985

W dniu poniedziałek, 13 kwietnia 2015 18:48:15 UTC+2 użytkownik asetof...@gmail.com napisał:
> Fma wrote ...
> 
> Yes one can write C programs
> using just && and || operator
> No goto, no while(  ) for() if()
> etc

why you wrote such short lines? this is 
about 25 characters, standard line is 
i think 60-80 (i wrote shorter as i have 
small resolution and wdit window is small here
but not as such short (mine seem 45-55)

(besides that you wrote insane, it may be sometimes good but often bad as leads to boredom etc)

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

#59986

Fir wrote:
I wrote:
>> No goto, no while(  ) for() if() 
>> etc 

>why you wrote such short lines? this is 
>about 25 characters, standard line is 
>i think 60-80 (i wrote shorter as i have 
>small resolution and wdit window is small here 
>but not as such short (mine seem 45-55)

The range line I can see here now in a line it is:
1111111111111111111111111111111111111
But if rotate cellphone would be:
00000000000000000000000000000000000000000000000000000000
But I would see just 4 lines at time

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

#59987

On 13/04/2015 22:28, asetofsymbols@gmail.com wrote:
> Fir wrote:

>> why you wrote such short lines? this is
>> about 25 characters, standard line is
>> i think 60-80 (i wrote shorter as i have
>> small resolution and wdit window is small here
>> but not as such short (mine seem 45-55)
>
> The range line I can see here now in a line it is:
> 1111111111111111111111111111111111111
> But if rotate cellphone would be:
> 00000000000000000000000000000000000000000000000000000000
> But I would see just 4 lines at time
>

Can you run C code on a cellphone? If so, how?

-- 
Bartc

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

#59988

On Monday, April 13, 2015 at 11:51:12 PM UTC+2, Bart wrote:
> On 13/04/2015 22:28, asetofsymbols@gmail.com wrote:
> > Fir wrote:
> 
> >> why you wrote such short lines? this is
> >> about 25 characters, standard line is
> >> i think 60-80 (i wrote shorter as i have
> >> small resolution and wdit window is small here
> >> but not as such short (mine seem 45-55)
> >
> > The range line I can see here now in a line it is:
> > 1111111111111111111111111111111111111
> > But if rotate cellphone would be:
> > 00000000000000000000000000000000000000000000000000000000
> > But I would see just 4 lines at time
> >
> 
> Can you run C code on a cellphone? If so, how?
> 

I'd be very surprised to discover that his cellphone doesn't run any compiled
C code ;)

Ciao!

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

#59990

On 13/04/2015 22:58, fmassei@gmail.com wrote:
> On Monday, April 13, 2015 at 11:51:12 PM UTC+2, Bart wrote:

>> Can you run C code on a cellphone? If so, how?
>>
>
> I'd be very surprised to discover that his cellphone doesn't run any compiled
> C code ;)

No doubt there will be compiled C code buried somewhere inside.

But I thought to create apps you needed to use something like 
Objective-C or Java, and to do so via some hugely complex SDK.

-- 
Bartc

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

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

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

csiph-web