2cb87f4f8f
There were some odd discrepancy for `integerToByteString` on the mem side. Either 1 or about 1000 mem units off; which I couldn't quite figure out. Yet, it proves useful to validate builtin at large and ensure we have a valid cost model for v3. |
||
|---|---|---|
| .. | ||
| ite | ||
| iteAtIntegerArrowIntegerApplied1 | ||
| iteAtIntegerArrowIntegerApplied2 | ||
| iteAtIntegerArrowIntegerAppliedApplied | ||
| iteAtIntegerArrowIntegerWithCond | ||
| iteForceAppForce | ||
| iteForced | ||
| iteForcedForced | ||
| iteForcedWithIntegerAndString | ||
| iteStringInteger | ||
| iteStringString | ||
| iteUnforcedFullyApplied | ||
| iteUnforcedWithCond | ||
| iteWrongCondTypeFullyAppied | ||
| iteWrongCondTypePartiallyApplied | ||
| multiplyIntegerForceError1 | ||
| multiplyIntegerForceError2 | ||
| multiplyIntegerForceError3 | ||
| README.md | ||
README.md
The test cases here are all extracted from the tests in
plutus-core/untyped-plutus-core/test/Evaluation/Golden.hs and check that
interleaving of forces and normal arguments for builtin applications behaves
correctly. Most of these are for ifThenElse (ite) because that has the most
complicated interleaving behaviour of our current builtins (it expects an
argument of the built-in bool type, then a force, then two term arguments).