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.

Sign up for GitHub

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

Jump to bottom

Allow construct RIF element from question-style string #38998

Open
wants to merge 4 commits into
base: develop
Choose a base branch
from
Open

Allow construct RIF element from question-style string #38998

wants to merge 4 commits into from

Conversation

user202729
Copy link
Contributor

@user202729 user202729 commented Nov 18, 2024 •
edited
Loading

As in the title. It allows you to say e.g. RIF("1.23?2e-5").

Partially handles #36797. (only for real case. Complex case is not handled yet, but in principle it should not be too difficult.)

(I don't see any disadvantage of allowing this, it's backwards compatible)

Issue: currently

sage: RIF("10", base=37)
37
sage: ZZ("10", base=37)
[error]

should this inconsistency be fixed? If so how?

[Edit: actually the rule of conversion should probably follow string to mpfr conversion rule or string to mpz conversion rule ]

📝 Checklist

  • The title is concise and informative.
  • The description explains in detail what this PR is about.
  • I have linked a relevant issue or discussion.
  • I have created tests covering the changes.
  • I have updated the documentation and checked the documentation preview. (there's no documentation change, but should we explicitly mention the feature? I think the feature to construct from [a..b] isn't explicitly mentioned either…?)

⌛ Dependencies

#39001

@github-actions GitHub Actions
Copy link

github-actions bot commented Nov 18, 2024 •
edited
Loading

Documentation preview for this PR (built with commit 805ecee; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

@user202729 user202729 marked this pull request as draft November 19, 2024 00:04
@user202729 user202729 force-pushed the real-interval-field-construct-question-style branch from fc0b60b to 14e1827 Compare November 19, 2024 03:01
@user202729 user202729 marked this pull request as ready for review November 19, 2024 03:02
@user202729 user202729 force-pushed the real-interval-field-construct-question-style branch from e8848d5 to c9e5c99 Compare November 19, 2024 03:58
tscrim
tscrim approved these changes Nov 26, 2024
View reviewed changes
Copy link
Collaborator

@tscrim tscrim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM; does what it says and is well tested.

@tscrim
Copy link
Collaborator

tscrim commented Nov 26, 2024

We can worry about the integer case later on I think.

@user202729
Copy link
Contributor Author

Thanks!

vbraun pushed a commit to vbraun/sage that referenced this pull request Dec 6, 2024
sagemathgh-38998: Allow construct RIF element from question-style string
d98a18e 
    
As in the title. It allows you to say e.g. `RIF("1.23?2e-5")`.

Partially handles sagemath#36797. (only
for real case. Complex case is not handled yet, but in principle it
should not be too difficult.)

(I don't see any disadvantage of allowing this, it's backwards
compatible)

Issue: currently

```
sage: RIF("10", base=37)
37
sage: ZZ("10", base=37)
[error]
```

should this inconsistency be fixed? If so how?

[Edit: actually the rule of conversion should probably follow [string to
mpfr conversion rule](https://www.mpfr.org/mpfr-current/mpfr.html#index-
mpfr_005fstrtofr) or [string to mpz conversion
rule](https://gmplib.org/manual/Assigning-Integers) ]

### 📝 Checklist

- [x] The title is concise and informative.
- [x] The description explains in detail what this PR is about.
- [x] I have linked a relevant issue or discussion.
- [x] I have created tests covering the changes.
- [x] I have updated the documentation and checked the documentation
preview. (there's no documentation change, but should we explicitly
mention the feature? I think the feature to construct from `[a..b]`
isn't explicitly mentioned either…?)

### ⌛ Dependencies

<!-- List all open PRs that this PR logically depends on. For example,
-->
<!-- - sagemath#12345: short description why this is a dependency -->
<!-- - sagemath#34567: ... -->


sagemath#39001
    
URL: sagemath#38998
Reported by: user202729
Reviewer(s): Travis Scrimshaw
vbraun pushed a commit to vbraun/sage that referenced this pull request Dec 8, 2024
sagemathgh-38998: Allow construct RIF element from question-style string
2b47cb6 
    
As in the title. It allows you to say e.g. `RIF("1.23?2e-5")`.

Partially handles sagemath#36797. (only
for real case. Complex case is not handled yet, but in principle it
should not be too difficult.)

(I don't see any disadvantage of allowing this, it's backwards
compatible)

Issue: currently

```
sage: RIF("10", base=37)
37
sage: ZZ("10", base=37)
[error]
```

should this inconsistency be fixed? If so how?

[Edit: actually the rule of conversion should probably follow [string to
mpfr conversion rule](https://www.mpfr.org/mpfr-current/mpfr.html#index-
mpfr_005fstrtofr) or [string to mpz conversion
rule](https://gmplib.org/manual/Assigning-Integers) ]

### 📝 Checklist

- [x] The title is concise and informative.
- [x] The description explains in detail what this PR is about.
- [x] I have linked a relevant issue or discussion.
- [x] I have created tests covering the changes.
- [x] I have updated the documentation and checked the documentation
preview. (there's no documentation change, but should we explicitly
mention the feature? I think the feature to construct from `[a..b]`
isn't explicitly mentioned either…?)

### ⌛ Dependencies

<!-- List all open PRs that this PR logically depends on. For example,
-->
<!-- - sagemath#12345: short description why this is a dependency -->
<!-- - sagemath#34567: ... -->


sagemath#39001
    
URL: sagemath#38998
Reported by: user202729
Reviewer(s): Travis Scrimshaw
@vbraun
Copy link
Member

vbraun commented Dec 8, 2024

On 32-bit:

**********************************************************************
File "src/sage/rings/convert/mpfi.pyx", line 133, in sage.rings.convert.mpfi._from_str_question_style
Failed example:
    x = RIF("1.123456?2e1000000000"); x
Expected:
    1.12346?e1000000000
Got:
    [-infinity .. +infinity]
**********************************************************************
File "src/sage/rings/convert/mpfi.pyx", line 135, in sage.rings.convert.mpfi._from_str_question_style
Failed example:
    x.str(style="question", error_digits=3)
Expected:
    '1.12345600?201e1000000000'
Got:
    '[-infinity .. +infinity]'
**********************************************************************
1 item had failures:
   2 of  50 in sage.rings.convert.mpfi._from_str_question_style
    [57 tests, 2 failures, 0.58s wall]
**********************************************************************

@user202729
Copy link
Contributor Author

user202729 commented Dec 8, 2024 •
edited
Loading

Most likely the binary exponent in 32-bit is limited to 2^30, and 10^10^9 > 2^2^30.

Fix should be simple.

(I don't have a 32-bit environment to test on, however experimentally on 64-bit environment RR(2)^int(2^64/4.01) can be handled with well, so I assume on 32-bit environment RR(2)^int(2^32/4.01) should be good, which 10^10^8 is smaller)

@user202729 user202729 requested a review from tscrim December 8, 2024 15:30
vbraun pushed a commit to vbraun/sage that referenced this pull request Dec 11, 2024
sagemathgh-38998: Allow construct RIF element from question-style string
9cb7534 
    
As in the title. It allows you to say e.g. `RIF("1.23?2e-5")`.

Partially handles sagemath#36797. (only
for real case. Complex case is not handled yet, but in principle it
should not be too difficult.)

(I don't see any disadvantage of allowing this, it's backwards
compatible)

Issue: currently

```
sage: RIF("10", base=37)
37
sage: ZZ("10", base=37)
[error]
```

should this inconsistency be fixed? If so how?

[Edit: actually the rule of conversion should probably follow [string to
mpfr conversion rule](https://www.mpfr.org/mpfr-current/mpfr.html#index-
mpfr_005fstrtofr) or [string to mpz conversion
rule](https://gmplib.org/manual/Assigning-Integers) ]

### 📝 Checklist

- [x] The title is concise and informative.
- [x] The description explains in detail what this PR is about.
- [x] I have linked a relevant issue or discussion.
- [x] I have created tests covering the changes.
- [x] I have updated the documentation and checked the documentation
preview. (there's no documentation change, but should we explicitly
mention the feature? I think the feature to construct from `[a..b]`
isn't explicitly mentioned either…?)

### ⌛ Dependencies

<!-- List all open PRs that this PR logically depends on. For example,
-->
<!-- - sagemath#12345: short description why this is a dependency -->
<!-- - sagemath#34567: ... -->


sagemath#39001
    
URL: sagemath#38998
Reported by: user202729
Reviewer(s): Travis Scrimshaw
vbraun pushed a commit to vbraun/sage that referenced this pull request Dec 12, 2024
sagemathgh-38998: Allow construct RIF element from question-style string
13951f2 
    
As in the title. It allows you to say e.g. `RIF("1.23?2e-5")`.

Partially handles sagemath#36797. (only
for real case. Complex case is not handled yet, but in principle it
should not be too difficult.)

(I don't see any disadvantage of allowing this, it's backwards
compatible)

Issue: currently

```
sage: RIF("10", base=37)
37
sage: ZZ("10", base=37)
[error]
```

should this inconsistency be fixed? If so how?

[Edit: actually the rule of conversion should probably follow [string to
mpfr conversion rule](https://www.mpfr.org/mpfr-current/mpfr.html#index-
mpfr_005fstrtofr) or [string to mpz conversion
rule](https://gmplib.org/manual/Assigning-Integers) ]

### 📝 Checklist

- [x] The title is concise and informative.
- [x] The description explains in detail what this PR is about.
- [x] I have linked a relevant issue or discussion.
- [x] I have created tests covering the changes.
- [x] I have updated the documentation and checked the documentation
preview. (there's no documentation change, but should we explicitly
mention the feature? I think the feature to construct from `[a..b]`
isn't explicitly mentioned either…?)

### ⌛ Dependencies

<!-- List all open PRs that this PR logically depends on. For example,
-->
<!-- - sagemath#12345: short description why this is a dependency -->
<!-- - sagemath#34567: ... -->


sagemath#39001
    
URL: sagemath#38998
Reported by: user202729
Reviewer(s): Travis Scrimshaw
vbraun pushed a commit to vbraun/sage that referenced this pull request Dec 13, 2024
sagemathgh-38998: Allow construct RIF element from question-style string
e16589b 
    
As in the title. It allows you to say e.g. `RIF("1.23?2e-5")`.

Partially handles sagemath#36797. (only
for real case. Complex case is not handled yet, but in principle it
should not be too difficult.)

(I don't see any disadvantage of allowing this, it's backwards
compatible)

Issue: currently

```
sage: RIF("10", base=37)
37
sage: ZZ("10", base=37)
[error]
```

should this inconsistency be fixed? If so how?

[Edit: actually the rule of conversion should probably follow [string to
mpfr conversion rule](https://www.mpfr.org/mpfr-current/mpfr.html#index-
mpfr_005fstrtofr) or [string to mpz conversion
rule](https://gmplib.org/manual/Assigning-Integers) ]

### 📝 Checklist

- [x] The title is concise and informative.
- [x] The description explains in detail what this PR is about.
- [x] I have linked a relevant issue or discussion.
- [x] I have created tests covering the changes.
- [x] I have updated the documentation and checked the documentation
preview. (there's no documentation change, but should we explicitly
mention the feature? I think the feature to construct from `[a..b]`
isn't explicitly mentioned either…?)

### ⌛ Dependencies

<!-- List all open PRs that this PR logically depends on. For example,
-->
<!-- - sagemath#12345: short description why this is a dependency -->
<!-- - sagemath#34567: ... -->


sagemath#39001
    
URL: sagemath#38998
Reported by: user202729
Reviewer(s): Travis Scrimshaw
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@tscrim tscrim tscrim approved these changes

Assignees
No one assigned
Labels
c: basic arithmetic s: positive review t: enhancement
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@user202729 @tscrim @vbraun