Can x set delta with Manhattan length longer than 1? And what are the "the least/greater point which contains a non-space cell, relative to the origin"?

[Nakilon]

I'm implementing Befunge-98 in Ruby.

The problem is that according to the Lahey-space wrapping the backtracking a long delta is not the same as circling around a sphere -- it is going to have a shift.
Also because of that it is not clear where it should stop on the other side in case, for example, when dx=0, dy>1 and the column starts lower than some another column. I.e. what is the "addressable space" -- if the program is 0001-p 001-0p, where is now the "least point which contains a non-space cell"? And what if I put 32 instead of 0?

[cpressey]

Can x set delta with Manhattan length longer than 1?

The spec does not specify any restriction on the delta that can be set with x.

And what are the "the least/greater point which contains a non-space cell, relative to the origin"?

The spec defines "least point" as "point with the smallest numerical coordinates of a region; also known as the upper-left corner, when used in the context of Befunge". (this is defined in the "File Input/Output" section, for whatever reason.)

I interpret this to mean: if you have a set of points in Funge-space, and you enclose them in the smallest possible rectangle that encloses them, the least point is the upper-left corner of that rectangle - it has the smallest co-ordinate values. (and the greatest point is, correspondingly, the lower-right corner.)

I interpret "relative to the origin" to mean, the value reported by y for this least point, is relative to the origin. (This is in contrast to what y reports for the greatest point, which is expressed as relative to the least point, rather than relative to the origin, for whatever reason.)

if the program is 0001-p 001-0p, where is now the "least point which contains a non-space cell"?

I would interpret it to be (-1, -1), even though this cell actually contains space. i.e. My interpretation is that "contains a non-space cell" refers to the region rather than the least point itself. I think a complaint that the spec uses language strangely for this definition, would be a valid complaint.

And what if I put 32 instead of 0?

Then it would be (0, 0), assuming that's where your program starts.

But that's just my interpretation -- you might want to test it on some other Befunge interpreters to see what they say.

But also note, what I've said above applies to the value reported by y. From the middle part of your question, it's clear that your concerns involve same-line wrapping. You don't need to use the concept of "least points" to describe same-line wrapping.

The problem is that according to the Lahey-space wrapping the backtracking a long delta is not the same as circling around a sphere -- it is going to have a shift.

I don't know what you mean by "shift", but this sentence from the spec:

"the IP will always wrap such that it would eventually return to the instruction it was on before it wrapped"

...certainly rules out many of the possibilities that come to my mind from the word "shift".

If the program occupies (0, 0)-(20, 0) and the IP is at (20, 0) and its delta is (1, 0) and you have written a non-space value into (-1, -1), the IP will wrap around to (0, 0). The fact there is a value at (-1, -1) does not affect it.

The concept extends to delta values with Manhattan distance >1, because even though these deltas might skip over cells as the IP moves, these deltas still define lines.

If, in the above example, the IP was at (0, 0) and its delta was (5, -3), it would execute the instruction at (0, 0) over and over again, because there are no other instructions on that line. It stays on the same line. This is why it's called "same-line wrapping".

Hope this explanation makes sense and is helpful.

[Nakilon]

If the program occupies (0, 0)-(20, 0) and the IP is at (20, 0) and its delta is (1, 0) and you have written a non-space value into (-1, -1), the IP will wrap around to (0, 0).

And if the delta was (1, 1) it would wrap to (19, -1), right? If so I guess I now understand the "same-line wrapping", but:

What if the non-space characters are scattered from (0,0) to (10,0), the IP is at (9,0) and the delta is (3,0)? Will it jump to (0,0) or (2,0)?
What if the absolute value of dx is many times larger than the current width of the non-space region that the IP is supposed to wrap around?
Where will it go if the non-space region is from (0,0) to (1,1), IP is at (0,0) and delta is (1,3)? i.e. when the movement angle is not 45 degrees and it wraps in the middle of the delta jump.

you might want to test it on some other Befunge interpreters to see what they say

I would like to refer to your interpretation if someone asks me "why (my) interpreter works like this...?" when I finish it.

[Nakilon]

Answering my own question:

And if the delta was (1, 1) it would wrap to (19, -1), right?

I guess not, it will just loop forever because there is nothing to the North-West from it.

More questions:

---

ASCII Instruction          Before    After     Other Effects
----- -----------          ------    -----     -------------
,     Output Character     c                   writechar(c)

How does it work if cell is bigger than one byte?

---

The k "Iterate" instruction pops a value n off the stack. Then it finds the next instruction in Funge-space in the path of the IP (note that this cannot be a marker such as space or ;)

What are other markers? "? Anything else? What does mean "cannot"? My interpreter should raise an exception? Or should it add delta until it finds not-a-marker (this is how it's implemented in my draft right now but I don't remember where I took it from and will probably remove it)?

[tjol]

The k "Iterate" instruction pops a value n off the stack. Then it finds the next instruction in Funge-space in the path of the IP (note that this cannot be a marker such as space or ;)

What are other markers? "? Anything else? What does mean "cannot"? My interpreter should raise an exception? Or should it add delta until it finds not-a-marker (this is how it's implemented in my draft right now but I don't remember where I took it from and will probably remove it)?

It’s undefined behaviour, you can do whatever you want.

That being said, most interpreters that I’ve tried interpret this as (essentially) using the next instruction that would have been executed if the k were’t there,

so 3 k ; ~@~ ; 1 pushes 1 four times.

This is also tested in Mycology.

If you’re looking for more k-related undefined behaviour, have a look here: https://github.com/tjol/rfunge/blob/master/tests/manual_tests/k.b98