Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: new functions in stdlib from stdlib.fc and math.fc #986

Open
wants to merge 29 commits into
base: main
Choose a base branch
from

Conversation

Gusarich
Copy link
Member

@Gusarich Gusarich commented Oct 25, 2024

Issue

Closes #770
Towards #1029 (only myCode())

Checklist

  • I have updated CHANGELOG.md
  • I have documented my contribution in docs/ and made the build locally
  • I have added tests to demonstrate the contribution is correctly implemented: this usually includes both positive and negative tests, showing the happy path(s) and featuring intentionally broken cases
  • I have run all the tests locally and no test failure was reported
  • I have run the linter, formatter and spellchecker
  • I did not do unrelated and/or undiscussed refactorings

Current State

  • All stdlib.fc functions are present in Tact stdlib in some form, with some exceptions:
    • no tuple manipulation functions, because there is no tuple support in Tact. Do we really need them? @anton-trunov
    • no minmax and no slice_bits_refs because we don't have tensor types in Tact and it would be useless: Tensor types #1116
    • no set_data and get_data because Tact manages persistent storage by itself
    • no bless and other continuation functions because Tact manages control flow itself and for running some arbitrary code it's better to use RUNVM which doesn't require continuations parameters
    • no raw_reserve_extra because it requires an uint32 -> varuint32 dictionary and we only support varuint16 for values currently: VarUInt32, VarInt16, VarInt32 serialization types #1117
  • All mathlib.fc functions are present in Tact stdlib in some form, with some exceptions:
    • no fixed-point arithmetic related functions: Fixed-point arithmetics library #1118
    • no nan and is_nan because we don't support NaN in Tact. Do we really need them? @anton-trunov
    • no sub_rev because it is useless in our case
    • no ...MOD instructions because they return two values as a tensor and it won't be very developer-friendly in Tact to make them return tuples in my opinion: Tensor types #1116
  • All new functions are covered with tests

@Gusarich Gusarich added this to the v1.6.0 milestone Oct 25, 2024
Copy link
Member

@novusnota novusnota left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for reviewing the draft, I just wanted to keep those notes around :)

stdlib/stdlib.fc Outdated Show resolved Hide resolved
stdlib/stdlib.fc Outdated Show resolved Hide resolved
stdlib/stdlib.fc Outdated Show resolved Hide resolved
stdlib/std/math.tact Outdated Show resolved Hide resolved
stdlib/std/cells.tact Outdated Show resolved Hide resolved
stdlib/std/cells.tact Outdated Show resolved Hide resolved
stdlib/std/cells.tact Outdated Show resolved Hide resolved
stdlib/std/cells.tact Outdated Show resolved Hide resolved
@Gusarich Gusarich force-pushed the stdlib-extension-with-mathlib branch from 178e712 to b9b6206 Compare November 17, 2024 07:41
@Gusarich
Copy link
Member Author

@novusnota @anton-trunov Implemented all functions. I'd like to hear some intermediate feedback on them before I proceed with writing tests.

I made sure to include all missing functions from both stdlib.fc and mathlib.fc with some exceptions (see PR description).

Copy link
Member

@anton-trunov anton-trunov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

afair, mathlib.fc has lots of functions for fixed-arithmetic as well, I think we should add those too (perhaps as a separate library, like fixed_point_math.tact).

Also, I left a couple comments in the source code

CHANGELOG.md Outdated Show resolved Hide resolved
refs: Int;
}

asm fun computeDataSize(cell: Cell, maxCells: Int): DataSize { CDATASIZE TRIPLE }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would TRIPLE work here? Structures are returned as tensors, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TRIPLE makes three elements into a tuple of length 3. I think it should work

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, but our structs are tensors, not tuples, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

structs are implemented as tuples in Tact (that's why we had problems with long ones in the first place, remember?)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, I must have mistaken it with the unbundled approach in the storage

stdlib/std/math.tact Outdated Show resolved Hide resolved
ctx.asm("", "UBITSIZE");
});

