I don't see any concrete reason why is_true(x) and is_false(!x) must
be identical... we've already lost a sane definition of equality in
many ways if floating point numbers are involved, so keeping it this
way isn't going to make it any worse.
On Thu, Jun 5, 2008 at 5:28 PM, Kyle Schalm <[EMAIL P
I'm hearing some scary proposals in this thread, like crippling
symbolic processing, or introducing a whole new set of comparison
relations. At the same time I feel that the behaviour John is
describing is indeed confusing to newcomers and off-putting enough to
be worth doing something about. I be
On Jun 5, 2:24 pm, "Rhys Ulerich" <[EMAIL PROTECTED]> wrote:
> > this asymmetry between true and false seems bad. shouldn't "is_true(x)
> > == is_false(!x)" always be true?
>
> Depends on whether or not you're talking to a SQL person. I think
> is_true(x) == is_false(!x)
> should either be
>
> this asymmetry between true and false seems bad. shouldn't "is_true(x)
> == is_false(!x)" always be true?
>
Depends on whether or not you're talking to a SQL person. I think
is_true(x) == is_false(!x)
should either be true or inconclusive.
- Rhys
--~--~-~--~~~---
> >> I'm not sure what to do if the user requests a comparison that
> >> sage can't easily determine:
>
> >> sage: sqrt(3) + sqrt(8) == sqrt(5) + pi
>
> >> One idea would be to return a symbolic equation
>
> >> sqrt(3) + sqrt(8) === sqrt(5) + pi
>
> >> but probably the best is to raise an except
How do you know for sure if something is not equal and that we are
just not lacking an advanced enough simplifier? For trivial cases
this will work and it will have to throw exceptions for everything
else.
On Wed, Jun 4, 2008 at 6:17 PM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
>
> On Jun 4, 2
On Jun 4, 2008, at 5:23 PM, Carl Witty wrote:
> On Jun 4, 5:08 pm, Robert Bradshaw <[EMAIL PROTECTED]>
> wrote:
>>> In this thread:http://groups.google.com/group/sage-devel/
>>> browse_thread/thread/bcdc671d2791056e/e086a9d59ff4b9ba
>>> it seems that the consensus was to throw an error here; but
+1 to "Rigerous" testing of equality, but being able to rigorously
show if something is not equal is hard (and in many nontrivial cases
not possible). bool() should return true "if it can be shown to be
equal"
On Wed, Jun 4, 2008 at 6:23 PM, Jason Grout <[EMAIL PROTECTED]> wrote:
>
> Robert Brad
Robert Bradshaw wrote:
> On Jun 4, 2008, at 4:57 PM, Carl Witty wrote:
>
>> On Jun 4, 4:16 pm, Robert Bradshaw <[EMAIL PROTECTED]>
>> wrote:
>>> On Jun 4, 2008, at 2:46 PM, Jason Grout wrote:
>>>
Of course, bool(some equation) returning False does not necessarily
mean
that the two
On Jun 4, 5:08 pm, Robert Bradshaw <[EMAIL PROTECTED]>
wrote:
> > In this thread:http://groups.google.com/group/sage-devel/
> > browse_thread/thread/bcdc671d2791056e/e086a9d59ff4b9ba
> > it seems that the consensus was to throw an error here; but nobody
> > ever implemented it (or even opened a tr
On Jun 4, 2008, at 5:05 PM, Gary Furnish wrote:
> Errors should not under any circumstances be thrown if bool(x==y) is
> inconclusive. It would break half of the code that depends on
> symbolics, and would require try blocks around every if statement.
Can you give an example of something that w
On Jun 4, 2008, at 4:57 PM, Carl Witty wrote:
>
> On Jun 4, 4:16 pm, Robert Bradshaw <[EMAIL PROTECTED]>
> wrote:
>> On Jun 4, 2008, at 2:46 PM, Jason Grout wrote:
>>
>>> Of course, bool(some equation) returning False does not necessarily
>>> mean
>>> that the two expressions are not equal; it on
Errors should not under any circumstances be thrown if bool(x==y) is
inconclusive. It would break half of the code that depends on
symbolics, and would require try blocks around every if statement.
On Wed, Jun 4, 2008 at 5:57 PM, Carl Witty <[EMAIL PROTECTED]> wrote:
>
> On Jun 4, 4:16 pm, Rober
On Jun 4, 4:16 pm, Robert Bradshaw <[EMAIL PROTECTED]>
wrote:
> On Jun 4, 2008, at 2:46 PM, Jason Grout wrote:
>
> > Of course, bool(some equation) returning False does not necessarily
> > mean
> > that the two expressions are not equal; it only means that we couldn't
> > prove them to be equal
On Jun 4, 2008, at 2:46 PM, Jason Grout wrote:
> Of course, bool(some equation) returning False does not necessarily
> mean
> that the two expressions are not equal; it only means that we couldn't
> prove them to be equal using some simple simplifications.
>
> From the docstring for _nonzero_
Robert Bradshaw wrote:
> On Jun 4, 2008, at 8:40 AM, Dan Christensen wrote:
>
>> "William Stein" <[EMAIL PROTECTED]> writes:
>>
>>> Sage Enhancement Proposal: Change comparisons that involve
>>> elements of the symbolic ring to return True or False if both sides
>>> of the symbolic comparison are
On Jun 4, 2008, at 8:40 AM, Dan Christensen wrote:
>
> "William Stein" <[EMAIL PROTECTED]> writes:
>
>> Sage Enhancement Proposal: Change comparisons that involve
>> elements of the symbolic ring to return True or False if both sides
>> of the symbolic comparison are constants and the comparison
"William Stein" <[EMAIL PROTECTED]> writes:
> Sage Enhancement Proposal: Change comparisons that involve
> elements of the symbolic ring to return True or False if both sides
> of the symbolic comparison are constants and the comparison can
> be definitely determined.
I'm not sure what symbolic
+1 to this.
Sage Enhancement Proposal: Change comparisons that involve
elements of the symbolic ring to return True or False if both sides
of the symbolic comparison are constants and the comparison can
be definitely determined. [...] There would be a discussion on sage-devel,
probably some voti
In every CAS I've used, the tendency to reduce true symbolic equations to
boolean True drives me nuts.
What if the user wants to start from a known true equation and then
manipulate both sides to obtain an identity of some sort? Automatic
reduction to a boolean value disallows this use case.
I v
On Thu, May 15, 2008 at 10:42 PM, John H Palmieri
<[EMAIL PROTECTED]> wrote:
>
>
>
> On May 15, 9:56 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
>> On Thu, May 15, 2008 at 9:48 PM, John H Palmieri <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> > Is this a bug?
>>
>> > sage: 3 == pi
>> > 3 == pi
>> > sa
On May 15, 9:56 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> On Thu, May 15, 2008 at 9:48 PM, John H Palmieri <[EMAIL PROTECTED]> wrote:
>
>
>
> > Is this a bug?
>
> > sage: 3 == pi
> > 3 == pi
> > sage: i == i
> > I == I
>
> > Shouldn't this return "False" and "True", respectively?
>
> Thos
On Thu, May 15, 2008 at 9:48 PM, John H Palmieri <[EMAIL PROTECTED]> wrote:
>
> Is this a bug?
>
> sage: 3 == pi
> 3 == pi
> sage: i == i
> I == I
>
> Shouldn't this return "False" and "True", respectively?
Those are symbolic equations:
sage: type(I == I)
It's just a more general case of:
sag
23 matches
Mail list logo
