I’m having trouble with a problem, and I’ve distilled out a smaller working example of the problematic behavior. Doenet
The only value that acts that I would expect is when c=1, probably because of how the function f is defined with a pi(x-1) in its argument. For all the other critical values, I don’t know if there are rounding errors or what is going on. Sometimes the boolean is true, sometimes it is false, but none of the <sign>elements return 0 even though the value displayed is 0. What am I missing?
The problem is numerical round-off. By default, displaySmallAsZero is set to be 10^(-14). (It is unaffected by displayDigits, so setting displayDigits="50" didn’t help.) If you set displaySmallAsZero="0" or displaySmallAsZero="false", you’ll see that f'(-1), for example, is calculated as -1.5 * 10^(-15). Since that’s smaller in magnitude than the default displaySmallAsZero, it looks like it is zero. But, since it is negative, the sign gives -1.
I’m not sure what is the best way to deal with this. For example, should <sign> have an attribute to consider numbers smaller than a certain value as 0?
For now, you can use something like round($$fP($c),14) (though you’ll have to simplify the <math> or use a <number> to get that to be zero). Alternatively, you could use the DoenetML <round> component as <round numDecimals="14">$$fP($c)</round>.
Thank you! I went with the <round>tag, and I used 10 decimals, because there was at least one value where -6 times 10^-15 rounded to -1 times 10^-14, not 0. For my application, if the graph visually made the value look like 0, I wanted the output of the sign tag to be zero, so I probably should have used even fewer decimals to be even safer.
An attribute might be nice. Or maybe there’s a better way to do it without using the sign tag at all? I ended up adding 2 to the output of <sign> and using that as the correct index of a dropdown menu where the options are negative, zero, positive (in that specific order!).
Your approach seems reasonable to me. I can’t think of a better approach off the top of my head.
We could have an attribute like <sign smallConsideredZero="10^(-10)" >. I think the default should be 0, even though that doesn’t match the default displaySmallAsZero.