REBOL3 tracker
  0.9.12 beta
Ticket #0001629 User: anonymous


Short URL:
TypeBug Statustested Date1-Jul-2010 12:36
Versionalpha 99 CategoryMezzanine Submitted byBrianH
PlatformAll Severityminor Prioritynormal

Summary MOVE/to/skip has the wrong math for the destination index
Description MOVE/skip is supposed to scale the offset and length of the move by a record size, and it does. But when you specify MOVE/to, making the offset an index, it uses the wrong math to calculate the scaling: a simple multiplication. It should instead be a spanned index.

Note: This also affects R2 2.7.7 and R2/Forward
Example code
>> head move/skip at [a 1 2 b 3 4] 4 -1 3
== [b 3 4 a 1 2]  ; correct
>> head move/to/skip at [a 1 2 b 3 4] 4 1 3
== [a 1 b 3 4 2]  ; should be [b 3 4 a 1 2]
; Note that the 1 was multiplied by 3 to get the destination index

Assigned ton/a Fixed inalpha 108 Last Update20-Oct-2010 03:55

1-Jul-2010 13:01

Fixed in R3 mezz-series.r 7551, R2 mezz-series.r 7552 and R2/Forward
2-Jul-2010 10:37

I like the idea of the move function, but I just think it would be faster (and memory safe) to use the native swap in R3 to do such.
Though, currently we only can swap one value at a time. It would be convenient to add a looping behavior thru a refinement /size or /length.

swap/size serie-1 serie-2 10

A move would be implemented by refering the same serie, 2 times.

swap/size serie-1 skip serie-1 10 10
2-Jul-2010 11:10

Your first example would work, but swapping a span of elements within the same series quickly runs into issues with overlapping spans. Part of the problem is that two series references are used, and halfway through the swap one of those references will become invalid, and remain invalid afterwards, as will the resulting data.

The whole reason that MOVE is included in R3 and R2 in the first place is that it is immune to aliasing and overlap problems, even before this fix is applied. Part of what makes MOVE safe to use is that it only has one series reference, and the rest are done by integer offsets, indexes and lengths. There was a long discussion that ended up with the MOVE function, and it was proven that these constraints are necessary to make the function safe to use. We could make MOVE native, but it would still need to behave the same.

MOVE is there so that people won't be as tempted to reinvent it, since most of the time they end up with a function that doesn't work in some circumstances. It's a common problem.

Date User Field Action Change
20-Oct-2010 03:55 BrianH Status Modified built => tested
22-Sep-2010 06:36 carl Fixedin Modified => alpha 108
22-Sep-2010 06:36 carl Status Modified pending => built
2-Jul-2010 11:23 BrianH Comment : 0002421 Modified -
2-Jul-2010 11:20 BrianH Comment : 0002421 Modified -
2-Jul-2010 11:18 BrianH Comment : 0002421 Modified -
2-Jul-2010 11:11 BrianH Comment : 0002421 Modified -
2-Jul-2010 11:10 BrianH Comment : 0002421 Added -
2-Jul-2010 10:37 Steeve Comment : 0002420 Added -
1-Jul-2010 13:02 BrianH Comment : 0002418 Modified -
1-Jul-2010 13:02 BrianH Description Modified -
1-Jul-2010 13:01 BrianH Comment : 0002418 Added -
1-Jul-2010 13:00 BrianH Code Modified -
1-Jul-2010 13:00 BrianH Status Modified submitted => pending
1-Jul-2010 12:36 BrianH Ticket Added -