Senders of #asLimitedPrecisionReal
Locked
Senders of #asLimitedPrecisionReal
 
|
Hi,
Some mathematical functions currently make use of #asLimitedPrecisionReal. basically ending operations on Fractions in results that aren't accurate enough in our environment. This beacuse because instances of Float are used by default. examples: (3/4) raisedTo: (4/3) or (3 /4) sqrt The obvious solution here would be to simply convert into instances of Double before attempting the mathematical operation. However we only need to work with instances of Fraction or Double and it would be nice to avoid forgetting the usage of #asDouble before any math. I realize that the ANSI Smalltalk spec suggests/mandates conversions to Floats but I wanted to hear any comments on this topic. Thanks and Regards, Federico _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Senders of #asLimitedPrecisionReal
|
|
Have you considered subclassing Fraction according to your specific needs?
On 1/25/13 8:14 AM, Federico Mennite wrote: > Hi, > Some mathematical functions currently make use of > #asLimitedPrecisionReal. basically ending operations on Fractions in > results that aren't accurate enough in our environment. This beacuse > because instances of Float are used by default. examples: (3/4) > raisedTo: (4/3) or (3 /4) sqrt > > The obvious solution here would be to simply convert into instances of > Double before attempting the mathematical operation. > However we only need to work with instances of Fraction or Double and it > would be nice to avoid forgetting the usage of #asDouble before any math. > > I realize that the ANSI Smalltalk spec suggests/mandates conversions to > Floats but I wanted to hear any comments on this topic. > > Thanks and Regards, > Federico > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Senders of #asLimitedPrecisionReal
|
|
Yes. That could be a path to explore. That would also require to change
some of the methods referring to class Fraction in the base image. I see 2 issues here: - are there any primitives that return instances of Fraction? #/ and other methods wisely seem not to be doing this. So we are probably ok with that. - would there be any side effects for other base components such as graphics functions, etc? Thanks for comments, Federico On 25.01.2013 17:19, Andres Valloud wrote: > Have you considered subclassing Fraction according to your specific > needs? > > On 1/25/13 8:14 AM, Federico Mennite wrote: >> Hi, >> Some mathematical functions currently make use of >> #asLimitedPrecisionReal. basically ending operations on Fractions in >> results that aren't accurate enough in our environment. This beacuse >> because instances of Float are used by default. examples: (3/4) >> raisedTo: (4/3) or (3 /4) sqrt >> >> The obvious solution here would be to simply convert into instances of >> Double before attempting the mathematical operation. >> However we only need to work with instances of Fraction or Double and it >> would be nice to avoid forgetting the usage of #asDouble before any >> math. >> >> I realize that the ANSI Smalltalk spec suggests/mandates conversions to >> Floats but I wanted to hear any comments on this topic. >> >> Thanks and Regards, >> Federico >> >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Senders of #asLimitedPrecisionReal
|
|
Sorry my post wasn't complete.
It seems to me that changing the implementation of Number>>asLimitedPrecisionReal to return Double has the same side effect risks than subclassing but with a simpler change to the base image. Regards, Federico On 28.01.2013 12:44, Federico Mennite wrote: > Yes. That could be a path to explore. That would also require to > change some of the methods referring to class Fraction in the base image. > I see 2 issues here: > - are there any primitives that return instances of Fraction? #/ and > other methods wisely seem not to be doing this. So we are probably ok > with that. > - would there be any side effects for other base components such as > graphics functions, etc? > > Thanks for comments, > Federico > > > On 25.01.2013 17:19, Andres Valloud wrote: >> Have you considered subclassing Fraction according to your specific >> needs? >> >> On 1/25/13 8:14 AM, Federico Mennite wrote: >>> Hi, >>> Some mathematical functions currently make use of >>> #asLimitedPrecisionReal. basically ending operations on Fractions in >>> results that aren't accurate enough in our environment. This beacuse >>> because instances of Float are used by default. examples: (3/4) >>> raisedTo: (4/3) or (3 /4) sqrt >>> >>> The obvious solution here would be to simply convert into instances of >>> Double before attempting the mathematical operation. >>> However we only need to work with instances of Fraction or Double >>> and it >>> would be nice to avoid forgetting the usage of #asDouble before any >>> math. >>> >>> I realize that the ANSI Smalltalk spec suggests/mandates conversions to >>> Floats but I wanted to hear any comments on this topic. >>> >>> Thanks and Regards, >>> Federico >>> >>> >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email] >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Senders of #asLimitedPrecisionReal
|
|
That would change the behavior of the whole system, instead of
implementing the specific functionality you need so that it can be used in a scoped manner. On 1/28/13 5:37 AM, Federico Mennite wrote: > Sorry my post wasn't complete. > > It seems to me that changing the implementation of > Number>>asLimitedPrecisionReal to return Double has the same side effect > risks than subclassing but with a simpler change to the base image. > > Regards, > Federico > > > > On 28.01.2013 12:44, Federico Mennite wrote: >> Yes. That could be a path to explore. That would also require to >> change some of the methods referring to class Fraction in the base image. >> I see 2 issues here: >> - are there any primitives that return instances of Fraction? #/ and >> other methods wisely seem not to be doing this. So we are probably ok >> with that. >> - would there be any side effects for other base components such as >> graphics functions, etc? >> >> Thanks for comments, >> Federico >> >> >> On 25.01.2013 17:19, Andres Valloud wrote: >>> Have you considered subclassing Fraction according to your specific >>> needs? >>> >>> On 1/25/13 8:14 AM, Federico Mennite wrote: >>>> Hi, >>>> Some mathematical functions currently make use of >>>> #asLimitedPrecisionReal. basically ending operations on Fractions in >>>> results that aren't accurate enough in our environment. This beacuse >>>> because instances of Float are used by default. examples: (3/4) >>>> raisedTo: (4/3) or (3 /4) sqrt >>>> >>>> The obvious solution here would be to simply convert into instances of >>>> Double before attempting the mathematical operation. >>>> However we only need to work with instances of Fraction or Double >>>> and it >>>> would be nice to avoid forgetting the usage of #asDouble before any >>>> math. >>>> >>>> I realize that the ANSI Smalltalk spec suggests/mandates conversions to >>>> Floats but I wanted to hear any comments on this topic. >>>> >>>> Thanks and Regards, >>>> Federico >>>> >>>> >>>> _______________________________________________ >>>> vwnc mailing list >>>> [hidden email] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>>> >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email] >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Senders of #asLimitedPrecisionReal
|
|
In reply to this post by federico.mennite@lifeware.ch
Have you considered the use of FixedPoint? Internally the value is represented by a fraction to preserve accuracy, but it prints itself as a limited precision real (with an annoying 's' suffix). Dave Stevenson[hidden email] From: Federico Mennite <[hidden email]> To: "[hidden email]" <[hidden email]> Sent: Mon, January 28, 2013 3:46:10 AM Subject: Re: [vwnc] Senders of #asLimitedPrecisionReal Yes. That could be a path to explore. That would also require to change some of the methods referring to class Fraction in the base image. I see 2 issues here: - are there any primitives that return instances of Fraction? #/ and other methods wisely seem not to be doing this. So we are probably ok with that. - would there be any side effects for other base components such as graphics functions, etc? Thanks for comments, Federico On 25.01.2013 17:19, Andres Valloud wrote: > Have you considered subclassing Fraction according to your specific needs? > > On 1/25/13 8:14 AM, Federico Mennite wrote: >> Hi, >> Some mathematical functions currently make use of >> #asLimitedPrecisionReal. basically ending operations on Fractions in >> results that aren't accurate enough in our environment. This beacuse >> because instances of Float are used by default. examples: (3/4) >> raisedTo: (4/3) or (3 /4) sqrt >> >> The obvious solution here would be to simply convert into instances of >> Double before attempting the mathematical operation. >> However we only need to work with instances of Fraction or Double and it >> would be nice to avoid forgetting the usage of #asDouble before any math. >> >> I realize that the ANSI Smalltalk spec suggests/mandates conversions to >> Floats but I wanted to hear any comments on this topic. >> >> Thanks and Regards, >> Federico >> >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Senders of #asLimitedPrecisionReal
|
|
But FixedPoint does not preserve precision for sqrt, etc.
E.g. 2s100 sqrt answers 1.41421 I made a simple test a few years ago and wrote a FixedPoint>>sqrt by means of Newton-Raphson FixedPoint>>sqrt ..."Answer the square root of the receiver." ...| xn xold lim | ...xn := self sqrtFloor asFixedPoint: scale. ...xold := self. ...lim := (10 ** xn scale) reciprocal. ...[(xold - xn) abs > lim] whileTrue: .........[xold := xn. .........xn := (xn + (self / xn)) / 2]. ...^xn With this fix the answer to 2s100 sqrt is 1.4142135623730950488016887242096980785696718753769480731766797379907324784621070388503875343276415727s Björn On Mon, Jan 28, 2013 at 5:37 PM, Dave & Vicki Stevenson <[hidden email]> wrote:
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Senders of #asLimitedPrecisionReal
|
|
In reply to this post by Andres Valloud-6
I realize that,
However I think that in our environment this scope is going to be very large. Anyway thanks to everyone who spent some time commenting. Regards, Federico On 28.01.2013 17:28, Andres Valloud wrote: > That would change the behavior of the whole system, instead of > implementing the specific functionality you need so that it can be > used in a scoped manner. > > On 1/28/13 5:37 AM, Federico Mennite wrote: >> Sorry my post wasn't complete. >> >> It seems to me that changing the implementation of >> Number>>asLimitedPrecisionReal to return Double has the same side effect >> risks than subclassing but with a simpler change to the base image. >> >> Regards, >> Federico >> >> >> >> On 28.01.2013 12:44, Federico Mennite wrote: >>> Yes. That could be a path to explore. That would also require to >>> change some of the methods referring to class Fraction in the base >>> image. >>> I see 2 issues here: >>> - are there any primitives that return instances of Fraction? #/ and >>> other methods wisely seem not to be doing this. So we are probably ok >>> with that. >>> - would there be any side effects for other base components such as >>> graphics functions, etc? >>> >>> Thanks for comments, >>> Federico >>> >>> >>> On 25.01.2013 17:19, Andres Valloud wrote: >>>> Have you considered subclassing Fraction according to your specific >>>> needs? >>>> >>>> On 1/25/13 8:14 AM, Federico Mennite wrote: >>>>> Hi, >>>>> Some mathematical functions currently make use of >>>>> #asLimitedPrecisionReal. basically ending operations on Fractions in >>>>> results that aren't accurate enough in our environment. This beacuse >>>>> because instances of Float are used by default. examples: (3/4) >>>>> raisedTo: (4/3) or (3 /4) sqrt >>>>> >>>>> The obvious solution here would be to simply convert into >>>>> instances of >>>>> Double before attempting the mathematical operation. >>>>> However we only need to work with instances of Fraction or Double >>>>> and it >>>>> would be nice to avoid forgetting the usage of #asDouble before any >>>>> math. >>>>> >>>>> I realize that the ANSI Smalltalk spec suggests/mandates >>>>> conversions to >>>>> Floats but I wanted to hear any comments on this topic. >>>>> >>>>> Thanks and Regards, >>>>> Federico >>>>> >>>>> >>>>> _______________________________________________ >>>>> vwnc mailing list >>>>> [hidden email] >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>>>> >>>> _______________________________________________ >>>> vwnc mailing list >>>> [hidden email] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>> >>> >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email] >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Senders of #asLimitedPrecisionReal
|
|
In reply to this post by federico.mennite@lifeware.ch
On 01/28/13 08:37, Federico Mennite wrote:
> Sorry my post wasn't complete. > > It seems to me that changing the implementation of > Number>>asLimitedPrecisionReal to return Double has the same side > effect risks than subclassing but with a simpler change to the base > image. > > Regards, > Federico This is what the "Numerical Methods" package in the public repository does. I use this package quite a bit and have never had a problem with this change. This seems to be an area where VW is showing its age...literals like 3.2 should produce doubles and numerical operations should convert to doubles when needed. I would be surprised (well, not entirely) if anyone out there still needs "single precision" (IEEE 754-binary32) values as pervasively as they need doubles. David _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |