On 11/10/21 8:14 AM, Howerd Oakford wrote:
> On Tuesday, November 9, 2021 at 4:03:48 PM UTC+1, Öö Tiib wrote:
>> On Monday, 8 November 2021 at 19:56:23 UTC+2, how...@gmail.com wrote:
....
>>> In the actual system we have to store both latitude and longitude for several thousand points, so I don't really want to use uint64_t and manually do a 32 bit modulus...
>> Further distraction. If you need distances then converting from
>> spherical coordinates to Euclidian takes quite a trigonometry
>> and int32_t is not what one is using there. Use double.
>
> Hi Öö Tiib,
>
> My understanding is that you must scale the longitude difference by the cosine of the latitude, to first order.
> Is there something I am missing here ?

If you project the two points of interest to you onto a cylinder whose
axis coincides the with line between the north and south poles of the
earth, that approach will give you the length of the shortest path, on
that cylinder, between those two points. The size of that cylinder
depends upon which of the two latitudes you are taking the cosine of.

If d is the length in radians of the shortest path on the surface of the
Earth connecting those two points (ignoring the fact that the earth
isn't spherical), and those two points have latitudes lat1 and lat2, and
the difference in longitude between those two points is dlon, then

cos(d) = sin(lat1)*sin(lat2) - cos(lat1)*cos(lat2)*cos(dlon);

You'll have to solve that equation for d, and resolve the ambiguity due
to the fact that, for an give value of x between -1 and 1, there's two
different d's that satisfy cos(d) = x.

Notice that wrap-around it handled automatically by the fact that every
angle is used as an argument to a periodic trig function - there's no
need to worry about it explicitly.

On 10/11/2021 13:14, Howerd Oakford wrote:
> On Tuesday, November 9, 2021 at 4:03:48 PM UTC+1, Öö Tiib wrote:
>> On Monday, 8 November 2021 at 19:56:23 UTC+2, how...@gmail.com wrote:
>>> Hi C-folks,
>>>
>>> Following the extremely helpful responses to my last question, I would like to ask another one :
>>> I have a signed variable int32_t Latitude that represents the latitude on Earth, from -180 degrees West to 179.9999... degrees East.
>> What strange discussion you have here guys? What West what East?
>> Geodetic latitude: the angle between the normal and the equatorial plane.
>> So latitude can't be bigger than 90° (North pole) nor smaller than -90° (South pole).
>>> Since we are using an ARM64 processor and GCC cross compiler, the system is conventional two's complement.
>>>
>>> So is it OK, (with a comment to appease MISRA), to use the actual behaviour of the processor to wraparound (overflow?) from 179.99999... to -180 degrees?
>>>
>>> If not, is it OK to drop down to ARM assembler to avoid the "undefined behaviour" of C?
>>>
>>> In the actual system we have to store both latitude and longitude for several thousand points, so I don't really want to use uint64_t and manually do a 32 bit modulus...
>> Further distraction. If you need distances then converting from
>> spherical coordinates to Euclidian takes quite a trigonometry
>> and int32_t is not what one is using there. Use double.
>
> Hi Öö Tiib,
>
> My understanding is that you must scale the longitude difference by the cosine of the latitude, to first order.
> Is there something I am missing here ?

What you're missing is, how will you do such calculations using a scaled
integer value?

What type do you think cos() takes, and returns?

You will need to convert your uint32 value: scale it down by about 11.93
million, to get it to degrees, then by about 57.3 to get it to radians,
before you can pass it to cos().

The return value of cos() will be -1.0 to +1.0; a double (and maybe
negative).

You need to consider whether the considerable trouble of using a scaled
integer is worth it.

On 11/10/21 8:14 AM, Howerd Oakford wrote:
> On Tuesday, November 9, 2021 at 4:03:48 PM UTC+1, Öö Tiib wrote:
>> On Monday, 8 November 2021 at 19:56:23 UTC+2, how...@gmail.com wrote:
>>> Hi C-folks,
>>>
>>> Following the extremely helpful responses to my last question, I would like to ask another one :
>>> I have a signed variable int32_t Latitude that represents the latitude on Earth, from -180 degrees West to 179.9999... degrees East.
>> What strange discussion you have here guys? What West what East?
>> Geodetic latitude: the angle between the normal and the equatorial plane.
>> So latitude can't be bigger than 90° (North pole) nor smaller than -90° (South pole).
>>> Since we are using an ARM64 processor and GCC cross compiler, the system is conventional two's complement.
>>>
>>> So is it OK, (with a comment to appease MISRA), to use the actual behaviour of the processor to wraparound (overflow?) from 179.99999... to -180 degrees?
>>>
>>> If not, is it OK to drop down to ARM assembler to avoid the "undefined behaviour" of C?
>>>
>>> In the actual system we have to store both latitude and longitude for several thousand points, so I don't really want to use uint64_t and manually do a 32 bit modulus...
>> Further distraction. If you need distances then converting from
>> spherical coordinates to Euclidian takes quite a trigonometry
>> and int32_t is not what one is using there. Use double.
>
> Hi Öö Tiib,
>
> My understanding is that you must scale the longitude difference by the cosine of the latitude, to first order.
> Is there something I am missing here ?
>
> Cheers,
> Howerd
>

No, that doesn't work.

if the two points are on the same latitude, that will give you the
length of the path that follows that line of latitude between the two
points.

If the longitude difference is significant, then there can be a
significantly shorter route that follows a 'great circle' route that
follow the real straight line between the points.

At the extreme of 180 degrees of latitude difference, the shortest line
goes straight over the pole to the other side.

On 11/10/2021 7:37 AM, James Kuyper wrote:
> On 11/10/21 8:14 AM, Howerd Oakford wrote:
>> On Tuesday, November 9, 2021 at 4:03:48 PM UTC+1, Öö Tiib wrote:
>>> On Monday, 8 November 2021 at 19:56:23 UTC+2, how...@gmail.com wrote:
> ...
>>>> In the actual system we have to store both latitude and longitude for several thousand points, so I don't really want to use uint64_t and manually do a 32 bit modulus...
>>> Further distraction. If you need distances then converting from
>>> spherical coordinates to Euclidian takes quite a trigonometry
>>> and int32_t is not what one is using there. Use double.
>>
>> Hi Öö Tiib,
>>
>> My understanding is that you must scale the longitude difference by the cosine of the latitude, to first order.
>> Is there something I am missing here ?
>
> If you project the two points of interest to you onto a cylinder whose
> axis coincides the with line between the north and south poles of the
> earth, that approach will give you the length of the shortest path, on
> that cylinder, between those two points. The size of that cylinder
> depends upon which of the two latitudes you are taking the cosine of.

For some reason this is reminding me of a distance estimated cylinder
using a ray marcher.

>
> If d is the length in radians of the shortest path on the surface of the
> Earth connecting those two points (ignoring the fact that the earth
> isn't spherical), and those two points have latitudes lat1 and lat2, and
> the difference in longitude between those two points is dlon, then
>
> cos(d) = sin(lat1)*sin(lat2) - cos(lat1)*cos(lat2)*cos(dlon);
>
> You'll have to solve that equation for d, and resolve the ambiguity due
> to the fact that, for an give value of x between -1 and 1, there's two
> different d's that satisfy cos(d) = x.
>
> Notice that wrap-around it handled automatically by the fact that every
> angle is used as an argument to a periodic trig function - there's no
> need to worry about it explicitly.
>

Am 08.11.2021 um 18:56 schrieb Howerd Oakford:
> Hi C-folks,
>
> Following the extremely helpful responses to my last question, I would like to ask another one :
> I have a signed variable int32_t Latitude that represents the latitude on Earth, from -180 degrees West to 179.9999... degrees East.
>
> Since we are using an ARM64 processor and GCC cross compiler, the system is conventional two's complement.
>
> So is it OK, (with a comment to appease MISRA), to use the actual behaviour of the processor to wraparound (overflow?) from 179.99999... to -180 degrees?
>
> If not, is it OK to drop down to ARM assembler to avoid the "undefined behaviour" of C?
>
> In the actual system we have to store both latitude and longitude for several thousand points, so I don't really want to use uint64_t and manually do a 32 bit modulus...
>
> Cheers,
> Howerd

Look at this code:

bool f( int i )
{ return (int)((unsigned)i + 1u) < i;
}

Although g++ optimizes away signed overflows if the unsigned-casts would
be omitted here, the upper overflow check works. Casting negative values
to an unsigned value is UB, but you can rely on the upper code to work
because there are almost no computers today that use something different
than 2's complement values.

This is the code you will get:

cmpl $2147483647, %edi ; 0x7FFFFFFF
sete %al
ret

On Wednesday, November 10, 2021 at 4:49:14 PM UTC+1, Bart wrote:
> On 10/11/2021 13:14, Howerd Oakford wrote:
> > On Tuesday, November 9, 2021 at 4:03:48 PM UTC+1, Öö Tiib wrote:
> >> On Monday, 8 November 2021 at 19:56:23 UTC+2, how...@gmail.com wrote:
> >>> Hi C-folks,
> >>>
> >>> Following the extremely helpful responses to my last question, I would like to ask another one :
> >>> I have a signed variable int32_t Latitude that represents the latitude on Earth, from -180 degrees West to 179.9999... degrees East.
> >> What strange discussion you have here guys? What West what East?
> >> Geodetic latitude: the angle between the normal and the equatorial plane.
> >> So latitude can't be bigger than 90° (North pole) nor smaller than -90° (South pole).
> >>> Since we are using an ARM64 processor and GCC cross compiler, the system is conventional two's complement.
> >>>
> >>> So is it OK, (with a comment to appease MISRA), to use the actual behaviour of the processor to wraparound (overflow?) from 179.99999... to -180 degrees?
> >>>
> >>> If not, is it OK to drop down to ARM assembler to avoid the "undefined behaviour" of C?
> >>>
> >>> In the actual system we have to store both latitude and longitude for several thousand points, so I don't really want to use uint64_t and manually do a 32 bit modulus...
> >> Further distraction. If you need distances then converting from
> >> spherical coordinates to Euclidian takes quite a trigonometry
> >> and int32_t is not what one is using there. Use double.
> >
> > Hi Öö Tiib,
> >
> > My understanding is that you must scale the longitude difference by the cosine of the latitude, to first order.
> > Is there something I am missing here ?
> What you're missing is, how will you do such calculations using a scaled
> integer value?
>
> What type do you think cos() takes, and returns?
>
> You will need to convert your uint32 value: scale it down by about 11.93
> million, to get it to degrees, then by about 57.3 to get it to radians,
> before you can pass it to cos().
>
> The return value of cos() will be -1.0 to +1.0; a double (and maybe
> negative).
>
> You need to consider whether the considerable trouble of using a scaled
> integer is worth it.

Hi Bart,

> What you're missing is, how will you do such calculations using a scaled
> integer value?
My plan is to use Hart's approximation for cosine to create a pair of values and multiply/divide the input by them.
I have always thought that trig functions are best handled as pairs of numbers.

The application that I am working on is speed-critical, so I might use floats if it is faster on an ARM64.

Cheers,
Howerd

On Wednesday, November 10, 2021 at 4:38:09 PM UTC+1, james...@alumni.caltech.edu wrote:
> On 11/10/21 8:14 AM, Howerd Oakford wrote:
> > On Tuesday, November 9, 2021 at 4:03:48 PM UTC+1, Öö Tiib wrote:
> >> On Monday, 8 November 2021 at 19:56:23 UTC+2, how...@gmail.com wrote:
> ...
> >>> In the actual system we have to store both latitude and longitude for several thousand points, so I don't really want to use uint64_t and manually do a 32 bit modulus...
> >> Further distraction. If you need distances then converting from
> >> spherical coordinates to Euclidian takes quite a trigonometry
> >> and int32_t is not what one is using there. Use double.
> >
> > Hi Öö Tiib,
> >
> > My understanding is that you must scale the longitude difference by the cosine of the latitude, to first order.
> > Is there something I am missing here ?
> If you project the two points of interest to you onto a cylinder whose
> axis coincides the with line between the north and south poles of the
> earth, that approach will give you the length of the shortest path, on
> that cylinder, between those two points. The size of that cylinder
> depends upon which of the two latitudes you are taking the cosine of.
>
> If d is the length in radians of the shortest path on the surface of the
> Earth connecting those two points (ignoring the fact that the earth
> isn't spherical), and those two points have latitudes lat1 and lat2, and
> the difference in longitude between those two points is dlon, then
>
> cos(d) = sin(lat1)*sin(lat2) - cos(lat1)*cos(lat2)*cos(dlon);
>
> You'll have to solve that equation for d, and resolve the ambiguity due
> to the fact that, for an give value of x between -1 and 1, there's two
> different d's that satisfy cos(d) = x.
>
> Notice that wrap-around it handled automatically by the fact that every
> angle is used as an argument to a periodic trig function - there's no
> need to worry about it explicitly.

Hi James,

The task is to calculate the linear distance between two points given their latitude and longitude, over small distances.

I am only interested in a very limited range (a few 100's of metres), on the Earth's surface.

At this scale, I think, that you can map the polar surface to a flat surface, and convert the longitude distance to linear distance using the latitude..
The latitude difference, dLat in degrees, maps to the length of the straight line distance between the two points :
dX = dLat * ( Earth's_Circumference / 360 )
The longitude difference, dLon in degrees, is the same except, that as the latitude gets higher the circle round the Earth gets smaller, so must be scaled down :
dY = dLon * ( Earth's_Circumference / 360 ) * cosine( Lat )
( I wish I could draw a picture here - it would save a thousand words ;-)

LinearDistance = sqrt( (dX*dX) + (dY*dY ) ) // Pythagorous

Thanks for your response,

Cheers,
Howerd

On Thursday, November 11, 2021 at 2:19:39 AM UTC+1, Richard Damon wrote:
> On 11/10/21 8:14 AM, Howerd Oakford wrote:
> > On Tuesday, November 9, 2021 at 4:03:48 PM UTC+1, Öö Tiib wrote:
> >> On Monday, 8 November 2021 at 19:56:23 UTC+2, how...@gmail.com wrote:
> >>> Hi C-folks,
> >>>
> >>> Following the extremely helpful responses to my last question, I would like to ask another one :
> >>> I have a signed variable int32_t Latitude that represents the latitude on Earth, from -180 degrees West to 179.9999... degrees East.
> >> What strange discussion you have here guys? What West what East?
> >> Geodetic latitude: the angle between the normal and the equatorial plane.
> >> So latitude can't be bigger than 90° (North pole) nor smaller than -90° (South pole).
> >>> Since we are using an ARM64 processor and GCC cross compiler, the system is conventional two's complement.
> >>>
> >>> So is it OK, (with a comment to appease MISRA), to use the actual behaviour of the processor to wraparound (overflow?) from 179.99999... to -180 degrees?
> >>>
> >>> If not, is it OK to drop down to ARM assembler to avoid the "undefined behaviour" of C?
> >>>
> >>> In the actual system we have to store both latitude and longitude for several thousand points, so I don't really want to use uint64_t and manually do a 32 bit modulus...
> >> Further distraction. If you need distances then converting from
> >> spherical coordinates to Euclidian takes quite a trigonometry
> >> and int32_t is not what one is using there. Use double.
> >
> > Hi Öö Tiib,
> >
> > My understanding is that you must scale the longitude difference by the cosine of the latitude, to first order.
> > Is there something I am missing here ?
> >
> > Cheers,
> > Howerd
> >
> No, that doesn't work.
>
> if the two points are on the same latitude, that will give you the
> length of the path that follows that line of latitude between the two
> points.
>
> If the longitude difference is significant, then there can be a
> significantly shorter route that follows a 'great circle' route that
> follow the real straight line between the points.
>
> At the extreme of 180 degrees of latitude difference, the shortest line
> goes straight over the pole to the other side.

Hi Richard,

Sorry - I didn't make it clear that this only has to work over a range of a few 100 metres!

Cheers,
Howerd

On Thu, 11 Nov 2021 14:30:31 -0800, Howerd Oakford wrote:

> On Thursday, November 11, 2021 at 2:19:39 AM UTC+1, Richard Damon wrote:
[snip]
>> If the longitude difference is significant, then there can be a
>> significantly shorter route that follows a 'great circle' route that
>> follow the real straight line between the points.
>>
>> At the extreme of 180 degrees of latitude difference, the shortest line
>> goes straight over the pole to the other side.
>
> Hi Richard,
>
> Sorry - I didn't make it clear that this only has to work over a range
> of a few 100 metres!
>
> Cheers,
> Howerd

Have you looked at haversines yet?
(https://en.wikipedia.org/wiki/Haversine_formula
See also:
https://www.movable-type.co.uk/scripts/gis-faq-5.1.html
http://mathforum.org/library/drmath/view/51879.html
https://rosettacode.org/wiki/Haversine_formula
)

"The haversine formula determines the great-circle distance between two
points on a sphere given their longitudes and latitudes."

--
Lew Pitcher
"In Skills, We Trust"

On 11/11/21 5:30 PM, Howerd Oakford wrote:
> On Thursday, November 11, 2021 at 2:19:39 AM UTC+1, Richard Damon wrote:
>> On 11/10/21 8:14 AM, Howerd Oakford wrote:
>>> On Tuesday, November 9, 2021 at 4:03:48 PM UTC+1, Öö Tiib wrote:
>>>> On Monday, 8 November 2021 at 19:56:23 UTC+2, how...@gmail.com wrote:
>>>>> Hi C-folks,
>>>>>
>>>>> Following the extremely helpful responses to my last question, I would like to ask another one :
>>>>> I have a signed variable int32_t Latitude that represents the latitude on Earth, from -180 degrees West to 179.9999... degrees East.
>>>> What strange discussion you have here guys? What West what East?
>>>> Geodetic latitude: the angle between the normal and the equatorial plane.
>>>> So latitude can't be bigger than 90° (North pole) nor smaller than -90° (South pole).
>>>>> Since we are using an ARM64 processor and GCC cross compiler, the system is conventional two's complement.
>>>>>
>>>>> So is it OK, (with a comment to appease MISRA), to use the actual behaviour of the processor to wraparound (overflow?) from 179.99999... to -180 degrees?
>>>>>
>>>>> If not, is it OK to drop down to ARM assembler to avoid the "undefined behaviour" of C?
>>>>>
>>>>> In the actual system we have to store both latitude and longitude for several thousand points, so I don't really want to use uint64_t and manually do a 32 bit modulus...
>>>> Further distraction. If you need distances then converting from
>>>> spherical coordinates to Euclidian takes quite a trigonometry
>>>> and int32_t is not what one is using there. Use double.
>>>
>>> Hi Öö Tiib,
>>>
>>> My understanding is that you must scale the longitude difference by the cosine of the latitude, to first order.
>>> Is there something I am missing here ?
>>>
>>> Cheers,
>>> Howerd
>>>
>> No, that doesn't work.
>>
>> if the two points are on the same latitude, that will give you the
>> length of the path that follows that line of latitude between the two
>> points.
>>
>> If the longitude difference is significant, then there can be a
>> significantly shorter route that follows a 'great circle' route that
>> follow the real straight line between the points.
>>
>> At the extreme of 180 degrees of latitude difference, the shortest line
>> goes straight over the pole to the other side.
>
> Hi Richard,
>
> Sorry - I didn't make it clear that this only has to work over a range of a few 100 metres!
>
> Cheers,
> Howerd
>

At ranges of a few 100 meters then the simple formula works (unless you
get very near the poles), but be warned at that scale you start to have
to worry about the shape of your reference Spheroid and reference marks.
Yes at the local level it isn't that important, but getting the numbers
in fhe first place you need to make sure everything is using the same
reference system.

If you like C++: this is a C++20-class that takes a signed integral tem-
plate-parameter and if you do some arithmetic operations on it and do a
comparison afterwards, the comparison is done in every case, i.e. the
compiler doesn't optimize away overflows:

#include <iostream>
#include <random>
#include "sgi.h"

using namespace std;

short rnd();

int main()
{ using sgis = sgi<short>;
sgis a( rnd() ), b( rnd() );
bool f = a + b < a;
cout << f << endl;
}

#if defined(_MSC_VER)
__declspec(noinline)
#elif defined(__GNUC__)
__attribute((noinline))
#endif
short rnd()
{ static mt19937_64 mt( (random_device())() );
static uniform_int_distribution<short> uid( -10, +10 );
return uid( mt );
}

This generates the following code:

call "?rnd@@YAFXZ"
mov esi, eax
call "?rnd@@YAFXZ"
lea ecx, [rax + rsi]
cmp cx, si
setl cl
test ax, ax
setne dl
and dl, cl

This is the class for sgi:

#pragma once
#include <type_traits>
#include <concepts>
#include <compare>

template<typename T>
concept sgi_concept = std::is_integral_v<T> && std::is_signed_v<T>;

template<typename T>
requires sgi_concept<T>
struct sgi
{ sgi() = default;
template<typename T2>
requires sgi_concept<T2>
sgi( T2 value );
template<typename T2>
sgi( sgi<T2> const &other );
operator T();
template<typename T2>
sgi &operator |=( sgi<T2> const &other );
template<typename T2>
sgi &operator ^=( sgi<T2> const &other );
template<typename T2>
sgi &operator &=( sgi<T2> const &other );
sgi &operator >>=( unsigned shift );
sgi &operator <<=( unsigned shift );
template<typename T2>
sgi &operator %=( sgi<T2> const &other );
template<typename T2>
sgi &operator /=( sgi<T2> const &other );
template<typename T2>
sgi &operator *=( sgi<T2> const &other );
template<typename T2>
sgi &operator -=( sgi<T2> const &other);
template<typename T2>
sgi &operator +=( sgi<T2> const &other );
template<typename T2>
sgi &operator =( sgi<T2> const &other );
template<typename T2>
requires sgi_concept<T2>
sgi &operator =( T2 value );
template<typename T1, typename T2>
friend bool operator ||( sgi<T1> const &left, sgi<T2> const &right );
template<typename T1, typename T2>
friend bool operator &&( sgi<T1> const &left, sgi<T2> const &right );
template<typename T1, typename T2>
friend sgi<std::conditional_t<sizeof(T1) >= sizeof(T2), T1, T2>>
operator |( sgi<T1> const &left, sgi<T2> const &right );
template<typename T1, typename T2>
friend sgi<std::conditional_t<sizeof(T1) >= sizeof(T2), T1, T2>>
operator ^( sgi<T1> const &left, sgi<T2> const &right );
template<typename T1, typename T2>
friend sgi<std::conditional_t<sizeof(T1) >= sizeof(T2), T1, T2>>
operator &( sgi<T1> const &left, sgi<T2> const &right );
template<typename T1, typename T2>
friend bool operator !=( sgi<T1> const &left, sgi<T2> const &right );
template<typename T1, typename T2>
friend std::strong_ordering operator <=>( sgi<T1> const &left, sgi<T2>
const &right );
template<typename T2>
friend sgi<T2> operator <<( sgi<T2> const &left, unsigned shift );
template<typename T2>
friend sgi<T2> operator >>( sgi<T> const &left, unsigned shift );
template<typename T1, typename T2>
friend sgi<std::conditional_t<sizeof(T1) >= sizeof(T2), T1, T2>>
operator -( sgi<T1> const &left, sgi<T2> const &right );
template<typename T1, typename T2>
friend sgi<std::conditional_t<sizeof(T1) >= sizeof(T2), T1, T2>>
operator +( sgi<T1> const &left, sgi<T2> const &right );
template<typename T1, typename T2>
friend sgi<std::conditional_t<sizeof(T1) >= sizeof(T2), T1, T2>>
operator %( sgi<T1> const &left, sgi<T2> const &right );
template<typename T1, typename T2>
friend sgi<std::conditional_t<sizeof(T1) >= sizeof(T2), T1, T2>>
operator /( sgi<T1> const &left, sgi<T2> const &right );
template<typename T1, typename T2>
friend sgi<std::conditional_t<sizeof(T1) >= sizeof(T2), T1, T2>>
operator *( sgi<T1> const &left, sgi<T2> const &right );
sgi<T> &operator --();
sgi<T> &operator ++();
sgi<T> operator --( int );
sgi<T> operator ++( int );
private:
using TU = std::make_unsigned_t<T>;
TU value;
};

template<typename T>
requires sgi_concept<T>
template<typename T2>
inline
sgi<T>::sgi( sgi<T2> const &other ) :
value( (T)(T2)other.value )
{ }

template<typename T>
requires sgi_concept<T>
template<typename T2>
requires sgi_concept<T2>
inline
sgi<T>::sgi( T2 value ) :
value( (T)value )
{ }

template<typename T>
requires sgi_concept<T>
inline
sgi<T>::operator T()
{ return value;
}

template<typename T>
requires sgi_concept<T>
template<typename T2>
inline
sgi<T> &sgi<T>::operator |=( sgi<T2> const &value )
{ value |= (T)(T2)value.value;
return *this;
}

template<typename T>
requires sgi_concept<T>
template<typename T2>
inline
sgi<T> &sgi<T>::operator ^=( sgi<T2> const &value )
{ value ^= (T)(T2)value.value;
return *this;
}

template<typename T>
requires sgi_concept<T>
template<typename T2>
inline
sgi<T> &sgi<T>::operator &=( sgi<T2> const &value )
{ value &= (T)(T2)value.value;
return *this;
}

template<typename T>
requires sgi_concept<T>
inline
sgi<T> &sgi<T>::operator >>=( unsigned shift )
{ value = (T)value >> shift;
return *this;
}

template<typename T>
requires sgi_concept<T>
inline
sgi<T> &sgi<T>::operator <<=( unsigned shift )
{ value = (T)value << shift;
return *this;
}

template<typename T>
requires sgi_concept<T>
template<typename T2>
inline
sgi<T> &sgi<T>::operator %=( sgi<T2> const &other )
{ value = (T)((T)value % (T2)other.value);
return *this;
}

template<typename T>
requires sgi_concept<T>
template<typename T2>
inline
sgi<T> &sgi<T>::operator /=( sgi<T2> const &other )
{ value = (T)((T)value / (T2)other.value);
return *this;
}

template<typename T>
requires sgi_concept<T>
template<typename T2>
inline
sgi<T> &sgi<T>::operator *=( sgi<T2> const &other )
{ value = (T)((T)value * (T2)other.value);
return *this;
}

template<typename T>
requires sgi_concept<T>
template<typename T2>
inline
sgi<T> &sgi<T>::operator -=( sgi<T2> const &other )
{ value -= (T)(T2)other.value;
return *this;
}

template<typename T>
requires sgi_concept<T>
template<typename T2>
inline
sgi<T> &sgi<T>::operator +=( sgi<T2> const &other )
{ value += (T)(T2)other.value;
return *this;
}

template<typename T>
requires sgi_concept<T>
template<typename T2>
inline
sgi<T> &sgi<T>::operator =( sgi<T2> const &other )
{ value = (T)(T2)other.value;
return *this;
}

template<typename T>
requires sgi_concept<T>
template<typename T2>
requires sgi_concept<T2>
inline
sgi<T> &sgi<T>::operator =( T2 value )
{ this->value = (T)value;
return *this;
}

template<typename T1, typename T2>
inline
bool operator ||( sgi<T1> const &left, sgi<T2> const &right )
{ return left.value || right.value;
}

template<typename T1, typename T2>
inline
bool operator &&( sgi<T1> const &left, sgi<T2> const &right )
{ return left.value && right.value;
}

template<typename T1, typename T2>
inline
sgi<std::conditional_t<sizeof(T1) >= sizeof(T2), T1, T2>> operator |(
sgi<T1> const &left, sgi<T2> const &right )
{ return sgi<std::conditional_t<sizeof(T1) >= sizeof(T2), T1, T2>>(
(T1)left.value | (T2)right.value );
}

The three way comparison operator is poorly optimizesd, so I implemented
>=, >, <= and < myself. This results in the followging code:

call "?rnd@@YAFXZ"
mov esi, eax
call "?rnd@@YAFXZ"
add eax, esi
cmp ax, si
setl dl

#pragma once
#include <type_traits>
#include <concepts>
#include <compare>

template<typename T>
concept sgi_concept = std::is_integral_v<T> && std::is_signed_v<T>;

template<typename T>
requires sgi_concept<T>
struct sgi
{ sgi() = default;
template<typename T2>
requires sgi_concept<T2>
sgi( T2 value );
template<typename T2>
sgi( sgi<T2> const &other );
operator T();
template<typename T2>
sgi &operator |=( sgi<T2> const &other );
template<typename T2>
sgi &operator ^=( sgi<T2> const &other );
template<typename T2>
sgi &operator &=( sgi<T2> const &other );
sgi &operator >>=( unsigned shift );
sgi &operator <<=( unsigned shift );
template<typename T2>
sgi &operator %=( sgi<T2> const &other );
template<typename T2>
sgi &operator /=( sgi<T2> const &other );
template<typename T2>
sgi &operator *=( sgi<T2> const &other );
template<typename T2>
sgi &operator -=( sgi<T2> const &other);
template<typename T2>
sgi &operator +=( sgi<T2> const &other );
template<typename T2>
sgi &operator =( sgi<T2> const &other );
template<typename T2>
requires sgi_concept<T2>
sgi &operator =( T2 value );
template<typename T1, typename T2>
friend bool operator ||( sgi<T1> const &left, sgi<T2> const &right );
template<typename T1, typename T2>
friend bool operator &&( sgi<T1> const &left, sgi<T2> const &right );
template<typename T1, typename T2>
friend sgi<std::conditional_t<sizeof(T1) >= sizeof(T2), T1, T2>>
operator |( sgi<T1> const &left, sgi<T2> const &right );
template<typename T1, typename T2>
friend sgi<std::conditional_t<sizeof(T1) >= sizeof(T2), T1, T2>>
operator ^( sgi<T1> const &left, sgi<T2> const &right );
template<typename T1, typename T2>
friend sgi<std::conditional_t<sizeof(T1) >= sizeof(T2), T1, T2>>
operator &( sgi<T1> const &left, sgi<T2> const &right );
template<typename T1, typename T2>
friend bool operator !=( sgi<T1> const &left, sgi<T2> const &right );
template<typename T1, typename T2>
friend bool operator >=( sgi<T1> const &left, sgi<T2> const &right );
template<typename T1, typename T2>
friend bool operator >( sgi<T1> const &left, sgi<T2> const &right );
template<typename T1, typename T2>
friend bool operator <=( sgi<T1> const &left, sgi<T2> const &right );
template<typename T1, typename T2>
friend bool operator <( sgi<T1> const &left, sgi<T2> const &right );
template<typename T2>
friend sgi<T2> operator <<( sgi<T2> const &left, unsigned shift );
template<typename T2>
friend sgi<T2> operator >>( sgi<T> const &left, unsigned shift );
template<typename T1, typename T2>
friend sgi<std::conditional_t<sizeof(T1) >= sizeof(T2), T1, T2>>
operator -( sgi<T1> const &left, sgi<T2> const &right );
template<typename T1, typename T2>
friend sgi<std::conditional_t<sizeof(T1) >= sizeof(T2), T1, T2>>
operator +( sgi<T1> const &left, sgi<T2> const &right );
template<typename T1, typename T2>
friend sgi<std::conditional_t<sizeof(T1) >= sizeof(T2), T1, T2>>
operator %( sgi<T1> const &left, sgi<T2> const &right );
template<typename T1, typename T2>
friend sgi<std::conditional_t<sizeof(T1) >= sizeof(T2), T1, T2>>
operator /( sgi<T1> const &left, sgi<T2> const &right );
template<typename T1, typename T2>
friend sgi<std::conditional_t<sizeof(T1) >= sizeof(T2), T1, T2>>
operator *( sgi<T1> const &left, sgi<T2> const &right );
sgi<T> &operator --();
sgi<T> &operator ++();
sgi<T> operator --( int );
sgi<T> operator ++( int );
private:
using TU = std::make_unsigned_t<T>;
TU value;
};

template<typename T>
requires sgi_concept<T>
template<typename T2>
inline
sgi<T>::sgi( sgi<T2> const &other ) :
value( (T)(T2)other.value )
{ }

template<typename T>
requires sgi_concept<T>
template<typename T2>
requires sgi_concept<T2>
inline
sgi<T>::sgi( T2 value ) :
value( (T)value )
{ }

template<typename T>
requires sgi_concept<T>
inline
sgi<T>::operator T()
{ return value;
}

template<typename T>
requires sgi_concept<T>
template<typename T2>
inline
sgi<T> &sgi<T>::operator |=( sgi<T2> const &value )
{ value |= (T)(T2)value.value;
return *this;
}

template<typename T>
requires sgi_concept<T>
template<typename T2>
inline
sgi<T> &sgi<T>::operator ^=( sgi<T2> const &value )
{ value ^= (T)(T2)value.value;
return *this;
}

template<typename T>
requires sgi_concept<T>
template<typename T2>
inline
sgi<T> &sgi<T>::operator &=( sgi<T2> const &value )
{ value &= (T)(T2)value.value;
return *this;
}

template<typename T>
requires sgi_concept<T>
inline
sgi<T> &sgi<T>::operator >>=( unsigned shift )
{ value = (T)value >> shift;
return *this;
}

template<typename T>
requires sgi_concept<T>
inline
sgi<T> &sgi<T>::operator <<=( unsigned shift )
{ value = (T)value << shift;
return *this;
}

template<typename T>
requires sgi_concept<T>
template<typename T2>
inline
sgi<T> &sgi<T>::operator %=( sgi<T2> const &other )
{ value = (T)((T)value % (T2)other.value);
return *this;
}

template<typename T>
requires sgi_concept<T>
template<typename T2>
inline
sgi<T> &sgi<T>::operator /=( sgi<T2> const &other )
{ value = (T)((T)value / (T2)other.value);
return *this;
}

template<typename T>
requires sgi_concept<T>
template<typename T2>
inline
sgi<T> &sgi<T>::operator *=( sgi<T2> const &other )
{ value = (T)((T)value * (T2)other.value);
return *this;
}

template<typename T>
requires sgi_concept<T>
template<typename T2>
inline
sgi<T> &sgi<T>::operator -=( sgi<T2> const &other )
{ value -= (T)(T2)other.value;
return *this;
}

template<typename T>
requires sgi_concept<T>
template<typename T2>
inline
sgi<T> &sgi<T>::operator +=( sgi<T2> const &other )
{ value += (T)(T2)other.value;
return *this;
}

template<typename T>
requires sgi_concept<T>
template<typename T2>
inline
sgi<T> &sgi<T>::operator =( sgi<T2> const &other )
{ value = (T)(T2)other.value;
return *this;
}

template<typename T>
requires sgi_concept<T>
template<typename T2>
requires sgi_concept<T2>
inline
sgi<T> &sgi<T>::operator =( T2 value )
{ this->value = (T)value;
return *this;
}

template<typename T1, typename T2>
inline
bool operator ||( sgi<T1> const &left, sgi<T2> const &right )
{ return left.value || right.value;
}

template<typename T1, typename T2>
inline
bool operator &&( sgi<T1> const &left, sgi<T2> const &right )
{ return left.value && right.value;
}

template<typename T1, typename T2>
inline
sgi<std::conditional_t<sizeof(T1) >= sizeof(T2), T1, T2>> operator |(
sgi<T1> const &left, sgi<T2> const &right )
{ return sgi<std::conditional_t<sizeof(T1) >= sizeof(T2), T1, T2>>(
(T1)left.value | (T2)right.value );
}

template<typename T1, typename T2>
inline
sgi<std::conditional_t<sizeof(T1) >= sizeof(T2), T1, T2>> operator ^(
sgi<T1> const &left, sgi<T2> const &right )
{ return sgi<std::conditional_t<sizeof(T1) >= sizeof(T2), T1, T2>>(
(T1)left.value ^ (T2)right.value );
}

Howerd Oakford to Richard Damon:

> > I presume you are scaling the numbers so 179.999 degrees
> > would be 0x7FFFFFFF and -180 would be 0x80000000
>
> Exactly.

Why not store latitude and longitude in the `float' or
`double' type as degrees (or radians), and wrap tham explic-
itly:

lat_add( float a, float b )
{ const float MAG = 180.0;
float res;
res = a + b;
if( res >= MAG ) res -= 2*MAG;
else if( res < MAG ) res += 2*MAG;
return res;
}

Is it for reasons of optimisation that you use normalised
integers instead?

--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]

Howerd Oakford:

> Because we receive the data as a string in the form
> "123456789" or "-123456789" , and the Schema for the data
> format refers to this as an int32_t. So naturally, I con-
> verted it to an int32_t.

On the contrary -- it is unnatural, because data-exchage
format serves a purpose different from that of the corre-
sponding data structure in the program. Most of the time,
the best approach is to convert the data to whatver internal
representation is most convenient for the task at hand. Re-
liance on low-level facilities instead of explicit logic
makes the program less readable and less portable (including
to other languages!).

--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]

Howerd Oakford:

> The application that I am working on is speed-critical

I recommend the following approach:

1. Create the simplest and easist implementation that you

can think of.
2. If measurements show it too slow, run it in the profi-
er and determine the narrowest bottleneck.

3. Optimise that away, and repeat.

--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]

On 11/19/2021 11:49 AM, Anton Shepelev wrote:
> Howerd Oakford to Richard Damon:
>
>>> I presume you are scaling the numbers so 179.999 degrees
>>> would be 0x7FFFFFFF and -180 would be 0x80000000
>>
>> Exactly.
>
> Why not store latitude and longitude in the `float' or
> `double' type as degrees (or radians), and wrap tham explic-
> itly:
>
> lat_add( float a, float b )
> { const float MAG = 180.0;
> float res;
> res = a + b;
> if( res >= MAG ) res -= 2*MAG;
> else if( res < MAG ) res += 2*MAG;
> return res;
> }
>
> Is it for reasons of optimisation that you use normalised
> integers instead?
>

Or because it requires extra care:

> else if( res < MAG ) res += 2*MAG;

doesn't work, you need:

else if( res < -MAG ) res += 2*MAG;

You also have to consider rounding errors around +/-MAG.

Integer arithmetic has less kinks than floating point, there are
circumstances where it is preferable.
I am not saying that it is the good choice here, in fact I think there
is just not enough information in what the OP has given to give a
definite answer.

This is a completed implementation of the sgi-class. It now includes
all relevant operators and it includes all integral-promotions so that
f.a. sgi<char> * sgi<char> becomes a sgi<int>.
Look how flexible the return-type is deduced:

template<typename T1, typename T2>
inline
sgi<decltype((T1)1 * (T2)1)> operator *( sgi<T1> left, sgi<T2> right )
{ return sgi<decltype((T1)1 * (T2)1)>( (T1)left.value * (T2)right.value );
}

C++ is just the most powerful systems-programming language.

#pragma once
#include <type_traits>

template<typename T>
concept sgi_value = std::is_integral_v<T> && std::is_signed_v<T>;

template<typename T>
requires sgi_value<T>
struct sgi final
{ sgi() = default;
sgi( sgi_value auto value );
template<typename T2>
sgi( sgi<T2> other );
template<typename T2>
requires sgi_value<T2>
explicit operator T2() const;
template<typename T2>
sgi &operator |=( sgi<T2> other );
sgi &operator |=( sgi_value auto other );
template<typename T2>
sgi &operator ^=( sgi<T2> other );
sgi &operator ^=( sgi_value auto other );
template<typename T2>
sgi &operator &=( sgi<T2> other );
sgi &operator &=( sgi_value auto value );
sgi &operator >>=( unsigned shift );
sgi &operator <<=( unsigned shift );
template<typename T2>
sgi &operator %=( sgi<T2> other );
sgi &operator %=( sgi_value auto other );
template<typename T2>
sgi &operator /=( sgi<T2> other );
sgi &operator /=( sgi_value auto other );
template<typename T2>
sgi &operator *=( sgi<T2> other );
sgi &operator *=( sgi_value auto other );
template<typename T2>
sgi &operator -=( sgi<T2> other);
sgi &operator -=( sgi_value auto other );
template<typename T2>
sgi &operator +=( sgi<T2> other );
sgi &operator +=( sgi_value auto other );
template<typename T2>
sgi &operator =( sgi<T2> other );
sgi &operator =( sgi_value auto other );
template<typename T1, typename T2>
friend bool operator ||( sgi<T1> left, sgi<T2> right );
template<typename T2>
friend bool operator ||( sgi_value auto left, sgi<T2> right );
template<typename T1>
friend bool operator ||( sgi<T1> left, sgi_value auto right );
template<typename T1, typename T2>
friend bool operator &&( sgi<T1> left, sgi<T2> right );
template<typename T2>
friend bool operator &&( sgi_value auto left, sgi<T2> right );
template<typename T1>
friend bool operator &&( sgi<T1> left, sgi_value auto right );
template<typename T1, typename T2>
friend sgi<decltype((T1)1 | (T2)1)> operator |( sgi<T1> left, sgi<T2>
right );
template<typename T1, typename T2>
friend sgi<decltype((T1)1 | (T2)1)> operator |( T1 left, sgi<T2> right );
template<typename T1, typename T2>
friend sgi<decltype((T1)1 | (T2)1)> operator |( sgi<T1> left, T2 right );
template<typename T1, typename T2>
friend sgi<decltype((T1)1 ^ (T2)1)> operator ^( sgi<T1> left, sgi<T2>
right );
template<typename T1, typename T2>
friend sgi<decltype((T1)1 ^ (T2)1)> operator ^( T1 left, sgi<T2> right );
template<typename T1, typename T2>
friend sgi<decltype((T1)1 ^ (T2)1)> operator ^( sgi<T1> left, T2 right );
template<typename T1, typename T2>
friend sgi<decltype((T1)1 & (T2)1)> operator ^( sgi<T1> left, sgi<T2>
right );
template<typename T1, typename T2>
friend sgi<decltype((T1)1 & (T2)1)> operator ^( T1 left, sgi<T2> right );
template<typename T1, typename T2>
friend sgi<decltype((T1)1 & (T2)1)> operator ^( sgi<T1> left, T2 right );
template<typename T1, typename T2>
friend bool operator !=( sgi<T1> left, sgi<T2> right );
template<typename T2>
friend bool operator !=( sgi_value auto left, sgi<T2> right );
template<typename T1>
friend bool operator !=( sgi<T1> left, sgi_value auto right );
template<typename T1, typename T2>
friend bool operator ==( sgi<T1> left, sgi<T2> right );
template<typename T2>
friend bool operator ==( sgi_value auto left, sgi<T2> right );
template<typename T1>
friend bool operator ==( sgi<T1> left, sgi_value auto right );
template<typename T1, typename T2>
friend bool operator >=( sgi<T1> left, sgi<T2> right );
template<typename T2>
friend bool operator >=( sgi_value auto left, sgi<T2> right );
template<typename T1>
friend bool operator >=( sgi<T1> left, sgi_value auto right );
template<typename T1, typename T2>
friend bool operator >( sgi<T1> left, sgi<T2> right );
template<typename T2>
friend bool operator >( sgi_value auto left, sgi<T2> right );
template<typename T1>
friend bool operator >( sgi<T1> left, sgi_value auto right );
template<typename T1, typename T2>
friend bool operator <=( sgi<T1> left, sgi<T2> right );
template<typename T2>
friend bool operator <=( sgi_value auto left, sgi<T2> right );
template<typename T1>
friend bool operator <=( sgi<T1> left, sgi_value auto right );
template<typename T1, typename T2>
friend bool operator <( sgi<T1> left, sgi<T2> right );
template<typename T2>
friend bool operator <( sgi_value auto left, sgi<T2> right );
template<typename T1>
friend bool operator <( sgi<T1> left, sgi_value auto right );
template<typename T1, typename T2>
friend sgi<decltype((T1)1 - (T2)1)> operator -( sgi<T1> left, sgi<T2>
right );
template<typename T1, typename T2>
requires sgi_value<T1>
friend sgi<decltype((T1)1 - (T2)1)> operator -( T1 left, sgi<T2> right );
template<typename T1, typename T2>
requires sgi_value<T2>
friend sgi<decltype((T1)1 - (T2)1)> operator -( sgi<T1> left, T2 right );
template<typename T1, typename T2>
friend sgi<decltype((T1)1 + (T2)1)> operator +( sgi<T1> left, sgi<T2>
right );
template<typename T1, typename T2>
requires sgi_value<T1>
friend sgi<decltype((T1)1 + (T2)1)> operator +( T1 left, sgi<T2> right );
template<typename T1, typename T2>
requires sgi_value<T2>
friend sgi<decltype((T1)1 + (T2)1)> operator +( sgi<T1> left, T2 right );
template<typename T1, typename T2>
friend sgi<decltype((T1)1 % (T2)1)> operator %( sgi<T1> left, sgi<T2>
right );
template<typename T1, typename T2>
requires sgi_value<T1>
friend sgi<decltype((T1)1 % (T2)1)> operator %( T1 left, sgi<T2> right );
template<typename T1, typename T2>
requires sgi_value<T2>
friend sgi<decltype((T1)1 % (T2)1)> operator %( sgi<T1> left, T2 right );
template<typename T1, typename T2>
friend sgi<decltype((T1)1 / (T2)1)> operator /( sgi<T1> left, sgi<T2>
right );
template<typename T1, typename T2>
requires sgi_value<T1>
friend sgi<decltype((T1)1 / (T2)1)> operator /( T1 left, sgi<T2> right );
template<typename T1, typename T2>
requires sgi_value<T2>
friend sgi<decltype((T1)1 / (T2)1)> operator /( sgi<T1> left, T2 right );
template<typename T1, typename T2>
friend sgi<decltype((T1)1 * (T2)1)> operator *( sgi<T1> left, sgi<T2>
right );
template<typename T1, typename T2>
requires sgi_value<T1>
friend sgi<decltype((T1)1 * (T2)1)> operator *( T1 left, sgi<T2> right );
template<typename T1, typename T2>
requires sgi_value<T2>
friend sgi<decltype((T1)1 * (T2)1)> operator *( sgi<T1> left, T2 right );
sgi operator ~() const;
bool operator !() const;
sgi operator +() const;
sgi operator -() const;
sgi<T> &operator --();
sgi<T> &operator ++();
sgi<T> operator --( int );
sgi<T> operator ++( int );
private:
using TU = std::make_unsigned_t<T>;
TU value;
};

template<typename T>
requires sgi_value<T>
template<typename T2>
inline
sgi<T>::sgi( sgi<T2> other ) :
value( (T)(T2)other.value )
{ }

template<typename T>
requires sgi_value<T>
inline
sgi<T>::sgi( sgi_value auto other ) :
value( (T)other )
{ }

template<typename T>
requires sgi_value<T>
template<typename T2>
requires sgi_value<T2>
inline
sgi<T>::operator T2() const
{ return (T2)(T)value;
}

template<typename T>
requires sgi_value<T>
template<typename T2>
inline
sgi<T> &sgi<T>::operator |=( sgi<T2> other )
{
Click here to read the complete article

On 20/11/2021 14:56, Bonita Montero wrote:
> This is a completed implementation of the sgi-class. It now includes
> all relevant operators and it includes all integral-promotions so that
> f.a. sgi<char> * sgi<char> becomes a sgi<int>.
> Look how flexible the return-type is deduced:
>
> template<typename T1, typename T2>
> inline
> sgi<decltype((T1)1 * (T2)1)> operator *( sgi<T1> left, sgi<T2> right )
> {
>     return sgi<decltype((T1)1 * (T2)1)>( (T1)left.value *
> (T2)right.value );
> }

<snip>

Blimey, that's a lot of templates.

But what's an sgi-class, and what's it got to do with signed integer
overflow?

Am 20.11.2021 um 16:14 schrieb Bart:
> On 20/11/2021 14:56, Bonita Montero wrote:
>> This is a completed implementation of the sgi-class. It now includes
>> all relevant operators and it includes all integral-promotions so that
>> f.a. sgi<char> * sgi<char> becomes a sgi<int>.
>> Look how flexible the return-type is deduced:
>>
>> template<typename T1, typename T2>
>> inline
>> sgi<decltype((T1)1 * (T2)1)> operator *( sgi<T1> left, sgi<T2> right )
>> {
>>      return sgi<decltype((T1)1 * (T2)1)>( (T1)left.value *
>> (T2)right.value );
>> }
>
> <snip>
>
> Blimey, that's a lot of templates.
>
> But what's an sgi-class, and what's it got to do with signed integer
> overflow?

Its a replacement for all signed integers and you can check overflows
with it. I.e. you could write:

int main()
{ using sgis = sgi<short>;
sgis a( rnd() );
bool f = a + 1 < a;
cout << f << endl;
}

And f is calculated at runtime and it doesn't become a constant though
optimization. So you can check for signed overflows at runtime. This
might not be required often, but the sgi-class is more convenient than
this casting-orgy which also prevents that the compiler optimizes away
the comparison.

Manfred to Anton Shepelev:

> > lat_add( float a, float b )
> > { const float MAG = 180.0;
> > float res;
> > res = a + b;
> > if( res >= MAG ) res -= 2*MAG;
> > else if( res < MAG ) res += 2*MAG;
> > return res;
> > }
> >
> > Is it for reasons of optimisation that you use nor-
> > malised integers instead?
>
> Or because it requires extra care
> [...]
> you need:
>
> else if( res < -MAG ) res += 2*MAG;

Blame that on me rather than on my idea. I have negligible
experience with numeric calculations and wrote my post from
work after completing a super-urgent task and before switch-
ing to a merely urgent one.

> You also have to consider rounding errors around +/-MAG.

I had not thought of that. Can my function (with your cor-
rection) yield an out-of-range result? What then --

float lat_add( float a, float b )
{ const float MAG = 180.0;
float res;
res = a + b;
if( res >= MAG ) { res -= 2*MAG; if (res < -MAG) res = -MAG;
else if( res < -MAG ) { res += 2*MAG; if (res >= MAG) res = -MAG;
return res;
}

I am not sure whether this additional clamping is needed.

> Integer arithmetic has less kinks than floating point,
> there are circumstances where it is preferable. I am not
> saying that it is the good choice here, in fact I think
> there is just not enough information in what the OP has
> given to give a definite answer.

Thanks for the explanation.

--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]