[vwnc] Discussion on ScaledDecimal (FixedPoint in VW) ...

This discussion has been opened up on the Gemstone mail group.

I would like to see answers from the VW crowd on this too.

The key question, to summarize, is should a ScaledDecimal (FixedPoint)
value with
say 2 decimals (scale of 2) be roundedToScale at each operation.

For example, currently
    1.00s / 3.00s
gives
    numerator 1, denominator 3, scale 2
If it were to be roundedToScale it would give
    numerator 33, denominator 100, scale 2

Currently both Gemstone and VW do the former, retaining all the
information until the code
specifically asks to roundToScale.  A proposal has been put forth to
change this to do the
rounding at each action point.

Comments?

--
Dennis Smith                         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              sip:[hidden email]
Canada         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Since rounding loses information, I don't understand why round before
the final result, unless the idea is to model some lossy process?

- Dave


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
Behalf
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

That is my feeling too -- but I wanted to hear what others had to say.

Wallen, David wrote:

Since rounding loses information, I don't understand why round before
the final result, unless the idea is to model some lossy process?

- Dave


  

-----Original Message-----
From: [hidden email] [[hidden email]] On
    

Behalf
  

Of Dennis Smith
Sent: Tuesday, December 15, 2009 12:21 PM
To: VWNC,
Subject: [vwnc] Discussion on ScaledDecimal (FixedPoint in VW) ...

This discussion has been opened up on the Gemstone mail group.

I would like to see answers from the VW crowd on this too.

The key question, to summarize, is should a ScaledDecimal (FixedPoint)
value with
say 2 decimals (scale of 2) be roundedToScale at each operation.

For example, currently
    1.00s / 3.00s
gives
    numerator 1, denominator 3, scale 2
If it were to be roundedToScale it would give
    numerator 33, denominator 100, scale 2

Currently both Gemstone and VW do the former, retaining all the
information until the code
specifically asks to roundToScale.  A proposal has been put forth to
change this to do the
rounding at each action point.

Comments?

--
Dennis Smith                 		         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              <a class="moz-txt-link-freetext" href="sip:dennis@CherniakSoftware.com">sip:dennis@...
Canada			         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
    

-- 
Dennis Smith                 		         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              <a class="moz-txt-link-freetext" href="sip:dennis@CherniakSoftware.com">sip:dennis@...
Canada			         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Dennis Smith escreveu:
The present way seems more correct, since the roundToScale still employs
a Fraction to store a result and reduces the accuracy of the value
(which may lead to degeneration of the results) like for example you add
30 of these values with latter.


--
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

I think it depends on the rules used by your domain.
What do banks and financial institutions do?

Terry
 
===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Dennis Smith wrote:
> That is my feeling too -- but I wanted to hear what others had to say.
>
> Wallen, David wrote:
>> Since rounding loses information, I don't understand why round before
>> the final result, unless the idea is to model some lossy process?

If you want full precision why don't you use fractions? The current
implementation of FixedPoint does not perform fixed point calculations.
If you want to fixed point calculations, you must send #roundToScale
after each operation. My preference is to have the FixedPoint class
represent fixed point numbers and the Fraction class represent fractions.


John Brant
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Obviously, nobody wants to lose precision in "internal" calculations.
Some people like to round in "intermediate" calculations, e.g. anything
that will appear on a customer invoice. Some people prefer to keep full
precision until the very last step, e.g. the total on an invoice.

The problem to my mind is that there's no such thing in Smalltalk as an
"internal" calculation. If we make a method round its return value, it
works OK for the "intermediate rounders" if they call that method
directly, but loses precision in a way even they don't want, if it is
called indirectly (possibly many times) as part of some other method
call. Since the details of how calls are routed is private to the
implementation, and arithmetic calls get bounced around a whole lot, I'm
pretty sure we couldn't round return values.

The only way around this would be to have all the public API methods
round, and all actual calculations only happen via private methods. All
public methods could only call private methods, all private methods
could only call private methods, and all user code could only call
public methods. Not exactly an elegant solution, and certainly requiring
massive changes to existing base and user code.

