You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A goal of Beta/One is not to teach things in the tutorial that will need to be unlearned. The necessity of having a story for the handling of "BigNum" arithmetic suggests that the INTEGER! type should have BigNum range...which raises the issue for efficiency of the use of non-immediate values.
Support for BigNum arithmetic is likely not a realistic goal to occur for Beta/One...as it involves too much rewiring of the arithmetic code--as well as decisions on whether to use the existing bigint.c for Crypto from axTLS or not.
However, the approach described in the post of using non-immediate values is viable, and could be used to give the semantics required for efficient bignums--just within the range of today's 64-bit integers. This means that:
x: copy 10
add x 5
print x
Would print out 15. The proposal outlines that this would be the behavior of ADD but not of +, which would not modify its argument, and return an immutable number...which could be implemented efficiently without the use of a memory allocation.
This lesser goal is a requirement to implement in time for Beta/One.
The text was updated successfully, but these errors were encountered:
hostilefork
changed the title
Beta/One: Mutable INTEGER! semantics for ADD
Beta/One: Mutable/Lockable INTEGER! semantics
Jul 4, 2018
A goal of Beta/One is not to teach things in the tutorial that will need to be unlearned. The necessity of having a story for the handling of "BigNum" arithmetic suggests that the INTEGER! type should have BigNum range...which raises the issue for efficiency of the use of non-immediate values.
The concept is outlined here in a forum post:
https://forum.rebol.info/t/planning-ahead-for-bignum-arithmetic/623
Support for BigNum arithmetic is likely not a realistic goal to occur for Beta/One...as it involves too much rewiring of the arithmetic code--as well as decisions on whether to use the existing bigint.c for Crypto from axTLS or not.
However, the approach described in the post of using non-immediate values is viable, and could be used to give the semantics required for efficient bignums--just within the range of today's 64-bit integers. This means that:
Would print out 15. The proposal outlines that this would be the behavior of ADD but not of +, which would not modify its argument, and return an immutable number...which could be implemented efficiently without the use of a memory allocation.
This lesser goal is a requirement to implement in time for Beta/One.
The text was updated successfully, but these errors were encountered: