Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Re: on goto

Reply
Thread Tools

Re: on goto

 
 
Nick Keighley
Guest
Posts: n/a
 
      05-12-2010
On 12 May, 12:44, Richard Heathfield <(E-Mail Removed)> wrote:
> Nick Keighley wrote:
> > On 12 May, 03:00, pete <(E-Mail Removed)> wrote:

>
> <snip>
>
> >> I find SEME to be less objectionable in functions
> >> which are small enough so that you can't look at one exit
> >> without noticing the all the rest of the exits.

>
> > is there any other sort of function?

>
> Hell yes!


I once counted 11 pages (of blue stripey listing) between the "if" and
it's corresponding "else". And that was 11 pages of dense and tangled
code. I think it had gotos as well. Wish I'd framed it.



 
Reply With Quote
 
 
 
 
gwowen
Guest
Posts: n/a
 
      05-12-2010
On May 12, 3:14*pm, Richard Heathfield <(E-Mail Removed)> wrote:

> If you're going to pick holes in people's spelling, you'll get a better
> response if you learn the difference between "principal" and
> "principle". You might also get a better response if you behaved a
> little more politely.


Physician, heal thyself. Still baiting Nilges in comp.lang.c? Jesus
must be so proud.
 
Reply With Quote
 
 
 
 
Lie Ryan
Guest
Posts: n/a
 
      05-12-2010
On 05/12/10 23:46, Nick Keighley wrote:
> On 12 May, 12:44, Richard Heathfield <(E-Mail Removed)> wrote:
>> Nick Keighley wrote:
>>> On 12 May, 03:00, pete <(E-Mail Removed)> wrote:

>>
>> <snip>
>>
>>>> I find SEME to be less objectionable in functions
>>>> which are small enough so that you can't look at one exit
>>>> without noticing the all the rest of the exits.

>>
>>> is there any other sort of function?

>>
>> Hell yes!

>
> I once counted 11 pages (of blue stripey listing) between the "if" and
> it's corresponding "else". And that was 11 pages of dense and tangled
> code. I think it had gotos as well. Wish I'd framed it.


written by imperative programmer who hasn't got accostumed to making
function/method/procedure/whatever?
 
Reply With Quote
 
Seebs
Guest
Posts: n/a
 
      05-12-2010
On 2010-05-12, Daniel T. <(E-Mail Removed)> wrote:
> The fact is, it's quite hard (though maybe not impossible,) to find a
> justification for using the example provided, even if the example is
> good for justifying SEME. (Even Seebs example of a dungeon game doesn't
> work, because it is highly unlikely that such a game would contain a 3-D
> array that is ragged in each dimension.)


In each dimension, no, but I have seen many in which the rows of locations
were not contiguous for each level, and where width and height could vary
from one level to another. So while it's true that adjacent rows are not
usually of different widths, it is quite common for adjacent rows to be
separate allocations, because the width of rows in different levels is
different, so foo[x][y] would not do the right thing if you tried to make
them all one big hunk.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / http://www.velocityreviews.com/forums/(E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      05-13-2010
On 12 May, 09:18, gwowen <(E-Mail Removed)> wrote:
> On May 11, 6:44*pm, Seebs <(E-Mail Removed)> wrote:
> > On 2010-05-11, Richard Heathfield <(E-Mail Removed)> wrote:
> > > Seebs wrote:


> > >>> You already have a list of foos, properly ordered for fast searching.
> > >> No, I don't.
> > > Then I suggest you get one.

>
> > It's often completely unsuitable to the problem at hand.

>
> If your problem is not amenable to Richard H's potted solutions, the
> fault lies with your problem, not Richard's solution. *You should know
> this by now.
>
> So if you have a disk-backed self-caching nested container storing a
> 2million * 2million * 2million high resolution MRI scan image,
> scrupiously reconstructed using Radon transforms. *You're searching
> for pixels of a certain shade (that indicate a possible tumor, say),
> then the first thing you should do is convert it into a one-
> dimensional in-memory sorted C-array.


how long does the sort take? Presumably you're doing more than one
search.

> The fact that you won't be able
> to obtain the co-ordinates afterwards to display the appropriate slice
> to the physician is irrelevant.


well he might not agree

>*Sort and binary search. *Any other
> solution is wrong.


I'm guessing you've actually done this

 
Reply With Quote
 
Dann Corbit
Guest
Posts: n/a
 
      05-13-2010
In article <0d8a3e52-4885-4443-9e10-679d56ccd2d3
@a34g2000yqn.googlegroups.com>, (E-Mail Removed) says...
>
> On 12 May, 09:18, gwowen <(E-Mail Removed)> wrote:
> > On May 11, 6:44*pm, Seebs <(E-Mail Removed)> wrote:
> > > On 2010-05-11, Richard Heathfield <(E-Mail Removed)> wrote:
> > > > Seebs wrote:

>
> > > >>> You already have a list of foos, properly ordered for fast searching.
> > > >> No, I don't.
> > > > Then I suggest you get one.

> >
> > > It's often completely unsuitable to the problem at hand.

> >
> > If your problem is not amenable to Richard H's potted solutions, the
> > fault lies with your problem, not Richard's solution. *You should know
> > this by now.
> >
> > So if you have a disk-backed self-caching nested container storing a
> > 2million * 2million * 2million high resolution MRI scan image,
> > scrupiously reconstructed using Radon transforms. *You're searching
> > for pixels of a certain shade (that indicate a possible tumor, say),
> > then the first thing you should do is convert it into a one-
> > dimensional in-memory sorted C-array.

>
> how long does the sort take? Presumably you're doing more than one
> search.
>
> > The fact that you won't be able
> > to obtain the co-ordinates afterwards to display the appropriate slice
> > to the physician is irrelevant.

>
> well he might not agree
>
> >*Sort and binary search. *Any other
> > solution is wrong.

>
> I'm guessing you've actually done this


I hope not. It would be a travesty to perform a sort to locate somthing
easily found with a linear search.

Exactly N operations (where N is the pixel count) are needed to find
every pixel of a certain color (if K different pixels are needed then
hash the K wanted pixels to find the desired hash signatures, and have K
buckets, discarding all unwanted hash values).
Sorting will take N*log(N) operations.
8 * 10^18 is a lot of operations and will take some time.
Increasing that to C * 43 * 8 * 10^18 {where C is necessarily larger
than 1} is not a good idea, as I see it.

BTW, I guess that sorting this image will be rather problematic because
it is going to be an EXTERNAL sort for sure (at least 8 TB if the pixels
can only hold 256 values, and that is doubtful for a full resolution
medical image). That means it will probably take weeks.

I shudder at the sorting suggesting, and I love to sort things.
 
Reply With Quote
 
Nick
Guest
Posts: n/a
 
      05-20-2010
Richard Heathfield <(E-Mail Removed)> writes:

> Lie Ryan wrote:
> <snip>
>
>>
>> If I'm searching for all cells whose sprite size is 56 pixels (e.g.
>> 7x, do I create a list of all integers in the program?

>
> If sprite size matters to you, it makes sense to have a list of
> (probably pointers to) sprites, sorted by sprite size. Instead of
> searching cell by cell, you find the sprites that are the right size,
> and then look at where they're displayed. That will be a darn sight
> faster than iterating over your entire screen checking every pixel.


Except, of course, as we all really know, there will be times when you
just occasionally need to do something - perhaps when printing debugging
information - that you otherwise have no need to.

Creating multiple indexes on every field in a complex tree of structures
for example, just in case you ever want to check any one of them for any
particular value, even when written out in Sanskrit, seems overkill to
me.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      05-20-2010
On 20 May, 08:00, Nick <(E-Mail Removed)> wrote:
> Richard Heathfield <(E-Mail Removed)> writes:
> > Lie Ryan wrote:
> > <snip>

>
> >> If I'm searching for all cells whose sprite size is 56 pixels (e.g.
> >> 7x, do I create a list of all integers in the program?

>
> > If sprite size matters to you, it makes sense to have a list of
> > (probably pointers to) sprites, sorted by sprite size. Instead of
> > searching cell by cell, you find the sprites that are the right size,
> > and then look at where they're displayed. That will be a darn sight
> > faster than iterating over your entire screen checking every pixel.

>
> Except, of course, as we all really know, there will be times when you
> just occasionally need to do something - perhaps when printing debugging
> information - that you otherwise have no need to.
>
> Creating multiple indexes on every field in a complex tree of structures
> for example, just in case you ever want to check any one of them for any
> particular value, even when written out in Sanskrit, seems overkill to
> me.


put it in a database and let the DBMS decide when it needs additional
indexes



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
VHDL Goto statement ? Skybuck Flying VHDL 9 08-26-2005 01:46 PM
Re: VHDL Goto statement ? Skybuck Flying VHDL 0 08-08-2005 03:21 AM
where does Console.WriteLine() goto in a web app? Flip ASP .Net 1 04-14-2005 08:01 PM
where does Console.WriteLine() goto? Flip ASP .Net 6 11-18-2004 06:05 PM
goto statement is recommened in systemc? youngsun park VHDL 2 11-18-2003 03:47 PM



Advertisments