...
foreach (y, ref row; offsetMap)
{
   auto run = 0;
    auto nPixels = 0;
    foreach (x; 0..size.x)
    {
         immutable SDL_FPair offset  = { center.x - x, y - center.y };
...

and why does it violate the principle of making the right thing the easy thing to do?

On 21/06/2020 3:08 AM, Danni Coy wrote:
> ...
> foreach (y, ref row; offsetMap)
> {
>     auto run = 0;
>      auto nPixels = 0;
>      foreach (x; 0..size.x)
>      {
>           immutable SDL_FPair offset  = { center.x - x, y - center.y };
> ...
> 
> and why does it violate the principle of making the right thing the
> easy thing to do?
> 

oo oo, is it that you didn't want x and y to be of type size_t?

And why are you initializing run and nPixels manually?

On Sun, Jun 21, 2020 at 1:15 AM rikki cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 21/06/2020 3:08 AM, Danni Coy wrote:
> > ...
> > foreach (y, ref row; offsetMap)
> > {
> >     auto run = 0;
> >      auto nPixels = 0;
> >      foreach (x; 0..size.x)
> >      {
> >           immutable SDL_FPair offset  = { center.x - x, y - center.y };
> > ...
> >
> > and why does it violate the principle of making the right thing the easy thing to do?
> >
>
> oo oo, is it that you didn't want x and y to be of type size_t?
more specifically I didn't want them to be unsigned
I am adapting the code from C++ code,
coming from other Algol syntax languages. That one is a real
gotcha. I tried explicitly making x and y ints and I got a depreciation warning.

> And why are you initializing run and nPixels manually?
the value there so the compiler can figure out the type (auto)

On 21/06/2020 4:00 AM, Danni Coy wrote:
> On Sun, Jun 21, 2020 at 1:15 AM rikki cattermole via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>>
>> On 21/06/2020 3:08 AM, Danni Coy wrote:
>>> ...
>>> foreach (y, ref row; offsetMap)
>>> {
>>>      auto run = 0;
>>>       auto nPixels = 0;
>>>       foreach (x; 0..size.x)
>>>       {
>>>            immutable SDL_FPair offset  = { center.x - x, y - center.y };
>>> ...
>>>
>>> and why does it violate the principle of making the right thing the
>>> easy thing to do?
>>>
>>
>> oo oo, is it that you didn't want x and y to be of type size_t?
> more specifically I didn't want them to be unsigned
> I am adapting the code from C++ code,
> coming from other Algol syntax languages. That one is a real
> gotcha. I tried explicitly making x and y ints and I got a depreciation warning.

You are performing an operation on memory, size_t is indeed what you wanted. It is an offset into the address space past another offset (the pointer).

You cannot fit the entire address space into an int, but a size_t value is guaranteed to be able to do this.

Hence size_t is the correct data type for indexes over a slice.

>> And why are you initializing run and nPixels manually?
> the value there so the compiler can figure out the type (auto)

You don't need to do this.

All D types are default initialized to a value.

int in this case will default initialize to 0, which is what you are doing explicitly.

On 6/20/20 12:00 PM, Danni Coy wrote:

> I tried explicitly making x and y ints and I got a depreciation warning.

foreach(ptrdiff_t y, ref row; offsetMap)

is that what you wanted?

ptrdiff_t is the signed version of size_t. The complaint is not that you are converting from unsigned to signed, but that you are converting from 64-bit to 32-bit.

-Steve

On Saturday, 20 June 2020 at 18:15:27 UTC, Steven Schveighoffer wrote:
> On 6/20/20 12:00 PM, Danni Coy wrote:
>
>> I tried explicitly making x and y ints and I got a depreciation warning.
>
> foreach(ptrdiff_t y, ref row; offsetMap)
>
> is that what you wanted?
>
> ptrdiff_t is the signed version of size_t. The complaint is not that you are converting from unsigned to signed, but that you are converting from 64-bit to 32-bit.
>
> -Steve

Why isn't that deprecated as well? implicitly converting from ulong to long is an error as much as ulong to uint.

On Sun, Jun 21, 2020 at 2:25 AM rikki cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 21/06/2020 4:00 AM, Danni Coy wrote:
> > On Sun, Jun 21, 2020 at 1:15 AM rikki cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >>
> >> On 21/06/2020 3:08 AM, Danni Coy wrote:
> >>> ...
> >>> foreach (y, ref row; offsetMap)
> >>> {
> >>>      auto run = 0;
> >>>       auto nPixels = 0;
> >>>       foreach (x; 0..size.x)
> >>>       {
> >>>            immutable SDL_FPair offset  = { center.x - x, y - center.y };
> >>> ...
> >>>
> >>> and why does it violate the principle of making the right thing the easy thing to do?
> >>>
> >>
> >> oo oo, is it that you didn't want x and y to be of type size_t?
> > more specifically I didn't want them to be unsigned
> > I am adapting the code from C++ code,
> > coming from other Algol syntax languages. That one is a real
> > gotcha. I tried explicitly making x and y ints and I got a depreciation warning.
>
> You are performing an operation on memory, size_t is indeed what you wanted. It is an offset into the address space past another offset (the pointer).

I am working with slices rather than with pointers directly.
In this case the maximum size of x or y I could possibly imagine being
useful is less than 64,000
realistic sizes for what I am doing are in the 10s or 100s.
This might not be the part I am most worried about.

> All D types are default initialized to a value.
>
> int in this case will default initialize to 0, which is what you are doing explicitly.

I can do
int nPixels;
or
auto nPixels = 0;

On Sun, Jun 21, 2020 at 9:40 AM Avrina via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Saturday, 20 June 2020 at 18:15:27 UTC, Steven Schveighoffer wrote:
> > On 6/20/20 12:00 PM, Danni Coy wrote:
> >
> >> I tried explicitly making x and y ints and I got a depreciation warning.
> >
> > foreach(ptrdiff_t y, ref row; offsetMap)
> >
> > is that what you wanted?
> >
> > ptrdiff_t is the signed version of size_t. The complaint is not that you are converting from unsigned to signed, but that you are converting from 64-bit to 32-bit.
> >
> > -Steve
>
> Why isn't that deprecated as well? implicitly converting from ulong to long is an error as much as ulong to uint.

It turns out this line is the bigger problem.

 immutable SDL_FPair offset  = { center.x - x, y - center.y };
FPair is a
struct SDL_FPair
{
    float x;
    float y;
...
if those values were ints.
dmd will not allow a downcast from ulong to int
(the compiler would have caught the issue for me)
but it will allow casting ulong to float which is why It took me a
couple of hours with a debugger
trying to find the bug.
So this turns out to be more of a corner case than I thought.
offset is a pair of floats because it's about to used in a bunch of
angle calculations and I wanted to minimise the number of casts.

On Saturday, 20 June 2020 at 23:36:25 UTC, Avrina wrote:
> On Saturday, 20 June 2020 at 18:15:27 UTC, Steven Schveighoffer wrote:
>> On 6/20/20 12:00 PM, Danni Coy wrote:
>>
>>> I tried explicitly making x and y ints and I got a depreciation warning.
>>
>> foreach(ptrdiff_t y, ref row; offsetMap)
>>
>> is that what you wanted?
>>
>> ptrdiff_t is the signed version of size_t. The complaint is not that you are converting from unsigned to signed, but that you are converting from 64-bit to 32-bit.
>>
>> -Steve
>
> Why isn't that deprecated as well? implicitly converting from ulong to long is an error as much as ulong to uint.

No. conversion of ulong to uint loses 32 times more data than conversion to long does.

On Sunday, 21 June 2020 at 10:12:22 UTC, Patrick Schluter wrote:
> On Saturday, 20 June 2020 at 23:36:25 UTC, Avrina wrote:
>> On Saturday, 20 June 2020 at 18:15:27 UTC, Steven Schveighoffer wrote:
>>> On 6/20/20 12:00 PM, Danni Coy wrote:
>>>
>>>> I tried explicitly making x and y ints and I got a depreciation warning.
>>>
>>> foreach(ptrdiff_t y, ref row; offsetMap)
>>>
>>> is that what you wanted?
>>>
>>> ptrdiff_t is the signed version of size_t. The complaint is not that you are converting from unsigned to signed, but that you are converting from 64-bit to 32-bit.
>>>
>>> -Steve
>>
>> Why isn't that deprecated as well? implicitly converting from ulong to long is an error as much as ulong to uint.
>
> No. conversion of ulong to uint loses 32 times more data than conversion to long does.

Lol, it's not linear friend.

You lose around 18446744069414584319 values from ulong to uint, you lose 9223372032559808512 from ulong to long. Which is about 2 times less data. Which makes sense as it is basically 2^64 - 2^63, so of course it would only be x2 -- not x32.