www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - iota to array

reply psychoticRabbit <meagain meagain.com> writes:
Hi. Anyone know whether something like this is possible?

I've tried various conversions/casts, but no luck yet.

Essentially, I want to cast the result set of the iota to an 
array, during initialisation of the variable.

no, I don't want to use 'auto'. I want an array object ;-)

--------------
module test;

import std.stdio;
import std.range : iota;

void main()
{
     int[] intArr = iota(1, 11); // 1..10
     double[] doubleArr = iota(1.0, 11.0); // 1.0..10.0
     char[] charArr = iota('a', '{');  // a..z
}
-------------
Feb 24 2018
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, February 25, 2018 05:24:54 psychoticRabbit via Digitalmars-d-
learn wrote:
 Hi. Anyone know whether something like this is possible?

 I've tried various conversions/casts, but no luck yet.

 Essentially, I want to cast the result set of the iota to an
 array, during initialisation of the variable.

 no, I don't want to use 'auto'. I want an array object ;-)

 --------------
 module test;

 import std.stdio;
 import std.range : iota;

 void main()
 {
      int[] intArr = iota(1, 11); // 1..10
      double[] doubleArr = iota(1.0, 11.0); // 1.0..10.0
      char[] charArr = iota('a', '{');  // a..z
 }
 -------------
As with any range, you can call std.array.array to convert it to an array. So, you can have: int[] intArr = iota(1, 11).array(); or more idiomatically: auto intArr = iota(1, 11).array(); And auto does _not_ mean that it's not an array. It just means that the type is inferred, which is pretty much required when you're dealing with ranges, because the range types get a bit disgusting to type even if they're not Voldemort types, and if they are Voldemort types, then you pretty much have to use auto, since you can't refer to the type by name. But in general, even when you know exactly what the type is, it's good practice to use auto, since then you're avoiding repeating the type, and it makes it so that you don't have to change as much code later if the type of the variable changes. The classic example of where auto should be used when you know exactly what the type is would be with new. e.g. MyClass c = new MyClass; is unnecessarily redundant, and auto c = new MyClass; is preferred. In your case, providing the type isn't redundant, since the type isn't listed on the right-hand side of the expression, but it's still unnecessary to list the type, so auto is generally preferred - though obviously, if you really want to be explicit about the types everywhere, there's nothing stopping you from doing so. It just makes the code harder to maintain if the type ever changes. - Jonathan M Davis
Feb 24 2018
next sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Sunday, 25 February 2018 at 05:40:19 UTC, Jonathan M Davis 
wrote:
     int[] intArr = iota(1, 11).array();


 - Jonathan M Davis
thanks! oh man. It's so easy to do stuff in D ;-) But this leads me to a new problem now. When I run my code below, I get ints printed instead of doubles?? --------------------- module test; import std.stdio : writeln; import std.traits : isArray; import std.array : array; import std.range : iota; void main() { int[] intArr = iota(1, 11).array(); // 1..10 double[] doubleArr = iota(1.0, 11.0).array(); // 1.0..10.0 char[] charArr = iota('a', '{').array(); // a..z printArray(intArr); printArray(doubleArr); // why is it printing ints instead of doubles?? printArray(charArr); } void printArray(T)(const ref T[] a) if (isArray!(T[])) { foreach(t; a) writeln(t); } ---------------------------------
Feb 24 2018
next sibling parent Uknown <sireeshkodali1 gmail.com> writes:
On Sunday, 25 February 2018 at 06:22:03 UTC, psychoticRabbit 
wrote:
 On Sunday, 25 February 2018 at 05:40:19 UTC, Jonathan M Davis 
 wrote:
     int[] intArr = iota(1, 11).array();


 - Jonathan M Davis
thanks! oh man. It's so easy to do stuff in D ;-) But this leads me to a new problem now. When I run my code below, I get ints printed instead of doubles?? --------------------- module test; import std.stdio : writeln; import std.traits : isArray; import std.array : array; import std.range : iota; void main() { int[] intArr = iota(1, 11).array(); // 1..10 double[] doubleArr = iota(1.0, 11.0).array(); // 1.0..10.0 char[] charArr = iota('a', '{').array(); // a..z printArray(intArr); printArray(doubleArr); // why is it printing ints instead of doubles?? printArray(charArr); } void printArray(T)(const ref T[] a) if (isArray!(T[])) { foreach(t; a) writeln(t); } ---------------------------------
2 Things: 1. You can just use writeln to directly print Arrays. If you want a specific format for the array you can use writef/writefln 2. By default, writeln will print [1, 2, 3] when your array contains [1.0, 2.0, 3.0], since thats considered neater. You can use writefln to address that. You can see this here: https://run.dlang.io/is/bNxIsH You can read more about format strings here: https://dlang.org/phobos/std_format.html#format-string
Feb 24 2018
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, February 25, 2018 06:22:03 psychoticRabbit via Digitalmars-d-
learn wrote:
 On Sunday, 25 February 2018 at 05:40:19 UTC, Jonathan M Davis

 wrote:
     int[] intArr = iota(1, 11).array();

 - Jonathan M Davis
thanks! oh man. It's so easy to do stuff in D ;-) But this leads me to a new problem now. When I run my code below, I get ints printed instead of doubles?? --------------------- module test; import std.stdio : writeln; import std.traits : isArray; import std.array : array; import std.range : iota; void main() { int[] intArr = iota(1, 11).array(); // 1..10 double[] doubleArr = iota(1.0, 11.0).array(); // 1.0..10.0 char[] charArr = iota('a', '{').array(); // a..z printArray(intArr); printArray(doubleArr); // why is it printing ints instead of doubles?? printArray(charArr); } void printArray(T)(const ref T[] a) if (isArray!(T[])) { foreach(t; a) writeln(t); } ---------------------------------
It's not printing ints. It's printing doubles. It's just that all of the doubles have nothing to the right of the decimal point, so they don't get printed with a decimal point. If you did something like start with 1.1, then you'd see decimal points, because there would be data to the right of the decimal point. The same thing happens if you do writeln(1.0); as opposed to something like writeln(1.3); BTW, you can just call writeln on the array directly, and then you'll get something like [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] - Jonathan M Davis
Feb 24 2018
parent reply psychoticRabbit <meagain meagain.com> writes:
On Sunday, 25 February 2018 at 06:35:07 UTC, Jonathan M Davis 
wrote:
 It's not printing ints. It's printing doubles. It's just that 
 all of the doubles have nothing to the right of the decimal 
 point, so they don't get printed with a decimal point. If you 
 did something like start with 1.1, then you'd see decimal 
 points, because there would be data to the right of the decimal 
 point. The same thing happens if you do

 writeln(1.0);

 as opposed to something like

 writeln(1.3);
thanks. But umm.... what happended to the principle of least astonishment? writeln(1.1); (prints 1.1) whereas.. writeln(1.0); (prints 1) I don't get it. Cause it's 'nicer'?? I ended up having to work around this..like this: ------- void printArray(T)(const ref T[] a) if (isArray!(T[])) { if( isFloatingPoint!T) foreach(t; a) writefln("%.1f", t); else foreach(t; a) writefln("%s", t); } -------
Feb 25 2018
parent reply rumbu <rumbu rumbu.ro> writes:
On Sunday, 25 February 2018 at 08:08:30 UTC, psychoticRabbit 
wrote:
 But umm.... what happended to the principle of least 
 astonishment?

 writeln(1.1); (prints 1.1)
 whereas..
 writeln(1.0); (prints 1)

 I don't get it. Cause it's 'nicer'??
Because writeln(someFloat) is equivalent to writefln("%g", someFloat). And according to printf specification, "trailing zeros are removed from the fractional part of the result; a decimal point appears only if it is followed by at least one digit"
Feb 25 2018
parent reply psychoticRabbit <meagain meagain.com> writes:
On Sunday, 25 February 2018 at 08:46:19 UTC, rumbu wrote:
 On Sunday, 25 February 2018 at 08:08:30 UTC, psychoticRabbit 
 wrote:
 But umm.... what happended to the principle of least 
 astonishment?

 writeln(1.1); (prints 1.1)
 whereas..
 writeln(1.0); (prints 1)

 I don't get it. Cause it's 'nicer'??
Because writeln(someFloat) is equivalent to writefln("%g", someFloat). And according to printf specification, "trailing zeros are removed from the fractional part of the result; a decimal point appears only if it is followed by at least one digit"
oh. that explains it. I would have preffered it defaulted java style ;-) System.out.println(1.0); // i.e. it prints 'what I told it to print'.
Feb 25 2018
parent reply Andrea Fontana <nospam example.com> writes:
On Sunday, 25 February 2018 at 09:30:12 UTC, psychoticRabbit 
wrote:
 I would have preffered it defaulted java style ;-)

 System.out.println(1.0); // i.e. it prints 'what I told it to 
 print'.
System.out.println(1.0); // print 1.0 System.out.println(1.00000); // print 1.0 So it doesn't print "what you told it to print" Andrea Fontana
Feb 25 2018
parent reply psychoticRabbit <meagain meagain.com> writes:
On Sunday, 25 February 2018 at 12:13:31 UTC, Andrea Fontana wrote:
 On Sunday, 25 February 2018 at 09:30:12 UTC, psychoticRabbit 
 wrote:
 I would have preffered it defaulted java style ;-)

 System.out.println(1.0); // i.e. it prints 'what I told it to 
 print'.
System.out.println(1.0); // print 1.0 System.out.println(1.00000); // print 1.0 So it doesn't print "what you told it to print" Andrea Fontana
can someone please design a language that does what I tell it! please!! is that so hard?? print 1.0 does not mean go and print 1 .. it means go and print 1.0 languages are too much like people.. always thinking for themselves. I fed up! fed up I say!
Feb 25 2018
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 2/25/18 8:33 AM, psychoticRabbit wrote:
 On Sunday, 25 February 2018 at 12:13:31 UTC, Andrea Fontana wrote:
 On Sunday, 25 February 2018 at 09:30:12 UTC, psychoticRabbit wrote:
 I would have preffered it defaulted java style ;-)

 System.out.println(1.0); // i.e. it prints 'what I told it to print'.
System.out.println(1.0); // print 1.0 System.out.println(1.00000); // print 1.0 So it doesn't print "what you told it to print" Andrea Fontana
can someone please design a language that does what I tell it! please!! is that so hard?? print 1.0 does not mean go and print 1 .. it means go and print 1.0
1 == 1.0, no? You are printing a value, which means it has to go through a conversion from the value to a string (i.e. printable). writefln has no idea what you wrote as a literal, it just sees the value 1 (as a double). I hope we never make a distinction here! If you want to tell it EXACTLY what to print, print a string: writeln("1.0"); -Steve
Feb 25 2018
parent reply psychoticRabbit <meagain megain.com> writes:
On Sunday, 25 February 2018 at 14:52:19 UTC, Steven Schveighoffer 
wrote:
 1 == 1.0, no?
no. at least, not when a language forces you to think in terms of types. 1 is an int. 1.0 is a floating point. I admit, I've never printed output without using format specifiers, but still, if I say write(1.0), it should not go off and print what looks to me, like an int. Inheriting crap from C is no excuse ;-) and what's going on here btw? assert( 1 == 1.000000000000000001 ); // assertion error in DMD but not in LDC assert( 1 == 1.0000000000000000001 ); // no assertion error?? (compiled in 64bit mode)
Feb 26 2018
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Feb 26, 2018 at 11:34:06PM +0000, psychoticRabbit via
Digitalmars-d-learn wrote:
[...]
 and what's going on here btw?
 
 assert( 1 == 1.000000000000000001 );  // assertion error in DMD but not in
 LDC
 assert( 1 == 1.0000000000000000001 );  // no assertion error??
 
 (compiled in 64bit mode)
A 64-bit double can only hold about 14-15 decimal digits of precision. Anything past that, and there's a chance your "different" numbers are represented by exactly the same bits and the computer can't tell the difference. If you want arbitrary precision you'll have to use an arbitrary precision library like GMP. It will be a lot slower than built-in floats or doubles, though. In general, real numbers have an infinite number of digits, and so would require infinite memory and infinite time to perform any computations at all. What we have now is a reasonably practical compromise. :-D But that also means there will be some inherent inexactness because we're trying to represent an infinite number of digits in a small, finite space. (There *are* exact representations for certain subsets of irrationals that allow fast computation that does not lose precision. But generally, they are only useful for specific applications where you know beforehand what form(s) your numbers will take. For general arithmetic, you have to compromise between speed and accuracy.) T -- In theory, software is implemented according to the design that has been carefully worked out beforehand. In practice, design documents are written after the fact to describe the sorry mess that has gone on before.
Feb 26 2018
parent reply psychoticRabbit <meagain megain.com> writes:
On Tuesday, 27 February 2018 at 00:04:59 UTC, H. S. Teoh wrote:
 A 64-bit double can only hold about 14-15 decimal digits of 
 precision. Anything past that, and there's a chance your 
 "different" numbers are represented by exactly the same bits 
 and the computer can't tell the difference.

 T
