Opened 8 years ago
Last modified 6 years ago
#14384 needs_work enhancement
Support version number literals.
Reported by: | robertwb | Owned by: | jason |
---|---|---|---|
Priority: | major | Milestone: | sage-6.4 |
Component: | misc | Keywords: | |
Cc: | roed | Merged in: | |
Authors: | Robert Bradshaw | Reviewers: | David Roe |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
This can be done as we already have preparser hacks for real literals and numeric attributes.
Change History (27)
comment:1 Changed 8 years ago by
- Status changed from new to needs_review
comment:2 Changed 8 years ago by
- Work issues set to Support Singular's versioning scheme as well
comment:3 follow-up: ↓ 4 Changed 8 years ago by
comment:4 in reply to: ↑ 3 Changed 8 years ago by
""" sage: 3 - 1 - 6 -4 sage: 3-1-6 3-1-6 """Anyone who writes subtraction without spaces is a barbarian so this shouldn't cause any ambiguity.
I hope this is a joke at Leif's expense intended to point out that Singular's scheme would be hard to support... but the internet is not a subtle medium :(
comment:5 Changed 8 years ago by
Well, it was certainly a joke, but I wouldn't say it was at Leif's expense since he was joking too :) (We were talking about this ticket on the IRC channel.) In fact, if I hadn't been in the room when Robert wrote his patch, I would have thought Robert was joking as well! :P
comment:6 Changed 8 years ago by
<_leif> btw, it's not April 1st yet -- not even down under <kini> david roe is probably waiting for april 1 before setting it to positive review :P <_leif> Changes (by leif): * work_issues: => Support Singular's versioning scheme as well (I didn't set it to "needs work" though.) Another enhancement: sage: #14323 in 5.9.beta2 True
comment:7 Changed 8 years ago by
- Reviewers set to David Roe
- Status changed from needs_review to positive_review
- Work issues Support Singular's versioning scheme as well deleted
Looks good to me. I can't think of a good way to support Singular's system, so let's hold off on that for another ticket.
comment:8 Changed 8 years ago by
We should probably only support Singular's system on April 1, so maybe we need to add a date check to the code? ;)
(just kidding!)
comment:9 Changed 8 years ago by
- Status changed from positive_review to needs_work
So we're seriously going to do this?
Some comments:
- Move
class VersionNumber
somewhere else (probablysage/misc/versionnumber.py
for lack of a better place) - How can I get the raw patch for this commit from github?
- Error messages are going to be very confusing, try
sage: x = 4.5 sage: x.denominator()
comment:10 Changed 8 years ago by
I have to admit I was actually thinking this whole ticket was a joke until Keshav clarified. B)
(I really liked the type sage.rings.real_mpfr.VersionNumber
. ;-) )
comment:11 Changed 8 years ago by
I thought the whole ticket was a joke too. What's the rationale for doing this, other than "we can"? I don't see a compelling reason for having version number literals.
comment:12 Changed 8 years ago by
- Milestone changed from sage-5.9 to sage-duplicate/invalid/wontfix
- Status changed from needs_work to positive_review
I thought the whole ticket was a joke too. What's the rationale for doing this, other than "we can"?
Thank the Lord.
comment:13 Changed 8 years ago by
Wait, now I'm really confused. Does that conclusively settle it?
comment:14 follow-up: ↓ 15 Changed 8 years ago by
Apparently you have a rather authoritative-sounding voice, Jason :P
As for the rationale for doing this, well, I can recall approximately the conversation which led to this patch:
Should we tag our releases as just bare numbers like 5.9 or should we put a v in front like v5.9?
Well, I think it should be just 5.9 since I'm going to type stuff like
vanilla(5.9)
into the Sage prompt and expect it to just work.
Is it that much trouble to write
vanilla('v5.9')
... wait, you're going to callvanilla
with a float?
Yes! Why not?
Well then what about 4.7.2? That isn't a float...
True. But it could be an MPFR real! *hack hack*
!?
Behold, the first git-based trac ticket!
By the way, Jeroen, I noticed you semi-recently (8 months ago) merged a ticket by pulling a branch rather than applying a patch: #418. So while this might be the first git-based ticket, it's not the first pull request to the modern Sage codebase. Does this mean we could already be using a pull-request based model right now, for the Sage library at least? :)
comment:15 in reply to: ↑ 14 Changed 8 years ago by
Replying to kini:
Does this mean we could already be using a pull-request based model right now, for the Sage library at least? :)
Yes, but not using github :-)
comment:16 follow-up: ↓ 17 Changed 8 years ago by
- Milestone changed from sage-duplicate/invalid/wontfix to sage-5.9
- Status changed from positive_review to needs_work
I don't think we should mark it as won't-fix yet. Let's see what Robert says about Jeroen's suggestions first.
comment:17 in reply to: ↑ 16 Changed 8 years ago by
Replying to roed:
I don't think we should mark it as won't-fix yet. Let's see what Robert says about Jeroen's suggestions first.
I don't think it makes sense to support software version numbers (i.e., literals of that type) as a "native" type in a CAS; nobody will mind adding a class for versions, its constructor(s) taking a string (or probably also a float) argument, but this ticket is (currently) about the former.
Prepending a "v" could perhaps be a compromise, avoiding trouble (i.e., ambiguities) with floating-point literals, but I personally wouldn't like it either.
comment:18 Changed 8 years ago by
I have to say I got a little confused seeing something associated with mpfr that had alphabet characters in it too.
Personally, I think it's not worth the cost (confusion, yet another incompatibility, etc.) to introduce these to the preparser.
comment:19 Changed 8 years ago by
As much as I hate to be a spoilsport, I have to agree :)
However, the modifications to preparser.py fix a bug and are worthwhile.
comment:20 Changed 8 years ago by
It started out as a joke, but then we realized we had enough hooks in the preparser to actually do such a crazy thing without bending the langauge. x.denominator()
can be fixed, but I understand if this is too weird to go in. Otherwise, I'll move VersionNumber
to misc and make a patch.
comment:21 follow-up: ↓ 22 Changed 8 years ago by
Okay, here's my vote:
-1 to going into standard Sage
+1 to going into "cool hacks you can do in Sage"
+1 to going into the Sage April Fools collection
comment:22 in reply to: ↑ 21 ; follow-up: ↓ 23 Changed 8 years ago by
-1 to going into standard Sage
Yes.
+1 to going into "cool hacks you can do in Sage"
If we ever move the useful constructions into the reference manual and get rid of the constructions thing, we could replace it with "cool Sage hacks".
+1 to going into the Sage April Fools collection
Oh, like the move to Lisp...
comment:23 in reply to: ↑ 22 Changed 8 years ago by
Replying to kcrisman:
-1 to going into standard Sage
I'm +1 for going into standard Sage, but I don't feel strongly enough about it to argue.
+1 to going into "cool hacks you can do in Sage"
If we ever move the useful constructions into the reference manual and get rid of the constructions thing, we could replace it with "cool Sage hacks".
Sure.
+1 to going into the Sage April Fools collection
Oh, like the move to Lisp...
I don't think this works as well as an April Fools e-mail, since it's not actually a very major change. And we'd have to wait almost a year anyway. ;-)
comment:24 Changed 7 years ago by
- Milestone changed from sage-5.11 to sage-5.12
comment:25 Changed 7 years ago by
- Milestone changed from sage-6.1 to sage-6.2
comment:26 Changed 7 years ago by
- Milestone changed from sage-6.2 to sage-6.3
comment:27 Changed 6 years ago by
- Milestone changed from sage-6.3 to sage-6.4
Here is a doctest you can use:
Anyone who writes subtraction without spaces is a barbarian so this shouldn't cause any ambiguity.