Robert Bradshaw wrote:
> On Apr 2, 2008, at 12:05 PM, Jason Grout wrote:
>
>> Robert Bradshaw wrote:
>>> Thanks.
>>>
>>> I put a comment up on trac, but it boils down to
>>>
>>> sage: f = (x == 1)
>>> sage: g = (1 == x)
>>> sage: bool(f+g)
>>> True
>>> sage: ff = f._fast_float_('x') + g._fast_float_('x')
>>> sage: ff(0)
>>> 0.0
>>>
>>> but I think piecewise functions would be a good way to implement the
>>> desired functionality.
>> What sort of interface do you see with piecewise functions and the
>> _fast_float_ interface (i.e., what sort of opcodes?)
>
> Actually, given more thought, I think the opcodes you have chosen
> make sense, but there should be an "IF" opcode that operates on
> [true_val false_val test_val] as well which would allow for a full
> range of piecewise functions. (One could look at making conditional
> jumps so as to not calculate both sides of the expression, though
> this would be a fundamental change to the code. Hmm...)
Having a jump statement (maybe even just a je (jump if equal to zero) or
jne (jump if not equal to zero)) would indeed be powerful. I'm too
tired to think through how to implement them, but no doubt you've
already figured out a much more clever way :).
>
>> You bring up a good point about the clash between the current
>> semantics
>> of operations of symbolic equalities and my proposed fast_float
>> extension. Currently, operations operate on both sides of the
>> equation
>> if it makes sense (many times it doesn't make sense and an error is
>> thrown!).
>>
>> In the patch above, I think of a symbolic equation as a characteristic
>> function (i.e., 1 where it is true, 0 where it is false). This
>> provides
>> a very natural, short, and easy notation for such things:
>>
>> x*(x<1) + (-x)*(x>3) means piecewise([[(-Infinity,1), x], [(1,
>> Infinity), 0]]) + Piecewise([[(-Infinity, 3), 0], [(3, Infinity), -
>> x]])
>>
>> and
>>
>> x*(x<1) + (-x)*(x^2>4) means -- well, I don't know how to express the
>> constraint that x^2 > 4 using piecewise.
>>
>> while:
>>
>> x*(x<1) + (-x*y)*(x^2+y^2<1) -- I'm not sure even how to write this
>> down
>> using the two variables using piecewise.
>>
>> Personally, it seems that the characteristic-function approach is more
>> generally useful (and much nicer notationally) when calling
>> _fast_float_. Thoughts?
>
> In Sage 3*(x<1) becomes 3x < 3. One can argue whether or not this is
> a good thing (I think it is) but it shows how symbolic equations are
> distinct objects from symbolic expressions.
>
> I'm not thinking of piecewise functions as being limited by what the
> Piecewise class can do. (I'm sure there's a better name for it, but
> it's evading me for the moment. Basically, I'm thinking the condition
> is an arbitrary equation, and there is an expression for each truth
> value.) Basically the ternary operation.
>
>> As a middle-ground, how about I implement a SymbolicFormula class that
>> allows us to express logical combinations of SymbolicEquations. The
>> SymbolicFormula class, when multiplied under _fast_float_, will act
>> as a
>> characteristic function.
>
> I like this idea a lot, though I'm not sure "SymbolicFormula" is the
> best name for it. Perhaps "SymbolicCondition?" One could construct
> such things using && and ||, and it could short-circuit on
> evaluation. The output would be a boolean, which of course turns into
> a 1 or 0 when float(...) is called.
cwitty suggested the SymbolicFormula name based on symbolic logic. An
alternative would be SymbolicProposition. Your suggestion works too,
but seems more limiting (i.e., it seems to restrict the use to only
characteristic functions). The idea is that the class would encapsulate
any sort of logical proposition, including ones with quantifiers. I
like that idea; cwitty can use it, for example, to interface with qepcad.
For reference, the Mma way to do this is to wrap the symbolic statement
in the Boole function, which takes a statement and outputs 0 if false, 1
if true. However, Boole interacts well with integration and other
symbolic things; see
http://reference.wolfram.com/mathematica/ref/Boole.html )
So, how about this summary:
fast_float(SymbolicFormula*SymbolicExpression) --> the way things work
under my patch, but with SymbolicFormula instead of SymbolicEquation
(there's no need for an if-statement; the multiplication takes care of
it). The conditional jump opcode and corresponding if statement would
provide another way to do things, though.
boole(SymbolicEquation) --> SymbolicFormula encapsulating the
SymbolicEquation (We could also convert a SymbolicEquation to an
equivalent SymbolicFormula with SymbolicEquation & 1, for example). I
don't like the name "boole"; I would rather have something like
characteristic_function or indicator_function, but those are too long.
SymbolicFormula*SymbolicExpression --> a generalized piecewise function
(i.e., If SymbolicFormula Then SymbolicExpression). This generalized
thing can be used in integration or other places where it can use the
information intelligently. If fast_float is called on it, it can either
use an IF statement or do the multiplication like my patch.
On another note: && and || are not valid syntax (you probably already
knew that :). We can overload & and | (the bitwise operators). They
have the wrong precedence, but we can insist that people use parentheses
or they will get weird errors. I wish we could overload "and", "or",
and friends. In any case, it seems like it would be best to introduce
the logical opcodes into fast_float (and, or, etc.) Like you point out,
we would need a conditional jump then to be able to do short-circuiting.
Thanks,
Jason
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
