0
$\begingroup$

When using indexed object, I found the behavior of value 0.7 as the index quite strange, then did the following test.

enter image description here

The first output cell was executed directly as the second input cell.

Have not found other values with the same issue.

Edit: an example where non-int indexing is used in my intuitive but trouble-causing way.

 SimuBody[p1_, p2_] := Table[N@Sin[p1 x], {x, 1, p2, 1}]
 Table[p2 = 15; f[p1, p2] = SimuBody[p1, p2], {p1, 0.1, 0.7, 0.1}];
 Table[p2 = 12; 
 f[p1, p2] = SimuBody[p1, p2], {p1, {2.2, 0.001, -\[Pi], 3.3}}];
 Table[p2 = 5; f[p1, p2] = SimuBody[p1, p2], {p1, {7, 3.4}}];
 g[a_Symbol] := 
 DownValues[a] /. (HoldPattern[_[_[x__]]] :> z_) :> {{x}, z}
 ftab = g[f];
 ListPointPlot3D[
 Transpose@{ftab[[All, 1, 1]], ftab[[All, 1, 2]], ftab[[All, 2, 1]]}, 
 PlotRange -> All, Filling -> Bottom]
 f[0.7, 15]

I started using this non-int indexing method after reading this, where the index does not even have to be a number. So I assumed using non-integer should be ok.

Improve this question
$\endgroup$
12
  • 1
    $\begingroup$ Moral lesson: do not use inexact numbers for indexing. (I'm sure this is a dupe, but I can't find the earlier thread.) $\endgroup$
    – J. M. can't deal with it ♦
    Nov 16 '15 at 14:23
  • $\begingroup$ @J.M. closely related: 65298 $\endgroup$
    – Kuba ♦
    Nov 16 '15 at 14:25
  • 1
    $\begingroup$ Regardless of the subtleties of floating point arithmetic that cause this, I think this is a classic case of GIGO. What were you hoping to achieve by putting a non-integer number in Indexed? $\endgroup$
    – Szabolcs
    Nov 16 '15 at 14:55
  • 1
    $\begingroup$ When you said "indexed object", I thought you meant Indexed. Now I see what you mean. I think using the term "indexing" here may be confusing to some. I agree with J.M., please edit the post and explain what you said in your comment, then also show how the problem with comparing floating point numbers comes up. The simplest solution is to avoid this sort of comparison, but there may be other ways too (e.g. Nearest for binary search, etc.) My answer would depend on how exactly you end up comparing two floating point numbers which look the same but aren't really the same. $\endgroup$
    – Szabolcs
    Nov 16 '15 at 16:17
  • 2
    $\begingroup$ I just saw your update. In that example, it looks like you are comparing 0.7 that you typed by hand to 0.7 that was generated by Table. Is this the only situation where the problem comes up? I would suggest trying to always work with the exact parameters (p1, p2 values) that were generated by/for your simulation. Avoid using values you type by hand. When you want to find a value that you know exists, you can use Nearest to extract it from an existing list of p1-values. To make it easier to handle these, I suggest using Association instead of DownValues. $\endgroup$
    – Szabolcs
    Nov 16 '15 at 16:23