On Apr 2, 2008, at 10:32 PM, Jason Grout wrote:
>
> 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 :).
I've given it some thought, I think it'd just involve passing &i as a
parameter to process_op. Once concern is it would make it much harder
to convert the list of opcodes back into an expression...
>>
>>> 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).
SymbolicFormula (to me) sounds like an expression, e.g. pi *r^2 is a
symbolic formula. I like SymbolicProposition.
> 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.
Yes, sounds very good.
> 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.
I don't like the name "boole" either (though the function sounds
good). Maybe someone else has some ideas. In any case, with tab
completion, unique first-couple-of-characters can be more important
than the overall length of the function name.
> 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.
yeah.
> On another note: && and || are not valid syntax (you probably already
> knew that :).
I always remember its either && or & that's valid, but can never
remember which one. (If I think about it it should be clear though).
> 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.
Most people it seems have a hard time remembering which is "supposed"
to come first anyway...
> I wish we could overload "and", "or", and friends.
Yeah, though I don't think this is possible while retaining their
short-circuiting behavior.
> 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.
Sounds good.
In this light, I'd like to approve your patch if you remove the
_fast_float_ function from equations.py.
- Robert
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
