On 02/11/2023 15:07, bart wrote:
>
> On 02/11/2023 12:52, David Brown wrote:
> > On 02/11/2023 12:31, bart wrote:
>
> >> Is that a bad thing?
> >>
> >> I mean, which other current languages, other than C++, that have
> size-specific integer types, also have a set of 'least' and 'fast'
> versions?
> >>
> >> It doesn't seem to something that the creators of other languages
> lose sleep over.
> >>
> >> Those types appear to be relevant only to unusual architectures that
> only C bothers with.
> >>
> >
> > Like x86-64 ?
> >
> > I don't see any use of the "least" types, except on unusual
> architectures that don't support all of the common 8-bit, 16-bit, 32-bit
> and 64-bit types.  It's a good thing that C supports these
> architectures, because while some of these are outdated and of
> historical interest only, others are valid, active and popular within
> their niche markets.  It is understandable that most languages don't
> support them, but good that C does.
> >
> > The "fast" types are more useful.  They can be very helpful when
> making code that works well across different target sizes, as is very
> common in libraries for embedded development, reducing or avoiding the
> mess of "port" includes and library-specific type names.  And on bigger
> systems, such as normal PC's, they give you more efficient code while
> saying explicitly what you are looking for in the type.
> >
> > So on x86-64 for Linux, "int_fast16_t" and "int_fast32_t" are both
> 64-bit.  On x86-64 for Windows, since Windows always likes to be
> different from everyone else, "int_fast16_t" and "int_fast32_t" are both
> 32-bit.
>
> So what were the reasons for Linux to use 64 bits for int_fast16_t and
> Windows to use 32 bits?
>

I am not privy to the decision-making processes. But I expect Linux
x86-64 (and almost every other 64-bit compiler I checked on godbolt,
apart from Windows) does this because using 64-bit registers is faster
in at least some cases. Typically it helps avoid things like sign or
zero extension when loading a register, and can probably simplify some
instruction formats (depending on the target). I believe pointer +
offset calculations are more efficient with native size for the offset.

MS probably aimed for consistency with their 32-bit ABI, rather than
making better use of 64-bit facilities, just as they did with "long". I
wonder if they are regretting that decision these days?

Both Linux and Windows use 32-bit for "int_fast16_t" in 32-bit targets.
And all use 8-bit for "int_fast8_t", as far as I saw - I suppose most
8-bit values get promoted to "int" before most use-cases anyway.

> If I wanted an array of 100M int_fast16_t types, I would guess that an
> actual 16-bit type is faster than either 32 or 64 bits because it uses a
> lot less memory.

Yes. int_fast16_t is the wrong type to use for an array. The "fast"
types make sense for local variables and perhaps some solitary
statically allocated data. They are fast in registers, not in memory.
For arrays (other than tiny ones), cache effects mean that small is
fast, and thus "int_least16_t" is going to be the fastest type
supporting 16-bit values. (And as noted previously, this will be the
same as int16_t on all but specialised targets.)

>
> But for individual calculations, both 16-bit and 64-bit instructions
> frequently need an extra prefix byte over 32 bits. This is not
> necessarily faster, but overall there will be less code.
>

On x86-64, these prefixes usually get swallowed so early in the
instruction decode that they make no difference to the speed, unless you
get enough of them for the extra cache load to be relevant.

> So for both these cases, Windows' 32 bits make more sense than 64.
>

People who know far more about this than me, and even more than you (I
know you are more familiar with the details of x86-64 instructions than
I am), and who care about efficiency more than Microsoft (for whom
consistency with old flaws is more important than efficiency of new
systems), picked 8-byte types for the "fast" types on 64-bit systems. I
am confident that they did so on more evidence and technical data than
we have here.

Of course there will be situations when 32-bit types will be faster than
64-bit types - such decisions are based on statistical information and
common patterns, and will never be perfect in all circumstances.

> (If I look at the actual stdint.h for mingw, int16_t is just 'short'. On
> my WSL, inside /usr/include/stdint.h, it is defined on top of long,
> which may be 32 or 64 bits.)
>

