Re: iota to array
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.01 ); // assertion error in DMD but not in LDC assert( 1 == 1.001 ); // 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
Re: iota to array
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
Re: iota to array
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
Re: iota to array
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
Re: iota to array
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 +, 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 > > > > I really miss not having a (C# like) decimal type. > > 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/mutegviphsjwqzqfo...@forum.dlang.org - Jonathan M Davis
Re: iota to array
On Tue, Feb 27, 2018 at 12:26:56AM +, 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 > > I really miss not having a (C# like) decimal type. 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
Re: iota to array
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 I really miss not having a (C# like) decimal type.
Re: iota to array
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 +, psychoticRabbit via > Digitalmars-d-learn wrote: [...] > > > and what's going on here btw? > > > > assert( 1 == 1.01 ); // assertion error in DMD but not > > in LDC > > assert( 1 == 1.001 ); // 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
Re: iota to array
On Mon, Feb 26, 2018 at 11:34:06PM +, psychoticRabbit via Digitalmars-d-learn wrote: [...] > and what's going on here btw? > > assert( 1 == 1.01 ); // assertion error in DMD but not in > LDC > assert( 1 == 1.001 ); // 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.
Re: iota to array
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.01 ); // assertion error in DMD but not in LDC assert( 1 == 1.001 ); // no assertion error?? (compiled in 64bit mode)
Re: iota to array
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.0); // 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.
Re: iota to array
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 problem. In C#, if you are using a *decimal* data type, it prints 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.
Re: iota to array
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.0); // 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
Re: iota to array
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.0); // 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!
Re: iota to array
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.0); // print 1.0 So it doesn't print "what you told it to print" Andrea Fontana
Re: iota to array
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'.
Re: iota to array
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"
Re: iota to array
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);
}
---
Re: iota to array
On Sun, Feb 25, 2018 at 06:22:03AM +, 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
Re: iota to array
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
Re: iota to array
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
Re: iota to array
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);
}
-
Re: iota to array
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
}
-
Re: iota to array
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
iota to array
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
}
-