Instead, I think we should stick with what we have: all methods should
maintain precision, and if you want an "intermediate" or "final" value
rounded, you explicitly round it.

Steve

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

FixedPoints are simply Fractions with a fixed precision or number of places after the decimal  If you printed the fraction (1/3) with some very large precision, it should give you 0.33....33 - just what you expect.  But if you did this with a FixedPoint having a limiting scale of 6, you would get only 0.333333, with every additional digit thereafter being zero.

I don't have a particular problem with FixedPoints doing "fractional" and not "fixed point" arithmetic since this preserves information until you have to finalize the number.  If you need the FixedPoint in finalized form, then you can send #roundToScale.

Cheers!
 
Tom Hawker
--------------------------
Senior Framework Developer
--------------------------
Home +1 (408) 274-4128
Office +1 (408) 576-6591
Mobile +1 (408) 835-3643
 
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of John Brant
Sent: Tuesday, December 15, 2009 2:29 PM
To: Dennis Smith
Cc: VWNC,
Subject: Re: [vwnc] Discussion on ScaledDecimal (FixedPoint in VW) ...

Dennis Smith wrote:
> That is my feeling too -- but I wanted to hear what others had to say.
>
> Wallen, David wrote:
>> Since rounding loses information, I don't understand why round before
>> the final result, unless the idea is to model some lossy process?

If you want full precision why don't you use fractions? The current
implementation of FixedPoint does not perform fixed point calculations.
If you want to fixed point calculations, you must send #roundToScale
after each operation. My preference is to have the FixedPoint class
represent fixed point numbers and the Fraction class represent fractions.


John Brant
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is not
intended for you, please delete it immediately unread.  The internet
cannot guarantee that this communication is free of viruses, interception
or interference and anyone who communicates with us by email is taken
to accept the risks in doing so.  Without limitation, OOCL and its affiliates
accept no liability whatsoever and howsoever arising in connection with
the use of this email.  Under no circumstances shall this email constitute
a binding agreement to carry or for provision of carriage services by OOCL,
which is subject to the availability of carrier's equipment and vessels and
the terms and conditions of OOCL's standard bill of lading which is also
available at http://www.oocl.com.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

John Brant wrote:
> If you want full precision why don't you use fractions? The current
> implementation of FixedPoint does not perform fixed point calculations.
> If you want to fixed point calculations, you must send #roundToScale
> after each operation. My preference is to have the FixedPoint class
> represent fixed point numbers and the Fraction class represent fractions.

+1

Precisely the key point. Let FixedPoint actually represent fixed point
numbers.

Regards,

-Martin
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

I think its less what a specific company does than what the rules are.
I do know that tax (canadian) allow unlimited precession until certain
points where they say "now round (or truncate) to 2 decimals".

I guess my real issue is that we need control not arbitrary rounding or
truncation -- hm! that is another point.  Some requirements say round and
other truncate -- if each ScaledDecimal was to "change" to the defined
scale -- would you round or truncate?  I would have to be able to specify that,
and with the proposed change to Gemstone I would not be able to - someone
would make some arbitrary (and thus sometimes incorrect) decision.


Terry Raymond wrote:

I think it depends on the rules used by your domain.
What do banks and financial institutions do?

Terry
 
===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

  

-----Original Message-----
From: [hidden email] [[hidden email]] On Behalf Of Dennis Smith
Sent: Tuesday, December 15, 2009 3:21 PM
To: VWNC,
Subject: [vwnc] Discussion on ScaledDecimal (FixedPoint in VW) ...

This discussion has been opened up on the Gemstone mail group.

I would like to see answers from the VW crowd on this too.

The key question, to summarize, is should a ScaledDecimal (FixedPoint)
value with
say 2 decimals (scale of 2) be roundedToScale at each operation.

For example, currently
    1.00s / 3.00s
gives
    numerator 1, denominator 3, scale 2
If it were to be roundedToScale it would give
    numerator 33, denominator 100, scale 2

Currently both Gemstone and VW do the former, retaining all the
information until the code
specifically asks to roundToScale.  A proposal has been put forth to
change this to do the
rounding at each action point.

Comments?

