RE: Feature request of Nov 1, 2015 above.
Thanks for asking. In the computer’s little binary brain, logical true/false tests ALL result in either zero or 1, or zero and 1. In either case, the result winds up in the accumulator somewhere anyway. If that numeric result can be included in a formula one can structure all sorts of “either” – “or” numeric results. I’ve used this feature extensively in Microsoft Excel formulas for years.
Example in Torque – I’ve added a gauge for the Ford F150 5.4L Triton engine – PID #16CD (RCAM), the ECU’s “Requested cam retard” in crankshaft degrees. The SHOC phaser is ‘incapable’ of advancing timing. Only ‘retard’ from a base position. However, for unknown reasons – the ECU response to a cmd: 2216CD produces a two byte response that is frequently negative on the order of .02º to .09º. Even using the formula ((Signed(A)*256)+B)/10 and setting gauge minimum to Zero, the gauge still reads below zero slightly – an impossible condition. Simple boolean cure, if the Android system uses positive logic (Logical One for true result), would be (A>0)*(((A*256)+B)/10). If Android uses inverted logic (either 1, or 0 for true), then I would simply change the above preamble to the formula to ((A>0)*1), or (((A>0)*1)+1). Thus, my gauge would ONLY read ZERO, or a positive number, and nothing else.
In a Second Case – working on a gauge for the 5.4L Triton IMRCM (Intake Manifold Runner Control Valve – PID #1634), the ECU outputs a control word that _appears_ to “disable” the device’s movement by turning on the HIGH bit ???, (not intended to be a negative voltage output.) Although the values continue to change – it seems that the high bit prevents the valve from moving. (???) Therefore, I needed a gauge that “wouldn’t MOVE” when the high bit of A was TRUE, though the values continue to change. I “skinned the cat” by creating TWO phantom PID’s and structured formulas to simulate what I could have done with boolean logic as follows:
Phantom PID named IMRC_dis = Intake Manifold Runner Control Monitor A>7
Phantom PID named IMRC_sav = VAL{Intake Manifold runner Control Monitor}
The guage displays IMRCM (Intake Manifold Runner Control Monitor) w/ this formula
(VAL{IMRC_SAV)*VAL{IMRC_dis})+(((((A*256)+B)/63)*12.5001)*((VAL{IMRC_dis}*1)+1))
The gauge moves NORMALLY if the value of IMRCM is positive. Of course, this works by multiplying the value of IMRCM_sav by either Zero or One depending on the high bit, then ADDing the value of IMRCM * Zero or 1 depending on the OPPOSITE CONDITION of the high bit. One side or the other of the equation will be zero while the OTHER is one.
This workaround WORKS, but I think you can see how simple this could be accomplished with a direct boolean arithmetic implementation.
Which version of the above types of logical handling Android employs is immaterial. The user can quickly figure it out with a single test formula. The programmer need not concern himself with which it is, ALL would work the same with “=”, “not=”, “>”, “