ctx.fun(`__tact_sqrt`, () => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how about we implement this in Tact?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and what about other stdlib functions?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if a function can be implemented efficiently in Tact, we should implement it in Tact or open an issue and fix it

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

CHANGELOG.md Outdated Show resolved Hide resolved
@Gusarich Gusarich marked this pull request as ready for review November 28, 2024 05:21
@Gusarich Gusarich requested a review from a team as a code owner November 28, 2024 05:21
@Gusarich
Copy link
Member Author

@anton-trunov @novusnota covered all new functions with tests!

Found and fixed a few little mistakes in types (for addressNone and computeDataSize functions). Also added comments with formulas for new math functions

@anton-trunov
Copy link
Member

@Gusarich Let's

  • resolve the merge conflicts
  • move the notes from "current state" to their own separate issues

@anton-trunov anton-trunov self-assigned this Nov 28, 2024
Copy link
Member

@anton-trunov anton-trunov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should document the new functions in https://docs.tact-lang.org/ref/core-math and other relevant doc pages

@novusnota
Copy link
Member

We should document the new functions in https://docs.tact-lang.org/ref/core-math and other relevant doc pages

Will do

@novusnota
Copy link
Member

novusnota commented Dec 1, 2024

We should document the new functions in https://docs.tact-lang.org/ref/core-math and other relevant doc pages

Halfway there, will be finishing this soon.

UPD: 2/3rds are done, got to complete the cell related functions
UPD: done!

@Gusarich
Copy link
Member Author

Gusarich commented Dec 5, 2024

move the notes from "current state" to their own separate issues

@anton-trunov have a look at the updated notes. there are few of them that I don't think we need to cover in Tact

@anton-trunov
Copy link
Member

Looks good! Thanks for adding those

@novusnota
Copy link
Member

@anton-trunov @Gusarich

Added documentation for all of the new functions from this PR, except for the addressNone(), since its implementation is still in the works. Didn't add doc comments yet — once we agree on the descriptions in the documentation, then I'll quickly add the doc comments mirroring them.

@Gusarich Gusarich mentioned this pull request Dec 6, 2024
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we want to also add muldiv?

@anton-trunov
Copy link
Member

Let's bring this up to date, resolve the review comments and merge

@verytactical
Copy link
Contributor

Maybe we should split it into smaller PRs? Given the amount of discussion it created, it would probably be faster to merged if we didn't block merging the code with discussions on an unrelated part of stdlib.

An uneducated guess would be 3-4 PRs:

image

@novusnota
Copy link
Member

Maybe we should split it into smaller PRs? Given the amount of discussion it created, it would probably be faster to merged if we didn't block merging the code with discussions on an unrelated part of stdlib.

Well, the only unresolved thing here besides merge conflics is the addressNone() function — other functions were reviewed and even have public docs written for them right in this PR already.

Therefore, I suggest @Gusarich you (or I) fix merge conflics, add the doc comments to stdlib based on the documentation I've added prior, and then the addressNone() will wait for completion as per #1029

@verytactical @anton-trunov

@Gusarich
Copy link
Member Author

@novusnota @anton-trunov @Shvandre have a look please!

<Badge text="Available since Tact 1.6" variant="tip" size="medium"/><p/>

```tact
extends fun depth(self: Cell): Int;
Copy link
Contributor

@Shvandre Shvandre Jan 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe the argument should be optional? extends fun depth(self: Cell?). I haven't tested, but TVM.pdf (and TVM spec also) states

D765 — CDEPTH (c – x), returns the depth of Cell c. If c has no
references, then x = 0; otherwise x is one plus the maximum of depths
of cells referred to from c. If c is a Null instead of a Cell, returns zero.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, but calling null.depth() in order to simply obtain 0 doesn't make much sense. And if the user has something like let x: Cell? = ... at any point, I doubt calling x.depth() will be an efficient way to determine if x is null or not, since the !! would still be needed for later uses that require Cell and not Cell? type.

But I might be totally wrong :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say it makes sense if your Cell? is fro, incoming message, and your logic is somehow based on that. I haven't seen those examples, but I would add that as there is no overhead, and internal TVM instruction provides support for it.

<Badge text="Available since Tact 1.6" variant="tip" size="medium"/><p/>

```tact
extends fun computeDataSize(self: Cell, maxCells: Int): DataSize;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment here. What are the benefits of narrowing the application of a function? CDATAZISE works fine with null, and returns $x=y=z=0$

@novusnota
Copy link
Member

novusnota commented Jan 30, 2025

@Gusarich is addressNone() done? That is, may I document it in its current state, returning Address??

If not, we can remove it from the changelog, docs and sources for now. And then make a follow-up PR that'll re-introduce addressNone() with changes to the Address type itself, as suggested earlier :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Port stdlib.fc and mathlib.fc's asm functions to Tact's stdlib
5 participants