#2538 strange behaviour of function returning different values for same input

None
closed
nobody
None
5
2013-02-08
2013-01-24
Jan Teichmann
No

I have a function which produces weird returns as they are different depending on how I supply the arguments:

float(dZdt(1, 1.1, 0.01, 1.8));
.05134015462397822
float(tL[19]);
1.8
float(dZdt(1, 1.1, 0.01, tL[19]));
.05134015462397828
float(dZdt(1, 1.1, 0.01, tL)[19]);
-.6058689119704607

(version="5.29.1",timestamp="2012-12-13 16:17:55",host="x86_64-redhat-linux-gnu",lisp_name="SBCL",lisp_version="1.1.2-1.fc18")

Discussion

  • Raymond Toy
    Raymond Toy
    2013-01-24

    It's really hard to give help when you don't tell us what dZdt or tL are.

    If the problem is that the first dZdt gives a slightly different answer from the second, then it's very possible that tL[19] is printed as 1.8 but is actually very slightly different from 1.8.

    The third call to dZdt is totally different from the others, so it seems not relevant, unless that's the issue you're complaining about.

     
  • Jan Teichmann
    Jan Teichmann
    2013-01-24

    I'm sorry it has been a long day fighting with maxima. I will try to construct a minimal example which reproduces the behaviour.
    tL is a list made by
    tL: makelist(t/10,t,0,20)$
    so tL[19] is 9/5 or 1.8 as float.

    the function dZdt is rather ugly and I will see that I can reproduce it with something less complex. I will also try the code on a different version of maxima too.

     
  • Jan Teichmann
    Jan Teichmann
    2013-01-24

    I attached a minimal file which reproduces the problem on my computer. Im sorry but it's not very pretty ;) I think it has something to do with the definition of Q0 and Q1 (maybe the solve there)

    when calling p1 with one argument being a list it doesnt iterate over the entries of the list as it normally does when calling a function with a list as argument.

     
    Attachments
  • Hi,

    I'm afraid it's still not really obvious what the bug is here. Given minimal.wxm that you sent us, can you tell us a way to reproduce weird behaviour?

    Also, the behaviour of p1 not distributing over lists is by design. See distribute_over in the manual (I don't think there's a way to turn it on for user-defined functions at the moment, though).

    Rupert

     
  • Jan Teichmann
    Jan Teichmann
    2013-01-28

    Ok so the problem is that solve doesnt support distribute_over and therefore p1 returns always 0 when one argument is a list. (?) This function was part of an other recursive function and it wasnt obvious to me what was going on. I must say that I would prefer a proper lisp error here rather than this silent 0 return value. This would make it easier to understand and detect the underlying problem. What do you think?

     
  • Well, if I understand correctly, you're asking it to expand eg

    solve(0 = [1-x^2, 1-x])
    

    to

    solve([0 = 1-x^2, 0 = 1-x])
    

    But this would be pretty silly! After all, the left hand side is a single number and the right is a list with two elements...

    Anyway, I would suggest you follow this up on the mailing list rather than in a bug report.

     
  • Jan Teichmann
    Jan Teichmann
    2013-01-28

    I agree that it doesn't make sense for solve to distribute over a list in that way. And it's not a bug. I will write to the mailing list and see whether there is a way to raise an error such as "what you try probably makes no sense"
    Thanks for clarifying what went wrong! Sometime you don't see the woods for the trees ;)

     
  • Since, as you say, this isn't a bug, I'm closing this bug report. If I've made a mistake and missed something, please feel free to reopen it.

     
    • status: open --> closed