"int16_t" must be exactly 16 bits, and many <stdint.h> files will define
it based on "short int". It will not be based on "long", unless using
some unusual compiler extensions. (In the AVR port of gcc, the usual
<stdint.h> defines all the types as typedefs of "int" with gcc
attributes to control the size. I don't know why it does that, and I
haven't seen it elsewhere.)

On 11/2/2023 2:04 AM, David Brown wrote:
> On 01/11/2023 20:52, Chris M. Thomasson wrote:
>> On 11/1/2023 12:12 PM, David Brown wrote:
>
>>> I am immediately suspicious of any cryptography that is dependent on
>>> a character set, never mind the order of it - it sounds fragile.
>>> Cryptography that can't deal with arbitrary data hasn't been much use
>>> since WWII.
>>
>> Never use this funny toy of mine, (Funny Fractal Encryption (FFE)) as
>> a real encryption implement, NEVER! It was for fun, not for serious
>> work at all. Now, I do have an experimental encryption that I think
>> can potentially be used. Have you seen this before?
>>
>> https://groups.google.com/g/comp.lang.c/c/a53VxN8cwkY/m/XKl1-0a8DAAJ
>>
>> Fwiw, here is a hyper crude write up I did:
>>
>> http://funwithfractals.atspace.cc/ct_cipher
>>
>> What do you think? Crap, or kind of crap?
>>
>> ;^)
>>
>
> I am not a cryptography expert, but I am leaning towards the first
> choice :-)  I realise it is "pre-alpha version 0.0.0", and more playing
> with ideas than serious encryption.  But I can give you a couple of
> points and suggestions, which might be of use to you.
>
> First, cryptography is mathematics.  It makes things clearer if your
> algorithms are written mathematically.  The algorithms are not code -
> they are maths, and good typography and good naming in maths is
> different from good layout and good naming in programming.  And clear
> expressions are much better than descriptions in text.
>
> So don't write
>     Set I_P is used as an index for P, set it to zero.
>
> Prefer
>     iₚ ← 0
>
> (Use the best layout tools you are familiar with - raw html, LaTeX,
> LibreOffice's formula editors, whatever.)
>
> Don't think in C - think in mathematics.  So don't invent arrays and
> variables and change them, but write expressions and name them - then
> leave them unchanged.  Rather than "Prepend R to P", write "Pʹ ← R ++ P"
> and introduce a new name.  It is /hugely/ easier to comprehend the
> algorithm, and prove its correctness and other features, when you do this.
>
>
> Then there are some basic cryptography rules.  Your main hash algorithm
> has a certain size of output, such as 32-byte (for SHA-256).  There is
> then no point in using a key that has more than 256 bits of entropy, nor
> is there any point in using random salt with more entropy than that -
> you are simply guaranteeing duplications.  If the key is expected to be
> plain text that people can remember, then it needs to be much longer to
> get 256 bits of entropy (you use a long low-entropy text, then run it
> though a secure hash to get a condensed key with high relative entropy).
>
>
> As far as I can tell, the guts of your idea is that you are doing a
> sliding xor encryption but changing that encryption key as you go along,
> based on feeding the message into a hash function.  It's an interesting
> idea, but I don't think it is actually a good thing - I suspect it
> actually decreases the effectiveness of the encryption, and my gut
> feeling is that carefully crafted plain texts can be used as an attack
> to get the encryption key out.  But you'd be better asking a real
> cryptologist about that.
>
>
> Don't let that stop you playing around with these, however - there's
> always fun to be had with this kind of thing.
>
>
>

Thank you David. Crap is as it is... Simply because its never been
properly examined by professionals! Sigh... Btw, did you find some time
to run my example Python program? Btw, thanks for all of your advise on
how to improve my hyper crude little write up. Thanks man. Fwiw, here is
my little python experimental implementation of ver:0.0.0 (Pre-Alpha)

_____________________________
# Chris M. Thomasson Copyright 2018 (c)
# Experimental HMAC Cipher
#____________________________________________________________

# Our external libs
#____________________________________________________________
import random;
import hashlib;
import hmac;

# Some Utilities
#____________________________________________________________
def ct_bytes_to_hex(origin, offset):
hex = "";
n = len(origin);
t = "0123456789ABCDEF";
for i in range(offset, n):
c = ord(origin[i]);
nibl = c & 0x0F;
nibh = (c & 0xF0) >> 4;
hex = hex + t[nibh];
hex = hex + t[nibl];
hex = hex + " ";
if (not ((i + 1) % 16) and i != n - 1):
hex = hex + "\r\n";
return hex;

# Generate n random bytes
# These need should ideally be from a truly random, non-repeatable
# source. TRNG!
def ct_rand_bytes(n):
rb = "";
for i in range(n):
rb = rb + chr(random.randint(0, 255));
return rb;

# The Secret Key
# Contains all the parts of the secret key
#____________________________________________________________
class ct_secret_key:
def __init__(self, hmac_key, hash_algo, rand_n):
self.hmac_key = hmac_key;
self.hash_algo = hash_algo;
self.rand_n = rand_n;

def __repr__(self):
return "hmac_key:%s\nhash_algo:%s\nrand_n:%s" %
(ct_bytes_to_hex(self.hmac_key, 0), self.hash_algo, self.rand_n);

def __str__(self): return self.__repr__();

# The Ciphertext or Plaintext
# It holds the bytes of a ciphertext or a plaintext
#____________________________________________________________
class ct_bin:
def __init__(self, ctxt):
self.bytes = ctxt;
def __repr__(self):
return "%s" % (ct_bytes_to_hex(self.bytes, 0));

def __str__(self): return self.__repr__();

# The Crypt Round Function
#____________________________________________________________
def ct_crypt_round(SK, P, M):
H = hmac.new(SK.hmac_key.encode(), None, SK.hash_algo);
H.update(SK.hmac_key[::-1].encode());
C = "";
I_P = 0;
I_P_N = len(P.bytes);
while (I_P < I_P_N):
D = H.digest();
I_D = 0;
I_D_N = len(D);
while (I_P < I_P_N and I_D < I_D_N):
C_I_P = ord(P.bytes[I_P]) ^ D[I_D];
C = C + chr(C_I_P);
if (M == False):
H.update(P.bytes[I_P].encode());
H.update(chr(C_I_P).encode());
else:
H.update(chr(C_I_P).encode());
H.update(P.bytes[I_P].encode());
I_P = I_P + 1;
I_D = I_D + 1;
return ct_bin(C);

# The Crypt Function
#____________________________________________________________
def ct_crypt(SK, P, M):
if (M == False):
R = ct_rand_bytes(SK.rand_n);
P.bytes = R + P.bytes;
C = ct_crypt_round(SK, P, M);
C_1 = ct_bin(C.bytes[::-1]);
C = ct_crypt_round(SK, C_1, M);
if (M == True):
size = len(C.bytes) - SK.rand_n;
C.bytes = C.bytes[SK.rand_n : SK.rand_n + size];
return C;

# The Main Program
#____________________________________________________________

# Alice and Bob's Secret Key
#____________________
SK = ct_secret_key(
"This is the HMAC Key. It should be a crypto secure key! Damn it.",
hashlib.sha384, # The hash function. It should be a crypto secure hash.
73 # The number of bytes. The should be generated by a TRNG
);
print("%s" % (SK));

# Alice's Plaintext
#____________________
Original_Plaintext =
"ABCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCDE";
A_P = ct_bin(Original_Plaintext);
print(
"\n\nAlice's Plaintext Bytes:"
"\n____________________\n%s\n" % (A_P)
);

# Encrypt
#____________________
C = ct_crypt(SK, A_P, False);
print(
"\n\nCiphertext Bytes:"
"\n____________________\n%s\n" % (C)
);

# Decrypt
#____________________
B_P = ct_crypt(SK, C, True);
print(
"\n\nBob's Ciphertext Bytes:"
"\n____________________\n%s\n" % (B_P)
);

if (B_P.bytes != Original_Plaintext):
print("DATA CORRUPTED!");
_____________________________

Btw, David, when you get some free time, can you critique my python
here? Thanks.

:^)

