Hello Waldek, * I finally found some routines that do the overflow checks. At a cost of course. So, I have used CommutativeRing and some checking routines for arithmetic operations, checked_add, checked_sub etc..., they throw an exception and abort computation. As of now as I use them as literals that satisfies me.
(1) -> a:=juint64(18446744073709551615) (1) 0xffffffffffffffff (2) -> a+1 OverflowError: 18446744073709551615 + 1 overflowed for type UInt64 >> System error: Invalid command given to Julia Thanks for your quick response. - Greg Le dim. 2 nov. 2025 à 04:58, Waldek Hebisch <[email protected]> a écrit : > > On Sun, Nov 02, 2025 at 01:09:27AM +0100, Grégory Vanuxem wrote: > > hello, > > > > U64Int exports Ring I wonder why. Wouldn't it be something like > > OrderedAbelianMonoid, eventually OrderedAbelianMonoidSup, or something > > like that? I know its use from the documentation (u32vec.spad): > > > > )abbrev domain U64INT U64Int > > ++ Description: Domain of unsigned 64-bit integers. It is used > > ++ to declare that values of local variables fit into 64 bits. > > U64Int : Ring with > > qconvert : Integer -> % > > == Integer add > > qconvert(x) == x pretend % > > For current needs we probably could replace Ring by Type. In > other words I do not think we use any categorical properties > of U64Int. > > Logically, U64Int is a subset of integers which fits into 64 bits. > So strictly speaking only handful of operations like comparisons > is valid for all arguments. But the idea is that as long as > arguments and value fit into 64-bit operation is well defined. > In ususal style we could have something like 'addIfCan', etc. > But the whole reason to have such type at all is to allow direct > use of machine instructions. So while currently '+', '-', '*' > are unimplemented, they make sense and should translate to > corresponding machine instructions. > > As I wrote, currently all ring operations are unimplementd (and > unused), so Ring basically serves as a comment indicating that > '+', '-', '*'. We can change this in the future, ATM it is not > clear to me if we should use very restrictive type, like > Type or BasicType, or something more general. We may wish to > use U64Int in generic code, which could force us to add more > operations. Ring looked reasonable to me, because if needed > we can provide corresponding operations and it appears frequently > as requirement for generic operations. > > -- > Waldek Hebisch > > -- > You received this message because you are subscribed to the Google Groups > "FriCAS - computer algebra system" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/fricas-devel/aQbW3aamCvNA-vvN%40fricas.org. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/CAHnU2da7-pd1E5wNMTkStqrwYStjQCvHqA2oLc%3DsfbvRd2TN%2Bg%40mail.gmail.com.