--
Dennis Smith                 		         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              <a class="moz-txt-link-freetext" href="sip:dennis@CherniakSoftware.com">sip:dennis@...
Canada			         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

_______________________________________________
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
  

-- 
Dennis Smith                 		         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              <a class="moz-txt-link-freetext" href="sip:dennis@CherniakSoftware.com">sip:dennis@...
Canada			         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

John Brant wrote:

Dennis Smith wrote:
  

That is my feeling too -- but I wanted to hear what others had to say.

Wallen, David wrote:
    

Since rounding loses information, I don't understand why round before
the final result, unless the idea is to model some lossy process?
      

If you want full precision why don't you use fractions? The current
implementation of FixedPoint does not perform fixed point calculations.
If you want to fixed point calculations, you must send #roundToScale
after each operation. My preference is to have the FixedPoint class
represent fixed point numbers and the Fraction class represent fractions.
  

Who decides if they should round, truncate or ceil?  Accounting practices can define any of those 3.

John Brant
  

-- 
Dennis Smith                 		         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              <a class="moz-txt-link-freetext" href="sip:dennis@CherniakSoftware.com">sip:dennis@...
Canada			         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

If you want full precision why don't you use fractions? The current

implementation of FixedPoint does not perform fixed point calculations.
If you want to fixed point calculations, you must send #roundToScale
after each operation. My preference is to have the FixedPoint class
represent fixed point numbers and the Fraction class represent fractions.
    

+1

Precisely the key point. Let FixedPoint actually represent fixed point 
numbers.

  

Yes, that makes much more sense from an engineering point of view.

FixedPoint is used a lot in the domain of control engineering and automation, especially when the target hardware only support integer computations at full speed (there is no floating point unit). Many PLCs, microcontrollers and recently FPGA's belong to this category. Here the fixedpoint is a good alternative for a floatingpoint representation of real numbers or fractions, and it is used to

1. mimic the behavior of the integer computations in design and simulation tools
2. performs the actual code for the integer computations for the target hardware

The fixedpoint number is defined with respect to a certain base (2 or 10), and contains a number of bits, and either a scale&offset or a shift. Here is a nice example of the use of fixedpoint numbers in engineering:
   
http://www.mathworks.com/products/fixed/

I hope this helps the discussion further,

Paul Weustink


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Am 16.12.2009 um 01:31 schrieb Dennis Smith:

> I guess my real issue is that we need control not arbitrary rounding  
> or
> truncation

AFAIK, fixed point numbers are intended for /representing/ monetary  
values, e.g. in a database, a report or invoice document. Their  
purpose is to prevent incorrect sums and invisible rounding issues  
that would occur if decimal rounding was applied for printing only.

I would not use them for /calculations/ at all.

Just my 2 ct.

Andre

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Andre Schnoor wrote:

Am 16.12.2009 um 01:31 schrieb Dennis Smith:

  

I guess my real issue is that we need control not arbitrary rounding  
or
truncation
    

AFAIK, fixed point numbers are intended for /representing/ monetary  
values, e.g. in a database, a report or invoice document. Their  
purpose is to prevent incorrect sums and invisible rounding issues  
that would occur if decimal rounding was applied for printing only.

I would not use them for /calculations/ at all.

Just my 2 ct.
  

So what would you use for calculations then?  Float is out, not allowed for accounting calculations,
does not leave much??

Andre

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
  

-- 
Dennis Smith                 		         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              <a class="moz-txt-link-freetext" href="sip:dennis@CherniakSoftware.com">sip:dennis@...
Canada			         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Paul Weustink wrote:

If you want full precision why don't you use fractions? The current

implementation of FixedPoint does not perform fixed point calculations.
If you want to fixed point calculations, you must send #roundToScale
after each operation. My preference is to have the FixedPoint class
represent fixed point numbers and the Fraction class represent fractions.
    

+1

Precisely the key point. Let FixedPoint actually represent fixed point 
numbers.
    

That requires that you know in the code what the scale is -- if you are doing complex calculations and the
scale might not be just 2 (as in many $ amount calculations) the scale should be kept as part of the value
as in FixedPoint/ScaledDecimal

Yes, that makes much more sense from an engineering point of view.

