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

On 11/8/21 12:56 PM, Howerd Oakford 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.
>
> 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
>
>
>

Signed overflow is NOT defined by the C standard, though a given
implementation may do so. (GCC has an option to force it to not optimize
based on signed overflow not existing). Without using some
implementation specific option to make it add that promise, you run the
risk of an agresive optimizer giving you some unexpected results. The
biggest case would be if you ever did test to detect the wrap arround,
that is a key thing that might get optimized away.

The physical hardware will work perfectly fine.

And alternative is to store the values as uint32_t, as unsigned
arithmetic is defined to be defined as modulo arithmetic. You can then
convert the uit32_t to int32_t to get -180 to 179.999 range.

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

The other option is just scale things a bit smaller and manually do the
wrap around yourself. You do realize you are locating things to the
centimeter if I am doing my math right. At that scale, you need a lot of
corrections for the geodetic to keep things accurate.

On 08/11/2021 17:56, Howerd Oakford 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.
>
> 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?

Only if using some scaled representation where the limits of int32:

-2147483648 to 2147483647

are mapped to -180.0 to 179.9...

At least, it would be OK with pretty much every processor on the planet,
and most languages that support a 32-bit signed int type.

Except that C makes it undefined.

> If not, is it OK to drop down to ARM assembler to avoid the "undefined behaviour" of C?

You could do that, but there are few problems (like grappling with gcc
ASM syntax, or having to write a separate ASM module, or not portability).

But you can stay in C, and just cast to uint32_t, do the sum, then cast
back to int32_t.

However, since you are using ARM and not some 8-bit controller, why not
just use float or double? You would need to wrap using software:

if (d > 180.0) d -:= 360.0; // etc (assuming degrees not radians)

> 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...

How much RAM is in the machine? 1GM would store 128 million 64-bit readings.

On Mon, 8 Nov 2021 09:56:17 -0800 (PST), Howerd Oakford
<howerdo@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.
>
>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...

You will notice from the quoted material in this response that using
Goggle groups to post messages causes problems with the length of the
lines in your post. The recommendation is to use a real newsgroup
reader.

The answer to your first question depends on how you store fractional
degrees in an int32_t. Is 179.9999 actually stored as 0x7fffffff and
-180 stored as 0x80000000? If not, how does the hardware "know" that
adding .0001 to 179.9999 should cause a "carry" into the sign bit?

Regarding your second question, if you know the code the compiler will
generate and you know how the hardware will behave when it executes
those instructions, you can call this "implementation defined
behavior" for your environment. However, you would want to document
this VERY thoroughly because any change in the environment (such as
compiler version, compiler options, or hardware upgrade) would
necessitate reexamining this issue from scratch.

--
Remove del for email

On Monday, November 8, 2021 at 12:56:23 PM UTC-5, 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.

Use a uint32_t variable running from 0 degrees to 360-360/4294967296 degrees.
Wraparound does exactly what you want, and it's portable.

On 08/11/2021 19:51, Richard Damon wrote:
> On 11/8/21 12:56 PM, Howerd Oakford 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.
>>
>> 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
>>
>>
>>
>
> Signed overflow is NOT defined by the C standard, though a given
> implementation may do so. (GCC has an option to force it to not optimize
> based on signed overflow not existing).

That is not an accurate way to describe it. gcc has an option to give
signed integers wrapping semantics. It is not a matter of what
optimisations it enables or disables, it is a matter of adding an extra
"rule" to C to say that signed integer arithmetic has wrapping two's
complement results.

The flag in question is "-fwrapv", but IMHO it is better to use a pragma
in the source code as that makes it independent of any compiler flags
you have chosen:

#pragma GCC optimize "-fwrapv"

> Without using some
> implementation specific option to make it add that promise, you run the
> risk of an agresive optimizer giving you some unexpected results. The
> biggest case would be if you ever did test to detect the wrap arround,
> that is a key thing that might get optimized away.

Indeed. Never rely on undefined behaviour - even if it passes your
tests today, some day in the future it's going to bite you (or the
maintainers of your code). If you use "-fwrapv" with gcc (or clang, or
icc), you are no longer using undefined behaviour - you've given the
behaviour a definition.

