Jump to page: 1 2
Thread overview
[phobos] std.complex: ready for Phobos?
Apr 20, 2010
Philippe Sigaud
Apr 20, 2010
Don Clugston
Apr 20, 2010
Philippe Sigaud
Apr 21, 2010
Philippe Sigaud
Apr 21, 2010
Don Clugston
Apr 20, 2010
Walter Bright
April 19, 2010
Another point is that if Complex!T is to support arbitrary FP types, then the trigonometric functions in std.math must too. Personally, I think we should keep the constraint for now. If we loosen it later, at least nothing will break.

-Lars



----- Reply message -----
From: "Lars Tandle Kyllingstad" <lars at kyllingen.net>
Date: Mon, Apr 19, 2010 22:39
Subject: [phobos] std.complex: ready for Phobos?
To: "Phobos mailing list" <phobos at puremagic.com>

Andrei Alexandrescu wrote:
> Looks great. I have a few suggestions:
> 
> * Since this is all new code, I suggest we use const throughout wherever sensible (for all @property's, opEquals etc).

Good point, I'll add that.


> * The if isFloatingPoint!T constraint worries me that we won't support unlimited precision reals or fixed point numbers later. I suggest we leave the constraint out for now.

I've considered that.  But wouldn't it make more sense to define isFloatingPoint and isIntegral so they match compile-time interfaces instead of specific (built-in) types?


> * opAssign and opOpAssign should return a ref

See bug 2460, "ref functions can't be template functions".  If this is a low-priority bug, I can always work around it, but that seems rather pointless.  Also, considering that almost all operator overloading is now done with templates, it *really* should be fixed.


> Otherwise, this looks great. Good work!

Thanks! :)

-Lars



> On 04/19/2010 04:10 AM, Lars Tandle Kyllingstad wrote:
>> I've attached a new version of my std.complex proposal to this message.
>>
>> I can't think of more features to add, so please have a look at it and tell me what you think. Specifically,
>>
>> - What's missing?
>> - Should anything be removed?
>> - And, importantly, this potentially being my first contribution
>> to Phobos: Does the code meet Phobos' quality requirements?
>>
>> If there are no protests, I'll commit it to SVN.
>>
>> -Lars
>>
>>
>>
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos


-- 
Lars Tandle Kyllingstad
@: lars at kyllingen.net
#: 40233221
w: http://www.kyllingen.net

_______________________________________________
phobos mailing list
phobos at puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100419/d7abc4ef/attachment.html>
April 19, 2010
It's a good point. Replying to your other point, we need some traits to tell whether something is a built-in float. For those that look like a float, we should define isFloatingPointLike.

Andrei

On 04/19/2010 04:02 PM, Lars Tandle Kyllingstad wrote:
> Another point is that if Complex!T is to support arbitrary FP types, then the trigonometric functions in std.math must too. Personally, I think we should keep the constraint for now. If we loosen it later, at least nothing will break.
>
> -Lars
>
>
>
> ----- Reply message -----
> From: "Lars Tandle Kyllingstad" <lars at kyllingen.net>
> Date: Mon, Apr 19, 2010 22:39
> Subject: [phobos] std.complex: ready for Phobos?
> To: "Phobos mailing list" <phobos at puremagic.com>
>
> Andrei Alexandrescu wrote:
>  > Looks great. I have a few suggestions:
>  >
>  > * Since this is all new code, I suggest we use const throughout wherever
>  > sensible (for all @property's, opEquals etc).
>
> Good point, I'll add that.
>
>
>  > * The if isFloatingPoint!T constraint worries me that we won't support
>  > unlimited precision reals or fixed point numbers later. I suggest we
>  > leave the constraint out for now.
>
> I've considered that. But wouldn't it make more sense to define isFloatingPoint and isIntegral so they match compile-time interfaces instead of specific (built-in) types?
>
>
>  > * opAssign and opOpAssign should return a ref
>
> See bug 2460, "ref functions can't be template functions". If this is a low-priority bug, I can always work around it, but that seems rather pointless. Also, considering that almost all operator overloading is now done with templates, it *really* should be fixed.
>
>
>  > Otherwise, this looks great. Good work!
>
> Thanks! :)
>
> -Lars
>
>
>
>  > On 04/19/2010 04:10 AM, Lars Tandle Kyllingstad wrote:
>  >> I've attached a new version of my std.complex proposal to this message.
>  >>
>  >> I can't think of more features to add, so please have a look at it and
>  >> tell me what you think. Specifically,
>  >>
>  >> - What's missing?
>  >> - Should anything be removed?
>  >> - And, importantly, this potentially being my first contribution
>  >> to Phobos: Does the code meet Phobos' quality requirements?
>  >>
>  >> If there are no protests, I'll commit it to SVN.
>  >>
>  >> -Lars
>  >>
>  >>
>  >>
>  >> _______________________________________________
>  >> phobos mailing list
>  >> phobos at puremagic.com
>  >> http://lists.puremagic.com/mailman/listinfo/phobos
>
>
> --
> Lars Tandle Kyllingstad
> @: lars at kyllingen.net
> #: 40233221
> w: http://www.kyllingen.net
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
>
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
April 20, 2010
On Mon, Apr 19, 2010 at 23:05, Andrei Alexandrescu <andrei at erdani.com>wrote:

