Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x * Infinity assumes that x is positive #9547

Closed
fredrik-johansson opened this issue Jul 19, 2010 · 13 comments
Closed

x * Infinity assumes that x is positive #9547

fredrik-johansson opened this issue Jul 19, 2010 · 13 comments

Comments

@fredrik-johansson
Copy link
Contributor

sage: var('x') * Infinity
+Infinity

This is not right; x could represent something non-positive.

CC: @kcrisman

Component: symbolics

Reviewer: Burcin Erocal, Volker Braun

Issue created by migration from https://trac.sagemath.org/ticket/9547

@tscrim
Copy link
Collaborator

tscrim commented May 11, 2012

comment:1

Likely the solution will be related with #11506.

@burcin
Copy link
Contributor

burcin commented May 15, 2012

Reviewer: Burcin Erocal

@burcin
Copy link
Contributor

burcin commented May 15, 2012

comment:2

This is fixed by #12950. There is a doctest on line 2429 of sage/symbolic/expression.pyx. We should close this ticket when that is merged.

@burcin
Copy link
Contributor

burcin commented May 15, 2012

Author: Volker Braun

@burcin burcin assigned burcin and unassigned aghitza May 15, 2012
@burcin burcin added this to the sage-5.1 milestone May 15, 2012
@burcin burcin removed this from the sage-5.1 milestone Jun 29, 2012
@kcrisman
Copy link
Member

comment:6

Patch is at #12950, but still a valid ticket; that was a meta-ticket for the Pynac upgrade.

@kcrisman kcrisman added this to the sage-5.2 milestone Jun 29, 2012
@jdemeyer
Copy link
Contributor

comment:7

Replying to @kcrisman:

Patch is at #12950, but still a valid ticket; that was a meta-ticket for the Pynac upgrade.

Same question as #1861: why doesn't this count as duplicate/invalid/wontfix?

@kcrisman
Copy link
Member

comment:8

Patch is at #12950, but still a valid ticket; that was a meta-ticket for the Pynac upgrade.

Same question as #1861: why doesn't this count as duplicate/invalid/wontfix?

In my opinion (only?), tickets that are closed by metatickets are not duplicates. It seems better to me (only?) to make it clear that work went into all of the issues we close, instead of making it seem like we have hundreds of duplicates that people open. We already do have enough duplicates as it is :)

And we certainly fixed it, so it's not "wontfix", and it's not invalid either, or at least wasn't before #12950, which however, explicitly refers to this ticket - it's not like some other change in #12950 made this invalid, which does sometimes happen.

@jdemeyer
Copy link
Contributor

comment:9

If the issue is fixed by a different ticket, then this ticket should be either a "duplicate" or a "worksforme".

Has a doctest been added for this? If not, one could consider needs_work.

@kcrisman
Copy link
Member

comment:10

If the issue is fixed by a different ticket, then this ticket should be either a "duplicate" or a "worksforme".

I simply disagree. So you are saying that, hypothetically, a gigantic metaticket for foo.spkg that bundles fifty changes, all of which are doctested by some huge patch at that ticket, means all the others are duplicates? That seems to denigrate the hard work that went into each of those other tickets. Although the people currently working on these particular tickets are not counting on this material for promotion, that is certainly a future possibility, as standards evolve, especially at less research-focused institutions.

Has a doctest been added for this? If not, one could consider needs_work.

Yes, it is at #12950.

@jdemeyer
Copy link
Contributor

comment:11

Replying to @kcrisman:

If the issue is fixed by a different ticket, then this ticket should be either a "duplicate" or a "worksforme".

I simply disagree. So you are saying that, hypothetically, a gigantic metaticket for foo.spkg that bundles fifty changes, all of which are doctested by some huge patch at that ticket, means all the others are duplicates? That seems to denigrate the hard work that went into each of those other tickets. Although the people currently working on these particular tickets are not counting on this material for promotion, that is certainly a future possibility, as standards evolve, especially at less research-focused institutions.

You could give credit to those people on the other gigantic metaticket.

On this particular ticket here, I don't see any work done, so I would simply close it as duplicate.

@kcrisman
Copy link
Member

Changed reviewer from Burcin Erocal to Burcin Erocal, Volker Braun

@kcrisman
Copy link
Member

comment:12

You could give credit to those people on the other gigantic metaticket.

Which Burcin did. The point was that although a ticket isn't a great measure of work, we don't have to make it an even worse measure.

On this particular ticket here, I don't see any work done, so I would simply close it as duplicate.

Well, I was going by the fact that someone else filled in author and reviewer fields and the work "just happened" to be there; see also the discussion at #12950. But if you insist, I suppose I've engaged in enough bikeshedding for one day.

@kcrisman
Copy link
Member

Changed author from Volker Braun to none

@kcrisman kcrisman removed this from the sage-5.2 milestone Jun 29, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants