Recent

Author Topic: Back in cycle level  (Read 1405 times)

winni

  • Hero Member
  • *****
  • Posts: 1813
Re: Back in cycle level
« Reply #15 on: July 10, 2020, 03:28:07 pm »

Except that this has the same error I did in my first post also, if c is 3, the loop is broken and the a loop will continue which will increase a.


Oh, oh, oh.

This is expected behaviour - look into the first post of Jake012345.

But it is not caught in an endless loop but jumps into then next loop of the a - like he wanted.

First read. Then think. Then write.

Winni

440bx

  • Hero Member
  • *****
  • Posts: 2001
Re: Back in cycle level
« Reply #16 on: July 10, 2020, 03:31:47 pm »
I don't trust my mind reading skills that far that I can read minds through an internet forum
That's probably a good thing.  That said, I don't recall anyone ever posting that they need to create an infinite loop and, his request doesn't sound like he wants one:
I need to leave a cycle in a cycle but when I use Break/exit, that leave the whole cycle / procedure.
From what he said, it sounds like he wants to leave the _inner_ loop _only_ and keep executing the outer loop.  Granted his "BackTo('@');" very much sounds like a "goto" but, if he really wanted an infinite loop he wouldn't use an outer "for" loop.  A simple "while true do" gives him a nice shiny infinite loop.
FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

lucamar

  • Hero Member
  • *****
  • Posts: 3025
Re: Back in cycle level
« Reply #17 on: July 10, 2020, 03:34:46 pm »
Code: Pascal  [Select][+][-]
  1. procedure MyProcedure;
  2.  var a,b,c:integer;
  3. begin
  4.   for a:=0 to 10 do
  5.     for b:=0 to 10 do begin
  6.      c:=StrToInt(inputbox());
  7.      if c=3 then Break;
  8.    end;
  9. end;

Remember that the value of b becomes undefined if the break is taken.

Isn't it just the other way around? If the break is taken then b will keep its current value. It's undefined only if the loop ends normally.
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus 2.0.8/FPC 3.0.4 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

440bx

  • Hero Member
  • *****
  • Posts: 2001
Re: Back in cycle level
« Reply #18 on: July 10, 2020, 03:36:52 pm »
Isn't it just the other way around? If the break is taken then b will keep its current value. It's undefined only if the loop ends normally.
You are correct.  The value is undefined if the loop ends normally.
FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

Warfley

  • Sr. Member
  • ****
  • Posts: 303
Re: Back in cycle level
« Reply #19 on: July 10, 2020, 03:37:50 pm »


Oh, oh, oh.

This is expected behaviour - look into the first post of Jake012345.

But it is not caught in an endless loop but jumps into then next loop of the a - like he wanted.

First read. Then think. Then write.

Winni

His discription is not very clear (I mean if he wants to continue a, then break should have worked, but according to him it doesnt), but his code is, he basically wants goto.

So I think we can leave it with both possibilities, because either way, he now has a solution.

From what he said, it sounds like he wants to leave the _inner_ loop _only_ and keep executing the outer loop.  Granted his "BackTo('@');" very much sounds like a "goto" but, if he really wanted an infinite loop he wouldn't use an outer "for" loop.  A simple "while true do" gives him a nice shiny infinite loop.

It is only an infinite loop if c is always 3. If no 3 occurs, it will be 11*11

rvk

  • Hero Member
  • *****
  • Posts: 4288
Re: Back in cycle level
« Reply #20 on: July 10, 2020, 03:45:29 pm »
Remember that the value of b becomes undefined if the break is taken.
Isn't it just the other way around? If the break is taken then b will keep its current value. It's undefined only if the loop ends normally.
Yes, you are correct.
Using break/exit will preserve the loop variable (according to the language specifications).

Letting the loop end normally has an undetermined value.
That can be seen when you do something like this (I can't exceed MaxInt so the loop variable can't be loop_end + 1 which you would expect in other cases).
Code: Pascal  [Select][+][-]
  1. var
  2.   I: Integer;
  3. begin
  4.   for I := MaxInt - 5 to MaxInt do
  5.   begin
  6.     Memo1.Lines.Add(I.ToString);
  7.   end;
  8.   Memo1.Lines.Add('end loop');
  9.   Memo1.Lines.Add(I.ToString); // gives maxint as a result while with for 1 to 10 it will give 11 as result
  10. end;

440bx

  • Hero Member
  • *****
  • Posts: 2001
Re: Back in cycle level
« Reply #21 on: July 10, 2020, 03:53:56 pm »
It is only an infinite loop if c is always 3. If no 3 occurs, it will be 11*11
That is true but, the fact that he typed "for a = 1 to 10 do" really gives the impression that he is not interested in a case that results in an infinite loop.

He better not default the return value of InputBox to "3".  :D
FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

winni

  • Hero Member
  • *****
  • Posts: 1813
Re: Back in cycle level
« Reply #22 on: July 10, 2020, 04:05:30 pm »

It is only an infinite loop if c is always 3. If no 3 occurs, it will be 11*11

So you would buy a cardiac pacemaker where you hope that the 3 does not too often appear????

Oh boy!

Winni

Warfley

  • Sr. Member
  • ****
  • Posts: 303
