bugGNU Octave - Bugs: bug #40392, function parameter not used in...

 
 

bug #40392: function parameter not used in while loop correctly

Submitted by:  Shushan Wen <swen>
Submitted on:  Sun 27 Oct 2013 09:09:05 PM UTC  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: InvalidAssigned to: None
Originator Name: Shushan WenOpen/Closed: Closed
Release: 3.6.4Operating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Mon 28 Oct 2013 12:13:23 AM UTC, comment #11:

Try the following:

This is how Matlab behaves, so this is how Octave should behave.

Jordi GutiƩrrez Hermoso <jordigh>
Project Administrator
Mon 28 Oct 2013 12:12:57 AM UTC, comment #10:

I see. The variable type is different. Thanks, Michael and John.

Shushan

Shushan Wen <swen>
Mon 28 Oct 2013 12:09:05 AM UTC, comment #9:

OK. here is a fact:

octave:23> prob_002 200
Variables in the current scope:

Attr Name Size Bytes Class
==== ==== ==== ===== =====
a argn 1x5 5 char
f x 1x3 3 char

Total is 8 elements using 8 bytes

y = 10
y = 44
ans = 44
octave:24> prob_002 (200)
Variables in the current scope:

Attr Name Size Bytes Class
==== ==== ==== ===== =====
a argn 1x3 3 char
f x 1x1 8 double

Total is 4 elements using 11 bytes

y = 10
y = 44
y = 188
ans = 188
octave:25>
=============================
In the first case x is a char, in the second it is a double.
so the while c<=x %
is not doing that you thought.

And, John is right. But this is confusing.

Michael

Michael Godfrey <godfrey>
Project Member
Sun 27 Oct 2013 11:59:35 PM UTC, comment #8:

I can confirm that I see the same thing as Michael did.
"prob_200 200" returns incorrect value, but "prob_200( 200 )" is fine.
The thing is, with "prob_200 200", if we print x inside the function, x actually gets 200.

Shushan

Shushan Wen <swen>
Sun 27 Oct 2013 11:55:48 PM UTC, comment #7:

You are still modifying c inside the loop. You just happen to get the result you expect with a lower value.

Think about a simpler loop:

The sequence of events here is

  • set x to 10
  • test whether x < 10; if not, then execute the loop.
  • inside the loop, increment x by 10. Now x is 20.
  • test whether x is < 10. It is not, so don't execute the loop.

The while loop condition doesn't prevent the value from becoming larger than the limit if you increment the variable inside the loop.

I'm closing this report as invalid.

John W. Eaton <jwe>
Project Administrator
Sun 27 Oct 2013 11:52:26 PM UTC, comment #6:

I tried your latest example, replacing x with 200.
I get:
octave:8> prob_002(200)
y = 10
y = 44
y = 188
ans = 188
octave:9> prob_002(200)
y = 10
y = 44
y = 188
ans = 188
octave:10>

=========================
First output above is "x" second is "200"
Third is "200" but using your call:
prob_002 200
I get

octave:11> prob_002 200
y = 10
y = 44
ans = 44
octave:12>

So, the problem is with the usage: prob_200 200

Michael Godfrey <godfrey>
Project Member
Sun 27 Oct 2013 11:42:51 PM UTC, comment #5:

I see your point, John. I made a change and re-uploaded the program. Now c is updated after mod(c,2). The same issue is there.

Shushan

(file #29493)

Shushan Wen <swen>
Sun 27 Oct 2013 11:33:31 PM UTC, comment #4:

Hi John,
The idea is, within each loop, c becomes the next Fibonacci number, i.e., it increases each time, until x is reached, which is the condition the program should leave the while loop.

In my test, if I give x as 200 by calling "prob_002 200", ans=44. But if I change x to 200 in line 14, I get ans=188. This is a mismatch.

Thanks,

Shushan

Shushan Wen <swen>
Sun 27 Oct 2013 11:20:05 PM UTC, comment #3:

How do you expect your program to work? Since you modify c inside the loop, it is possible for c to be less than x when the loop starts, but greater than x by the time you compute mod(c,2).

John W. Eaton <jwe>
Project Administrator
Sun 27 Oct 2013 10:39:27 PM UTC, comment #2:

I'm using version 3.6.4 on CentOS and Ubuntu 13.10, both have the same issue.

Shushan

Shushan Wen <swen>
Sun 27 Oct 2013 10:00:34 PM UTC, comment #1:

Your example works correctly for me without
"hard coding 4000000".
This is using the current development Octave.

What version of Octave are you using?

Michael Godfrey <godfrey>
Project Member
Sun 27 Oct 2013 09:09:05 PM UTC, original submission:

In the attached .m file, I'm trying to calculate the sum even-valued Fibonacci numbers to certain limit. The limit is given as parameter x to the function, prob_002. The while loop ends earlier than it's supposed to. If I change x in line 14 to a hard-coded value such as 200, I can workaround the issue.

Shushan Wen <swen>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #29493:  prob_002.m added by swen (596B - application/octet-stream)
file #29491:  prob_002.m added by swen (596B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jordigh (Posted a comment)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by godfrey (Posted a comment)
  • -unavailable- added by swen (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 27 Oct 2013 11:55:48 PM UTCjweItem GroupIncorrect Result=>None
      StatusNone=>Invalid
      Open/ClosedOpen=>Closed
    Sun 27 Oct 2013 11:42:51 PM UTCswenAttached File-=>Added prob_002.m, #29493
    Sun 27 Oct 2013 09:09:05 PM UTCswenAttached File-=>Added prob_002.m, #29491

    Back to the top


    Powered by Savane 3.1-cleanup1