On 11/2/2023 10:51 AM, Chris M. Thomasson wrote:
> On 11/2/2023 2:04 AM, David Brown wrote:
>> On 01/11/2023 20:52, Chris M. Thomasson wrote:
>>> On 11/1/2023 12:12 PM, David Brown wrote:
>>
>>>> I am immediately suspicious of any cryptography that is dependent on
>>>> a character set, never mind the order of it - it sounds fragile.
>>>> Cryptography that can't deal with arbitrary data hasn't been much
>>>> use since WWII.
>>>
>>> Never use this funny toy of mine, (Funny Fractal Encryption (FFE)) as
>>> a real encryption implement, NEVER! It was for fun, not for serious
>>> work at all. Now, I do have an experimental encryption that I think
>>> can potentially be used. Have you seen this before?
>>>
>>> https://groups.google.com/g/comp.lang.c/c/a53VxN8cwkY/m/XKl1-0a8DAAJ
>>>
>>> Fwiw, here is a hyper crude write up I did:
>>>
>>> http://funwithfractals.atspace.cc/ct_cipher
>>>
>>> What do you think? Crap, or kind of crap?
>>>
>>> ;^)
>>>
>>
>> I am not a cryptography expert, but I am leaning towards the first
>> choice :-)  I realise it is "pre-alpha version 0.0.0", and more
>> playing with ideas than serious encryption.  But I can give you a
>> couple of points and suggestions, which might be of use to you.
>>
>> First, cryptography is mathematics.  It makes things clearer if your
>> algorithms are written mathematically.  The algorithms are not code -
>> they are maths, and good typography and good naming in maths is
>> different from good layout and good naming in programming.  And clear
>> expressions are much better than descriptions in text.
>>
>> So don't write
>>      Set I_P is used as an index for P, set it to zero.
>>
>> Prefer
>>      iₚ ← 0
>>
>> (Use the best layout tools you are familiar with - raw html, LaTeX,
>> LibreOffice's formula editors, whatever.)
>>
>> Don't think in C - think in mathematics.  So don't invent arrays and
>> variables and change them, but write expressions and name them - then
>> leave them unchanged.  Rather than "Prepend R to P", write "Pʹ ← R ++ P"
>> and introduce a new name.  It is /hugely/ easier to comprehend the
>> algorithm, and prove its correctness and other features, when you do
>> this.
>>
>>
>> Then there are some basic cryptography rules.  Your main hash
>> algorithm has a certain size of output, such as 32-byte (for
>> SHA-256).  There is then no point in using a key that has more than
>> 256 bits of entropy, nor is there any point in using random salt with
>> more entropy than that - you are simply guaranteeing duplications.  If
>> the key is expected to be plain text that people can remember, then it
>> needs to be much longer to get 256 bits of entropy (you use a long
>> low-entropy text, then run it though a secure hash to get a condensed
>> key with high relative entropy).
>>
>>
>> As far as I can tell, the guts of your idea is that you are doing a
>> sliding xor encryption but changing that encryption key as you go
>> along, based on feeding the message into a hash function.  It's an
>> interesting idea, but I don't think it is actually a good thing - I
>> suspect it actually decreases the effectiveness of the encryption, and
>> my gut feeling is that carefully crafted plain texts can be used as an
>> attack to get the encryption key out.  But you'd be better asking a
>> real cryptologist about that.
>>
>>
>> Don't let that stop you playing around with these, however - there's
>> always fun to be had with this kind of thing.
>>
>>
>>
>
> Thank you David. Crap is as it is... Simply because its never been
> properly examined by professionals! Sigh... Btw, did you find some time
> to run my example Python program? Btw, thanks for all of your advise on
> how to improve my hyper crude little write up. Thanks man. Fwiw, here is
> my little python experimental implementation of ver:0.0.0 (Pre-Alpha)
[...]
> Btw, David, when you get some free time, can you critique my python
> here? Thanks.

Oops! Sorry for that dumb ass comment! Why would you critique my python
code and post it here. Sorry! ;^o

>
> :^)

