Home > Archive > Smalltalk > April 2004 > Large Integer Sqrt broken? (VW)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Large Integer Sqrt broken? (VW)
|
|
| Brian Gridley 2004-04-20, 10:53 am |
| I was trying to use VW7 for the first time. The sqrt and raisedTo:
methods now break on large integers, as they try to convert to floats.
A couple years ago I used VW 2.x-3.x to do raisedTo: and did not have
this problem. Using the StMMath classes does not solve this either. Is
the old functionality gone for good, or is it available some other
way? I need something that works at a good speed for really big
numbers.
| |
| Martin Kobetic 2004-04-20, 11:52 am |
| This doesn't seem to be a regression. '100 factorial sqrt' fails the
conversion as far back as 2.5. However I don't see any problem with
raisedTo:. If you tried raisedTo: 0.5, then the conversion failure is in
the ln function not in raisedTo:. Basically all the functions that call
asLimitedPrecisionReal share this problem.
You can get a bit further doing explicit conversions to Double rather
than Float, i.e. '100 factorial asDouble sqrt' succeeds.
Brian Gridley wrote:
> I was trying to use VW7 for the first time. The sqrt and raisedTo:
> methods now break on large integers, as they try to convert to floats.
> A couple years ago I used VW 2.x-3.x to do raisedTo: and did not have
> this problem. Using the StMMath classes does not solve this either. Is
> the old functionality gone for good, or is it available some other
> way? I need something that works at a good speed for really big
> numbers.
--
Martin Kobetic, Cincom Smalltalk Development,
http://www.cincom.com/smalltalk
| |
| Brian Gridley 2004-04-20, 6:36 pm |
| Martin Kobetic <mkobetic@cincom.com> wrote in message news:<40853C8C.9000607@cincom.com>...
> This doesn't seem to be a regression. '100 factorial sqrt' fails the
> conversion as far back as 2.5. However I don't see any problem with
> raisedTo:. If you tried raisedTo: 0.5, then the conversion failure is in
> the ln function not in raisedTo:. Basically all the functions that call
> asLimitedPrecisionReal share this problem.
>
> You can get a bit further doing explicit conversions to Double rather
> than Float, i.e. '100 factorial asDouble sqrt' succeeds.
I need to be able to do numbers like (2 ** 1024) -1) and higher. Yes
I saw that the problem with raisedTo: was with the ln method. Has no
one encountered this issue before?[color=darkred]
>
> Brian Gridley wrote:
| |
| Martin Kobetic 2004-04-21, 12:58 pm |
| Brian Gridley wrote:
> I need to be able to do numbers like (2 ** 1024) -1) and higher. Yes
> I saw that the problem with raisedTo: was with the ln method. Has no
> one encountered this issue before?
I myself haven't heard a complaint about this yet, and as I said this
doesn't seem to be a newly introduced limitation.
The whole problem is rather interesting, e.g. what kind of number would
you expect as the result ? A float with fixed precision and unlimited
magnitude ? Or a large int computed down to the decimal point ? For very
large integers a fixed precision float result might actually be less
precise than a fully computed large integer.
There's also the issue of rounding the result; should it be sqrt
rounded, sqrt ceiling, sqrt floor ? Note that there's also sqrtRounded
in VW, but unfortunately it falls back on sqrt for large integers. But
it hints that there are several different variants of the function that
are potentially interesting.
Anyway, given the current state of the affairs, I'd say that you're
better of thinking about all these functions (i.e. sqrt, ln,
trigonometrics) as functions applicable to LimitedPrecisionReals only.
--
Martin Kobetic, Cincom Smalltalk Development,
http://www.cincom.com/smalltalk
| |
| Eliot Miranda 2004-04-21, 3:42 pm |
| Brian Gridley wrote:
> I was trying to use VW7 for the first time. The sqrt and raisedTo:
> methods now break on large integers, as they try to convert to floats.
> A couple years ago I used VW 2.x-3.x to do raisedTo: and did not have
> this problem. Using the StMMath classes does not solve this either. Is
> the old functionality gone for good, or is it available some other
> way? I need something that works at a good speed for really big
> numbers.
The issue here is that the square root of an integer isn't necessarily
an integer, so the default implementation simply attempt to coerce the
integer to a float and compute the float's square root. This falls down
outside the float range (or Double range if you coerce to that explicitly).
If what you want is an approximate integer result you'll have to use
something like Newton-Rapheson. You have a head start because the
sqrt's highBit is between the argument's highBit and the argument's
highBit + 1. But if you want an exact result in addition you'll have to
implement an extended floating-point type so that you can compute the
square of such an extended floating point type to compare against the
argument.
Presumably the algorithms are out there. The Gnu multiple precision
library (GMP) includes a square root function, and source is freely
available.
--
_______________,,,^..^,,,____________________________
Eliot Miranda Smalltalk - Scene not herd
| |
| Branislav Sott 2004-04-21, 6:38 pm |
| I have similar problem with VW7.2NC and Linux 2.6.x.
If I run such a code:
| a b |
1 to: 10000000 do: [:i|
a := self f: -1.0.
b := self f: -1.0.
a = b ifFalse: [self halt]]
where f is:
f: net
"lambda = 2"
^ 2 / (1+ (0 - lambda * net) exp) - 1.
it will surely halt. f: should return a number between 1 and -1
(-0.761594 in this example) and sometimes answers a different number
(-1.00626 or -0.748436 or else..) or halts with 'Can''t represent the
quotient as a Float', because
(1+ (0 - lambda * net) exp)) = 6.23185e-41
isTrue.
This problem doesnt occurs with kernel 2.4.x.
Branislav Sott
Brian Gridley wrote:
> I was trying to use VW7 for the first time. The sqrt and raisedTo:
> methods now break on large integers, as they try to convert to floats.
> A couple years ago I used VW 2.x-3.x to do raisedTo: and did not have
> this problem. Using the StMMath classes does not solve this either. Is
> the old functionality gone for good, or is it available some other
> way? I need something that works at a good speed for really big
> numbers.
| |
| Brian Gridley 2004-04-27, 4:01 am |
| Actually, for these large numbers I would be happy with the integer
portion of the square root. More and more it is sounding like I will
need to write such a function...
Martin Kobetic <mkobetic@cincom.com> wrote in message news:<40869962.5000704@cincom.com>...
> Brian Gridley wrote:
>
> I myself haven't heard a complaint about this yet, and as I said this
> doesn't seem to be a newly introduced limitation.
>
> The whole problem is rather interesting, e.g. what kind of number would
> you expect as the result ? A float with fixed precision and unlimited
> magnitude ? Or a large int computed down to the decimal point ? For very
> large integers a fixed precision float result might actually be less
> precise than a fully computed large integer.
>
> There's also the issue of rounding the result; should it be sqrt
> rounded, sqrt ceiling, sqrt floor ? Note that there's also sqrtRounded
> in VW, but unfortunately it falls back on sqrt for large integers. But
> it hints that there are several different variants of the function that
> are potentially interesting.
>
> Anyway, given the current state of the affairs, I'd say that you're
> better of thinking about all these functions (i.e. sqrt, ln,
> trigonometrics) as functions applicable to LimitedPrecisionReals only.
| |
| Alan Knight 2004-04-27, 4:01 am |
| I notice that there is a SmallInteger>>sqrtRounded which claims to be
using Newton's method, although not in a very general way.
bgridle1@progressive.com (Brian Gridley) wrote in
news:e3ab068e.0404260624.254135cb@posting.google.com:
> Actually, for these large numbers I would be happy with the integer
> portion of the square root. More and more it is sounding like I will
> need to write such a function...
>
>
> Martin Kobetic <mkobetic@cincom.com> wrote in message
> news:<40869962.5000704@cincom.com>...
>
--
Alan Knight [|], Cincom Smalltalk Development
knight@acm.org
aknight@cincom.com
http://www.cincom.com/smalltalk
"I believe that many of the systems we build today in Java would be
better built in Smalltalk and Gemstone." -- Martin Fowler, JAOO 2003
|
|
|
|
|