i once had written about micromodules
in future extended c

micromodules are like simple types or
structures but (maybe among yet something)
allow you to redefine some syntaxes of usage
to fire your coded action

syntax how to do it is not yet established,
even some rough rules how to do it is yet not
clear, but there is a topic to consider

by 'micromodule for complex number' i mean
situation where toy got number p (p=x+iy) which you
may use by accesing fields p.x p.y abut also
p.fi p.r (where .r .fi ale module and phase)
- i mean four fields but only 2 floats of
internal storage

this situation makes this micromodule specially
practical imo

what i mean 'ideal' ? by ideal i mean especially
good from some important number of aspects..
especially there is some aspect that i think
on mind that if you code some code that operates
on complex number by hand you could code the
'partial path' when some conwersions from x,y <--> r,fi
may be ommitted, if you encapsulate the number
in microstructure some simple idea is to convert
it heavily and this would make it all slower,
the question among some other is for example if
it could be done to be as efficient as hand
code (it could be gard to obtain so on first
draft of thinking i could skip that problem and
just try to see how it could look like at all
at first draft at least

some basic thought/draft

struct complex
{ float x; //typical physical ones
float y; //accesible normally

//bellow additional syntax defined
//as a part of micromodule

def syntax (complex.fi)=(float f)
{
float r = sqrt(x*x+y*y);
x = cos(f)*r;
y = sin(f)*r;
}

def syntax ret (complex.fi)
{
return atan2(x,y);
}

def syntax (complex.r)=(float R)
{
float fi = atan2(x,y);
x = cos(f)*R;
y = sin(f)*R;
}

def syntax ret (complex.r)
{
return sqrt(x*x+y*y);
}

}

various problems here, but the meritum is
to present draft of the idea

syntax is probbaly not much good but at the
moment is how it is and ilustrates option
for varios syntax additions/enhancements

i think the usage would be like

complex c1;

c1.x=10;
c1.y=1;

printf("module %d phase %d", c1.r, c1.fi);

//the above would fire underlying sqrt and atan2
calculations

complex c2;

c2.r=1;
c2.fi=M_PI/4;

c1.x+=c2.x;
c1.y+=c2.y;

ofc more syntax could and should be added for
example for complex to complex addition to ba
able to write

c1 = c1 + c2;

niedziela, 6 lutego 2022 o 20:16:42 UTC+1 fir napisał(a):
> some basic thought/draft
>
> struct complex
> {
> float x; //typical physical ones
> float y; //accesible normally
>
>
> //bellow additional syntax defined
> //as a part of micromodule
>
> def syntax (complex.fi)=(float f)
> {
> float r = sqrt(x*x+y*y);
> x = cos(f)*r;
> y = sin(f)*r;
> }
>
> def syntax ret (complex.fi)
> {
> return atan2(x,y);
> }
>
> def syntax (complex.r)=(float R)
> {
> float fi = atan2(x,y);
> x = cos(f)*R;
> y = sin(f)*R;
> }
>
> def syntax ret (complex.r)
> {
> return sqrt(x*x+y*y);
> }
>
> }
>
i think you get the idea, in fact first step i would like to improve is syntax, as good syntax makes thinking on it more pleasurable /attracting...when you redefine operators it not looks to much good imo, ewl as this c "leftside name rightside" is not much pleasurable itself

niedziela, 6 lutego 2022 o 20:32:57 UTC+1 fir napisał(a):
> niedziela, 6 lutego 2022 o 20:16:42 UTC+1 fir napisał(a):
> > some basic thought/draft
> >
> > struct complex
> > {
> > float x; //typical physical ones
> > float y; //accesible normally
> >
> >
> > //bellow additional syntax defined
> > //as a part of micromodule
> >
> > def syntax (complex.fi)=(float f)
> > {
> > float r = sqrt(x*x+y*y);
> > x = cos(f)*r;
> > y = sin(f)*r;
> > }
> >
> > def syntax ret (complex.fi)
> > {
> > return atan2(x,y);
> > }
> >
> > def syntax (complex.r)=(float R)
> > {
> > float fi = atan2(x,y);
> > x = cos(f)*R;
> > y = sin(f)*R;
> > }
> >
> > def syntax ret (complex.r)
> > {
> > return sqrt(x*x+y*y);
> > }
> >
> > }
> >
> i think you get the idea, in fact first step i would like to improve is syntax, as good syntax makes thinking on it more pleasurable /attracting...when you redefine operators it not looks to much good imo, ewl as this c "leftside name rightside" is not much pleasurable itself

thinking on it seems that those () make some problem, this come to my mind as kinda
alternative )im not sure if some of typenames should be vritten here in <> obligatory or non obligatory

struct <complex>
{ <float> x; //typical physical ones
<float> y; //accesible normally

def syntax <complex>.fi= <float> f
{
float r = sqrt(x*x+y*y);
x = cos(f)*r;
y = sin(f)*r;
}

def syntax ret <complex>.fi
{
return atan2(x,y);
}

def syntax <complex>.r= <float> R
{
float fi = atan2(x,y);
x = cos(fi)*R;
y = sin(fi)*R;
}

def syntax ret <complex>.r
{
return sqrt(x*x+y*y);
}

}

Better use C++ with the most convenient complex number support.
It supports arbitray types for the real and imaginary part of
the complex number and overloaded operators so you can handle
complex numbers like scalar datatypes.

niedziela, 6 lutego 2022 o 21:42:27 UTC+1 Bonita Montero napisał(a):
> Better use C++ with the most convenient complex number support.
> It supports arbitray types for the real and imaginary part of
> the complex number and overloaded operators so you can handle
> complex numbers like scalar datatypes.

and how they do that calculations? (i distaste c++ so i dont learn it)

can they

complex a(10,5);

cout <<"module "< a.r << "phase" << a.fi ;

a.fi+=(M_PI/180)*5; //add 5 degrees

cout <<"real "< a.x << "imaginary" << a.y ;

?

if thay can do they overcalculate it each time they use module, phase ?

