Bug introduced in 9.0 or earlier and fixed in 10.4
Hold@1`5 /. x_Real :> RuleCondition[N@x, True]
Hold@1`5 /. x_Real :> RuleCondition[N@2`5, True]
Hold@2`5 /. x_Real :> RuleCondition[N@2`5, True]
Hold@1`5 /. x_Real :> RuleCondition[N@t, True]
The returned answers, in StandardForm
, are:
Hold[1.0000]
Hold[2.]
Hold[2.0000]
Hold[t]
The problem is that the first and third lines should evaluate to machine precision numbers (like the 2nd line), but it appears that Mathematica is executing an approximate numerical equality test to determine whether or not to execute the RuleCondition
that doesn't show up during my attempts at tracing. Experts, do you consider this to be a bug? What would your workaround be? The context is that I am tracing a numerical routine that works with high precision numbers. I need to format the trace so that I can actually read it, thus the conversion to machine precision numbers that are inside a Hold (HoldForm
in the case of Trace
).
For those that don't know, RuleCondition
is what the right hand side of a Rule
or RuleDelayed
evaluates to if that right hand side contains an expression like Block[{},result/;condition]
, which is transformed to RuleCondition[result,condition]
and is evaluated outside of the context of the expression that originally matched the left hand side pattern of the Rule
or RuleDelayed
. RuleCondition
right hand side replacements don't happen if condition is False
. However, in this case, it appears that the condition must be True
AND the result must not be approximately equal to the left hand side pattern for the rule.
RuleCondition
. Additionally, your post is as clearly written and formatted as one can only wish for! Let me welcome you here and hope, you stay longer. $\endgroup$