Nick Sabalausky Wrote:

> "Justin Johansson" <no@spam.com> wrote in message news:haavf1$2gs7$1@digitalmars.com...
> >
> > It's a difficult challenge to get high performance, readable and
> > maintainable code out of complex number
> > intensive algorithms.   Use of library types for complex numbers has, in
> > my experience been problematic.
> > Complex numbers should be first class value types I say.
> >
> 
> There's been discussion before (I can't find it now, or remember the name for it) of type systems that allow for proper handling of things like m/s vs. m/(s*s) vs inch/min etc. I haven't actually worked with such a feature or with complex/imaginary numbers in any actual code, so I can't be sure, but I've been wondering if a type system like that would be an appropriate (or even ideal) way to handle real/complex/imaginary numbers.

> "I've also been wondering if it might be a huge benefit for distinguishing between strings that represent a filename vs file content vs file-extention-only vs relative-path+filename, vs absolute-path-only, etc. I've been really wanting a better way to handle that than just a variable naming convention.)"

Bingo. I'm sure there would be a huge benefit to be able to distinguish string or any primitive type in such manner without having to invent a Filename class, AbsolutePathName class etc.

This whole business about types is much to do about how to construct (and validate) the
type from primitive information -- often given in lexical form.  If I pass an email-address type
(even if it is really just a string) to an sendmail function, that function should not have to
revalidate/reparse the string to be sure that the string data is indeed a (lexically) valid email address.

Yeah, good point you bring up.

-- Justin Johansson

Andrei Alexandrescu:

>please name five remarkable complex literals.<

I agree that having a syntax is often not necessary (but it may be handy).
Complex literals in a program can be unremarkable too, they can be arguments of complex functions, integration intervals, default values that replace missing argument inputs, etc.


> That's not opBool, it's opIf. Testing with if does not mean conversion to bool and then testing the bool.

opIf sounds strange :-) Why don't you like the idea of the implicit conversion to bool followed by the testing of the bool? (someone may have already answered a similar question, please bear with me).
(Python has such standard method, as I have described (its name is diffeernt), while C# has two methods for true and falseness of an object/struct).


> I'd love to hear more about that. I've asked several times about it and never got a clear answer.

Probably you have to ask to people that use complex numbers heavily, like in refined numerical simulations. Do you know some researcher at the university? A numerical physicist or teacher of numeric computation may be fine. If you ask to normal programmers they probably will not give you a good answer. To design certain language features you need experts :-)

Bye,
bearophile

Sun, 04 Oct 2009 17:39:50 -0400, Justin Johansson thusly wrote:

> Nick Sabalausky Wrote:
>> "I've also
>> been wondering if it might be a huge benefit for distinguishing between
>> strings that represent a filename vs file content vs
>> file-extention-only vs relative-path+filename, vs absolute-path-only,
>> etc. I've been really wanting a better way to handle that than just a
>> variable naming convention.)"
> 
> Bingo. I'm sure there would be a huge benefit to be able to distinguish string or any primitive type in such manner without having to invent a Filename class, AbsolutePathName class etc.

You could use a variant:

typedef Filename = char[];
typedef Path = char[];

typedef File = JustFile Filename
             | RelPath Path Filename
             | AbsPath Path Filename

> 
> This whole business about types is much to do about how to construct (and validate) the type from primitive information -- often given in lexical form.  If I pass an email-address type (even if it is really just a string) to an sendmail function, that function should not have to revalidate/reparse the string to be sure that the string data is indeed a (lexically) valid email address.

Something that came to my mind while reading this: typedefs could also be extended to support contracts just like functions.

Justin Johansson Wrote:

> Bingo. I'm sure there would be a huge benefit to be able to distinguish string or any primitive type in such manner without having to invent a Filename class, AbsolutePathName class etc.

Can D typedef be used for such purpose?

Bye,
bearophile

bearophile wrote:
> opIf sounds strange :-) Why don't you like the idea of the implicit
> conversion to bool followed by the testing of the bool? (someone may
> have already answered a similar question, please bear with me).

Try this:

void * p;
if (p) {}

Then try this:

void * p;
bool b = p;


Andrei

bearophile Wrote:

> Justin Johansson Wrote:
> 
> > Bingo. I'm sure there would be a huge benefit to be able to distinguish string or any primitive type in such manner without having to invent a Filename class, AbsolutePathName class etc.
> 
> Can D typedef be used for such purpose?
> 
> Bye,
> bearophile

Yes it can to a degree.  It is useful and a little type-safe smarter than its C counterpart going
by the few D tests that I've done on my journey into the language.
Drawback, as far as I can tell, is the lack of a constructor for typedef'ed values.  Seems like you
need to synthesise a typedef'ed value with a function that casts it to the typedef type
from a primitive type inside the function and return the casted result.
Otherwise, reminiscent of leaky fountain pens of yesteryear, you can blot casts all over your code.
I may be wrong; there may be a better way in D.

Doesn't C++ allow you to construct primitive values in syntax similar to a function call,
e.g. int(20);
Whether same works for typedef types in C++ I cannot recall just right now.

Ciao
Justin

On Sun, Oct 4, 2009 at 5:58 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> bearophile wrote:
>>
>> opIf sounds strange :-) Why don't you like the idea of the implicit conversion to bool followed by the testing of the bool? (someone may have already answered a similar question, please bear with me).
>
> Try this:
>
> void * p;
> if (p) {}
>
> Then try this:
>
> void * p;
> bool b = p;

Okay, how about if if() used the result of an *explicit* cast to bool?
Barring the silly opCast operator (and maybe providing something
else), would this be consistent?

Andrei Alexandrescu Wrote:

> Nick Sabalausky wrote:
> > "Justin Johansson" <no@spam.com> wrote in message news:haavf1$2gs7$1@digitalmars.com...
> >> It's a difficult challenge to get high performance, readable and
> >> maintainable code out of complex number
> >> intensive algorithms.   Use of library types for complex numbers has, in
> >> my experience been problematic.
> >> Complex numbers should be first class value types I say.
> >>
> > 
> > There's been discussion before (I can't find it now, or remember the name for it) of type systems that allow for proper handling of things like m/s vs. m/(s*s) vs inch/min etc. I haven't actually worked with such a feature or with complex/imaginary numbers in any actual code, so I can't be sure, but I've been wondering if a type system like that would be an appropriate (or even ideal) way to handle real/complex/imaginary numbers.
> 
> It better be. Complex numbers aren't that complicated of a notion. What's lost in pulling them out of the language is the ability to define literals.

> "Now please name five remarkable complex literals."

(re, im) ::= (0, 0), (1,0), (0,1), (1,1), (pi/2, 0), (0, pi/2), e_to_the_power_(minus j),
 e_to_the_power_(minus j * pi/2)

Is that what you mean?

Guess one has to study Maxwell's equations, microwaves and the black art of Smith Charts to
appreciate .. not that anyone really cares too much these days .. no need to design antennae
for transmitters and receivers from scratch now that microwave towers and iPhones are consumer items.

(FYI, Electrical engineers use j and mathematicians use i to denote sqroot(-1).  We do that
since the letter i is conventionally used for current (as in amperes)).

-- Justin

On Mon, 05 Oct 2009 01:03:01 +0400, bearophile <bearophileHUGS@lycos.com> wrote:

> Walter Bright:
>
>> The
>> big reason for moving it to a library type is the user defined type
>> capabilities of D have grown to the point where there is no longer much
>> of any advantage to having it built in.
>
> If the compiler/language is now flexible enough to allow the creation of a very good complex number, and the compilation time for such library numbers is good enough, and they get compiled efficiently enough, then removing them from the language is positive. But is the compiler now good enough to allow to implement very good complex numbers in the std lib?
>
> One problem is to have a good syntax to define and use complex numbers. Time ago I have even suggested to keep the complex syntax in the compiler, and move the implementation in the std lib.
>
> Another problem that I think is present still is the lack of a method like opBool, that gets called in implicit boolean situations like if(somecomplex){...
>
> A third and more serious question is if the library complex type avoids the pitfalls discussed in the page about built-in complex numbers in the digitalmars site.
>
> Bye,
> bearophile

I don't see any reason why if (someComplexNumber) { ... } should be a valid code, it hardly makes any sense for me.
In fact, I am trying to avoid if (foo) as much as possible (unless foo is a bool, of course):

if (somePtr !is null) {
}

if (someInt != 0) {
}

but:

if (someCondition) {
}

I wouldn't like to sacrifice code clarity for saving a few keystrokes, but maybe it's just me.

On Mon, 05 Oct 2009 01:47:00 +0400, language_fan <foo@bar.com.invalid> wrote:

> Something that came to my mind while reading this: typedefs could also be
> extended to support contracts just like functions.

It is a nice idea! It would make D typedef much more powerful and useful.