Senders of #asLimitedPrecisionReal

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Senders of #asLimitedPrecisionReal

federico.mennite@lifeware.ch
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
Reply | Threaded
Open this post in threaded view
|

Re: Senders of #asLimitedPrecisionReal

Andres Valloud-6
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
Reply | Threaded
Open this post in threaded view
|

Re: Senders of #asLimitedPrecisionReal

federico.mennite@lifeware.ch
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
Reply | Threaded
Open this post in threaded view
|

Re: Senders of #asLimitedPrecisionReal

federico.mennite@lifeware.ch
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
Reply | Threaded
Open this post in threaded view
|

Re: Senders of #asLimitedPrecisionReal

Andres Valloud-6
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
Reply | Threaded
Open this post in threaded view
|

Re: Senders of #asLimitedPrecisionReal

Dave & Vicki Stevenson
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
Reply | Threaded
Open this post in threaded view
|

Re: Senders of #asLimitedPrecisionReal

Björn Eiderbäck-2
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:
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



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Senders of #asLimitedPrecisionReal

federico.mennite@lifeware.ch
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
Reply | Threaded
Open this post in threaded view
|

Re: Senders of #asLimitedPrecisionReal

cdavidshaffer
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