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

Fixed forRange in Julia for positive step values #3994

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Conversation

B-rando1
Copy link
Collaborator

Julia's ranges include the end value, and other languages don't. I updated the Julia renderer to subtract 1 from the end value to match the other languages.

Note that while this fixes it for positive step values, it does not for negative step values. More work needs to be done here.

Contributes to #3992

Julia's ranges include the end value, and other languages don't. I
updated the Julia renderer to subtract `1` from the end value to match
the other languages.

Note that while this fixes it for positive `step` values, it does not
for negative `step` values. More work needs to be done here.
@B-rando1 B-rando1 changed the title Updated range in Julia Fixed forRange in Julia for positive step values Dec 31, 2024
@B-rando1
Copy link
Collaborator Author

I'm not sure what's going on with HLint. The error in the log is E: Unable to locate package libtinfo5.

@@ -2,11 +2,11 @@ module VectorTest

global v1 = [1.0, 1.5]
global v2 = [0.0, -1.0]
for i in 0:1:length(v1) - 1
for i in 0:1:length(v1) - 1 - 1
Copy link
Owner

Choose a reason for hiding this comment

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

This seems odd -- length - 2 ? This looks like it is over-compensating!

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Good catch. I should have noticed that. It looks like I accounted for the range difference in the thunkAssign function, which uses the forRange function. Because this change is upstream of it (most likely the 'correct' place), it was affected. My new commit should remedy that.

Turns out that `thunkAssign` already subtracted `1`, so the new
generated code was subtracting it twice. This code should resolve that issue.
Copy link
Owner

@JacquesCarette JacquesCarette left a comment

Choose a reason for hiding this comment

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

I'm approving now, but won't merge in quite yet, as the linter did not run - looks like an upstream problem though, i.e. not your fault.

@JacquesCarette
Copy link
Owner

#3998 should fix that, but I'm waiting for a review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants