-
Notifications
You must be signed in to change notification settings - Fork 385
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(gnovm): add software floating point package #3185
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is 📢 Thoughts on this report? Let us know! |
74d793e
to
0ab6c55
Compare
🛠 PR Checks SummaryAll Automated Checks passed. ✅ Manual Checks (for Reviewers):
Read More🤖 This bot helps streamline PR reviews by verifying automated checks and providing guidance for contributors and reviewers. ✅ Automated Checks (for Contributors):🟢 Maintainers must be able to edit this pull request (more info) ☑️ Contributor Actions:
☑️ Reviewer Actions:
📚 Resources:Debug
|
34120ef
to
d4eecff
Compare
afe2028
to
182cde0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good job!
gnovm/pkg/gnolang/softfloat.go
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
don't create specific types with methods; just make GetFloat32 and GetFloat64 return uint32 and uint64 and make the operations, for instance the ones in op_binary.go, directly use the softfloat
package.
the custom type doesn't add much aside from wrapping the calls to the internal package, while having op_binary.go
use softfloat.Lte
makes very explicit what's going on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the feedback! I introduced the custom types with methods to improve readability, as I felt it made the code clearer and more explicit about the software floating-point operations. However, I understand your point about avoiding unnecessary abstraction. I will follow the Gno code standards and adjust the implementation if you guys think this approach doesn’t align with the preferred style.
tv.T = t | ||
tv.SetInt(x) | ||
case Int8Kind: | ||
validate(Float32Kind, Int8Kind, func() bool { | ||
val := float64(tv.GetFloat32()) | ||
trunc := math.Trunc(val) | ||
trunc := tv.GetFloat32().Trunc() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we not use something like F32toint32 here, and all other places?
This would also avoid us having to use Trunc and Mod
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't know how you will remove the float part without a trunc ? Maybe you think about a new approach ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
apologies, I see now this is only used for constants.
Looks good then
Closes: #312
The idea to use softfloat and work originates from this PR: #2863
Contributors' checklist...
BREAKING CHANGE: xxx
message was included in the description