Feb 26 2018
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 27, 2018 at 12:26:56AM +0000, psychoticRabbit via
Digitalmars-d-learn wrote:
 On Tuesday, 27 February 2018 at 00:04:59 UTC, H. S. Teoh wrote:
 
 A 64-bit double can only hold about 14-15 decimal digits of
 precision.  Anything past that, and there's a chance your
 "different" numbers are represented by exactly the same bits and the
 computer can't tell the difference.
 
 T
Didn't somebody write a decimal library type recently? Try searching on code.dlang.org, you can probably find it there. T -- They say that "guns don't kill people, people kill people." Well I think the gun helps. If you just stood there and yelled BANG, I don't think you'd kill too many people. -- Eddie Izzard, Dressed to Kill
Feb 26 2018
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, February 26, 2018 17:49:21 H. S. Teoh via Digitalmars-d-learn 
wrote:
 On Tue, Feb 27, 2018 at 12:26:56AM +0000, psychoticRabbit via Digitalmars-
d-learn wrote:
 On Tuesday, 27 February 2018 at 00:04:59 UTC, H. S. Teoh wrote:
 A 64-bit double can only hold about 14-15 decimal digits of
 precision.  Anything past that, and there's a chance your
 "different" numbers are represented by exactly the same bits and the
 computer can't tell the difference.

 T
Didn't somebody write a decimal library type recently? Try searching on code.dlang.org, you can probably find it there.
http://code.dlang.org/packages/decimal It got a lot of positive feedback. https://forum.dlang.org/post/mutegviphsjwqzqfouhs forum.dlang.org - Jonathan M Davis
Feb 26 2018
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, February 26, 2018 16:04:59 H. S. Teoh via Digitalmars-d-learn 
wrote:
 On Mon, Feb 26, 2018 at 11:34:06PM +0000, psychoticRabbit via
 Digitalmars-d-learn wrote: [...]

 and what's going on here btw?

 assert( 1 == 1.000000000000000001 );  // assertion error in DMD but not
 in LDC
 assert( 1 == 1.0000000000000000001 );  // no assertion error??

 (compiled in 64bit mode)
A 64-bit double can only hold about 14-15 decimal digits of precision. Anything past that, and there's a chance your "different" numbers are represented by exactly the same bits and the computer can't tell the difference. If you want arbitrary precision you'll have to use an arbitrary precision library like GMP. It will be a lot slower than built-in floats or doubles, though. In general, real numbers have an infinite number of digits, and so would require infinite memory and infinite time to perform any computations at all. What we have now is a reasonably practical compromise. :-D But that also means there will be some inherent inexactness because we're trying to represent an infinite number of digits in a small, finite space. (There *are* exact representations for certain subsets of irrationals that allow fast computation that does not lose precision. But generally, they are only useful for specific applications where you know beforehand what form(s) your numbers will take. For general arithmetic, you have to compromise between speed and accuracy.)
No. No. No. Floating point values are just insane. ;) http://dconf.org/2016/talks/clugston.html In all seriousness, floating point values do tend to be highly frustrating to deal with, and personally, I've gotten to the point that I generally avoid them unless I need them. And much as that talks is titled "Using Floating Point Without Losing Your Sanity," I came away from it even more convinced that avoiding floating point values is pretty much the only sane solution - though unfortunately, sometimes, you really don't have a choice. - Jonathan M Davis
Feb 26 2018
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Feb 26, 2018 at 05:18:00PM -0700, Jonathan M Davis via
Digitalmars-d-learn wrote:
 On Monday, February 26, 2018 16:04:59 H. S. Teoh via Digitalmars-d-learn 
 wrote:
[...]
 (There *are* exact representations for certain subsets of
 irrationals that allow fast computation that does not lose
 precision. But generally, they are only useful for specific
 applications where you know beforehand what form(s) your numbers
 will take. For general arithmetic, you have to compromise between
 speed and accuracy.)
No. No. No. Floating point values are just insane. ;)
Ah, but I wasn't talking about floating point values. :-D I was thinking more along the lines of: https://github.com/quickfur/qrat [...]
 In all seriousness, floating point values do tend to be highly
 frustrating to deal with, and personally, I've gotten to the point
 that I generally avoid them unless I need them. And much as that talks
 is titled "Using Floating Point Without Losing Your Sanity," I came
 away from it even more convinced that avoiding floating point values
 is pretty much the only sane solution - though unfortunately,
 sometimes, you really don't have a choice.
