[Oberon] real math

[Jörg Straube]

Rob

It depends on the version of Oberon you're looking at.

In Oberon-2 there are five numeric types forming a hierarchy
  LONGREAL >= REAL >= LONGINT >= INTEGER >= SHORTINT.
  The division operator / always results in a real type:
  If one operand is LONGREAL the result is LONGREAL, in all other cases the result is REAL.
  480 / 100 results in 4.8 (REAL)     480.D0 / 100 results in 4.8 (LONGREAL)

In Oberon-07 that's different.
  Numeric types don't build a hierarchy and the operands of / have to have the same type.
  480 / 100 results in 4 (INTEGER)    480. / 100. result in 4.8 (REAL)

br, Jörg

> Am 12.11.2014 um 02:18 schrieb rob solomon <drrob106 at verizon.net>:
> 
> Not knowing much about oberon, but I have use modula-2 for many years.  I have one observation.
> 
> r := 480 / 100 * 100;
> 
> In modula-2, this line would not be allowed, as it is doing integer arithmetic, getting an integer result, and they trying to assign this integer result to a real number.
> 
> Is oberon less type-strict?  Is oberon more like C and Fortran in this way?
> 
> 
> 
>> On 11/11/2014 11:15 AM, Felix Friedrich wrote:
>> Dear all,
>> 
>> with respect to the differences you observe I would like to point out that the variant of the underlying hardware and compiler also play an important role. In addition to the floating point standard. And also in addition to possible compiler optimisations.
>> 
>> Example: one compiler (e.g. older AOS compiler) may still emit code for the FPU, which internally works with 80 bit precision. The results are only truncated to 32 bit when writing back to a general purpose register. So no loss of precision during expression computation. On newer machines the same task is usually computed on the SSE unit with 32-bit precision and the precision is lost during computation already.
>> 
>> So, there is nothing wrong with any of the implementations but there are just implementation specific differences. Still, the principles of "What Every Computer Scientist Should Know About Floating-Point Arithmetic" do apply.
>> 
>> Best regards
>> Felix 
>> 
>> 
>> 
>> 
>>> On 11.11.2014 15:50, Yaroslav Romanchenko wrote:
>>> 
>>> How many right suggestions. But... anyway something wrong with real math in Oberon implementation, because same example in BlackBox returns yet another result expected by Zdenek.
>>> 
>>> Code:
>>> MODULE M1;
>>> 
>>> IMPORT
>>> StdLog;
>>> 
>>> PROCEDURE Do*;
>>> VAR
>>> r: REAL;
>>> BEGIN
>>> r := 480 / 100 * 100;
>>> StdLog.Int(ENTIER(r * 1000000));
>>> StdLog.Ln;
>>> END Do;
>>> 
>>> BEGIN
>>> END M1.
>>> Output:
>>> 480000000
>>> Same result as BlackBox returned in commercial Embarcadero RAD Studio using type corresponding single type.
>>> 
>>> ---
>>> Cheers, SAGE
>>> http://sage.com.ua/
>>> 
>>> 
>>> --
>>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>> 
>> 
>> 
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/oberon/attachments/20141112/c6fa0574/attachment.html