Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2012-08

Floating point comparison with ulps precision

5 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Alexander Klenin

To fix a bug with caused by rounding errors, I have added ulps-based comparison code to TAChart in r38232.
The bug was encountered by an actual user, so I requested a merge of that code to 1.0.

However, since it depends on floating point and integer representation, it might cause problems
for users on non-Intel platforms (does somebody use TAChart on ARM?), so perhaps some kind of IFDEF is in order.
Please review.

Also, extended version of this code might be a useful addition to the FPC's math unit -
if the FPC team is interested, I'll consider working on that.

Alexander S. Klenin

Reply by email

Sven Barth
to Alexander Klenin
Alexander Klenin wrote 10 lines
To fix a bug with caused by rounding errors, I have added ulps-based comparison code to TAChart in r38232. The bug was encountered by an actual user, so I requested a merge of that code to 1.0. However, since it depends on floating point and integer representation, it might cause problems for users on non-Intel platforms (does somebody use TAChart on ARM?), so perhaps some kind of IFDEF is in order. Please review.

Yes, we do (arm-wince). In how far would I notice this change?

Also, extended version of this code might be a useful addition to the FPC's math unit - if the FPC team is interested, I'll consider working on that.

You should ask this on the fpc-devel list.

Regards,
Sven

Reply by email

Alexander Klenin
to Sven Barth
Sven Barth wrote 6 lines
> However, since it depends on floating point and integer > representation, it might cause problems > for users on non-Intel platforms (does somebody use TAChart on ARM?), > so perhaps some kind of IFDEF is in order. Yes, we do (arm-wince).

Nice. I am curious -- in what project? Does it work good?

In how far would I notice this change?

The bug which was fixed is reproduced as follows:
1) Create TChart
2) Set BottomAxis.Intervals.Options=[aipUseCount], Margins.Left=0, Margins.Right=0.
3) Try zooming around the chart. Before r38232, leftmost and rightmost marks would often disappear,
after the should be always visible.
My concern is with integer and FP representation.
IIUC, there are both big-endian and little-endian ARM versions? Are Double values always in IEEE754 format?

Alexander S. Klenin

Reply by email

Sven Barth
to Alexander Klenin
Alexander Klenin wrote 8 lines
On Tue, Aug 14, 2012 at 8:00 PM, Sven Barth wrote: >> However, since it depends on floating point and integer >> representation, it might cause problems >> for users on non-Intel platforms (does somebody use TAChart on ARM?), >> so perhaps some kind of IFDEF is in order. > > Yes, we do (arm-wince). Nice. I am curious -- in what project? Does it work good?

We are using it for a mobile client application for our desktop (Delphi) application. It's an application geared for industrial use and we use TAChart to display the trend of measurement values. The chart consists (more or less) of a line series for the trend and multiple line series for tolerance values (which can change in the lifetime of a measurement). The chart works really well and looks very nice. The zooming is a nice gimmick (which we found out by accident ;) ), though it's usage on a touchscreen device is a bit non obvious...

Show quoted text 8 lines
> In how far would I notice this change? The bug which was fixed is reproduced as follows: 1) Create TChart 2) Set BottomAxis.Intervals.Options=[aipUseCount], Margins.Left=0, Margins.Right=0. 3) Try zooming around the chart. Before r38232, leftmost and rightmost marks would often disappear, after the should be always visible.

I'll try to check this. Will take some time though.

My concern is with integer and FP representation. IIUC, there are both big-endian and little-endian ARM versions?

Yes, some of them can even be switched from big-endian to little-endian. Most ARMs seem to be little-endian though...

Are Double values always in IEEE754 format?

Sorry, I don't know.

Regards,
Sven

Reply by email

Florian Klämpfl
to Sven Barth
Sven Barth wrote 10 lines
> My concern is with integer and FP representation. > IIUC, there are both big-endian and little-endian ARM versions? Yes, some of them can even be switched from big-endian to little-endian. Most ARMs seem to be little-endian though... > Are Double values always in IEEE754 format? > Sorry, I don't know.

In general, ARM uses the IEEE754 format. Newer ones are all little endian, older ones were often big endian. FPC has defines for this: FPC_LITTLE_ENDIAN/FPC_BIG_ENDIAN

The caveats are:
- fpa (old ARM hardware fpu, seldomly implemented, today dead in practice) used a strange double format: the bytes inside the two dwords followed the endianess of the cpu, the dwords itself are big endian, i.e. first hi dword, then lo dword. If this is the case, fpc defines FPC_DOUBLE_HILO_SWAPPED
- IIRC some fpus are not fully IEEE754 compliant regarding computational results but this does not affect the formst itself

Implementing TExtended80Rec and friends properly should easily hide these issues in user code though.

Reply by email