>
> The physical hardware will work perfectly fine.
>
> And alternative is to store the values as uint32_t, as unsigned
> arithmetic is defined to be defined as modulo arithmetic. You can then
> convert the uit32_t to int32_t to get -180 to 179.999 range.
>

Yes. That is usually the safe and portable way to get the behaviour.
(It's not /entirely/ portable, since there is implementation-defined
behaviour there, but it will work on any realistic C implementation.)

> I presume you are scaling the numbers so 179.999 degrees would be
> 0x7FFFFFFF and -180 would be 0x80000000
>
> The other option is just scale things a bit smaller and manually do the
> wrap around yourself. You do realize you are locating things to the
> centimeter if I am doing my math right. At that scale, you need a lot of
> corrections for the geodetic to keep things accurate.
>

On 08/11/2021 19:53, Bart wrote:
> On 08/11/2021 17:56, Howerd Oakford 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.
>>
>> 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?
>
> Only if using some scaled representation where the limits of int32:
>
>    -2147483648 to 2147483647
>
> are mapped to -180.0 to 179.9...
>

Indeed.

> At least, it would be OK with pretty much every processor on the planet,
> and most languages that support a 32-bit signed int type.
>

For some undefined value of "most languages" - and irrelevant to a C
programmer asking C questions in a C newsgroup.

> Except that C makes it undefined.
>

Exactly. Some of MISRA's rules are downright stupid - this particular
one, banning reliance on any overflow behaviour of signed integers - is
a good one.

>
>> If not, is it OK to drop down to ARM assembler to avoid the "undefined
>> behaviour" of C?
>
> You could do that, but there are few problems (like grappling with gcc
> ASM syntax, or having to write a separate ASM module, or not portability).
>

gcc's asm syntax is powerful, but can be frightening when you are
unfamiliar with it. It is vastly better (and IMHO easier) than writing
separate assembly modules. But it is not portable, not MISRA friendly,
and - as you say - not necessary here.

> But you can stay in C, and just cast to uint32_t, do the sum, then cast
> back to int32_t.
>

Yes.

> However, since you are using ARM and not some 8-bit controller, why not
> just use float or double? You would need to wrap using software:
>
>    if (d > 180.0) d -:= 360.0;   // etc (assuming degrees not radians)
>

Indeed. Any 64-bit ARM target supports hardware floating point (most
small 32-bit ARM microcontrollers do not). Using floating point makes
the code clearer, and often more efficient, than working with scaled
integer arithmetic.

>
>> 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...
>
> How much RAM is in the machine? 1GM would store 128 million 64-bit
> readings.
>

It sounds like the OP is suffering from premature optimisation here!

On Mon, 2021-11-08, Howerd Oakford 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...

You don't have to store anything: you can do the calculation in
64-bit, deal with overflow, and go back to 32-bit.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On 08/11/2021 19:34, David Brown wrote:
> On 08/11/2021 19:53, Bart wrote:
>> On 08/11/2021 17:56, Howerd Oakford 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.
>>>
>>> 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?
>>
>> Only if using some scaled representation where the limits of int32:
>>
>>    -2147483648 to 2147483647
>>
>> are mapped to -180.0 to 179.9...
>>
>
> Indeed.
>
>> At least, it would be OK with pretty much every processor on the planet,
>> and most languages that support a 32-bit signed int type.
>>
>
> For some undefined value of "most languages" - and irrelevant to a C
> programmer asking C questions in a C newsgroup.

I was emphasising out that integer overflow is tolerated with
well-defined behaviour nearly everywhere else, so there is nothing
really wrong with wanting to rely on it.

It just that some languages aren't keen on it. In C it is UB, others may
trap the overflow..

You can only be really confident in ASM, which is perverse.

