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