[...] Well, the way I deal with floating point is, design my code with the assumption that things will be inaccurate, and compensate accordingly. :-P For the most part, it works reasonably well. Though, granted, there are still those odd cases where you have total precision loss. So yeah, it does get frustrating to deal with. But my usual Large Blunt Object approach to it is to just arbitrarily rewrite expressions until they stop exhibiting pathological behaviour. I suppose ultimately if it really absolutely matters that the code works in all possible cases with the best results, I'd sit down and actually work through how to minimize precision loss. But generally, I just don't have the patience to do that except in the few important places where it matters. At one point, I even threw in the towel and write a hackish "accuratizer" program that basically matches the first 7-8 digits of numbers and substituted them from a pregenerated list of known values results can take on. :-P This is highly context-sensitive, of course, and depends on outside knowledge that only works for specific cases. But it was very satisfying to run the program on data that's about 6-8 digits accurate, and have it spit out linear combinations of √2 accurate to 14 digits. :-D (Of course, this only works when the data is known to be combinations of √2. Otherwise it will only produce nonsensical output.) T -- I think Debian's doing something wrong, `apt-get install pesticide', doesn't seem to remove the bugs on my system! -- Mike Dresser
Feb 26 2018
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 2/26/18 6:34 PM, psychoticRabbit wrote:
 On Sunday, 25 February 2018 at 14:52:19 UTC, Steven Schveighoffer wrote:
 1 == 1.0, no?
no. at least, not when a language forces you to think in terms of types.
But you aren't. You are thinking in terms of text representation of values (which is what a literal is). This works just fine: double x = 1; double y = 1.0; assert(x == y); The same generated code to store 1 into x is used to store 1.0 into y. There is no difference to the compiler, it's just different in the source code.
 I admit, I've never printed output without using format specifiers, but 
 still, if I say write(1.0), it should not go off and print what looks to 
 me, like an int.
If it didn't, I'm sure others would complain about it :)
 Inheriting crap from C is no excuse ;-)
 
 and what's going on here btw?
 
 assert( 1 == 1.000000000000000001 );  // assertion error in DMD but not 
 in LDC
 assert( 1 == 1.0000000000000000001 );  // no assertion error??
Floating point is not exact. In fact, even the one that asserts, cannot be accurately represented internally. At some decimal place, it cannot store any more significant digits, so it just approximates. You may want to just get used to this, it's the way floating point has -Steve
Feb 27 2018
prev sibling next sibling parent rumbu <rumbu rumbu.ro> writes:
On Sunday, 25 February 2018 at 13:33:07 UTC, psychoticRabbit 
wrote:
 can someone please design a language that does what I tell it!

 please!!

 is that so hard??

 print 1.0 does not mean go and print 1 .. it means go and print 
 1.0

 languages are too much like people.. always thinking for 
 themselves.

 I fed up!

 fed up I say!
That's in fact a data representation problem not a language as expected: decimal one = 1m; //internally represented as 10^^0 decimal one2 = 1.0m; //internally represented as 10^^-1 decimal one3 = 1.00m; //internally represented as 100^^-2 //one == one2 == one3, but the output is different: Console.WriteLine(one); //outputs 1 Console.WriteLine(one2); //outputs 1.0 Console.WriteLine(one3); //outputs 1.00 Nor Java and nor D have any built-in decimal type, therefore the internal representation of floating point values is always double (or float, or real). Double has a unique representation for 1, 1.0 or 1.00 and it's always 2^^0. How the writeln/println functions outputs 2^0, it's a design decision. Since D is inheriting C concepts (including printf), it will use the %g format as in C. I'm not a Java fan, therefore I don't know what was behind the decision of the language creators to output floating point values with at least one decimal digit.
Feb 25 2018
prev sibling parent Harry <harry.perks gmail.com> writes:
On Sunday, 25 February 2018 at 13:33:07 UTC, psychoticRabbit 
wrote:
 On Sunday, 25 February 2018 at 12:13:31 UTC, Andrea Fontana 
 wrote:
 On Sunday, 25 February 2018 at 09:30:12 UTC, psychoticRabbit 
 wrote:
 I would have preffered it defaulted java style ;-)

 System.out.println(1.0); // i.e. it prints 'what I told it to 
 print'.
System.out.println(1.0); // print 1.0 System.out.println(1.00000); // print 1.0 So it doesn't print "what you told it to print" Andrea Fontana
can someone please design a language that does what I tell it! please!! is that so hard?? print 1.0 does not mean go and print 1 .. it means go and print 1.0 languages are too much like people.. always thinking for themselves. I fed up! fed up I say!
Don't worry little rabbit 1 == 1.0 so it is OK.
Feb 25 2018
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Feb 25, 2018 at 06:22:03AM +0000, psychoticRabbit via
Digitalmars-d-learn wrote:
[..]
     printArray(doubleArr); // why is it printing ints instead of doubles??
[...]
 void printArray(T)(const ref T[] a) if (isArray!(T[]))
 {
     foreach(t; a)
         writeln(t);
Try: writefln("%.3f", t); instead.
 }
 
 ---------------------------------
T -- Dogs have owners ... cats have staff. -- Krista Casada
Feb 24 2018
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, February 26, 2018 18:33:13 H. S. Teoh via Digitalmars-d-learn 
wrote:
 Well, the way I deal with floating point is, design my code with the
 assumption that things will be inaccurate, and compensate accordingly.
The way that I usually deal with it is to simply not use floating point numbers, because for most things that I do, I don't need them. Now, for those where I do need them, I'm forced to do like you're discussing and plan for the fact that FP math is inaccurate, but fortunately, I rarely need floating point values. Obviously, that's not true for everyone. But it's certainly the case that I advocate avoiding FP when it's not actually necessary, whereas some folks use it frequently when it's not necessary. One case that I found interesting was that in writing core.time.convClockFreq so that it didn't require floating point values, it not only avoided the inaccuracies caused by using FP, but it even was able to cover a larger range of values than FP because of how it splits out the whole number and fractional portions to do the math. - Jonathan M Davis
Feb 26 2018
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Feb 26, 2018 at 07:50:10PM -0700, Jonathan M Davis via
Digitalmars-d-learn wrote:
[...]
 One case that I found interesting was that in writing
 core.time.convClockFreq so that it didn't require floating point
 values, it not only avoided the inaccuracies caused by using FP, but
 it even was able to cover a larger range of values than FP because of
 how it splits out the whole number and fractional portions to do the
 math.
[...] It would be nice to have a standard rational / fractional number library in Phobos. It's a pretty common need. IIRC, somebody wrote one some time ago. I wonder if it's worth pushing it into Phobos. T -- War doesn't prove who's right, just who's left. -- BSD Games' Fortune
Feb 26 2018
prev sibling parent Seb <seb wilzba.ch> writes:
On Sunday, 25 February 2018 at 05:24:54 UTC, psychoticRabbit 
wrote:
 Hi. Anyone know whether something like this is possible?

 I've tried various conversions/casts, but no luck yet.

 Essentially, I want to cast the result set of the iota to an 
 array, during initialisation of the variable.
You can't do that, because iota is a range and only exists as a range struct on the stack. Think about it as a struct with three variables (start, end, stepSize) - not as an array. Of course, iota is a lot smarter than that as things like `10.iota[3 .. $]` or `3 in 10.iota` work, but it's important to notice that e.g. `iota[1 .. 2]` just returns a new range object. No GC allocation happens here and "the array" never actually exists in memory.
 no, I don't want to use 'auto'. I want an array object ;-)
This has nothing to do with auto. Auto is just a filler word for the compiler that says: "whatever is the type of the declaration, use this as the type". In other words, the compiler does this automatically for you: --- typeof(10.iota) r = 10.iota; --- Anyhow it looks like what you want to do is to __allocate__ an array. You can do so with std.array.array. --- import std.array, std.range; void main() { int[] arr = 10.iota.array; } --- https://run.dlang.io/is/kKSzjH Again, notice that the actual implementation of array is this (in the non-optimized case): --- auto array(Range)(Range r) { auto a = appender!(E[])(); // <- allocation happens in the appender foreach (e; r) a.put(e); return a.data; } --- (without constraints for simplicity) Of course, Phobos has a more sophisticated version of std.array.array, but it's basically like this: https://github.com/dlang/phobos/blob/master/std/array.d#L97
 --------------
 module test;

 import std.stdio;
 import std.range : iota;

 void main()
 {
     int[] intArr = iota(1, 11); // 1..10
     double[] doubleArr = iota(1.0, 11.0); // 1.0..10.0
     char[] charArr = iota('a', '{');  // a..z
 }
 -------------
Feb 24 2018