is this a bug?
Same issue with
call ({report []} @>) with inputs (() / ()) @<:>Actually, anything NaN fed as an input to run () or call () becomes 0.
If this is important to you, you can get around the problem like this…
(the slot should be unevaluated)
They aren’t concerned about 0/0 being NaN, they are concerned about NaN spontaneously turning into 0 when fed to a custom block.
why is this important
… for me to mention to @kingnico1133?
OR
… for programs in Snap?
(or something else)
Maybe a custom block relies on NaN being an input for math or something, idk.
yeah. I just have no idea why someone would need to use this.
I’ve encountered this before, actually. Sometimes, you don’t know ahead of time you’ll be dividing by zero, especially in a math project. My Matrix Algebra project had this issue, because to get the inverse of a matrix (the way you “divide” matrices, like a reciprocal), you need to divide every item by the determinant of that matrix, which is on occasion 0. When this occurs, the matrix doesn’t have an inverse. However, you don’t necessarily know this going in, and thus my inverse function will sometimes return a matrix full of infinities and negative infinities (assuming none of the items in the matrix is 0, in which case that item is already NaN). From here, doing certain operations can turn those infinities into NaNs. Finally, things like MAP will turn those NaNs into 0s, making it seem like nothing went wrong and give bogus answers:
Instead, I had to add NaN checks throughout and replace NaN the mysteriously behaving something or other with “NaN” the string.
I think i found a way around it
{report () :: operators reporter} :: hat
report (item (1 v) of (this [inputs V])