On Monday, November 8, 2021 at 7:51:54 PM UTC+1, Richard Damon wrote:
> On 11/8/21 12:56 PM, Howerd Oakford 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.
> >
> > 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
> >
> >
> >
> Signed overflow is NOT defined by the C standard, though a given
> implementation may do so. (GCC has an option to force it to not optimize
> based on signed overflow not existing). Without using some
> implementation specific option to make it add that promise, you run the
> risk of an agresive optimizer giving you some unexpected results. The
> biggest case would be if you ever did test to detect the wrap arround,
> that is a key thing that might get optimized away.
>
> The physical hardware will work perfectly fine.
>
> And alternative is to store the values as uint32_t, as unsigned
> arithmetic is defined to be defined as modulo arithmetic. You can then
> convert the uit32_t to int32_t to get -180 to 179.999 range.
>
> I presume you are scaling the numbers so 179.999 degrees would be
> 0x7FFFFFFF and -180 would be 0x80000000
>
> The other option is just scale things a bit smaller and manually do the
> wrap around yourself. You do realize you are locating things to the
> centimeter if I am doing my math right. At that scale, you need a lot of
> corrections for the geodetic to keep things accurate.
Hi Richard,

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

So, how about two macros for use on signed latitude and longitudes :
#define plus_int32( a, b ) int32_t( (uint32_t)(a) + (uint32_t)(b) )
#define minus_int32( a, b ) int32_t( (uint32_t)(a) - (uint32_t)(b) )

Would this produce the same code as setting the "-fwrapv" flag?

Doesn't casting between signed and unsigned integers present a similar wraparound problem?
Isn't this also dependent on a one's or two's complement environment, and therefore has "undefined behaviour"?

Cheers,
Howerd

On Monday, November 8, 2021 at 8:25:35 PM UTC+1, Eric Sosman wrote:
> On Monday, November 8, 2021 at 12:56:23 PM UTC-5, 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.
> Use a uint32_t variable running from 0 degrees to 360-360/4294967296 degrees.
> Wraparound does exactly what you want, and it's portable.
Hi Eric,

So 1 degree West would be 359 degrees East - this is a great idea - thanks!

Cheers,
Howerd

On 11/8/21 3:45 PM, Howerd Oakford wrote:
> On Monday, November 8, 2021 at 7:51:54 PM UTC+1, Richard Damon wrote:
>> On 11/8/21 12:56 PM, Howerd Oakford 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.
>>>
>>> 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
>>>
>>>
>>>
>> Signed overflow is NOT defined by the C standard, though a given
>> implementation may do so. (GCC has an option to force it to not optimize
>> based on signed overflow not existing). Without using some
>> implementation specific option to make it add that promise, you run the
>> risk of an agresive optimizer giving you some unexpected results. The
>> biggest case would be if you ever did test to detect the wrap arround,
>> that is a key thing that might get optimized away.
>>
>> The physical hardware will work perfectly fine.
>>
>> And alternative is to store the values as uint32_t, as unsigned
>> arithmetic is defined to be defined as modulo arithmetic. You can then
>> convert the uit32_t to int32_t to get -180 to 179.999 range.
>>
>> I presume you are scaling the numbers so 179.999 degrees would be
>> 0x7FFFFFFF and -180 would be 0x80000000
>>
>> The other option is just scale things a bit smaller and manually do the
>> wrap around yourself. You do realize you are locating things to the
>> centimeter if I am doing my math right. At that scale, you need a lot of
>> corrections for the geodetic to keep things accurate.
> Hi Richard,
>
>> I presume you are scaling the numbers so 179.999 degrees would be
>> 0x7FFFFFFF and -180 would be 0x80000000
> Exactly.
>
> So, how about two macros for use on signed latitude and longitudes :
> #define plus_int32( a, b ) int32_t( (uint32_t)(a) + (uint32_t)(b) )
> #define minus_int32( a, b ) int32_t( (uint32_t)(a) - (uint32_t)(b) )
>
> Would this produce the same code as setting the "-fwrapv" flag?
>
> Doesn't casting between signed and unsigned integers present a similar wraparound problem?
> Isn't this also dependent on a one's or two's complement environment, and therefore has "undefined behaviour"?
>
> Cheers,
> Howerd
>

Casting signed to unsigned is defined via the modulo rule.
Casting unsigned to signed isn't UB on 'overflow' but implementation
defined behavior which will almost certainly be doing what you want in
this case.

On an arbitrary machine, the unsigned to signed conversion might do
strange things to large nubmers going negative, but if you know that you
have a 2's complement machine with no padding bits in the signed number
representation, they will almost certainly define it the right way, as
that is what is certainly the cheapest.

