bytes.as-int

[IngeniariusSoftware]

eo/eo-runtime/src/main/java/org/eolang/Param.java

Lines 117 to 131 in f9bf9be

	else if (Long.class.equals(type)) {
	if (ret.length == 1) {
	res = (long) ret[0];
	}
	else {
	final byte[] cpy = new byte[Long.BYTES];
	cpy[0] = ret[0];
	int posx = cpy.length;
	int posy = ret.length;
	while (posy-- > 1 && posx-- > 1) {
	cpy[posx] = ret[posy];
	}
	res = ByteBuffer.wrap(cpy).getLong();
	}
	}

the current implementation of as-bytes gives us incorrect results for bytes:

1) 01-00.as-int  ->   72057594037927936 instead 256
2) FF-FF.as-int  ->  -72057594037927681 instead -1
3) 00-00-00-00-00-00-01-00.not.as-int  -> -144115188075855617 instead -257

[yegor256]

@andreoss what do you think?

[andreoss]

@yegor256 @IngeniariusSoftware
Looks like the expected behaviour to me.
If you want to convert to int you should use 8 bytes, or the value will get padded to 8 bytes (keeping the first byte in order to preserve the sign)

#608

[yegor256]

@andreoss @IngeniariusSoftware I think 01-00.as-int should lead to an error instead of returning some number. Indeed, bytes.as-int should expect exactly eight bytes.

[IngeniariusSoftware]

@andreoss, is this really the expected behavior? I looked at how bytes are converted to numbers in different languages, and there, expressed in our logic, bytes are placed at the end of the array without transferring the first byte to the beginning. If necessary, completing the sign:

Input	EO	Others
01-00	01-00-00-00-00-00-00-00	00-00-00-00-00-00-00-01
FF-FF	FF-00-00-00-00-00-00-FF	FF-FF-FF-FF-FF-FF-FF-FF

@yegor25, what is the advantage of using a strictly 8-byte limit? Isn't this redundant encoding? Pay attention to the 3)

00-00-00-00-00-00-01-00.not.as-int = -144115188075855617
Expected: -257

I specifically take 8 bytes, but the result is still different. Instead of storing all 8 bytes, BigInteger truncates to the required minimum, and as a result our converter gets FE-FF instead of FF-FF-FF-FF-FF-FF-FE-FF.

[yegor256]

@IngeniariusSoftware the design of EO is "explicit". This means that we don't make any assumptions, which are not visible to a programmer. Instead, we "fail fast" when the input doesn't look exactly as we expect it. It must be the responsibility of a programmer: to prepare the data the way we expect it to look like. That's why I suggest as-int to fail if anything except eight bytes is provided.

[andreoss]

@yegor256 Please, assign

[yegor256]

@andreoss go ahead please

[yegor256]

@andreoss what's up with this?

[andreoss]

@yegor256 Will open a PR, sorry for the delay

[0pdd]

@IngeniariusSoftware the puzzle #1043 is still not solved.

[0pdd]

@IngeniariusSoftware the puzzle #1046 is still not solved; solved: #1043.

[0pdd]

@IngeniariusSoftware the puzzle #1142 is still not solved; solved: #1043, #1046.

[0pdd]

@IngeniariusSoftware 3 puzzles #1183, #1184, #1185 are still not solved; solved: #1043, #1046, #1142.

[0pdd]

@IngeniariusSoftware 2 puzzles #1183, #1185 are still not solved; solved: #1043, #1046, #1142, #1184.

[0pdd]

@IngeniariusSoftware 2 puzzles #1183, #1207 are still not solved; solved: #1043, #1046, #1142, #1184, #1185.

[0pdd]

@IngeniariusSoftware the puzzle #1183 is still not solved; solved: #1043, #1046, #1142, #1184, #1185, #1207.

[0pdd]

@IngeniariusSoftware all 7 puzzles are solved here: #1043, #1046, #1142, #1183, #1184, #1185, #1207.