U64Int and Ring

[Grégory Vanuxem]

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 %

I ask this since I plan to add its equivalent to JLObjectType when
accessing internal Julia object structure and I wonder what it will
export. Any idea about which category(ies) I should use?

I do not want substraction, just eventually substractIfCan. I
looked at NonNegativeInteger to see its exports but it's too a lot for
me and I do not want to use SubDomain, I plan to add it to a personal
category JLMachineType. Example:

(1) -> randtest("randtest_wide")

(1)
[-0.9999999995343387126922607421875000120370621524201385531291391908951192436
96186 +/- 4.54e-79]
Type: NMRealBall
(2) -> jlPropertyNames %

(2) (:mid_exp, :mid_size, :mid_d1, :mid_d2, :rad_exp, :rad_man, :parent)
Type: JLObject
(3) -> jlGetProperty(%%(1),"mid_size")

(3) 0x0000000000000007
Type: JLObject
(4) -> jlType %

(4) "UInt64"
Type: String

Regards,

- Greg

=================================================
(5) -> jlDocumentation randtest
randtest(randtype) returns a random number depending on the Julia symbol rand
type. :urandom an uniformly distributed random number contained in [0,1]. To
test corner cases: :randtest returns a finite random number, :randtest_exact
returns a zero radius random number, :randtest_precise returns a precise rand
om number i.e. with a radius of around 2^-precision() the magnitude o
f the midpoint, :randtest_special returns a special random number where midpo
int and/or radius might be NaNs or infinities, :randtest_wide returns a rando
m number with a large radius that might be big relative to its midpoint.
Signature:
(JLSymbol)->%
From:
NMArbField

(6) -> jlDocumentation jlPropertyNames
jlPropertyNames(obj) returns the property/element names of obj.
Signature:
(%)->JLObject
From:
JLObjectType

(7) -> jlDocumentation jlGetProperty
jlGetProperty(obj, sym) returns the property/element sym of obj.
Signature:
(%,JLSymbol)->JLObject
From:
JLObjectType

(8) -> jlDocumentation jlType
jlType(obj) returns the Julia type of obj.
Signature:
(%)->String
From:
JLObjectType

[Waldek Hebisch]

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

[Grégory Vanuxem]

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

> --
> 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 fricas-devel...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/aQbW3aamCvNA-vvN%40fricas.org.