Value costing: insertCoin, unionValue, scaleValue #7435

ana-pantilie · 2025-11-19T21:31:35Z

Fixes https://github.com/IntersectMBO/plutus-private/issues/1899
Fixes https://github.com/IntersectMBO/plutus-private/issues/1900
Fixes https://github.com/IntersectMBO/plutus-private/issues/2004

See https://plutus.cardano.intersectmbo.org/pr-preview/cost-models/pr-7435/ for cost model vizualizations

plutus-core/plutus-core/src/PlutusCore/Evaluation/Machine/CostingFun/SimpleJSON.hs

plutus-core/cost-model/budgeting-bench/Benchmarks/Values.hs

plutus-core/cost-model/data/builtinCostModelC.json

plutus-core/cost-model/create-cost-model/BuiltinMemoryModels.hs

…s larger

github-actions · 2025-12-18T19:35:36Z

PR Preview Action v1.6.3
🚀 View preview at https://IntersectMBO.github.io/plutus/pr-preview/cost-models/pr-7435/
Built to branch `gh-pages` at 2025-12-24 12:16 UTC. Preview will be ready when the GitHub Pages deployment is complete.

plutus-core/plutus-core/src/PlutusCore/Value.hs

plutus-core/plutus-core/src/PlutusCore/Default/Builtins.hs

zliu41 · 2025-12-20T08:09:46Z

plutus-core/cost-model/data/builtinCostModelC.json

+    "memory": {
+      "arguments": {
+        "intercept": 24,
+        "slope": 21


How are the slope and intercept determined?

See the note.

plutus-core/plutus-core/src/PlutusCore/Default/Builtins.hs

zliu41 · 2025-12-22T23:42:42Z

plutus-core/cost-model/budgeting-bench/Benchmarks/Values.hs

+  generateConstrainedValueWithMaxPolicyAndQuantity numPolicies tokensPerPolicy maxBound
+
+-- | Generate constrained Value with information about max-size policy and quantity
+generateConstrainedValueWithMaxPolicyAndQuantity


Did you intend to use this somewhere, perhaps in scaleValueArgs? Otherwise there's not much point factoring this out.

I think this is a remnant of the experimentation which happened on this branch. I'll revert the change it if I have time.

zliu41 · 2025-12-22T23:59:04Z

plutus-core/cost-model/create-cost-model/BuiltinMemoryModels.hs

+  - 2 words for the key 'Int' closure
+  - 2 words for the value 'Int' closure
+Putting this all together, we arrive at the following memory usage function:
+    1*n + 4 + 7 + 1


It's unclear what the "4", "7" and "1" refer to. Please make it more obvious.

They come from me drawing out the closures from my understanding of ghc's memory allocation and counting the number of words (which are mentioned in the note). I don't think this methodology is the best, so we might end up removing this note in the end.

The note is useful, just organize it better and make it easier to follow. There's a lot of "1 word for this", "2 words for that", etc etc., and it is non-obvious what the "4" "7" "1" correspond to.

zliu41 · 2025-12-22T23:59:36Z

plutus-core/cost-model/create-cost-model/BuiltinMemoryModels.hs

+  ... and the allocations for the 'IntMap' and nested 'Map' themselves.
+The 'Map' and 'IntMap' are implemented as a self-balancing binary tree and a big-endian patricia tree,
+respectively. Since we are interested in the worst-case memory usage, we assume that
+for each application of the builtin function both of the trees have to be completely reallocated.


This only applies to unionValue, since in insertCoin and scaleValue, there's only one tree.

Also, insertCoin never completely allocates the whole tree, even in the worst case.

zliu41 · 2025-12-23T00:01:34Z

plutus-core/cost-model/data/builtinCostModelC.json

+        "intercept": 45,
+        "slope": 21
+      },
+      "type": "linear_in_w"


I'd still like to know if insertCoin is CPU bound or memory bound.

I don't know, I haven't had time to check this yet.

It's important to know this because if it exhausts memory 10 times faster than it exhausts CPU, it indicates that the memory cost is nonsensical and can severely limit the usefulness of Value.

I had time today to do this, these are the results. I created and ran the following test:

compiledInsertCoin :: CompiledCode BuiltinValue compiledInsertCoin = $$(compile [||insertCoin||]) `unsafeApplyCode` liftCodeDef "foo" `unsafeApplyCode` liftCodeDef "bar" `unsafeApplyCode` liftCodeDef 10 `unsafeApplyCode` liftCodeDef (mkValueInData 1000000) mkValueInData :: Int -> BuiltinValue mkValueInData n = let currSymbols = (\x -> B.mkB $ "cS" <> B.encodeUtf8 (B.toBuiltin (Text.pack (show x)))) <$> take n [1 ..] tokN = B.mkB "tN" entries = B.mkMap [ ( cS , B.mkMap [(tokN, B.mkI 100)] ) | cS <- currSymbols ] in B.unsafeDataAsValue entries

The resulting budget is:

CPU: 935_697 Memory: 1_786 AST Size: 12 Flat Size: 17_888_928

I would say that's definitely not memory bound, unless I didn't construct the example properly.

You can do a rough calculation like this: when you insertCoin into a Value of max depth 10:

CPU = (18413 * 10 + 356924) / 10000000000 = 0.00541054% of the transaction CPU limit Memory = (21 * 10 + 45) / 14000000 = 0.001821428% of the transaction memory limit

So we are good.

zliu41 · 2025-12-23T00:03:59Z

plutus-core/cost-model/create-cost-model/BuiltinMemoryModels.hs

+respectively. Since we are interested in the worst-case memory usage, we assume that
+for each application of the builtin function both of the trees have to be completely reallocated.
+Since we are dealing with a nested 'Map' with the structure 'Map CurrencySymbol (Map TokenName Integer)',
+we can consider only the worst-case scenario where the map is flattened, i.e., each currency symbol maps


I don't know why this is the worst case memory-wise, and I highly doubt this is the worst case for insertCoin. When inserting a node into a Map, usually the deeper the Map is, the more allocation is needed. I imagine a deep Map also makes rebalancing trickier.

I don't know why this is the worst case memory-wise, and I highly doubt this is the worst case for insertCoin.

It's not, I was mistaken. @kwxm, @Unisay and I had a meeting a few days ago where we discussed this. I think the structure of the map doesn't matter when it comes to how much memory is allocated (for one map), only the number of nodes does. But that doesn't really matter much because we care about the new memory being allocated after the builtin run, not the total memory.

I imagine a deep Map also makes rebalancing trickier.

You're probably right, but it's tricky to figure out what the worst case is and how much memory is allocated.

I think we need to approach memory costing for the Value builtins similar to the way we approach cpu costing: by experimentally finding the worst case and generating the data which we can base predictions on. I don't think we currently do this for the memory costing of any of the other builtins, so we need to also add the required code infrastructure to generate the models using R.

At the same time, @kwxm said we gave up on doing accurate memory costing a while ago, but I don't know the reason behind this.

It is almost always sufficient to determine the amount of allocation by understanding how the algorithm works. I don't even know how you can accurately measure allocations from a specific builtin call - seems quite tricky.

For insertCoin, the key is to be aware that rebalancing allocates at most O(logn) nodes. I think it's more than enough to assume that it allocates ValueMaxDepth number of nodes and be done with it. If you want to be more precise, feel free to read the paper to determine the exact worst case (which should still be far easier than trying to measure it accurately), but for memory cost we don't need to be that precise.

zliu41

The Value builtins should now be added to PlutusLedgerApi.Common.Versions.

zliu41 · 2025-12-24T00:25:22Z

plutus-core/cost-model/create-cost-model/BuiltinMemoryModels.hs

+  - 2 words for the key 'Int' closure
+  - 2 words for the value 'Int' closure
+Putting this all together, we arrive at the following memory usage function:
+    1*n + 4 + 7 + 1


The note is useful, just organize it better and make it easier to follow. There's a lot of "1 word for this", "2 words for that", etc etc., and it is non-obvious what the "4" "7" "1" correspond to.

zliu41 · 2025-12-24T00:56:50Z

plutus-core/cost-model/create-cost-model/BuiltinMemoryModels.hs

+respectively. Since we are interested in the worst-case memory usage, we assume that
+for each application of the builtin function both of the trees have to be completely reallocated.
+Since we are dealing with a nested 'Map' with the structure 'Map CurrencySymbol (Map TokenName Integer)',
+we can consider only the worst-case scenario where the map is flattened, i.e., each currency symbol maps


It is almost always sufficient to determine the amount of allocation by understanding how the algorithm works. I don't even know how you can accurately measure allocations from a specific builtin call - seems quite tricky.

For insertCoin, the key is to be aware that rebalancing allocates at most O(logn) nodes. I think it's more than enough to assume that it allocates ValueMaxDepth number of nodes and be done with it. If you want to be more precise, feel free to read the paper to determine the exact worst case (which should still be far easier than trying to measure it accurately), but for memory cost we don't need to be that precise.

zliu41 · 2025-12-24T01:02:48Z

plutus-core/cost-model/data/builtinCostModelC.json

+        "intercept": 45,
+        "slope": 21
+      },
+      "type": "linear_in_w"


It's important to know this because if it exhausts memory 10 times faster than it exhausts CPU, it indicates that the memory cost is nonsensical and can severely limit the usefulness of Value.

…inal

zliu41

Looks good but we need @kwxm to sign off on this.

zliu41 · 2025-12-24T23:48:52Z

plutus-core/cost-model/data/builtinCostModelC.json

+        "intercept": 45,
+        "slope": 21
+      },
+      "type": "linear_in_w"


You can do a rough calculation like this: when you insertCoin into a Value of max depth 10:

CPU = (18413 * 10 + 356924) / 10000000000 = 0.00541054% of the transaction CPU limit Memory = (21 * 10 + 45) / 14000000 = 0.001821428% of the transaction memory limit

So we are good.

kwxm

Here are some initial comments; I'll continue to review the PR (in particular, the benchmarking code: it's going to take me a while to grasp the details of that) and add more comments later. It all looks pretty sensible so far though.

kwxm · 2026-01-05T03:39:40Z

plutus-core/plutus-core/src/PlutusCore/Evaluation/Machine/CostingFun/Core.hs

+-- | a*x + b*y + c*x*y + I
+data TwoVariableWithInteractionFunction = TwoVariableWithInteractionFunction
+  { intercept :: Intercept
+  , slopex :: Slope


I'd suggest not including x and y in the parameter names here since it's conceivable that we could re-use this for something else where it's applied to other parameters. Similar costing functions use slope1 and slope2 instead, and I suppose we could have slope12 as well; alternatively, this is a type of polynomial (and the graph isn't a plane, so it doesn't really make sense to call the coefficients "slopes"), so we could use the already existing Coefficient00, Coefficient01, Coefficient 10, and Coefficient11 instead, although that's a bit lengthy.

This thing is in fact an instance of the TwoVariableQuadraticFunction type (with the x^2 and y^2 coeccificents equal to zero), but it'd probably be overkill to use that instead.

kwxm · 2026-01-05T03:45:43Z

plutus-core/plutus-core/src/PlutusCore/Evaluation/Machine/CostingFun/Core.hs

  (ModelTwoArgumentsConstantCost c) = lazy $ \_ _ -> CostLast c
 runTwoArgumentModel
-  (ModelTwoArgumentsAddedSizes (OneVariableLinearFunction intercept slope)) =
+  (ModelTwoArgumentsAddedSizes (OneVariableLinearFunction intercept' slope)) =


Are these all intercept' now because TwoVariableWithInteractionFunction contains a field called intercept? It seems questionable to change a large number of variable names so that the simple form of the name can be used in a small number of places. Note that other similar types have unwieldy field names like oneVariableLinearFunctionIntercept to avoid clashes and leave the simple names available for use elsewhere.

kwxm · 2026-01-05T03:58:03Z

plutus-core/cost-model/data/models.R

+    benchname <- regex("([[:alnum:]_]+)/(\\d+)(?:/(\\d+))?(?:/(\\d+))?(?:/(\\d+))?")
    ## We have benchmark names like "AddInteger/11/22", the numbers representing the sizes of
    ## the inputs to the benchmark.  This extracts the name and up to three numbers, returning
    ## "NA" for any that are missing.  If we ever have builtins with more than three arguments


This comment's outdated now because we do in fact have builtins with more than three arguments and have had for some time. I think this is the first time we've had to base costing on an argument after the third one though.

kwxm · 2026-01-05T04:01:30Z

plutus-core/cost-model/data/models.R

    ## constant anyway).

-    numbercols = c("x_mem", "y_mem", "z_mem")
+    numbercols = c("x_mem", "y_mem", "z_mem", "w_mem")


A very small quibble: when I've been working with benchmark results in R I've been in the habit of calling the arguments x, y, z, u, v, and w, as in the toframe script. I don't think that notation's actually made it into the codebase anywhere before though. I'm not sure what we'll do if we have to worry about a seventh argument at some time in the future. It's a bit late now, but maybe we should have called the arguments x1. x2, x3, ...

kwxm · 2026-01-05T04:09:30Z

plutus-core/cost-model/data/models.R

+        filtered <- data %>%
+            filter.and.check.nonempty(fname) %>%
+            discard.overhead ()
+        filtered$off <- 1 # offset to force inclusion of intercept in the model


What happens if you let lm infer the intercept? Do you get some huge number? I think it's generally regarded as bad practice to force models to got through specific points since it can cause all kinds of distortion. This will probably give you estimates smaller than the real value for small inputs, but maybe that's acceptable if it gives better estimates for bigger values. Admittedly, letting lm infer the intercept means that you sometimes end up with a negative intercept, and there's code in this file to adjust it if that happens.

Oh wait, that gets ignored anyway because it does infer a negative intercept: when you run generate-cost-model it says (amongst other things)

** WARNING: a negative coefficient -3216.982664 for (Intercept) occurred in the model for unValueData. This has been adjusted to 0.001. ** WARNING: a negative coefficient -764.798877 for (Intercept) occurred in the model for unionValue. This has been adjusted to 0.001. ** WARNING: a negative coefficient -2163.609705 for (Intercept) occurred in the model for scaleValue. This has been adjusted to 0.001.

So in the JSON file these all end up with an intercept of 1000 anyway. I'm not sure what's going on here...

kwxm · 2026-01-05T22:55:55Z

plutus-core/cost-model/print-cost-model/Main.hs

+  var1
+  var2 =
+    printf
+      "%d + %d + %d*%s + %d*%s + %d*%s*%s"


Suggested change

"%d + %d + %d*%s + %d*%s + %d*%s*%s"

"%d + %d*%s + %d*%s + %d*%s*%s"

There's an extra %d at the start.

kwxm · 2026-01-06T02:24:22Z

plutus-core/cost-model/data/models.R

    unValueDataModel          <- linearInX ("UnValueData")
+
+    # Y wrapped with `TotalSize` (contained value size)
+    scaleValueModel           <- linearInY ("ScaleValue")


I'm still puzzled by the shape of the data here, but making it linear in y does give a good overapproximation for all values of y. The downward bend at the start drags the regression line down quite a bit and you end up with a negavie intercept, but later that gets adjusted to 1000 and we end up with a line that lies just above all of the benchmark times.

kwxm · 2026-01-06T02:45:32Z

plutus-ledger-api/src/PlutusLedgerApi/Common/Versions.hs

+  , LookupCoin
+  , InsertCoin
+  , ValueContains
+  , UnionValue
+  , ScaleValue
+  , ValueData
+  , UnValueData


Suggested change

, LookupCoin

, InsertCoin

, ValueContains

, UnionValue

, ScaleValue

, ValueData

, UnValueData

, InsertCoin

, LookupCoin

, UnionValue

, ValueContains

, ValueData

, UnValueData

, ScaleValue

^ That's the same order as the constructors in Builtins.hs. It probably doesn't matter, but let's be consistent.

kwxm

I've added some more comments. I still need to check the benchmarking code though (not that I expect any problems, since the benchmark results look quite reasonable).

kwxm · 2026-01-06T02:49:37Z

plutus-ledger-api/src/PlutusLedgerApi/V1/ParamName.hs

  | UnValueData'cpu'arguments'intercept
  | UnValueData'cpu'arguments'slope
  | UnValueData'memory'arguments
+  | InsertCoin'cpu'arguments'intercept


Maybe we should also put the parameter names in the same order as the constructors in Builtins.hs (and also for V2 and V3). Again, it probably doesn't matter, but it'd make it a bit easier to match up the parameters with the relevant builtins.

kwxm · 2026-01-06T02:54:34Z

plutus-core/cost-model/budgeting-bench/Main.hs

      <> Benchmarks.Unit.makeBenchmarks gen
-      <> Benchmarks.Values.makeBenchmarks gen
+      <> Benchmarks.Values.makeBenchmarks
+        gen


Why is this on a new line? Is fourmolu being awkward?

kwxm · 2026-01-06T03:12:14Z

plutus-core/plutus-core/src/PlutusCore/Value.hs

+
+Shortcircuits if either value is empty.
+
+Since 'unionValue' is commutative, we switch the arguments whenever the second


This means that we effectively always evaluate unionValue x y with the total size of x greater than the total size of y, right? In the costing benchmarks for value it says

therefore we consider two Values where the first is a sub-value of the second.

and that's the case where the total size of x is less than the total size of y. For a horrible moment I thought that that was the wrong way round, but it doesn't matter because the implementation will swap them anyway. In fact maybe that's better, because it'll include the (very small) swapping time in the costs as well.

kwxm · 2026-01-06T03:32:48Z

plutus-core/cost-model/budgeting-bench/Common.hs

 -- gets back a 'Data' value it'll traverse all of it.
 benchWith params name term =
  bench name $
-    whnf (handleEvaluationErrors . evaluateCekNoEmit params) term


I may have to change this to use something like evaluateCekLikeInProd (see https://github.com/IntersectMBO/plutus-private/issues/1722), in which case the log messages will disappear again.

Also, I wonder if changing from a non-emitting evaluator to one which does emit will affect the benchmark performance. I guess we can check that by running a few benchmarks with both versions of the evaluator.

kwxm

This looks pretty much OK. I've added quite a lot of minor comments, and I think the memory cost for scaleValue needs to be updated.

kwxm · 2026-01-07T01:31:01Z

plutus-core/cost-model/budgeting-bench/Benchmarks/Values.hs

+Since 'scaleValue' needs to traverse the entire Value, we may fix the structure
+of the Value to be a flattened map with a single token name per policy ID.
+To ensure worst-case performance, we fix the resulting scaled quantities to
+be 'maxBound'. -}


I wonder if this really is the worst case. All of the multiplications are (maxBound/2) * 2, and perhaps mulitplication by 2 will be extra-efficient. Also, is there any danger that caching will speed things up, since we're doing the same multiplication each time? If we're really paranoid we could try something like generating random numbers close to maxBound and setting the scalar and the amount to be the square root of that, or something close. I suspect that most of the work will be done traversing the values, so the cost of the multiplications won't in fact make any significant difference (I could be wrong though!).

kwxm · 2026-01-07T02:10:53Z

plutus-core/cost-model/budgeting-bench/Benchmarks/Values.hs

+insertCoinArgs gen = do
+  lookupArgs <- lookupCoinArgs gen
+  let noOfBenchs = length lookupArgs
+  amounts <- genZeroOrMaxAmount gen noOfBenchs


Just to be annoying, I'd go for "Benches" here instead of "Benchs".

kwxm · 2026-01-07T02:29:53Z

plutus-core/cost-model/budgeting-bench/Benchmarks/Values.hs

+----------------------------------------------------------------------------------------------------
+-- ScaleValue --------------------------------------------------------------------------------------
+
+scaleValueBenchmark :: StdGen -> Benchmark


I'd still like to work oout why the graph is that odd shape (curved at first but then straightening out). The benchmark inputs look perfectly reasonable, so it's a bit mystifying. I don't think we need to let that hold us up though.

kwxm · 2026-01-07T02:33:46Z

plutus-core/cost-model/create-cost-model/BuiltinMemoryModels.hs

+
+## Overview
+
+The memory model for the Value builtin 'unionValue' estimates the heap allocation


This isn't just about unionValue: it talks about other builtins later. Presumably when this gets merged it'll need to be updated to deal with the other value builtins too, which might require significant rewriting.

kwxm · 2026-01-07T02:39:22Z

plutus-core/cost-model/create-cost-model/BuiltinMemoryModels.hs

+For each unique (currency symbol, token name) pair:
+
+Outer 'Map' (CurrencySymbol to inner 'Map'):
+  - 1 word for the 'Bin' closure


This is talking about the implementation of the Map type: there's nothing to tell the reader what Bin and Tip are, and seraching the Plutus code won't help. Maybe include the definition of Map so that we know what this is talking about.

kwxm · 2026-01-07T02:51:38Z

plutus-core/cost-model/create-cost-model/BuiltinMemoryModels.hs

+
+For 'unionValue', worst-case assumes disjoint sets of pairs in both 'Value's being united:
+
+    Memory = 21*n + 12 + 21*m + 12 = 21*(n + m) + 24


It doesn't say what m is, but presumably m and n are the sizes of the arguments.

kwxm · 2026-01-07T02:57:31Z

plutus-core/cost-model/create-cost-model/BuiltinMemoryModels.hs

+## Memory Analysis Assumptions
+
+We assume for each builtin application:
+  1. Both trees must be completely reallocated (worst-case)


The reader needs to know that Maps are implemented as trees here. If you look at the defintion of Value it's not obvious that trees are involved anywhere.

kwxm · 2026-01-07T02:57:53Z

plutus-core/cost-model/create-cost-model/BuiltinMemoryModels.hs

+
+## Memory Analysis Assumptions
+
+We assume for each builtin application:


each builtin application

This is just about unionValue, right?

kwxm · 2026-01-07T03:01:04Z

plutus-core/cost-model/create-cost-model/BuiltinMemoryModels.hs

+Remember, an integer is allocated as 3 words (pointer + closure data, where the data is max
+of two words size), so for 'scaleValue':
+
+    Memory = 3*n


This seems incorrect. If you're scaling a value with n nodes, in general the entire internal structure of the value will have to be re-created, so the total memory size of the output will be the same as the total memory size of the input, no? That would mean that the memory used by scaleValue on a value with n nodes is the total memory usage of a value with n nodes, which I think is 21n+12: that's a lot more than 3*n.

kwxm · 2026-01-07T03:09:52Z

plutus-core/cost-model/create-cost-model/BuiltinMemoryModels.hs

+
+\**Total for IntMap: 7 words (constant)**
+
+## Final Formula


The final formula for what? I think this is the total memory usage of a value with n entries, but it'd be helpful if it said that explicilty. I'd separate out this section and then use the formula in discussions of specific builtins later.

This was referenced Nov 19, 2025

Costing builtin value: insertCoin, unionValue, scaleValue #7423

Closed

BuiltinValue: insertCoin and unionValue and scaleValue costing #7384

Closed

This comment was marked as outdated.

Sign in to view

ana-pantilie changed the title ~~Value costing: insertCoin, unionValue~~ Value costing: insertCoin, unionValue, scaleValue Nov 20, 2025

This comment was marked as outdated.

Sign in to view

ana-pantilie force-pushed the ana/value-costing-final branch 3 times, most recently from 1e44958 to abdc6ed Compare December 5, 2025 14:15

zliu41 reviewed Dec 8, 2025

View reviewed changes

plutus-core/plutus-core/src/PlutusCore/Evaluation/Machine/CostingFun/SimpleJSON.hs Outdated Show resolved Hide resolved

plutus-core/cost-model/budgeting-bench/Benchmarks/Values.hs Outdated Show resolved Hide resolved

ana-pantilie commented Dec 15, 2025

View reviewed changes

plutus-core/cost-model/data/builtinCostModelC.json Outdated Show resolved Hide resolved

ana-pantilie commented Dec 16, 2025

View reviewed changes

plutus-core/cost-model/create-cost-model/BuiltinMemoryModels.hs Outdated Show resolved Hide resolved

ana-pantilie added 18 commits December 18, 2025 18:59

Add insertCoin and unionValue costing skeleton

d897a75

Add benchmarking code and costing model for insertCoin

3ed4321

Add benchmarking code and costing model for unionValue

9b566bd

New models for insertCoin and unionValue; regenerate data

ab1312b

Fix model parsing and printing, wip scaleValue

54557fe

Fix issues with rebase

61d398b

Temp: experimenting with different inputs for unionValue

c81b534

Fix unionValue: shortcircuit if one is empty, flip args when second i…

a464a1c

…s larger

Add alternative implementation for unionValue

b74c996

Add new benchmarking scenarios

7d79538

Tmp: scaleValue costing

a4a95bb

UnionValue + ScaleValue generators, changes to unionValue builtin

bf67123

Data frames scaleVal unionValFInal

1fe564a

Add model for unionValue

9afbe70

Add cost models for insertCoin and unionValue

fcb377d

Remove experimental csv files and frames

0f47947

Fix cost model json

ed707b0

Fix cost models

c702815

ana-pantilie requested a review from Unisay December 18, 2025 19:10

Add new functions to vizualization website

1fe82f1

ana-pantilie temporarily deployed to github-pages December 18, 2025 19:34 — with GitHub Actions Inactive

Fixes

0889b78

ana-pantilie temporarily deployed to github-pages December 18, 2025 19:49 — with GitHub Actions Inactive

Fix?

2b15ad5

ana-pantilie temporarily deployed to github-pages December 18, 2025 20:10 — with GitHub Actions Inactive

Add newtypes to denotations and regenerate golden files

c9fc008

ana-pantilie temporarily deployed to github-pages December 19, 2025 15:05 — with GitHub Actions Inactive

zliu41 reviewed Dec 20, 2025

View reviewed changes

Address review comments

d529ba8

ana-pantilie temporarily deployed to github-pages December 20, 2025 13:36 — with GitHub Actions Inactive

ana-pantilie requested a review from zliu41 December 20, 2025 13:38

zliu41 reviewed Dec 23, 2025

View reviewed changes

zliu41 reviewed Dec 24, 2025

View reviewed changes

Merge remote-tracking branch 'origin/master' into ana/value-costing-f…

78b9e7f

…inal

ana-pantilie temporarily deployed to github-pages December 24, 2025 11:17 — with GitHub Actions Inactive

Add Value builtins to batch 6

85d1aa9

ana-pantilie temporarily deployed to github-pages December 24, 2025 11:41 — with GitHub Actions Inactive

Address review comments

c411ba4

ana-pantilie temporarily deployed to github-pages December 24, 2025 12:15 — with GitHub Actions Inactive

ana-pantilie requested a review from zliu41 December 24, 2025 13:07

zliu41 approved these changes Dec 25, 2025

View reviewed changes

kwxm reviewed Jan 5, 2026

View reviewed changes

kwxm reviewed Jan 6, 2026

View reviewed changes

kwxm requested changes Jan 7, 2026

View reviewed changes

	"%d + %d + %d%s + %d%s + %d%s%s"
	"%d + %d%s + %d%s + %d%s%s"


		Shortcircuits if either value is empty.

		Since 'unionValue' is commutative, we switch the arguments whenever the second


		## Overview

		The memory model for the Value builtin 'unionValue' estimates the heap allocation


		For 'unionValue', worst-case assumes disjoint sets of pairs in both 'Value's being united:

		Memory = 21n + 12 + 21m + 12 = 21*(n + m) + 24


		## Memory Analysis Assumptions

		We assume for each builtin application:

Value costing: insertCoin, unionValue, scaleValue #7435

Are you sure you want to change the base?

Value costing: insertCoin, unionValue, scaleValue #7435

Conversation

ana-pantilie commented Nov 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as outdated.

This comment was marked as outdated.

This comment was marked as outdated.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

github-actions bot commented Dec 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Built to branch gh-pages at 2025-12-24 12:16 UTC. Preview will be ready when the GitHub Pages deployment is complete.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ana-pantilie Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ana-pantilie Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zliu41 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zliu41 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kwxm left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kwxm Jan 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

ana-pantilie commented Nov 19, 2025 •

edited

Loading

github-actions bot commented Dec 18, 2025 •

edited

Loading

Built to branch `gh-pages` at 2025-12-24 12:16 UTC.
Preview will be ready when the GitHub Pages deployment is complete.

ana-pantilie Dec 23, 2025 •

edited

Loading

ana-pantilie Dec 23, 2025 •

edited

Loading

kwxm left a comment •

edited

Loading

kwxm Jan 5, 2026 •

edited

Loading

kwxm Jan 5, 2026 •

edited

Loading

kwxm Jan 5, 2026 •

edited

Loading