Re: Back in cycle level
« Reply #23 on: July 10, 2020, 04:07:05 pm »
That is true but, the fact that he typed "for a = 1 to 10 do" really gives the impression that he is not interested in a case that results in an infinite loop.
He better not default the return value of InputBox to "3".  :D
Sure, I also have the impression he wants to do from 1 to 10 not from 0 to 10 (11 is an akward number of iterations), and having this goto scenario seems pretty odd to me, but maybe InputBox shows a form with the title: "choose your action 1: ... 2: ... 3: Delay this loop for another 11 iterations" and this is everything well thought out, how knows. Or maybe he really wants to annoy his users by adding a trick value which just keeps them in this loop, I mean who doesnt sometimes want to torture his users for choosing stupid input

AlanTheBeast

  • Jr. Member
  • **
  • Posts: 73
Re: Back in cycle level
« Reply #24 on: July 10, 2020, 05:52:56 pm »
I don't recall anyone ever posting that they need to create an infinite loop

Useful for realtime or permanent monitors.

True fact: some airlines have received notice that they must turn off the avionics on some aircraft within a specific period (100 hours or so) to avoid bugs related to counters etc. overflowing.  They tend to leave the aircraft hot at the gate between flights (on external APU) including overnight.

New code (in one case) gets around such bugs.

winni

  • Hero Member
  • *****
  • Posts: 1813
Re: Back in cycle level
« Reply #25 on: July 10, 2020, 08:15:33 pm »


True fact: some airlines have received notice that they must turn off the avionics on some aircraft within a specific period (100 hours or so) to avoid bugs related to counters etc. overflowing.  They tend to leave the aircraft hot at the gate between flights (on external APU) including overnight.


Hi !

That was the Boeing  (Boiiing) 787 Dreamliner.

Lousy Reason:

248 days = 2^31  seconds / 100

Restart minimum 248-1  days.

I don't know if they now fixed it, That was 2015.
It it not so easy to enlarge a 32-bit-integer....

Winni

AlanTheBeast

  • Jr. Member
  • **
  • Posts: 73
Re: Back in cycle level
« Reply #26 on: July 11, 2020, 06:35:53 pm »
I was referring to the Scarebus 350, actually and the offending rollover was about 150 days... but coming from the Avionics world such things don't surprise me regardless of model of a/c.  (And Boing and Scarebus buy avionics from many common suppliers re-using tons of code modified for each model and variant...).

As to resetting, fuel load is usually less than, say, 24 hours worth.  So based on various conditions that indicate the aircraft is safely on the ground (squat switches, airspeed_trend, groundspeed, parking_brake_set, etc. and so on) it would be easy enough (though not trivial) to implement resets of certain counters (etc.) after x hours and while state=parked_at_gate.  Of course that becomes a requirement which becomes a testable item which becomes ...  or simply when the offending parameter(s) exceed(s) a threshold (and state=parked_at_gate) then run the reset procedure(s).  Depending on the criticality level of the box, the costs of such could be quite high.

Easier to force that box to re-boot (while safely at the gate, of course).

Depending on what bus(es) a box is connected to, it can "listen" for various parameters even if it is not usually a user of a given parameter.  Otherwise other boxes would have to be programmed to provide the offending box with the reset command (when, ... you know).

(I don't know if it is actually done that way, but that is a way it could be done).
« Last Edit: July 11, 2020, 06:39:31 pm by AlanTheBeast »

MarkMLl

  • Hero Member
  • *****
  • Posts: 1232
Re: Back in cycle level
« Reply #27 on: July 11, 2020, 10:19:47 pm »
I was referring to the Scarebus 350, actually and the offending rollover was about 150 days... but coming from the Avionics world such things don't surprise me regardless of model of a/c.  (And Boing and Scarebus buy avionics from many common suppliers re-using tons of code modified for each model and variant...).

I'm pretty sure that there's quite a lot of critical systems with that sort of problem, and IIRC there was something about Shuttle missions not crossing New Year.

Wasn't there something about a prototype fighter (Tornado)? having a squat switch problem which became embarrassingly apparent when the pilot accidentally retracted the undercarriage before its maiden flight.

It's a different world. IIRC the i386DX got a massive life extension because it was the last Intel chip with predictable cycle counts.

MarkMLl
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.

winni

  • Hero Member
  • *****
  • Posts: 1813
Re: Back in cycle level
« Reply #28 on: July 12, 2020, 12:36:13 am »
Hi!

We can collect a lot of stories. The always try to brush it under the carpe but some funny (??) situations to remark:

In the early days of the 737 it was well definded what < 60 nodes had to happen. And  what > 60 nodes had to happen. But it was never defindet: what about 60 nodes. There was pilot rumor about a "strange second"  while landing and starting. It took some time until they "maintained" it.

When I was a young boy Germany bought a lot of Lockheed F-104 "Starfighter" - because of corruption. They fell doen from heaven - nearly one very week. When I was 13 we had a big party after shool: Number 100 of the starfighters,

After the Starfighters came the Tornados. Some for the Airforce and some for the Marines. Those one for the Marines where at once  out of duty. They had a new super-duper distance sensor on board, which held the plane in a constant distance to the ground - no matter if high voltage cabel, trees or buildings. But on the sea they reacted because of the waves like they flew on a  washbaord. Strange skiffle group. They first had to change the software ...

Winni
« Last Edit: July 12, 2020, 12:47:57 am by winni »

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2515
    • havefunsoft.com
Re: Back in cycle level
« Reply #29 on: July 12, 2020, 08:16:02 am »
When I was a young boy Germany bought a lot of Lockheed F-104 "Starfighter" - because of corruption. They fell doen from heaven - nearly one very week.
:o
this is actually a real history
Widowmaker indeed!
Patron Cocoa Widgetset development https://www.patreon.com/skalogryz

 

TinyPortal © 2005-2018