Sizeof int

[jacob navia]

Tom St Denis a écrit :

jacob navia wrote:




hehehe ... you're treading into my world now ...

"mp" stands for "multiple precision" as in the algorithms will adjust
the precision as required for you.

The "init_size" function is just for the cases where you know the size
of your numbers and want to avoid the realloc.

Tom

You do not handle floating point then. Lcc-win32 does.

 

[Mark McIntyre]

Tom St Denis a écrit :
You do not handle floating point then. <my stuff> does.

sorry, since when did CLC become a dick swinging session for two
offtopic posters ?
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

C has no concept of "size of word".

I often find that to explain something you have to refer to concepts
not defined in ISO standards, don't you?[/QUOTE]

Sure. Whenever I'm trying to explain the difference between futures
and forwards, I need to explain margin and quite possibly time value
of money.

How is that any more relevant to CLC than the concept of wordsize?
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Tom St Denis]

You do not handle floating point then. Lcc-win32 does.

I don't get your point. my reply was suggesting there are more
portable ways of achieving bignums than hacking the C language.

Personally, if you want to turn this personal, nobody worth have a look
uses lcc-win32. No offense, but it was [at least when I used it a few
years ago] the crappiest development suite out there. The resource
editor would often crash and working with symbols in headers was a
complete pain in the arse. The compiler doesn't optimize the code and
your extensions are only applicable to windows. Smart people would use
cygwin for windows development if they couldn't afford VS. At least
the GCC extensions in that work in other platforms which use GCC.

I'd say if you wanted to really turn lcc-win32 into a product of value
you have more to worry about then adding bignum support to the
language.

For instance, are you even working on Win64 support? How about real
code optimizations? Are you remotely close to C99 support? etc...

Tom

 

[jacob navia]

Mark McIntyre a écrit :

sorry, since when did CLC become a dick swinging session for two
offtopic posters ?

Ahh what a good argumentation!

It reflects immediately the intellectual capacities of the poster.

Basically there are two types of bignums support:
Integers only support or some kind of "floating" point
support. This is a design decision for the builders of
the package. Mr StDenis decided to support only integers,
then there is no point in setting sizeof(bignum int) in
its library.

I decided otherwise, so there must be a limit as to how many
bits will be supported by each number.

All this is obviously way beyond what you can understand.

Since you can't do otherwise you just throw obscenities
around and think you are very clever.

The subject of this thread was precisely if sizeof(int) could
be changed. This leads naturally to bignums implementations
where sizeof(int) can be changed at will.

Reading the subject of the thread is also something too difficult for
you.

If you followed the discussion you could have understood something.

But it is obviously much easier to throw some obscenity.

jacob

 

[jacob navia]

Tom St Denis a écrit :

I don't get your point.

Basically there are two types of bignums support:

Integers only support or some kind of "floating" point
support.

This is a design decision for the builders of
the package. You decided to support only integers,
then there is no point in setting sizeof(bignum int) in
your library.

I decided to support "floating" point, i.e. to represent the bignums
by a ratio of two indefinitely long integers. Then, the user must decide
which size should those numbers have. Then, (and we come here to the
original thread) there is a concrete sense in setting sizeof(int).

[snip off topic]

 

[Tom St Denis]

Basically there are two types of bignums support:
Integers only support or some kind of "floating" point
support. This is a design decision for the builders of
the package. Mr StDenis decided to support only integers,
then there is no point in setting sizeof(bignum int) in
its library.

You don't need to augment your type to support large integers.
Therefore, breaking your "C" compiler is kinda a bad idea.

The subject of this thread was precisely if sizeof(int) could
be changed. This leads naturally to bignums implementations
where sizeof(int) can be changed at will.

One may assume he wanted to change sizeof(int) to support large
numbers. One may think he wants to make a "faster" int or something.
Who knows.

But if the intent is large numbers, a bignum lib would be better.

Tom

 

[jacob navia]

Richard Tobin a écrit :

In my experience, "bignum" is used to refer to numbers without fixed
size limits (except memory, address space etc). You can't do reals
(rather than integers or rationals) like that, because almost all
operations can return numbers that can't be represented in any finite
size.