Since you said you were ARM, we know it is this sort of sane 2's complement.

On 08/11/2021 21:45, Howerd Oakford wrote:
> On Monday, November 8, 2021 at 7:51:54 PM UTC+1, Richard Damon wrote:

>
>> I presume you are scaling the numbers so 179.999 degrees would be
>> 0x7FFFFFFF and -180 would be 0x80000000
> Exactly.
>
> So, how about two macros for use on signed latitude and longitudes :
> #define plus_int32( a, b ) int32_t( (uint32_t)(a) + (uint32_t)(b) )
> #define minus_int32( a, b ) int32_t( (uint32_t)(a) - (uint32_t)(b) )
>
> Would this produce the same code as setting the "-fwrapv" flag?

It would give the same code, but it really is not a good idea. You are
better off thinking about the kind of data you have and how you want to
handle it. It's unlikely that scaled integers will be the clearest and
most practical way to hold such position data - the wrapping is of
negligible benefit. Aim for clarity of code - not for imagined object
code efficiency.

Howerd Oakford <howerdo@gmail.com> writes:

> On Monday, November 8, 2021 at 7:51:54 PM UTC+1, Richard Damon wrote:
>
>> I presume you are scaling the numbers so 179.999 degrees would be
>> 0x7FFFFFFF and -180 would be 0x80000000
>
> Exactly.
>
> So, how about two macros for use on signed latitude and longitudes :
> #define plus_int32( a, b ) int32_t( (uint32_t)(a) + (uint32_t)(b) )
> #define minus_int32( a, b ) int32_t( (uint32_t)(a) - (uint32_t)(b) )

There's a whiff of C++ there, but I think it's just a typo.

> Would this produce the same code as setting the "-fwrapv" flag?
>
> Doesn't casting between signed and unsigned integers present a similar
> wraparound problem?

Converting an out of range value to int32_t is implementation defined:

"the ... type is signed and the value cannot be represented in it;
either the result is implementation-defined or an
implementation-defined signal is raised."

You can do the conversion safely by first testing if the unsigned value
is greater than INT32_MAX and subtracting if it is.

But do you really need the value to be signed? If any kind of quantity
matches what C's unsigned ints do, it's angles. You need conversion on
input an output, but that's going t involve other factors as well.

> Isn't this also dependent on a one's or two's complement environment,
> and therefore has "undefined behaviour"?

All of the intN_t types are guaranteed to use two's complement for
negative values (and to have no padding bits).

--
Ben.

Eric Sosman <donalhambra@gmail.com> writes:

> On Monday, November 8, 2021 at 12:56:23 PM UTC-5, how...@gmail.com wrote:
>>
>> 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.
>
> Use a uint32_t variable running from 0 degrees to 360-360/4294967296 degrees.
> Wraparound does exactly what you want, and it's portable.

You beat me to it.

(If you are the same Eric Sosman, welcome back. If not, welcome.)

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> All of the intN_t types are guaranteed to use two's complement for
> negative values (and to have no padding bits).

But, to be clear, the requirement of two's-complement representation
does not imply a requirement for two's-complement-style wraparound
behavior. (Ben, I'm sure you know this.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 08/11/2021 20:49, Howerd Oakford wrote:
> On Monday, November 8, 2021 at 8:25:35 PM UTC+1, Eric Sosman wrote:
>> On Monday, November 8, 2021 at 12:56:23 PM UTC-5, 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.
>> Use a uint32_t variable running from 0 degrees to 360-360/4294967296 degrees.
>> Wraparound does exactly what you want, and it's portable.
> Hi Eric,
>
> So 1 degree West would be 359 degrees East - this is a great idea - thanks!

Just a little confusing to everyone used to using 0-180 degrees West
(Google maps doesn't like 181E-359E for a start.)

But, it's still not clear to me why you need to do this at all, or how
you will work with it in practice.

You mentioned incrementing, but if you want to increment by 1° say, it
means adding, what, 11930464 or 11930465?

If you wanted to add a offset X which can be positive or negative, how
is that going to work? Instead of -30°, do you add +330° instead?

(Personally, if I couldn't use floats, and had to use a 32-bit int, I
might use int32 with range of +/- 180 million, degrees*1000000, with
wraparound handled in software. [-180'000'000 .. +179'999'999]

To increment by 1°, add 1 million. For an offset of -30°, use -30
million. Normalise the results of any arithmetic to keep in the expected
range. But I don't know how precise you need this to be. This only gives
10cm resolution.)

On 11/8/21 6:42 PM, Bart wrote:
> On 08/11/2021 20:49, Howerd Oakford wrote:
>> On Monday, November 8, 2021 at 8:25:35 PM UTC+1, Eric Sosman wrote:
>>> On Monday, November 8, 2021 at 12:56:23 PM UTC-5, 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.
>>> Use a uint32_t variable running from 0 degrees to 360-360/4294967296
>>> degrees.
>>> Wraparound does exactly what you want, and it's portable.
>> Hi Eric,
>>
>> So 1 degree West would be 359 degrees East - this is a great idea -
>> thanks!
>
> Just a little confusing to everyone used to using 0-180 degrees West
> (Google maps doesn't like 181E-359E for a start.)
>
> But, it's still not clear to me why you need to do this at all, or how
> you will work with it in practice.
>
> You mentioned incrementing, but if you want to increment by 1° say, it
> means adding, what, 11930464 or 11930465?
>
> If you wanted to add a offset X which can be positive or negative, how
> is that going to work? Instead of -30°, do you add +330° instead?
>
> (Personally, if I couldn't use floats, and had to use a 32-bit int, I
> might use int32 with range of +/- 180 million, degrees*1000000, with
> wraparound handled in software. [-180'000'000 .. +179'999'999]
>
> To increment by 1°, add 1 million. For an offset of -30°, use -30
> million. Normalise the results of any arithmetic to keep in the expected
> range. But I don't know how precise you need this to be. This only gives
> 10cm resolution.)

Point to note, if you use 32 bit floats, instead of 32 bit integers, you
can store the range from -180 to +180 with 16+ fractional bits, which
gives better than 2 meter accuracy if I am doing my math right. (Angles
out side of -127 to +127 will be stored with 1 implied + 7 interger bits
+ 16 fractional bits of a degree, which at the equator is about
40,000,000m / 360 / 65536 ~ 1.7 meters resolution.)

Again, at that resolution, you are needing to do local corrections to
the reference spheroid for those numbers to be meaningful.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [...]
>> All of the intN_t types are guaranteed to use two's complement for
>> negative values (and to have no padding bits).
>
> But, to be clear, the requirement of two's-complement representation
> does not imply a requirement for two's-complement-style wraparound
> behavior. (Ben, I'm sure you know this.)

Yes, thanks. The context could have given that impression. The
significance is that intN_t and uintN_t have the same number of values
and that intN_t has one move negative value that positive so one can
always get the test and subtract conversion to work.

--
Ben.

On Tuesday, November 9, 2021 at 12:43:03 AM UTC+1, Bart wrote:
> On 08/11/2021 20:49, Howerd Oakford wrote:
> > On Monday, November 8, 2021 at 8:25:35 PM UTC+1, Eric Sosman wrote:
> >> On Monday, November 8, 2021 at 12:56:23 PM UTC-5, 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.
> >> Use a uint32_t variable running from 0 degrees to 360-360/4294967296 degrees.
> >> Wraparound does exactly what you want, and it's portable.
> > Hi Eric,
> >
> > So 1 degree West would be 359 degrees East - this is a great idea - thanks!
> Just a little confusing to everyone used to using 0-180 degrees West
> (Google maps doesn't like 181E-359E for a start.)
>
> But, it's still not clear to me why you need to do this at all, or how
> you will work with it in practice.
>
> You mentioned incrementing, but if you want to increment by 1° say, it
> means adding, what, 11930464 or 11930465?
>
> If you wanted to add a offset X which can be positive or negative, how
> is that going to work? Instead of -30°, do you add +330° instead?
>
> (Personally, if I couldn't use floats, and had to use a 32-bit int, I
> might use int32 with range of +/- 180 million, degrees*1000000, with
> wraparound handled in software. [-180'000'000 .. +179'999'999]
>
> To increment by 1°, add 1 million. For an offset of -30°, use -30
> million. Normalise the results of any arithmetic to keep in the expected
> range. But I don't know how precise you need this to be. This only gives
> 10cm resolution.)

Hi Bart,

> But, it's still not clear to me why you need to do this at all, or how
> you will work with it in practice.
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 converted it to an int32_t.

The hardware and ARM16 ASM are OK with wrapping this value, but C (correctly) complains because this depends on a two's complement environment.

Using a float does not give enough resoultion, using a double does, but either type requires two run-time conversions.

Using a smaller range requires extra run-time code to do the modulo calculation.

The use case for this is finding the distance between two points given their latitude and longitude, so it is useful if the distance calculation wraps so that moving 1 step West of -180 degrees gives you +179.9999.. East.

My prefered solution is to cast to uint_32_t and then back to int_32_t - thank you, Eric, Ben and David and all who suggested this.

With "-fwrapv" set the cast may not be necessary - this would be a "mental cast" - just think of the value as 0 to 359.999.. degrees instead of -180 to 179.999... degrees.
Since we know this is a two's complement system we know that this works.

Thanks again y'all,

Cheers,
Howerd

Howerd Oakford <howerdo@gmail.com> writes:

> My prefered solution is to cast to uint_32_t and then back to int_32_t
> - thank you, Eric, Ben and David and all who suggested this.

Hmm... That was not was what I was suggesting! But it may be a
confusion over terms. A cast is a C operator, but the word is often
used to mean any conversion, even one involving calculation.

You can safely cast (or just implicitly convert) an int32_t to uint32_t
when processing the input. All calculations on the unsigned values will
just warp (on all C implementations on all hardware) and you can then
safely convert (using a simple test and subtraction) back to signed if
that helps with presenting the information.

However, I doubt you even need this. Whatever you need to do to present
the results can be done from an unsigned 0-360 number as easily as a
signed one.

--
Ben.

On 09/11/2021 09:14, Howerd Oakford wrote:
> On Tuesday, November 9, 2021 at 12:43:03 AM UTC+1, Bart wrote:
>> On 08/11/2021 20:49, Howerd Oakford wrote:
>>> On Monday, November 8, 2021 at 8:25:35 PM UTC+1, Eric Sosman
>>> wrote:
>>>> On Monday, November 8, 2021 at 12:56:23 PM UTC-5,
>>>> 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.
>>>> Use a uint32_t variable running from 0 degrees to
>>>> 360-360/4294967296 degrees. Wraparound does exactly what you
>>>> want, and it's portable.
>>> Hi Eric,
>>>
>>> So 1 degree West would be 359 degrees East - this is a great idea
>>> - thanks!
>> Just a little confusing to everyone used to using 0-180 degrees
>> West (Google maps doesn't like 181E-359E for a start.)
>>
>> But, it's still not clear to me why you need to do this at all, or
>> how you will work with it in practice.
>>
>> You mentioned incrementing, but if you want to increment by 1° say,
>> it means adding, what, 11930464 or 11930465?
>>
>> If you wanted to add a offset X which can be positive or negative,
>> how is that going to work? Instead of -30°, do you add +330°
>> instead?
>>
>> (Personally, if I couldn't use floats, and had to use a 32-bit int,
>> I might use int32 with range of +/- 180 million, degrees*1000000,
>> with wraparound handled in software. [-180'000'000 .. +179'999'999]
>>
>>
>> To increment by 1°, add 1 million. For an offset of -30°, use -30
>> million. Normalise the results of any arithmetic to keep in the
>> expected range. But I don't know how precise you need this to be.
>> This only gives 10cm resolution.)
>
> Hi Bart,
>
>> But, it's still not clear to me why you need to do this at all, or
>> how you will work with it in practice.
> 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 converted it to an int32_t.
>

What is the scaling? Without knowing that, all your points about
wrapping, formats, etc., are /useless/.

> The hardware and ARM16 ASM are OK with wrapping this value, but C
> (correctly) complains because this depends on a two's complement
> environment.

Forget the hardware. Forget assembly. Forget everything you think you
know about efficiency here, because you are almost certainly wrong
unless you have done extensive measurements to show that you need to use
some kind of hardware wrapping to get fast enough results.

Forget the whole concept of wrapping signed integer arithmetic. C does
not give you that - regardless of whether you have two's complement
signed integers (the representation of the integers is independent from
the treatment of arithmetic overflows).

There /are/ ways to get safe, guaranteed wrapping behaviour for
arithmetic involving signed integers. These are almost certainly
counter-productive to your needs because you've got obsessed with those
instead of looking at what makes sense for your code and what types,
formats, scalings and operations you actually /need/ and what makes the
source code clearer and more maintainable.

>
> Using a float does not give enough resoultion, using a double does,
> but either type requires two run-time conversions.
>

A single-precision float will give you a resolution of about 2.5 meters.
What are you doing that needs greater precision than that?

A typical 64-bit ARM processor (I believe that is what you are using)
will do conversion from an integer to a double in a nanosecond or so.
What are you doing where that nanosecond is too long?

Conversion from a string of digits to an integer might take several
hundred clock cycles. Conversion to a double will take several hundred
plus 2 or 3 clock cycles. Why do you think it is remotely relevant?

> Using a smaller range requires extra run-time code to do the modulo
> calculation.
>
> The use case for this is finding the distance between two points
> given their latitude and longitude, so it is useful if the distance
> calculation wraps so that moving 1 step West of -180 degrees gives
> you +179.9999.. East.
>

It is not the /slightest/ bit useful for such calculations. Have you
looked at the maths for doing this distance calculation? Making a
cut-off, whether it be at -180 degrees or 360 degrees, is
counter-productive. Your distance calculations will all be done in
floating point unless you are working on an 8-bit AVR or you are insane,
meaning a scaled integer format is just pointless extra work before you
can do the mathematics. And those calculations will be so extensive
that any modulo calculations are lost in the noise.

> My prefered solution is to cast to uint_32_t and then back to
> int_32_t - thank you, Eric, Ben and David and all who suggested
> this.
>

That is a good way to get wrapping signed integer arithmetic. But from
what you have written here, it is worse than useless for your needs
because it is a massive distraction from doing something useful.

Basically, you are bikesheding. Don't do that.

> With "-fwrapv" set the cast may not be necessary - this would be a
> "mental cast" - just think of the value as 0 to 359.999.. degrees
> instead of -180 to 179.999... degrees. Since we know this is a two's
> complement system we know that this works.
>

On 09/11/2021 08:14, Howerd Oakford wrote:
> On Tuesday, November 9, 2021 at 12:43:03 AM UTC+1, Bart wrote:

>> But, it's still not clear to me why you need to do this at all, or how
>> you will work with it in practice.

> Because we receive the data as a string in the form "123456789" or "-123456789" , and the Schema for

What is the actual format: decimal radians, decimal degrees,
degrees:minutes:decimal seconds?

the data format refers to this as an int32_t.
> So naturally, I converted it to an int32_t.
>
> The hardware and ARM16 ASM are OK with wrapping this value, but C (correctly) complains because this depends on a two's complement environment.
>
> Using a float does not give enough resoultion, using a double does, but either type requires two run-time conversions.

Whether your latitude/longitude readings are radians or degrees, the
sort of calculations you describe scream floating point.

If float32 is too inprecise, use float64.

I was reluctant to use float64 35 years ago, because I needed software
emulation and it was slower. But for at least 30 years now hardware
float64 has been available to everyone.

I was obliged to switch eventually because a customer of my graphics app
was using it to represent geographical mapping data, and float32 was too
imprecise for absolute data points when coordinates were a long way from
zero.

I can't believe that decades later, this is still a consideration even
on a board computer. Any ARM device will be a supercomputer compared
with what I've used!

> Using a smaller range requires extra run-time code to do the modulo calculation.
>
> The use case for this is finding the distance between two points given their latitude and longitude, so it is useful if the distance calculation wraps so that moving 1 step West of -180 degrees gives you +179.9999.. East.

You seem to be hung-up on this aspect. My aforementioned app also worked
with angles, which were normalised, in software, to:

0 <= angle < 2 pi

in my case.

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.

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