Opened 8 years ago

Last modified 7 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:

Status badges

Description

This can be done as we already have preparser hacks for real literals and numeric attributes.

https://github.com/robertwb/sage/commits/versions

Change History (27)

comment:1 Changed 8 years ago by robertwb

  • Status changed from new to needs_review

comment:2 Changed 8 years ago by leif

  • Work issues set to Support Singular's versioning scheme as well

comment:3 follow-up: Changed 8 years ago by kini

Here is a doctest you can use:

"""
    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.

comment:4 in reply to: ↑ 3 Changed 8 years ago by kcrisman

"""
    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 kini

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

<_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 roed

  • 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 jason

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 jdemeyer

  • Status changed from positive_review to needs_work

So we're seriously going to do this?

Some comments:

  1. Move class VersionNumber somewhere else (probably sage/misc/versionnumber.py for lack of a better place)
  2. How can I get the raw patch for this commit from github?
  3. Error messages are going to be very confusing, try
    sage: x = 4.5
    sage: x.denominator()
    
Last edited 8 years ago by jdemeyer (previous) (diff)

comment:10 Changed 8 years ago by leif

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 jason

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 kcrisman

  • 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 jason

Wait, now I'm really confused. Does that conclusively settle it?

comment:14 follow-up: Changed 8 years ago by kini

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 call vanilla 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 jdemeyer

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: Changed 8 years ago by roed

  • 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 leif

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 jason

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 kini

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 robertwb

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: Changed 8 years ago by jason

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: Changed 8 years ago by kcrisman

-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 roed

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 8 years ago by jdemeyer

  • Milestone changed from sage-5.11 to sage-5.12

comment:25 Changed 8 years ago by vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:26 Changed 7 years ago by vbraun_spam

  • Milestone changed from sage-6.2 to sage-6.3

comment:27 Changed 7 years ago by vbraun_spam

  • Milestone changed from sage-6.3 to sage-6.4
Note: See TracTickets for help on using tickets.