True. But they can be approximated by rationals as near as
memory constraints allow. That is why you have to set a
size for the numbers, so that there is a limit in the approximation.

GMP uses a per number size, lcc-win32 uses a global size, and
all numbers are equal.

That sounds like rationals, not floating point. The point about
floating point is that the point floats...

-- Richard

Well, I wrote it in quotes. Obviously they are rational numbers.

 

[Richard Tobin]

Basically there are two types of bignums support:

In my experience, "bignum" is used to refer to numbers without fixed
size limits (except memory, address space etc). You can't do reals
(rather than integers or rationals) like that, because almost all
operations can return numbers that can't be represented in any finite
size.

I decided to support "floating" point, i.e. to represent the bignums
by a ratio of two indefinitely long integers.

That sounds like rationals, not floating point. The point about
floating point is that the point floats...

-- Richard

 

[Tak-Shing Chan]

C has no concept of "size of word".

ISO/IEC 9899:1999 (E) used the term ``word length'' in F.1
(normative).

Tak-Shing

 

[Dik T. Winter]

> Tom St Denis a écrit :
>
> Basically there are two types of bignums support:
>
> Integers only support or some kind of "floating" point
> support.

Perhaps. Or only floating point support (the package from Richard Brent).

> This is a design decision for the builders of
> the package. You decided to support only integers,
> then there is no point in setting sizeof(bignum int) in
> your library.

For integers there is no need to setting size. This is independent on
whether you also support floating point or not.

> I decided to support "floating" point, i.e. to represent the bignums
> by a ratio of two indefinitely long integers.

That is *not* floating point, and in most cases can not be suitably used
as a substitute for floating point, as it does not conform to common
requirements from numerical mathematics about floating point (a minimal
exponent range compared to the number of mantissa digits). It is also
not floating slash (a representation of rationals where the numerator
and denominator together occupy about the same amount of storage). It
is a representation of the rationals with fixed limit on the size of
numerator and denominator.

When you represent real numbers with them you get a terribly wobbling
precision. Moreover you will have problems to correctly define what
the operations on such numbers do when the result does not fit in the
representation. Consider such a representation with a single decimal
digit for numerator and denominator. What is the result of 1/9 + 1/8?
Is it 2/9 or 1/4 after rounding? Does 1/9 + 1/7 properly round to 1/4?
And 1/9 + 1/7 to 1/6? So your package is not suitable for numerical
mathematics. Thanks for the warning.

> Then, the user must decide
> which size should those numbers have. Then, (and we come here to the
> original thread) there is a concrete sense in setting sizeof(int).

And that is your problem, you conflate them both in the same type.

 

[Keith Thompson]

The subject of this thread was precisely if sizeof(int) could
be changed. This leads naturally to bignums implementations
where sizeof(int) can be changed at will.

No, having a bignum library doesn't mean you can change sizeof(int).
It may mean you can change sizeof(bignum).

 

[Keith Thompson]

In my experience, "bignum" is used to refer to numbers without fixed
size limits (except memory, address space etc). You can't do reals
(rather than integers or rationals) like that, because almost all
operations can return numbers that can't be represented in any finite
size.

But all simple arithmetic operations (+, -, *, /, even ** with an
integer right operand) yield only rational numbers given rational
operands, so you could represent all the results as ratios of
dynamically sized integer bignums. If you do it right, there should
be no need to specify the size. Of course, for some iterative
calculations the sizes can grow very large very quickly, which might
be worse than imposing a size limit and losing exactness. And the
whole thing breaks down when you introduce other functions such as
sqrt(). (Unless you create a representation that represents square
roots symbolically, but then implementing operations becomes
difficult.)

That sounds like rationals, not floating point. The point about
floating point is that the point floats...

Right. Floating-point numbers are a subset of real numbers; rational
numbers are another subset of real numbers.

 

[Andrew Poelstra]

C has no concept of "size of word".

I often find that to explain something you have to refer to concepts
not defined in ISO standards, don't you?
[/QUOTE]

Absolutely, and normally I wouldn't have called you on that, but in
this case, there are compilers which /don't/ conform to the processor's
register sizes. For example, gcc on an i386 has a "long long" type in
C99 mode which is 64 bits, twice as long as my processor's biggest
register.

Of course, this is all terrible off-topic on clc.

 

[Andrew Poelstra]

ISO/IEC 9899:1999 (E) used the term ``word length'' in F.1
(normative).

While I'm not sure of the context, and with my downed server
to worry about I can't go check,

I stand corrected.

 

[Gordon Burditt]

Well, The size of int depends upon the size of word on the machine and
I'd love to see the standard try to define such terms as "buggy code",
"atrocious style", and, when referring to something an application
is supposed to compute, a "dollar".

Absolutely, and normally I wouldn't have called you on that, but in
this case, there are compilers which /don't/ conform to the processor's
register sizes. For example, gcc on an i386 has a "long long" type in
C99 mode which is 64 bits, twice as long as my processor's biggest
register.

Another much OLDER non-conformance to CPU register sizes: C on a
PDP-11 had a "long" type, which was 32 bits, even though there were
no general registers that long. And no 32-bit add instruction.

Gordon L. Burditt

 

[jacob navia]

Dik T. Winter a écrit :

Perhaps. Or only floating point support (the package from Richard Brent).


For integers there is no need to setting size. This is independent on
whether you also support floating point or not.


That is *not* floating point, and in most cases can not be suitably used
as a substitute for floating point, as it does not conform to common
requirements from numerical mathematics about floating point (a minimal
exponent range compared to the number of mantissa digits). It is also
not floating slash (a representation of rationals where the numerator
and denominator together occupy about the same amount of storage). It
is a representation of the rationals with fixed limit on the size of
numerator and denominator.

No it is floating slash, and it is working since several years. I
started working on it for my lisp interpreter that I developed under
MSDOS around 1989.

When you represent real numbers with them you get a terribly wobbling
precision. Moreover you will have problems to correctly define what
the operations on such numbers do when the result does not fit in the
representation. Consider such a representation with a single decimal
digit for numerator and denominator. What is the result of 1/9 + 1/8?
Is it 2/9 or 1/4 after rounding? Does 1/9 + 1/7 properly round to 1/4?
And 1/9 + 1/7 to 1/6? So your package is not suitable for numerical
mathematics. Thanks for the warning.

You are welcome. First you misunderstand, then you start drawing
absurd conclusions. I am speaking about indefinitely long integers
not just two word size integers!

And that is your problem, you conflate them both in the same type.

????
I wrote sizeof (bgnum int)

 

[Keith Thompson]

Dik T. Winter a écrit :

????
I wrote sizeof (bgnum int)

Are you saying you were misquoted? I just checked your previous
article (3 steps up from this one), and you did write "... a concrete
sense in setting sizeof(int)." Perhaps that's not what you meant to
write, but it's what showed up under your name on my server.

 

[Richard Tobin]

In my experience, "bignum" is used to refer to numbers without fixed
size limits (except memory, address space etc). You can't do reals
(rather than integers or rationals) like that, because almost all
operations can return numbers that can't be represented in any finite
size.

[/QUOTE]

But all simple arithmetic operations (+, -, *, /, even ** with an
integer right operand) yield only rational numbers given rational
operands, so you could represent all the results as ratios of
dynamically sized integer bignums. If you do it right, there should
be no need to specify the size.

Yes, this is exactly what, for example, Common Lisp does. I intended
to make that clear when I said "rather than integers or rationals".

What I meant to say is that a floating-point-like representation of
reals can't precisely represent many results even when the
representation can use arbitrarily many digits.

-- Richard

 

[jacob navia]

Richard Tobin a écrit :

Yes, this is exactly what, for example, Common Lisp does. I intended
to make that clear when I said "rather than integers or rationals".

What I meant to say is that a floating-point-like representation of
reals can't precisely represent many results even when the
representation can use arbitrarily many digits.

-- Richard

That is true, as in any other reals representation. True floating
point has the same poblems, and this representation can't represent
many reals too. There is no silver bullet.