(besides i dont 'better' use coz im not mainly focused on 'using' but on inner logic of language(s)

niedziela, 6 lutego 2022 o 21:34:38 UTC+1 fir napisał(a):
> thinking on it seems that those () make some problem, this come to my mind as kinda
> alternative )im not sure if some of typenames should be vritten here in <> obligatory or non obligatory
> struct <complex>
> {
> <float> x; //typical physical ones
> <float> y; //accesible normally
> def syntax <complex>.fi= <float> f
> {
> float r = sqrt(x*x+y*y);
> x = cos(f)*r;
> y = sin(f)*r;
> }

ye, it seems that as some expressions look better with <float> and some with float i think it should be possible using it <int> <float> as using as typenames but not obligatory, just to being able to write nicer looking code

niedziela, 6 lutego 2022 o 21:52:37 UTC+1 fir napisał(a):
> niedziela, 6 lutego 2022 o 21:34:38 UTC+1 fir napisał(a):
> > thinking on it seems that those () make some problem, this come to my mind as kinda
> > alternative )im not sure if some of typenames should be vritten here in <> obligatory or non obligatory
> > struct <complex>
> > {
> > <float> x; //typical physical ones
> > <float> y; //accesible normally
> > def syntax <complex>.fi= <float> f
> > {
> > float r = sqrt(x*x+y*y);
> > x = cos(f)*r;
> > y = sin(f)*r;
> > }
> ye, it seems that as some expressions look better with <float> and some with float i think it should be possible using it <int> <float> as using as typenames but not obligatory, just to being able to write nicer looking code

as to syntax improvements i also found idea to alternatively allowing to replace it by ending
dot

if(a)
{ a;
b;
c;
}

if(a)
a;
b;
c;
..

depends on editor and case it dont look so bad (i add it as im not sure if i already mentioned that) (depending on contex there also opening ":" instead of "{" can be used so {} -> :. but sometimes ":" is not needed and if " :" used it also slows to skip some parenthesis before it like

if a<10 : something; something; .

niedziela, 6 lutego 2022 o 22:10:40 UTC+1 fir napisał(a):
> niedziela, 6 lutego 2022 o 21:52:37 UTC+1 fir napisał(a):
> > niedziela, 6 lutego 2022 o 21:34:38 UTC+1 fir napisał(a):
> > > thinking on it seems that those () make some problem, this come to my mind as kinda
> > > alternative )im not sure if some of typenames should be vritten here in <> obligatory or non obligatory
> > > struct <complex>
> > > {
> > > <float> x; //typical physical ones
> > > <float> y; //accesible normally
> > > def syntax <complex>.fi= <float> f
> > > {
> > > float r = sqrt(x*x+y*y);
> > > x = cos(f)*r;
> > > y = sin(f)*r;
> > > }
> > ye, it seems that as some expressions look better with <float> and some with float i think it should be possible using it <int> <float> as using as typenames but not obligatory, just to being able to write nicer looking code
> as to syntax improvements i also found idea to alternatively allowing to replace it by ending
> dot
>
> if(a)
> {
> a;
> b;
> c;
> }
>
> if(a)
> a;
> b;
> c;
> .
>
> depends on editor and case it dont look so bad (i add it as im not sure if i already mentioned that) (depending on contex there also opening ":" instead of "{" can be used so {} -> :. but sometimes ":" is not needed and if " :" used it also slows to skip some parenthesis before it like
>
> if a<10 : something; something; .

so including this i think this may be revritten more like

struct <complex> this
{ <float> x, y;

def syntax this.fi : return atan2(x,y) .
def syntax this.r : return sqrt(x*x+y*y) .

def syntax this.r = <float> R :
{
<float> fi = this.fi;
x = cos(fi)*R;
y = sin(fi)*R;
}

def syntax this.fi = <float> f
{
float r = this.r;
x = cos(f)*r;
y = sin(f)*r;
}

}

On 2/6/2022 12:49 PM, fir wrote:
> niedziela, 6 lutego 2022 o 21:42:27 UTC+1 Bonita Montero napisał(a):
>> Better use C++ with the most convenient complex number support.
>> It supports arbitray types for the real and imaginary part of
>> the complex number and overloaded operators so you can handle
>> complex numbers like scalar datatypes.
>
> and how they do that calculations? (i distaste c++ so i dont learn it)
>
> can they
>
> complex a(10,5);
>
> cout <<"module "< a.r << "phase" << a.fi ;
>
> a.fi+=(M_PI/180)*5; //add 5 degrees

Convert the complex to polar form, add the degrees, then convert back to
rectangular form.

>
> cout <<"real "< a.x << "imaginary" << a.y ;
>
> ?
>
>
> if thay can do they overcalculate it each time they use module, phase ?
>
> (besides i dont 'better' use coz im not mainly focused on 'using' but on inner logic of language(s)
>
>

niedziela, 6 lutego 2022 o 22:46:51 UTC+1 fir napisał(a):
> niedziela, 6 lutego 2022 o 22:10:40 UTC+1 fir napisał(a):
> > niedziela, 6 lutego 2022 o 21:52:37 UTC+1 fir napisał(a):
> > > niedziela, 6 lutego 2022 o 21:34:38 UTC+1 fir napisał(a):
> > > > thinking on it seems that those () make some problem, this come to my mind as kinda
> > > > alternative )im not sure if some of typenames should be vritten here in <> obligatory or non obligatory
> > > > struct <complex>
> > > > {
> > > > <float> x; //typical physical ones
> > > > <float> y; //accesible normally
> > > > def syntax <complex>.fi= <float> f
> > > > {
> > > > float r = sqrt(x*x+y*y);
> > > > x = cos(f)*r;
> > > > y = sin(f)*r;
> > > > }
> > > ye, it seems that as some expressions look better with <float> and some with float i think it should be possible using it <int> <float> as using as typenames but not obligatory, just to being able to write nicer looking code
> > as to syntax improvements i also found idea to alternatively allowing to replace it by ending
> > dot
> >
> > if(a)
> > {
> > a;
> > b;
> > c;
> > }
> >
> > if(a)
> > a;
> > b;
> > c;
> > .
> >
> > depends on editor and case it dont look so bad (i add it as im not sure if i already mentioned that) (depending on contex there also opening ":" instead of "{" can be used so {} -> :. but sometimes ":" is not needed and if " :" used it also slows to skip some parenthesis before it like
> >
> > if a<10 : something; something; .
> so including this i think this may be revritten more like
>
>
> struct <complex> this
> {
> <float> x, y;
>
> def syntax this.fi : return atan2(x,y) .
> def syntax this.r : return sqrt(x*x+y*y) .
>
> def syntax this.r = <float> R :
> {
> <float> fi = this.fi;
> x = cos(fi)*R;
> y = sin(fi)*R;
> }
> def syntax this.fi = <float> f
> {
> float r = this.r;
> x = cos(f)*r;
> y = sin(f)*r;
> }
>
> }

or maybe (further syntax simplification)

struct complex
{
float x, y;
syntax complex.fi : return atan2(x,y) .
syntax complex.r : return sqrt(x*x+y*y) .
syntax complex.r = float R { float fi = complex.fi; x = cos(fi)*R; y = sin(fi)*R; }
syntax complex.fi = float f { float r = this.r; x = cos(f)*r; y = sin(f)*r; }
}

for now it seems the best i obtained as to syntax

poniedziałek, 7 lutego 2022 o 09:02:39 UTC+1 fir napisał(a):
> or maybe (further syntax simplification)
>
> struct complex
> {
> float x, y;
> syntax complex.fi : return atan2(x,y) .
> syntax complex.r : return sqrt(x*x+y*y) .
> syntax complex.r = float R { float fi = complex.fi; x = cos(fi)*R; y = sin(fi)*R; }
> syntax complex.fi = float f { float r = this.r; x = cos(f)*r; y = sin(f)*r; }
> }
>
ewentually one could say that this .fi .r should be functions to denote that calculation is fired
complex c = { 10, 5};
float a = c.fi();
float r = c.r();
it has some sense (though in general i probably would want to cede it on programmer if he want to define syntax complex.fi : return atan2(x,y) . or syntax complex.fi() : return atan2(x,y) . )
but if so there is no syntax of defining assign that will fire a function

c.r()=10; //?

this clashes with normal c reading (when c.r() fires then assigns which is besides nonsense typicaly)

maybe something like c.(r)=10; ?
probably this is standable, and i think user probably should have freedom to state syntaxes as he wants

struct complex
{
float x, y;
syntax complex.fi() : return atan2(x,y) .
syntax complex.r() : return sqrt(x*x+y*y) .
syntax complex.(r) = float R { float fi = complex.fi; x = cos(fi)*R; y = sin(fi)*R; }
syntax complex.(fi) = float f { float r = this.r; x = cos(f)*r; y = sin(f)*r; }
}

i hope it not clashes with something further (though probably may)

poniedziałek, 7 lutego 2022 o 09:20:54 UTC+1 fir napisał(a):
> maybe something like c.(r)=10; ?
> probably this is standable, and i think user probably should have freedom to state syntaxes as he wants
> struct complex
> {
> float x, y;
> syntax complex.fi() : return atan2(x,y) .
> syntax complex.r() : return sqrt(x*x+y*y) .
> syntax complex.(r) = float R { float fi = complex.fi; x = cos(fi)*R; y = sin(fi)*R; }
> syntax complex.(fi) = float f { float r = this.r; x = cos(f)*r; y = sin(f)*r; }
> }
>
> i hope it not clashes with something further (though probably may)

slight typos here i menat rather

struct complex
{
float x, y;
syntax complex.fi() : return atan2(x,y) .
syntax complex.r() : return sqrt(x*x+y*y) .
syntax complex.(r) = float R { float fi = complex.fi(); x = cos(fi)*R; y = sin(fi)*R; }
syntax complex.(fi) = float f { float r = complex.r(); x = cos(f)*r; y = sin(f)*r; }
}

https://en.cppreference.com/w/cpp/numeric/complex

poniedziałek, 7 lutego 2022 o 09:47:31 UTC+1 Bonita Montero napisał(a):
> https://en.cppreference.com/w/cpp/numeric/complex

you know if you want to talk you should invest a little effort and write down explanation
yourself - this makes topic more prone to being talked...especialy for me whet is in c++ is quite
a side topic as to what im saying about (hovever i probably will look up in this link but after midday

Am 07.02.2022 um 10:01 schrieb fir:

> poniedziałek, 7 lutego 2022 o 09:47:31 UTC+1 Bonita Montero napisał(a):
>> https://en.cppreference.com/w/cpp/numeric/complex
>
> you know if you want to talk you should invest a little effort and write down explanation
> yourself - this makes topic more prone to being talked...especialy for me whet is in c++ is quite
> a side topic as to what im saying about (hovever i probably will look up in this link but after midday

The above link shows everything complex<> is capable of.

poniedziałek, 7 lutego 2022 o 10:15:54 UTC+1 Bonita Montero napisał(a):
> Am 07.02.2022 um 10:01 schrieb fir:
>
> > poniedziałek, 7 lutego 2022 o 09:47:31 UTC+1 Bonita Montero napisał(a):
> >> https://en.cppreference.com/w/cpp/numeric/complex
> >
> > you know if you want to talk you should invest a little effort and write down explanation
> > yourself - this makes topic more prone to being talked...especialy for me whet is in c++ is quite
> > a side topic as to what im saying about (hovever i probably will look up in this link but after midday
> The above link shows everything complex<> is capable of.

as for my eye it looks somewhat ugly...more would say to se a file of source with implementation of it (as what i give example is an implementation) but this is side topic.. as we in poland say "c++ jest dla kuców" (i mean i say it but in poland this would be like that and i dont know what is a translation of kuc in english..kuc is a pony, that kinda one in that context who go with a crowd of other ponys

Am 07.02.2022 um 14:56 schrieb fir:
> poniedziałek, 7 lutego 2022 o 10:15:54 UTC+1 Bonita Montero napisał(a):
>> Am 07.02.2022 um 10:01 schrieb fir:
>>
>>> poniedziałek, 7 lutego 2022 o 09:47:31 UTC+1 Bonita Montero napisał(a):
>>>> https://en.cppreference.com/w/cpp/numeric/complex
>>>
>>> you know if you want to talk you should invest a little effort and write down explanation
>>> yourself - this makes topic more prone to being talked...especialy for me whet is in c++ is quite
>>> a side topic as to what im saying about (hovever i probably will look up in this link but after midday
>> The above link shows everything complex<> is capable of.
>
> as for my eye it looks somewhat ugly...more would say to se a file of source with implementation of it (as what i give example is an implementation) but this is side topic.. as we in poland say "c++ jest dla kuców" (i mean i say it but in poland this would be like that and i dont know what is a translation of kuc in english..kuc is a pony, that kinda one in that context who go with a crowd of other ponys

What's unly with complex<> ?

poniedziałek, 7 lutego 2022 o 14:59:29 UTC+1 Bonita Montero napisał(a):
> Am 07.02.2022 um 14:56 schrieb fir:
> > poniedziałek, 7 lutego 2022 o 10:15:54 UTC+1 Bonita Montero napisał(a):
> >> Am 07.02.2022 um 10:01 schrieb fir:
> >>
> >>> poniedziałek, 7 lutego 2022 o 09:47:31 UTC+1 Bonita Montero napisał(a):
> >>>> https://en.cppreference.com/w/cpp/numeric/complex
> >>>
> >>> you know if you want to talk you should invest a little effort and write down explanation
> >>> yourself - this makes topic more prone to being talked...especialy for me whet is in c++ is quite
> >>> a side topic as to what im saying about (hovever i probably will look up in this link but after midday
> >> The above link shows everything complex<> is capable of.
> >
> > as for my eye it looks somewhat ugly...more would say to se a file of source with implementation of it (as what i give example is an implementation) but this is side topic.. as we in poland say "c++ jest dla kuców" (i mean i say it but in poland this would be like that and i dont know what is a translation of kuc in english..kuc is a pony, that kinda one in that context who go with a crowd of other ponys
> What's unly with complex<> ?

its hard question to answer and im not in a mood today to answer such hard and side questions..

i recently was saying to emo colegue girl from chat why i dont like this pony language c++

one aspect in c++ code is like a bunch of plastic layers (come like rings on onion but elss natural) one on another - where in c (at least good written but i suspect most people write not bad c) you got stright 'meat' (stright matter)

those c++ layers ale arso idiotic (at least big part of it is idiotic)

i hope my own extensions (all that micromodule stuff etc) will not go out far from this real metter (at least i hope so but to kip some things oryginal c quality is hard)

c++ is btw very ugly, i dont write in c++ but probably you may find some
examples of usage which are not looking very bad but the underlying rules and implementation is disaster to me - c++ is a cobol of last decades imo (as cobol was considered being a symbol for ugly language as i heard, c++ is in facty probebly worse)

but well this is my view on it and dont treat it as a reason to make war as i dont totaly care what c++ ponys do, our worlds do not cross

Am 07.02.2022 um 16:33 schrieb fir:

> poniedziałek, 7 lutego 2022 o 14:59:29 UTC+1 Bonita Montero napisał(a):

>> What's unly with complex<> ?

> its hard question to answer and im not in a mood today to answer such hard and side questions..

If you say it is ugly you'd know why.

> one aspect in c++ code is like a bunch of plastic layers (come like rings on onion but elss natural) one on another - where in c (at least good written but i suspect most people write not bad c) you got stright 'meat' (stright matter)

"Plastic layers" - polemic.

> those c++ layers ale arso idiotic (at least big part of it is idiotic)

C++ does have only a thin abstraction-layet in its classes
and not multiple layers.

> c++ is btw very ugly, ...

With C++ you're multiple times productive than in C and the code
is much more readable and maintainable.

poniedziałek, 7 lutego 2022 o 21:27:27 UTC+1 Bonita Montero napisał(a):
> Am 07.02.2022 um 16:33 schrieb fir:
>
> > poniedziałek, 7 lutego 2022 o 14:59:29 UTC+1 Bonita Montero napisał(a):
>
> >> What's unly with complex<> ?
>
> > its hard question to answer and im not in a mood today to answer such hard and side questions..
> If you say it is ugly you'd know why.

usually but not strictly always..you may imagine cases when you see something is ugly but its hard to explain exactly why
in c++ case it is yet a bit different...it is ugly becouse i could show you much more good alternatives but it would be a long list and i dont take the task, got better things to do

> > one aspect in c++ code is like a bunch of plastic layers (come like rings on onion but elss natural) one on another - where in c (at least good written but i suspect most people write not bad c) you got stright 'meat' (stright matter)
> "Plastic layers" - polemic.
> > those c++ layers ale arso idiotic (at least big part of it is idiotic)
> C++ does have only a thin abstraction-layet in its classes
> and not multiple layers.
>
depends, it depend how people use it and i dont see a much c++ codes (in last months i dont coded at all nor was interesting in reading about coding at all, now im back for a while)
hovewer in cases which i got in memory i seen a lot of names and syntactic/objectove knots covering underlaying real matter in preposterous way
by preposterous i mean that ratio of this covering names to that real matter is preposterously
high
java btw as far as i know it (know it yet less than c++) is even worse

in general i think c is for people who like to understand things (people focused on reazon) where pony languages are for ponys focused on puting things to their memory and avoid reasoning as far as they can (or at least enough far for them)

> > c++ is btw very ugly, ...
>
> With C++ you're multiple times productive than in C and the code
> is much more readable and maintainable.

its not true -- it was discussed here some years ago and it was stated that this productivity depends on libraries you got on hand not on language ...readability and maintability depends how clean you write some may write very readable c ... though who knows maybe for ponys c++ is better for non ponys c is better for me c is unparalably better

besides i do not subscribe to that kind of discusion based on generalities ...its time waste

On 2/7/2022 12:26 PM, Bonita Montero wrote:
> Am 07.02.2022 um 16:33 schrieb fir:
>
>> poniedziałek, 7 lutego 2022 o 14:59:29 UTC+1 Bonita Montero napisał(a):
>
>>> What's unly with complex<> ?
>
>> its hard question to answer and im not in a mood today to answer such
>> hard and side questions..
[...]
>> c++ is btw very ugly, ...
>
> With C++ you're multiple times productive than in C and the code
> is much more readable and maintainable.

Agreed. Fwiw, std::complex is very useful. One thing I might want to add
to the standard would be to get at the n-ary roots of a complex number.
I had to code it up myself in order to store data in the roots of a
complex number:

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

On 2/7/2022 2:49 PM, Chris M. Thomasson wrote:
> On 2/7/2022 12:26 PM, Bonita Montero wrote:
>> Am 07.02.2022 um 16:33 schrieb fir:
>>
>>> poniedziałek, 7 lutego 2022 o 14:59:29 UTC+1 Bonita Montero napisał(a):
>>
>>>> What's unly with complex<> ?
>>
>>> its hard question to answer and im not in a mood today to answer such
>>> hard and side questions..
> [...]
>>> c++ is btw very ugly, ...
>>
>> With C++ you're multiple times productive than in C and the code
>> is much more readable and maintainable.
>
> Agreed. Fwiw, std::complex is very useful. One thing I might want to add
> to the standard would be to get at the n-ary roots of a complex number.
> I had to code it up myself in order to store data in the roots of a
> complex number:
>
> https://groups.google.com/g/comp.lang.c++/c/bB1wA4wvoFc/m/ozDpUBlTAAAJ
>

https://groups.google.com/g/comp.lang.c++/c/05XwgswUnDg

Am 07.02.2022 um 21:47 schrieb fir:

>>> its hard question to answer and im not in a mood today to answer such hard and side questions..

>> If you say it is ugly you'd know why.

> usually but not strictly always..you may imagine cases when you see something is ugly but its hard to explain exactly why
> ...

That's the problem - you don't know C++.

>>> one aspect in c++ code is like a bunch of plastic layers (come like rings on onion but elss natural) one on another - where in c (at least good written but i suspect most people write not bad c) you got stright 'meat' (stright matter)

> java btw as far as i know it (know it yet less than c++) is even worse

If you don't need to have the performance
of C++ Java is an easier choice.

> its not true -- ...

It't true if you don't misuse the language-facilities.

wtorek, 8 lutego 2022 o 12:26:37 UTC+1 Bonita Montero napisał(a):
> Am 07.02.2022 um 21:47 schrieb fir:
>
> >>> its hard question to answer and im not in a mood today to answer such hard and side questions..
>
> >> If you say it is ugly you'd know why.
>
> > usually but not strictly always..you may imagine cases when you see something is ugly but its hard to explain exactly why
> > ...
>
> That's the problem - you don't know C++.
> >>> one aspect in c++ code is like a bunch of plastic layers (come like rings on onion but elss natural) one on another - where in c (at least good written but i suspect most people write not bad c) you got stright 'meat' (stright matter)
> > java btw as far as i know it (know it yet less than c++) is even worse
> If you don't need to have the performance
> of C++ Java is an easier choice.
>
> > its not true -- ...
>
> It't true if you don't misuse the language-facilities.

well, youre free to belive...

> well, youre free to belive...

hovever i may add you resemble dick hodgin...every man belives something but some special nuts
war crusades like hodgin with jesus and you with your c++ belif.. in fact from psychical paoint of view this is sorta heavy degradation of mind in my opinion (heavy nuts so to say..so im okay with you belive your belifs but fighting pony crusade is mental degradation problem imo..im not involved ;<)