On 02/11/2023 19:02, Chris M. Thomasson wrote:
> On 11/2/2023 10:51 AM, Chris M. Thomasson wrote:
>> On 11/2/2023 2:04 AM, David Brown wrote:
>>> On 01/11/2023 20:52, Chris M. Thomasson wrote:
>>>> On 11/1/2023 12:12 PM, David Brown wrote:
>>>
>>>>> I am immediately suspicious of any cryptography that is dependent
>>>>> on a character set, never mind the order of it - it sounds fragile.
>>>>> Cryptography that can't deal with arbitrary data hasn't been much
>>>>> use since WWII.
>>>>
>>>> Never use this funny toy of mine, (Funny Fractal Encryption (FFE))
>>>> as a real encryption implement, NEVER! It was for fun, not for
>>>> serious work at all. Now, I do have an experimental encryption that
>>>> I think can potentially be used. Have you seen this before?
>>>>
>>>> https://groups.google.com/g/comp.lang.c/c/a53VxN8cwkY/m/XKl1-0a8DAAJ
>>>>
>>>> Fwiw, here is a hyper crude write up I did:
>>>>
>>>> http://funwithfractals.atspace.cc/ct_cipher
>>>>
>>>> What do you think? Crap, or kind of crap?
>>>>
>>>> ;^)
>>>>
>>>
>>> I am not a cryptography expert, but I am leaning towards the first
>>> choice :-)  I realise it is "pre-alpha version 0.0.0", and more
>>> playing with ideas than serious encryption.  But I can give you a
>>> couple of points and suggestions, which might be of use to you.
>>>
>>> First, cryptography is mathematics.  It makes things clearer if your
>>> algorithms are written mathematically.  The algorithms are not code -
>>> they are maths, and good typography and good naming in maths is
>>> different from good layout and good naming in programming.  And clear
>>> expressions are much better than descriptions in text.
>>>
>>> So don't write
>>>      Set I_P is used as an index for P, set it to zero.
>>>
>>> Prefer
>>>      iₚ ← 0
>>>
>>> (Use the best layout tools you are familiar with - raw html, LaTeX,
>>> LibreOffice's formula editors, whatever.)
>>>
>>> Don't think in C - think in mathematics.  So don't invent arrays and
>>> variables and change them, but write expressions and name them - then
>>> leave them unchanged.  Rather than "Prepend R to P", write "Pʹ ← R ++ P"
>>> and introduce a new name.  It is /hugely/ easier to comprehend the
>>> algorithm, and prove its correctness and other features, when you do
>>> this.
>>>
>>>
>>> Then there are some basic cryptography rules.  Your main hash
>>> algorithm has a certain size of output, such as 32-byte (for
>>> SHA-256).  There is then no point in using a key that has more than
>>> 256 bits of entropy, nor is there any point in using random salt with
>>> more entropy than that - you are simply guaranteeing duplications.
>>> If the key is expected to be plain text that people can remember,
>>> then it needs to be much longer to get 256 bits of entropy (you use a
>>> long low-entropy text, then run it though a secure hash to get a
>>> condensed key with high relative entropy).
>>>
>>>
>>> As far as I can tell, the guts of your idea is that you are doing a
>>> sliding xor encryption but changing that encryption key as you go
>>> along, based on feeding the message into a hash function.  It's an
>>> interesting idea, but I don't think it is actually a good thing - I
>>> suspect it actually decreases the effectiveness of the encryption,
>>> and my gut feeling is that carefully crafted plain texts can be used
>>> as an attack to get the encryption key out.  But you'd be better
>>> asking a real cryptologist about that.
>>>
>>>
>>> Don't let that stop you playing around with these, however - there's
>>> always fun to be had with this kind of thing.
>>>
>>>
>>>
>>
>> Thank you David. Crap is as it is... Simply because its never been
>> properly examined by professionals! Sigh... Btw, did you find some
>> time to run my example Python program? Btw, thanks for all of your
>> advise on how to improve my hyper crude little write up. Thanks man.
>> Fwiw, here is my little python experimental implementation of
>> ver:0.0.0 (Pre-Alpha)
> [...]
>> Btw, David, when you get some free time, can you critique my python
>> here? Thanks.
>
> Oops! Sorry for that dumb ass comment! Why would you critique my python
> code and post it here. Sorry! ;^o
>

I can't promise I'll get time to try any of the code (C or Python), or
critique them. But I hope my comments on the algorithm and how to
describe it are helpful to you.

On 11/2/2023 12:02 PM, David Brown wrote:
> On 02/11/2023 19:02, Chris M. Thomasson wrote:
>> On 11/2/2023 10:51 AM, Chris M. Thomasson wrote:
>>> On 11/2/2023 2:04 AM, David Brown wrote:
>>>> On 01/11/2023 20:52, Chris M. Thomasson wrote:
>>>>> On 11/1/2023 12:12 PM, David Brown wrote:
>>>>
>>>>>> I am immediately suspicious of any cryptography that is dependent
>>>>>> on a character set, never mind the order of it - it sounds
>>>>>> fragile. Cryptography that can't deal with arbitrary data hasn't
>>>>>> been much use since WWII.
>>>>>
>>>>> Never use this funny toy of mine, (Funny Fractal Encryption (FFE))
>>>>> as a real encryption implement, NEVER! It was for fun, not for
>>>>> serious work at all. Now, I do have an experimental encryption that
>>>>> I think can potentially be used. Have you seen this before?
>>>>>
>>>>> https://groups.google.com/g/comp.lang.c/c/a53VxN8cwkY/m/XKl1-0a8DAAJ
>>>>>
>>>>> Fwiw, here is a hyper crude write up I did:
>>>>>
>>>>> http://funwithfractals.atspace.cc/ct_cipher
>>>>>
>>>>> What do you think? Crap, or kind of crap?
>>>>>
>>>>> ;^)
>>>>>
>>>>
>>>> I am not a cryptography expert, but I am leaning towards the first
>>>> choice :-)  I realise it is "pre-alpha version 0.0.0", and more
>>>> playing with ideas than serious encryption.  But I can give you a
>>>> couple of points and suggestions, which might be of use to you.
>>>>
>>>> First, cryptography is mathematics.  It makes things clearer if your
>>>> algorithms are written mathematically.  The algorithms are not code
>>>> - they are maths, and good typography and good naming in maths is
>>>> different from good layout and good naming in programming.  And
>>>> clear expressions are much better than descriptions in text.
>>>>
>>>> So don't write
>>>>      Set I_P is used as an index for P, set it to zero.
>>>>
>>>> Prefer
>>>>      iₚ ← 0
>>>>
>>>> (Use the best layout tools you are familiar with - raw html, LaTeX,
>>>> LibreOffice's formula editors, whatever.)
>>>>
>>>> Don't think in C - think in mathematics.  So don't invent arrays and
>>>> variables and change them, but write expressions and name them -
>>>> then leave them unchanged.  Rather than "Prepend R to P", write "Pʹ
>>>> ← R ++ P"
>>>> and introduce a new name.  It is /hugely/ easier to comprehend the
>>>> algorithm, and prove its correctness and other features, when you do
>>>> this.
>>>>
>>>>
>>>> Then there are some basic cryptography rules.  Your main hash
>>>> algorithm has a certain size of output, such as 32-byte (for
>>>> SHA-256).  There is then no point in using a key that has more than
>>>> 256 bits of entropy, nor is there any point in using random salt
>>>> with more entropy than that - you are simply guaranteeing
>>>> duplications. If the key is expected to be plain text that people
>>>> can remember, then it needs to be much longer to get 256 bits of
>>>> entropy (you use a long low-entropy text, then run it though a
>>>> secure hash to get a condensed key with high relative entropy).
>>>>
>>>>
>>>> As far as I can tell, the guts of your idea is that you are doing a
>>>> sliding xor encryption but changing that encryption key as you go
>>>> along, based on feeding the message into a hash function.  It's an
>>>> interesting idea, but I don't think it is actually a good thing - I
>>>> suspect it actually decreases the effectiveness of the encryption,
>>>> and my gut feeling is that carefully crafted plain texts can be used
>>>> as an attack to get the encryption key out.  But you'd be better
>>>> asking a real cryptologist about that.
>>>>
>>>>
>>>> Don't let that stop you playing around with these, however - there's
>>>> always fun to be had with this kind of thing.
>>>>
>>>>
>>>>
>>>
>>> Thank you David. Crap is as it is... Simply because its never been
>>> properly examined by professionals! Sigh... Btw, did you find some
>>> time to run my example Python program? Btw, thanks for all of your
>>> advise on how to improve my hyper crude little write up. Thanks man.
>>> Fwiw, here is my little python experimental implementation of
>>> ver:0.0.0 (Pre-Alpha)
>> [...]
>>> Btw, David, when you get some free time, can you critique my python
>>> here? Thanks.
>>
>> Oops! Sorry for that dumb ass comment! Why would you critique my
>> python code and post it here. Sorry! ;^o
>>
>
> I can't promise I'll get time to try any of the code (C or Python), or
> critique them.  But I hope my comments on the algorithm and how to
> describe it are helpful to you.

Very helpful. Thanks again, David. :^)

On 02/11/2023 15:53, David Brown wrote:
> On 02/11/2023 15:07, bart wrote:

>> So what were the reasons for Linux to use 64 bits for int_fast16_t
and Windows to use 32 bits?
>>

>> So for both these cases, Windows' 32 bits make more sense than 64.
>>
>
> People who know far more about this than me, and even more than you
(I know you are more familiar with the details of x86-64 instructions
than I am), and who care about efficiency more than Microsoft (for whom
consistency with old flaws is more important than efficiency of new
systems), picked 8-byte types for the "fast" types on 64-bit systems. I
am confident that they did so on more evidence and technical data than
we have here.

This is in line with my idea that using a 64-bit 'int' in C would have
been better, as discussed earlier in the year. As it is, 'int' is
usually 32 bits, and is still used extensively in programs rather than
explicitly requesting a 64-bit type.

It would eliminate a lot of problems, and perhaps fixed some of the
issues in the OP's program.

>
> Of course there will be situations when 32-bit types will be faster
than 64-bit types - such decisions are based on statistical information
and common patterns, and will never be perfect in all circumstances.
>
>> (If I look at the actual stdint.h for mingw, int16_t is just
'short'. On my WSL, inside /usr/include/stdint.h, it is defined on top
of long, which may be 32 or 64 bits.)
>>
>
> "int16_t" must be exactly 16 bits, and many <stdint.h> files will
define it based on "short int". It will not be based on "long", unless
using some unusual compiler extensions. (In the AVR port of gcc, the
usual <stdint.h> defines all the types as typedefs of "int" with gcc
attributes to control the size. I don't know why it does that, and I
haven't seen it elsewhere.)

Sorry, I meant 'int_fast16_t' was defined as 'short' on mingw and 'long'
on WSL.

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

> On 11/2/2023 2:04 AM, David Brown wrote:
>> First, cryptography is mathematics.  It makes things clearer if your
>> algorithms are written mathematically.
....
>> Don't let that stop you playing around with these, however - there's
>> always fun to be had with this kind of thing.
>
> Thank you David. Crap is as it is... Simply because its never been properly
> examined by professionals! Sigh...

There's a chicken-and-egg situation here. No professional will examine
it while it's "crap" so if it's crap through lack of review it will
remain so. In fact, no professional cryptographer will review it when
the fundamental algorithm is unspecified. To be taken seriously you
need to specify the method, as David says, mathematically. (I think you
had a go once in sci.crypt though that might have been for a different
algorithm.)

Anyway, also as David says, you can still have fun.

--
Ben.

bart <bc@freeuk.com> writes:

> On 02/11/2023 09:52, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 31/10/2023 00:52, Ben Bacarisse wrote:
>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>
>>>>> This has to be undefined behavior. Check it out:
>>>>>
>>>>> Here is my C code for a fun toy experimental fractal:
>>>>>
>>>>> https://pastebin.com/raw/fcV5YiJH
>>>>> (raw link to text...)
>>>> Ask your compiler for the maximum number of warnings and you should see
>>>> lots. For some reason you are mixing types in a peculiar way, and since
>>>> some of those types often have different sizes you will get different
>>>> arithmetic results on different systems.
>>>>
>>>>> The cpack is different on the two different compilers. Oh, that is always
>>>>> fun!
>>>> You need to decide what integer types you really want.
>>>
>>> And the sane way to do that is to stick strictly to <stdint.h> types, so
>>> that the sizes are independent of the compiler and platform.
>> Hmm... I would not want to say that exactly. Firstly, it perpetuates
>> the misconception that stdint.h only defines the exact-width types
>> helping the world to forget about the [u]int_(least|fast)N_t types!
>
> Is that a bad thing?

Yes.

> I mean, which other current languages, other than C++, that have
> size-specific integer types, also have a set of 'least' and 'fast'
> versions?
>
> It doesn't seem to [be] something that the creators of other languages
> lose sleep over.

They don't seem to, no. I wonder if the fact that C remains one of the
most widely used programming languages is in any way related to that.

> Those types appear to be relevant only to unusual architectures that only C
> bothers with.
>
>> Secondly, lots of algorithms can be written perfectly well using C's
>> ordinary types. The key is to know what the type names mean.
>
> Not this one.

I am 100% sure that you don't know that to be the case. Why? Because I
am 100% sure that not even Chris knows what the actual algorithm is.
You may be right, and if anyone ever specifies the algorithm we may even
be able to determine the facts of the matter, but we can't do so now.

--
Ben.

On 11/2/2023 1:43 PM, Ben Bacarisse wrote:
> bart <bc@freeuk.com> writes:
>
>> On 02/11/2023 09:52, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 31/10/2023 00:52, Ben Bacarisse wrote:
>>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>>
>>>>>> This has to be undefined behavior. Check it out:
>>>>>>
>>>>>> Here is my C code for a fun toy experimental fractal:
>>>>>>
>>>>>> https://pastebin.com/raw/fcV5YiJH
>>>>>> (raw link to text...)
>>>>> Ask your compiler for the maximum number of warnings and you should see
>>>>> lots. For some reason you are mixing types in a peculiar way, and since
>>>>> some of those types often have different sizes you will get different
>>>>> arithmetic results on different systems.
>>>>>
>>>>>> The cpack is different on the two different compilers. Oh, that is always
>>>>>> fun!
>>>>> You need to decide what integer types you really want.
>>>>
>>>> And the sane way to do that is to stick strictly to <stdint.h> types, so
>>>> that the sizes are independent of the compiler and platform.
>>> Hmm... I would not want to say that exactly. Firstly, it perpetuates
>>> the misconception that stdint.h only defines the exact-width types
>>> helping the world to forget about the [u]int_(least|fast)N_t types!
>>
>> Is that a bad thing?
>
> Yes.
>
>> I mean, which other current languages, other than C++, that have
>> size-specific integer types, also have a set of 'least' and 'fast'
>> versions?
>>
>> It doesn't seem to [be] something that the creators of other languages
>> lose sleep over.
>
> They don't seem to, no. I wonder if the fact that C remains one of the
> most widely used programming languages is in any way related to that.
>
>> Those types appear to be relevant only to unusual architectures that only C
>> bothers with.
>>
>>> Secondly, lots of algorithms can be written perfectly well using C's
>>> ordinary types. The key is to know what the type names mean.
>>
>> Not this one.
>
> I am 100% sure that you don't know that to be the case. Why? Because I
> am 100% sure that not even Chris knows what the actual algorithm is.

Basically, my Funny Fractal Encryption is based on Julia sets. I was
just poking around having fun wrt trying to use an escape time version
as a form of encryption. So, there is no set algorithm. You are
basically right.

http://funwithfractals.atspace.cc/ffe/

0.23046159622517684 0.3470667287528152
0.25771116242735903 0.10157512574580697

45 2F 4D 81 0F 38 05 2A 4C 8D A2 CB E8 4C 07 99 2A 82 CD CB 36 E6 E3 16
7C 69 87 C3 81 2B E3 B6 76 C5 5B 7D F4 8E D0 23 8D 68 3E B4 49 FD FB 00
95 2A 92 3F 48 F3 5C 36 F9 38 9D 72 4E 1E 06 32 0D 93 27 36 5A A0 C9 64
86 71 DA CA 78 E3 02 71 B7 D0 39 18 77 59 E1 E1 EF 6D F1 4E AA 8C CE EE
AC A0 CB 34 77 94 20 F6 0C 18 C5 A0 CF FE 1C E0 49 1E C8 92 6F B2 B3 42
20 AD 7F 40 27 84 0C 40 80 75 D2 68 6E B7 89 3C D7 7C 7C D8 6C 84 3E 6C
4D A3 0B 74 18 FC CE 09 91 54 86 F8 21 F9 00 68 B1 B7 67 29 4E 4A CD 16
CF 1E 74 0E EF 79 FD 07 83 E1 93 0E 97 19 B6 64 85 C2 98 52 3D FA 71 DF
61 DA 4E 7E 43 B0 17 E8 A1 07 9A 04 2E C5 B4 87 36 63 68 FE BC 35 82 77
F5 30 B1 4C

> You may be right, and if anyone ever specifies the algorithm we may even
> be able to determine the facts of the matter, but we can't do so now.
>

On 02/11/2023 21:28, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>
>> On 11/2/2023 2:04 AM, David Brown wrote:
>>> First, cryptography is mathematics.  It makes things clearer if your
>>> algorithms are written mathematically.
> ...
>>> Don't let that stop you playing around with these, however - there's
>>> always fun to be had with this kind of thing.
>>
>> Thank you David. Crap is as it is... Simply because its never been properly
>> examined by professionals! Sigh...
>
> There's a chicken-and-egg situation here. No professional will examine
> it while it's "crap" so if it's crap through lack of review it will
> remain so. In fact, no professional cryptographer will review it when
> the fundamental algorithm is unspecified. To be taken seriously you
> need to specify the method, as David says, mathematically. (I think you
> had a go once in sci.crypt though that might have been for a different
> algorithm.)
>
> Anyway, also as David says, you can still have fun.
>

And it's also worth remembering that not all encryption needs to be
"professional" to be useful. Sometimes a quick and simple scheme is
good enough. There's plenty of scope for ideas that give some basic
encryption with implementations that are very efficient on some level of
hardware (whether it be tuned to the latest x86-64 SIMD units or to
small microcontrollers).

(Not that Chris' current scheme is quick or simple!)

On 02/11/2023 20:15, bart wrote:
>
> On 02/11/2023 15:53, David Brown wrote:
> > On 02/11/2023 15:07, bart wrote:
>
> >> So what were the reasons for Linux to use 64 bits for int_fast16_t
> and Windows to use 32 bits?
> >>
>
> >> So for both these cases, Windows' 32 bits make more sense than 64.
> >>
> >
> > People who know far more about this than me, and even more than you
> (I know you are more familiar with the details of x86-64 instructions
> than I am), and who care about efficiency more than Microsoft (for whom
> consistency with old flaws is more important than efficiency of new
> systems), picked 8-byte types for the "fast" types on 64-bit systems.  I
> am confident that they did so on more evidence and technical data than
> we have here.
>
> This is in line with my idea that using a 64-bit 'int' in C would have
> been better, as discussed earlier in the year. As it is, 'int' is
> usually 32 bits, and is still used extensively in programs rather than
> explicitly requesting a 64-bit type.
>

Yes. I think you have some good arguments for 64-bit "int". I think,
however, the need for 8-bit, 16-bit, 32-bit and 64-bit sizes effectively
rules that out for C - it seems no one wants to add extended integer
types to make this work. (I once saw an April Fool's proposal to add
"long short int", "short long int", and endless combinations to C in
order to generate types of any sizes. But I can't find it at the moment.)

> It would eliminate a lot of problems, and perhaps fixed some of the
> issues in the OP's program.
>

True, but it would add many other challenges - not least of which no
mainstream C compiler supports them. "int64_t" and "uint64_t", however,
/are/ well supported.

> >
> > Of course there will be situations when 32-bit types will be faster
> than 64-bit types - such decisions are based on statistical information
> and common patterns, and will never be perfect in all circumstances.
> >
> >> (If I look at the actual stdint.h for mingw, int16_t is just
> 'short'. On my WSL, inside /usr/include/stdint.h, it is defined on top
> of long, which may be 32 or 64 bits.)
> >>
> >
> > "int16_t" must be exactly 16 bits, and many <stdint.h> files will
> define it based on "short int".  It will not be based on "long", unless
> using some unusual compiler extensions.  (In the AVR port of gcc, the
> usual <stdint.h> defines all the types as typedefs of "int" with gcc
> attributes to control the size.  I don't know why it does that, and I
> haven't seen it elsewhere.)
>
> Sorry, I meant 'int_fast16_t' was defined as 'short' on mingw and 'long'
> on WSL.
>

OK.

Of course, the <stdint.h> headers are tied tightly to the
implementation, and are not intended to be portable across systems - the
"mingw" folks know the size of "long" on their target and can rely on
that. They don't have to be concerned about it being 32-bit on some
platforms and 64-bit on others.

The smarter thing to do, at least for GCC, is to use the built-in
pre-defined types like "__INT_FAST16_TYPE__". These are pre-defined by
the compiler, precisely to make the implementation of <stdint.h> easy,
reliable and portable across targets.

David Brown <david.brown@hesbynett.no> writes:

> On 02/11/2023 21:28, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>
>>> On 11/2/2023 2:04 AM, David Brown wrote:
>>>> First, cryptography is mathematics.  It makes things clearer if your
>>>> algorithms are written mathematically.
>> ...
>>>> Don't let that stop you playing around with these, however - there's
>>>> always fun to be had with this kind of thing.
>>>
>>> Thank you David. Crap is as it is... Simply because its never been properly
>>> examined by professionals! Sigh...
>> There's a chicken-and-egg situation here. No professional will examine
>> it while it's "crap" so if it's crap through lack of review it will
>> remain so. In fact, no professional cryptographer will review it when
>> the fundamental algorithm is unspecified. To be taken seriously you
>> need to specify the method, as David says, mathematically. (I think you
>> had a go once in sci.crypt though that might have been for a different
>> algorithm.)
>> Anyway, also as David says, you can still have fun.
>
> And it's also worth remembering that not all encryption needs to be
> "professional" to be useful. Sometimes a quick and simple scheme is good
> enough. There's plenty of scope for ideas that give some basic encryption
> with implementations that are very efficient on some level of hardware

My feeling is that it's the "proper" encryption that has to be
efficient -- encrypting all hard drive traffic, backups, net
communication, bulk emails and so on. The "good enough" sort can
probably be inefficient.

--
Ben.

On 03/11/2023 11:10, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 02/11/2023 21:28, Ben Bacarisse wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>
>>>> On 11/2/2023 2:04 AM, David Brown wrote:
>>>>> First, cryptography is mathematics.  It makes things clearer if your
>>>>> algorithms are written mathematically.
>>> ...
>>>>> Don't let that stop you playing around with these, however - there's
>>>>> always fun to be had with this kind of thing.
>>>>
>>>> Thank you David. Crap is as it is... Simply because its never been properly
>>>> examined by professionals! Sigh...
>>> There's a chicken-and-egg situation here. No professional will examine
>>> it while it's "crap" so if it's crap through lack of review it will
>>> remain so. In fact, no professional cryptographer will review it when
>>> the fundamental algorithm is unspecified. To be taken seriously you
>>> need to specify the method, as David says, mathematically. (I think you
>>> had a go once in sci.crypt though that might have been for a different
>>> algorithm.)
>>> Anyway, also as David says, you can still have fun.
>>
>> And it's also worth remembering that not all encryption needs to be
>> "professional" to be useful. Sometimes a quick and simple scheme is good
>> enough. There's plenty of scope for ideas that give some basic encryption
>> with implementations that are very efficient on some level of hardware
>
> My feeling is that it's the "proper" encryption that has to be
> efficient -- encrypting all hard drive traffic, backups, net
> communication, bulk emails and so on. The "good enough" sort can
> probably be inefficient.
>

Ideally, it's /all/ efficient :-)

Efficient encryption is almost always done with symmetric ciphers - the
same key is used to lock and unlock the data. Asymmetric ciphers are
invariably much more demanding, and are thus used either for very
important encryption, public/private authentication, or to get a secure
exchange of a long random key for a symmetric cipher.

Within the class of symmetric ciphers, there is a lot of possibilities,
and there are balances between efficiency and security, especially when
"efficiency" can be in terms of hardware implementations, software on
big systems, software on small systems, and streaming or block-oriented,
to name just some aspects.

You are absolutely correct that for some uses, high security /and/ high
efficiency is important. You want your disk encryption or VPN traffic
to be secure but not cause too much slowdown for normal use. But there
are always tradeoffs here.

In cases where efficiency is not an issue, it is often actually easier
to use standardised solid encryption systems. Find a solid AES,
Blowfish or similar implementation for your chosen programming language,
and use that. The main reason why you'd want a quick and simple scheme
(other than for fun or learning) is because your target can't run such
standard algorithms fast enough for your needs (or perhaps, due to
limited memory, it can't run it at all).

David Brown <david.brown@hesbynett.no> writes:
>On 03/11/2023 11:10, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 02/11/2023 21:28, Ben Bacarisse wrote:
>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>
>>>>> On 11/2/2023 2:04 AM, David Brown wrote:
>>>>>> First, cryptography is mathematics.  It makes things clearer if your
>>>>>> algorithms are written mathematically.
>>>> ...
>>>>>> Don't let that stop you playing around with these, however - there's
>>>>>> always fun to be had with this kind of thing.
>>>>>
>>>>> Thank you David. Crap is as it is... Simply because its never been properly
>>>>> examined by professionals! Sigh...
>>>> There's a chicken-and-egg situation here. No professional will examine
>>>> it while it's "crap" so if it's crap through lack of review it will
>>>> remain so. In fact, no professional cryptographer will review it when
>>>> the fundamental algorithm is unspecified. To be taken seriously you
>>>> need to specify the method, as David says, mathematically. (I think you
>>>> had a go once in sci.crypt though that might have been for a different
>>>> algorithm.)
>>>> Anyway, also as David says, you can still have fun.
>>>
>>> And it's also worth remembering that not all encryption needs to be
>>> "professional" to be useful. Sometimes a quick and simple scheme is good
>>> enough. There's plenty of scope for ideas that give some basic encryption
>>> with implementations that are very efficient on some level of hardware
>>
>> My feeling is that it's the "proper" encryption that has to be
>> efficient -- encrypting all hard drive traffic, backups, net
>> communication, bulk emails and so on. The "good enough" sort can
>> probably be inefficient.
>>
>
>Ideally, it's /all/ efficient :-)
>
>Efficient encryption is almost always done with symmetric ciphers - the
>same key is used to lock and unlock the data. Asymmetric ciphers are
>invariably much more demanding, and are thus used either for very
>important encryption, public/private authentication, or to get a secure
>exchange of a long random key for a symmetric cipher.
>
>Within the class of symmetric ciphers, there is a lot of possibilities,
>and there are balances between efficiency and security, especially when
>"efficiency" can be in terms of hardware implementations, software on
>big systems, software on small systems, and streaming or block-oriented,
>to name just some aspects.

Generally hardware implementations are preferable for performance
(e.g. inline IPSEC on 100- or 400-Gb/sec ethernet ports).

On 11/3/2023 2:23 AM, David Brown wrote:
> On 02/11/2023 21:28, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>
>>> On 11/2/2023 2:04 AM, David Brown wrote:
>>>> First, cryptography is mathematics.  It makes things clearer if your
>>>> algorithms are written mathematically.
>> ...
>>>> Don't let that stop you playing around with these, however - there's
>>>> always fun to be had with this kind of thing.
>>>
>>> Thank you David. Crap is as it is... Simply because its never been
>>> properly
>>> examined by professionals! Sigh...
>>
>> There's a chicken-and-egg situation here.  No professional will examine
>> it while it's "crap" so if it's crap through lack of review it will
>> remain so.  In fact, no professional cryptographer will review it when
>> the fundamental algorithm is unspecified.  To be taken seriously you
>> need to specify the method, as David says, mathematically.  (I think you
>> had a go once in sci.crypt though that might have been for a different
>> algorithm.)
>>
>> Anyway, also as David says, you can still have fun.
>>
>
> And it's also worth remembering that not all encryption needs to be
> "professional" to be useful.  Sometimes a quick and simple scheme is
> good enough.  There's plenty of scope for ideas that give some basic
> encryption with implementations that are very efficient on some level of
> hardware (whether it be tuned to the latest x86-64 SIMD units or to
> small microcontrollers).
>
> (Not that Chris' current scheme is quick or simple!)
>
>

;^D

A C impl of my experimental scheme:

https://pastebin.com/raw/feUnA3kP

Ivvvvho, it can be "simple" because I am using the following HMAC lib
that does most of the heavy lifting for me:

https://github.com/ogay/hmac

I did not feel like coding up HMAC from scratch.

On 11/3/2023 9:52 AM, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 03/11/2023 11:10, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 02/11/2023 21:28, Ben Bacarisse wrote:
>>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>>
>>>>>> On 11/2/2023 2:04 AM, David Brown wrote:
>>>>>>> First, cryptography is mathematics.  It makes things clearer if your
>>>>>>> algorithms are written mathematically.
>>>>> ...
>>>>>>> Don't let that stop you playing around with these, however - there's
>>>>>>> always fun to be had with this kind of thing.
>>>>>>
>>>>>> Thank you David. Crap is as it is... Simply because its never been properly
>>>>>> examined by professionals! Sigh...
>>>>> There's a chicken-and-egg situation here. No professional will examine
>>>>> it while it's "crap" so if it's crap through lack of review it will
>>>>> remain so. In fact, no professional cryptographer will review it when
>>>>> the fundamental algorithm is unspecified. To be taken seriously you
>>>>> need to specify the method, as David says, mathematically. (I think you
>>>>> had a go once in sci.crypt though that might have been for a different
>>>>> algorithm.)
>>>>> Anyway, also as David says, you can still have fun.
>>>>
>>>> And it's also worth remembering that not all encryption needs to be
>>>> "professional" to be useful. Sometimes a quick and simple scheme is good
>>>> enough. There's plenty of scope for ideas that give some basic encryption
>>>> with implementations that are very efficient on some level of hardware
>>>
>>> My feeling is that it's the "proper" encryption that has to be
>>> efficient -- encrypting all hard drive traffic, backups, net
>>> communication, bulk emails and so on. The "good enough" sort can
>>> probably be inefficient.
>>>
>>
>> Ideally, it's /all/ efficient :-)
>>
>> Efficient encryption is almost always done with symmetric ciphers - the
>> same key is used to lock and unlock the data. Asymmetric ciphers are
>> invariably much more demanding, and are thus used either for very
>> important encryption, public/private authentication, or to get a secure
>> exchange of a long random key for a symmetric cipher.
>>
>> Within the class of symmetric ciphers, there is a lot of possibilities,
>> and there are balances between efficiency and security, especially when
>> "efficiency" can be in terms of hardware implementations, software on
>> big systems, software on small systems, and streaming or block-oriented,
>> to name just some aspects.
>
> Generally hardware implementations are preferable for performance
> (e.g. inline IPSEC on 100- or 400-Gb/sec ethernet ports).

Hardware HMAC would make my experiment go a lot faster...

On 11/2/2023 12:02 PM, David Brown wrote:
> On 02/11/2023 19:02, Chris M. Thomasson wrote:
[...]
>>> Btw, David, when you get some free time, can you critique my python
>>> here? Thanks.
>>
>> Oops! Sorry for that dumb ass comment! Why would you critique my
>> python code and post it here. Sorry! ;^o
>>
>
> I can't promise I'll get time to try any of the code (C or Python), or
> critique them.  But I hope my comments on the algorithm and how to
> describe it are helpful to you.
>
>

Fwiw, a friend of mine did a little write up of one of my algorithms
over here:

https://paulbourke.net/fractals/multijulia

Paul is a very smart guy, and so are you and Ben, a lot of people on
this group. The spam has went down to zero for me so far... ;^)

On 11/3/2023 11:57 PM, Chris M. Thomasson wrote:
> On 11/2/2023 12:02 PM, David Brown wrote:
>> On 02/11/2023 19:02, Chris M. Thomasson wrote:
> [...]
>>>> Btw, David, when you get some free time, can you critique my python
>>>> here? Thanks.
>>>
>>> Oops! Sorry for that dumb ass comment! Why would you critique my
>>> python code and post it here. Sorry! ;^o
>>>
>>
>> I can't promise I'll get time to try any of the code (C or Python), or
>> critique them.  But I hope my comments on the algorithm and how to
>> describe it are helpful to you.
>>
>>
>
> Fwiw, a friend of mine did a little write up of one of my algorithms
> over here:
>
> https://paulbourke.net/fractals/multijulia
>
> Paul is a very smart guy, and so are you and Ben, a lot of people on
> this group. The spam has went down to zero for me so far... ;^)

Paul did some more write ups of my work:

https://paulbourke.net/fractals/logspiral

https://paulbourke.net/fractals/septagon

On 10/30/2023 2:01 PM, Chris M. Thomasson wrote:
> This has to be undefined behavior. Check it out:
>
> Here is my C code for a fun toy experimental fractal:
>
> https://pastebin.com/raw/fcV5YiJH
> (raw link to text...)[...]

I will get back into this, got caught up with some other work right now.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Richard Harnden <richard.nospam@gmail.invalid> writes:
>
>> On 30/10/2023 21:01, Chris M. Thomasson wrote:
>>
>>> https://pastebin.com/raw/fcV5YiJH
>>
>> $ gcc -std=c99 -pedantic -W -Wall -fsanitize=undefined -O2 -lm ffe.c

>> ffe.c:305:18: warning: taking the absolute value of unsigned type
>> 'unsigned int' has no effect [-Wabsolute-value]
>> ec = abs(icount - ec);
>> ^
>> ffe.c:305:18: note: remove the call to 'abs' since unsigned values
>> cannot be negative
>> ec = abs(icount - ec);
>> ^~~
>> 1 warning generated.
>>
>> If you follow that advise, then it doesn't decrypt.
>
> That's "compiler" advice! While icount - ec is indeed unsigned,
> the conversion to int (the argument type of abs) is sometimes
> undefined due to overflow.

Converting an unsigned int to int is implementation-defined, not
undefined. (The C standard also allows an implementation-defined
signal to be raised, but it's unlikely either gcc or clang does
so.)

> So removing the call is fine in the eyes of a compiler because the
> result will be the same in the defined cases and compilers don't
> care about the undefined ones.

The compiler is giving stupid advice. The result is defined in
all cases, except for when the (post-conversion) argument value
happens to be INT_MIN. Unless the implementation-defined rule
for converting an unsigned int to an int is very strange,
removing the call changes the program's semantics.

On 10/30/2023 2:01 PM, Chris M. Thomasson wrote:
> This has to be undefined behavior. Check it out:
>
> Here is my C code for a fun toy experimental fractal:
>
> https://pastebin.com/raw/fcV5YiJH
> (raw link to text...)
[...]

I want to mix this into:

https://groups.google.com/g/comp.lang.c++/c/bB1wA4wvoFc/m/GdzmMd41AQAJ

Humm...