> It's a good point. Replying to your other point, we need some traits to tell whether something is a built-in float. For those that look like a float, we should define isFloatingPointLike.
>
> Andrei
>
>
> On 04/19/2010 04:02 PM, Lars Tandle Kyllingstad wrote:
>
>> Another point is that if Complex!T is to support arbitrary FP types, then the trigonometric functions in std.math must too.
>>
>
Hi,

sorry to interrupt on your conversation (if I can post on the Phobos list), but Lars' comment on CT interfaces got me thinking: is it enough to test the subjacent type with these templates ?

- some type defines some operators (definesOperators!(T, "+", "-", ...)
- some type can be used with some functions (acceptedBy!(T, "hypot", ...)
- some type can be cast to real.

they could be all easily done, I think.

Mostly, it seems to me your code would have a global constraint with struct
Complex(T) if (definesOperators!(T, /+ the whole paraphernalia+/)

And, just around abs and arg, testing if T is accepted by hypot and atan2 _or_ if it can by explicitly cast to a real.

Commenting out abs/arg is enough to get  a Complex!BigInt to compile. but assignment does not work:

Complex!BigInt c;
c = 23; // opAssign asks for a BigInt (R : T)
maybe you should ask for something that can be cast to T.

Complex opAssign(R)(R r) if (__traits(compiles, {T t; R r; t=r;} ))
    {
        re = r;
        im = 0;
        return this;
    }

Philippe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100420/ad7f77e2/attachment.html>
April 20, 2010
Does Complex!BigInt (or Complex!int, for that matter) *ever* make sense?
  I mean, yes, it *sounds* cool, and I'm normally against introducing
gratuitous constraints on functionality, but in this case I think I
prefer restricting T to real number types.

Have in mind that not only will one have to disable (or introduce special cases for) abs() and arg(), but also some of the operations, in particular division and exponentiation.

It all sounds like more work, more maintenance, more complex code (hur hur), for very little or no benefit.

-Lars


Philippe Sigaud wrote:
> 
> 
> On Mon, Apr 19, 2010 at 23:05, Andrei Alexandrescu <andrei at erdani.com <mailto:andrei at erdani.com>> wrote:
> 
>     It's a good point. Replying to your other point, we need some traits
>     to tell whether something is a built-in float. For those that look
>     like a float, we should define isFloatingPointLike.
> 
>     Andrei
> 
> 
>     On 04/19/2010 04:02 PM, Lars Tandle Kyllingstad wrote:
> 
>         Another point is that if Complex!T is to support arbitrary FP types,
>         then the trigonometric functions in std.math must too.
> 
> 
> Hi,
> 
> sorry to interrupt on your conversation (if I can post on the Phobos list), but Lars' comment on CT interfaces got me thinking: is it enough to test the subjacent type with these templates ?
> 
> - some type defines some operators (definesOperators!(T, "+", "-", ...)
> - some type can be used with some functions (acceptedBy!(T, "hypot", ...)
> - some type can be cast to real.
> 
> they could be all easily done, I think.
> 
> Mostly, it seems to me your code would have a global constraint with struct Complex(T) if (definesOperators!(T, /+ the whole paraphernalia+/)
> 
> And, just around abs and arg, testing if T is accepted by hypot and atan2 _or_ if it can by explicitly cast to a real.
> 
> Commenting out abs/arg is enough to get  a Complex!BigInt to compile. but assignment does not work:
> 
> Complex!BigInt c;
> c = 23; // opAssign asks for a BigInt (R : T)
> maybe you should ask for something that can be cast to T.
> 
> Complex opAssign(R)(R r) if (__traits(compiles, {T t; R r; t=r;} ))
>     {
>         re = r;
>         im = 0;
>         return this;
>     }
> 
> Philippe
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
April 20, 2010
On 20 April 2010 11:06, Lars Tandle Kyllingstad <lars at kyllingen.net> wrote:
> Does Complex!BigInt (or Complex!int, for that matter) *ever* make sense? ?I mean, yes, it *sounds* cool, and I'm normally against introducing gratuitous constraints on functionality, but in this case I think I prefer restricting T to real number types.
>
> Have in mind that not only will one have to disable (or introduce special
> cases for) abs() and arg(), but also some of the operations, in particular
> division and exponentiation.
>
> It all sounds like more work, more maintenance, more complex code (hur hur), for very little or no benefit.

I agree. Mathematically, complex integers are a fundamentally
different type (they are Gaussian integers, and have some interesting
properties which general complex numbers don't have, for example, they
can be primes) .
However, Complex!BigFloat will make sense. It's also possible to
imagine using a fixed-point type.
So eventually isFloatingPoint!T might change to a slightly more
general function. But I don't think we should worry about that for
now.
April 20, 2010
On 04/20/2010 05:35 AM, Don Clugston wrote:
> So eventually isFloatingPoint!T might change to a slightly more general function. But I don't think we should worry about that for now.

I agree.

Andrei
April 20, 2010

Lars Tandle Kyllingstad wrote:
> Personally, I think we should keep the constraint for now. If we loosen it later, at least nothing will break.
>

I think that is an eminently sensible strategy.
April 20, 2010
On Tue, Apr 20, 2010 at 11:06, Lars Tandle Kyllingstad <lars at kyllingen.net>wrote:

> Does Complex!BigInt (or Complex!int, for that matter) *ever* make sense?  I mean, yes, it *sounds* cool, and I'm normally against introducing gratuitous constraints on functionality, but in this case I think I prefer restricting T to real number types.
>
> Have in mind that not only will one have to disable (or introduce special
> cases for) abs() and arg(), but also some of the operations, in particular
> division and exponentiation.
>
> It all sounds like more work, more maintenance, more complex code (hur hur), for very little or no benefit.
>
>
I completly agree, and wasn't trying to sell Complex for any integral type!
My only suggestion was to use a generic template to determine what operators
were supported by a type, based on your suggestion to use compile-time
interfaces, ? la std.range.
I was using BigInt as non-built-in numeric type, the only one available on
Phobos.

But then I thought that the compiler already checks at compile-time that the operations are possible, so I'm not so certain about the need for such a template. Maybe as a way to document the code?

Sorry for the noise, I'll let you continue your good work.

Philippe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100420/bb81b9a4/attachment.html>
April 20, 2010
Philippe Sigaud wrote:
> On Tue, Apr 20, 2010 at 11:06, Lars Tandle Kyllingstad <lars at kyllingen.net <mailto:lars at kyllingen.net>> wrote:
> 
>     Does Complex!BigInt (or Complex!int, for that matter) *ever* make
>     sense?  I mean, yes, it *sounds* cool, and I'm normally against
>     introducing gratuitous constraints on functionality, but in this
>     case I think I prefer restricting T to real number types.
> 
>     Have in mind that not only will one have to disable (or introduce
>     special cases for) abs() and arg(), but also some of the operations,
>     in particular division and exponentiation.
> 
>     It all sounds like more work, more maintenance, more complex code
>     (hur hur), for very little or no benefit.
> 
> 
> I completly agree, and wasn't trying to sell Complex for any integral
> type! My only suggestion was to use a generic template to determine what
> operators were supported by a type, based on your suggestion to use
> compile-time interfaces, ? la std.range.
> I was using BigInt as non-built-in numeric type, the only one available
> on Phobos.

Ok, it seems I understood you too literally.  I think we mostly agree then.  Ideally, the constraint on Complex!T should act as a compile-time interface that checks whether T *behaves* like a floating-point type. However, in this case I personally think Complex!T should work equally well for all T or not at all, and for the time being that means using isFloatingPoint.


> But then I thought that the compiler already checks at compile-time that the operations are possible, so I'm not so certain about the need for such a template. Maybe as a way to document the code?

That, and for error messages that are easier to understand and track down.


> Sorry for the noise, I'll let you continue your good work.

Nono, don't be.  Feedback is always good. :)  Like I said, I just think it's better to start with a tight constraint and relax it if it turns out that that's what people want.

-Lars

April 21, 2010
On Tue, Apr 20, 2010 at 22:57, Lars Tandle Kyllingstad <lars at kyllingen.net>wrote:

> Ok, it seems I understood you too literally.  I think we mostly agree then.
>  Ideally, the constraint on Complex!T should act as a compile-time interface
> that checks whether T *behaves* like a floating-point type. However, in this
> case I personally think Complex!T should work equally well for all T or not
> at all, and for the time being that means using isFloatingPoint.
>

And what defines a FP-like behavior, as opposed to merely numeric / defining mathematical operators?

Having 0, 1, and something between 0 and 1?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100421/a89fe515/attachment.html>
« First   ‹ Prev
1 2