FixedPoint is used a lot in the domain of control engineering and automation, especially when the target hardware only support integer computations at full speed (there is no floating point unit). Many PLCs, microcontrollers and recently FPGA's belong to this category. Here the fixedpoint is a good alternative for a floatingpoint representation of real numbers or fractions, and it is used to

1. mimic the behavior of the integer computations in design and simulation tools
2. performs the actual code for the integer computations for the target hardware

The fixedpoint number is defined with respect to a certain base (2 or 10), and contains a number of bits, and either a scale&offset or a shift. Here is a nice example of the use of fixedpoint numbers in engineering:
   
http://www.mathworks.com/products/fixed/

I hope this helps the discussion further,

Paul Weustink

--

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
  

-- 
Dennis Smith                 		         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              <a class="moz-txt-link-freetext" href="sip:dennis@CherniakSoftware.com">sip:dennis@...
Canada			         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Am 16.12.2009 um 13:59 schrieb Dennis Smith:

I'm using Double to calculate (e.g. mortgage, taxes, ROI, stock  
dilution, revenue splits), then represent the final result as fixed  
point.

Doing math with fixed point as the intermediate format adds up  
rounding errors.

Andre

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

It seems to me that the entire discussion here boils down to the VisualWorks FixedPoint class being poorly named. What it does is useful functionality, but it's not really fixed point, and there isn't anything in VisualWorks that does do real fixed point as far as I know. As John Brant said, one can just use fractions for indefinite precision, and that's really all that class is - a wrapper around fractions. To do real fixed point,  you just use integers, so a wrapper around integers would accompish the same sort of thing. And then the only worry would be all the people using the existing class who weren't expecting it to go from essentially infinite precision to extremely limited precision. Or we could name it ReallyFixedPoint :-)



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Andre Schnoor wrote: Hope you don't get an audit by a knowledgeable accountant -- they won't
accept it.
Floats (and Doubles) have issues with accuracy in accounting -- that is
why we have
various forms of FixedPoint (ScaledDecimal).  Most databases provide a
storage and even
a computational form of  Decimal values to handle those cases.
>
> Andre
>

--
Dennis Smith                         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              sip:[hidden email]
Canada         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Wouldn't ScaledDecimal be a good name?
Maybe not, since a ScaledDecimal is the equivalent of FixedPoint in
other Smalltalk dialects...

Am 16.12.09 23:40, schrieb Alan Knight:
> As John Brant said, one can just use fractions for indefinite precision,
> and that's really all that class is - a wrapper around fractions. To do
> real fixed point,  you just use integers, so a wrapper around integers
> would accompish the same sort of thing. And then the only worry would be
> all the people using the existing class who weren't expecting it to go
> from essentially infinite precision to extremely limited precision. Or
> we could name it ReallyFixedPoint :-)
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

I disagree -- if you actually USE FixedPoint (I don't care what you call it) -- it does exactly what is
required for accounting apps -- and I have been working with Accounting and Payroll for about 12 years now.

We do large A/R, A/P, G/L and Payroll apps -- and we need exactly what FixedPoint provides.

At various points one has to Round or Truncate (or Ceil) based on what you are doing, and you need
control over when it occurs.  Having it arbitrarily round at each operation would make it useless to us and
we would then have to create out own.

Whoever designed this in VW new what they were doing.


Alan Knight wrote:

It seems to me that the entire discussion here boils down to the VisualWorks FixedPoint class being poorly named. What it does is useful functionality, but it's not really fixed point, and there isn't anything in VisualWorks that does do real fixed point as far as I know. As John Brant said, one can just use fractions for indefinite precision, and that's really all that class is - a wrapper around fractions. To do real fixed point,  you just use integers, so a wrapper around integers would accompish the same sort of thing. And then the only worry would be all the people using the existing class who weren't expecting it to go from essentially infinite precision to extremely limited precision. Or we could name it ReallyFixedPoint :-)

--

Alan Knight [|], Engineering Manager, Cincom Smalltalk

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
  

-- 
Dennis Smith                 		         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              <a class="moz-txt-link-freetext" href="sip:dennis@CherniakSoftware.com">sip:dennis@...
Canada			         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc