Re: Sorted Array Wrapper Range
On Thursday, 4 December 2014 at 07:58:25 UTC, Tobias Pankrath wrote: I see two typical variants: - Direct: Always sorts on write() and modify() - Lazy: Sorts lazily on read() read() of course uses binarySearch You won't be able to grow that range, would you? Why, because of slice invalidation?
Re: Sorted Array Wrapper Range
On Saturday, 6 December 2014 at 14:10:21 UTC, Nordlöw wrote: On Thursday, 4 December 2014 at 07:58:25 UTC, Tobias Pankrath wrote: I see two typical variants: - Direct: Always sorts on write() and modify() - Lazy: Sorts lazily on read() read() of course uses binarySearch You won't be able to grow that range, would you? Why, because of slice invalidation? Because a RandomAccessRange has no means to grow in general. Compare your proposed wrapper to http://dlang.org/phobos/std_container.html#.BinaryHeap
Re: Sorted Array Wrapper Range
On Saturday, 6 December 2014 at 14:14:18 UTC, Tobias Pankrath wrote: Because a RandomAccessRange has no means to grow in general. Compare your proposed wrapper to http://dlang.org/phobos/std_container.html#.BinaryHeap So what should the basic operations in a SortedRange wrapper template be? And how should the wrapped type be restricted?
Delegate returning itself
Is there a way to create a delegate that returns itself? alias MyDelegate delegate() MyDelegate; // OR alias MyDelegate = MyDelegate delegate(); When I compile this I get: Error: alias MyDelegate recursive alias declaration The error makes sense but I still feel like there should be a way to create a delegate that returns itself. Maybe there's something I haven't thought of. Does anyone have an idea on how to do this?
Re: Delegate returning itself
The problem is the recursive *alias* rather than the delegate. Just don't use the alias name inside itself so like alias MyDelegate = void delegate() delegate(); will work. The first void delegate() is the return value of the MyDelegate type.
repack ubyte[] to use only 7 bits
Is there a standard way to do this? The code below is untested, as I
haven't yet written the x7to8 routine, and came up with a better way to
do what this was to accomplish, but it feels as if this should be
somewhere in the standard library, if I could only find it.
/** Repack the data from an array of ubytes into an array of ubytes of
* which only the last 7 are significant. The high bit will be set only
* if the byte would otherwise be zero.*/
byte[]x8to7 (ubyte[] bin)
{
ubyte[] bout;
//bit masks:0 = 0xfe = 1110, 0x00 =
//1 = 0x7f = 0111, 0x00 =
//2 = 0x3f = 0011, 0x80 = 1000
//3 = 0x1f = 0001, 0xc0 = 1100
//4 = 0x0f = , 0xe0 = 1110
//5 = 0x07 = 0111, 0xf0 =
//6 = 0x03 = 0011, 0xf8 = 1000
//7 = 0x01 = 0001, 0xfc = 1100
if (bin.length 1)returnbout;
intfByte, fBit;
while(fByte bin.length)
{if (fByte + 1 == bin.length fBit 1) break;
ubyteb;
switch (fBit)
{case0:
b=bin[fByte]/ 2;
break;
case1:
b=bin[fByte] 0x7f;
break;
case2:
ubyteb1=(bin[fByte] 0x3f) 1;
ubyteb2=(bin[fByte + 1] 0x80) 7;
b~=(b1 | b2);
break;
case3:
ubyteb1=(bin[fByte] 0x1f) 2;
ubyteb2=(bin[fByte + 1] 0xc0) 6;
b~= (b1 | b2);
break;
case4:
ubyteb1=(bin[fByte] 0x0f) 3;
ubyteb2=(bin[fByte + 1] 0xe0) 5;
b~= (b1 | b2);
break;
case5:
ubyteb1=(bin[fByte] 0x07) 4;
ubyteb2=(bin[fByte + 1] 0xf0) 4;
b~= (b1 | b2);
break;
case6:
ubyteb1=(bin[fByte] 0x03) 5;
ubyteb2=(bin[fByte + 1] 0xf8) 3;
b~= (b1 | b2);
break;
case7:
ubyteb1=(bin[fByte] 0x01) 6;
ubyteb2=(bin[fByte + 1] 0xfc) 2;
b~= (b1 | b2);
break;
default:
assert (false, This path should never be taken);
}//switch (fBit)
if(b == 0)bout~=0x80;
elsebout~=b;
fBit=fBit + 7;
if(fBit 7)
{fByte++;
fBit -=7;
}
}
}
Re: Adding days to std.datetime.Date
On Tuesday, December 02, 2014 14:14:58 Steven Schveighoffer via Digitalmars-d-learn wrote: On 12/2/14 2:00 PM, H. S. Teoh via Digitalmars-d-learn wrote: On Tue, Dec 02, 2014 at 06:49:54PM +, via Digitalmars-d-learn wrote: But still, why this method http://dlang.org/phobos/std_datetime.html#.Date.add only supports month or years while this one http://dlang.org/phobos/std_datetime.html#.Date.roll does ? But still, why this method http://dlang.org/phobos/std_datetime.html#.Date.add only supports month or years while this one http://dlang.org/phobos/std_datetime.html#.Date.roll does support days ?* Hmm. Looks like an oversight. File a bug? Not an oversight. Date.add and Date.roll are for adding units that are variable. For example, how many days are in a month? Answer: depends on the month. How many days in a year? Answer: depends on the year. But days are NOT variable, there are exactly 24 hours in a day. So to add a day, you just add a day with +=. Exactly. add wouldn't even exist if it weren't for the fact that Duration doesn't work with units greater than weeks because of they depend on what date you're talking about. - Jonathan M Davis
Re: Adding days to std.datetime.Date
On Tuesday, December 02, 2014 14:21:35 Steven Schveighoffer via Digitalmars-d-learn wrote: On 12/2/14 2:14 PM, Steven Schveighoffer wrote: Not an oversight. Date.add and Date.roll are for adding units that are variable. For example, how many days are in a month? Answer: depends on the month. How many days in a year? Answer: depends on the year. But days are NOT variable, there are exactly 24 hours in a day. So to add a day, you just add a day with +=. Aaaand to expand on this, since roll *does* support days, it's because the number being added isn't the important unit, it's the unit above. Hence rolling days means you will stay in the same month. I'm not exactly sure of the reason behind roll, but I'm sure Jonathan has one :) A prime example of where to use it would be if you have a GUI with spinners for the values, and you didn't want incrementing the day to increment the month. It would be kind of annoying to implement that without roll. And since you need to specify the units for rolling (and the addition operator was already used for normal adding), adding a Duration to the time point in order to roll didn't make sense, and a separate function was needed for it even for the smaller units. I don't remember if roll originated with Boost, or if I came up with it though (since portions of std.datetime's API are based on Boost - e.g. julianDay is only there because Boost had it, and astronomers use it such that it seemed useful enough to have; I wouldn't have come up with it on my own though). - Jonathan M Davis
Accented Characters and Counting Syllables
Given the fact that static assert(é.length == 2); I was surprised that static assert(é.byCodeUnit.length == 2); static assert(é.byCodePoint.length == 2); Isn't there a way to iterate over accented characters (in my case UTF-8) in D? Or is this an inherent problem in Unicode? I need this in a syllable counting algorithm that needs to distinguish accented and non-accented variants of vowels. For example café (2 syllables) compared to babe (one syllable.
Re: repack ubyte[] to use only 7 bits
Charles Hixson:
byte[]x8to7 (ubyte[] bin)
Better to add some annotations, like pure, @safe, nothrow, if you
can, and to annotate the bin with an in.
intfByte, fBit;
It's probably better to define them as size_t.
switch (fBit)
I think D doesn't yet allow this switch to be _meaningfully_ a
final switch.
b=bin[fByte] 0x7f;
D allows binary number literals as 0b100110010101.
b~=(b1 | b2);
Perhaps an output range is better?
if(b == 0)bout~=0x80;
elsebout~=b;
fBit=fBit + 7;
if(fBit 7)
{fByte++;
fBit -=7;
The formatting seems a bit messy.
Bye,
bearophile
Re: Accented Characters and Counting Syllables
On Sat, Dec 06, 2014 at 10:37:17PM +, Nordlöw via Digitalmars-d-learn wrote: Given the fact that static assert(é.length == 2); I was surprised that static assert(é.byCodeUnit.length == 2); static assert(é.byCodePoint.length == 2); Isn't there a way to iterate over accented characters (in my case UTF-8) in D? Or is this an inherent problem in Unicode? I need this in a syllable counting algorithm that needs to distinguish accented and non-accented variants of vowels. For example café (2 syllables) compared to babe (one syllable. This is a Unicode issue. What you want is neither byCodeUnit nor byCodePoint, but byGrapheme. A grapheme is the Unicode equivalent of what lay people would call a character. A Unicode character (or more precisely, a code point) is not necessarily a complete grapheme, as your example above shows; it's just a numerical value that uniquely identifies an entry in the Unicode character database. T -- There are 10 kinds of people in the world: those who can count in binary, and those who can't.
Re: @property usage
On Thursday, December 04, 2014 10:21:10 uri via Digitalmars-d-learn wrote: Hi All, Do you guys use @property much, or is it largely ignored/avoided? @property is used rather freuently - e.g. some of the functions in the range API are required to be properties. Typically, @property is used when you'd use a getter or setter in another language (or when you need to emulate a variable). Using get* or set* would generally not be considered idiomatic D and is not typically done. @property functions are used instead. Now, because the parens are optional on functions with no arguments, there are plenty of cases where functions are called without parens when they're not properties, but property functions are quite common. - Jonathan M Davis
Re: Check type is a struct at compile time?
On Friday, December 05, 2014 20:38:30 Gary Willoughby via Digitalmars-d-learn
wrote:
How can i check that a type is a struct at compile time? I know i
can test for a class like this:
static if(is(T == class))
{
...
}
But how to do the same thing for a struct?
static if(is(T == struct))
{
}
- Jonathan M Davis
Re: @property usage
On Sat, 06 Dec 2014 15:23:10 -0800 Jonathan M Davis via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Thursday, December 04, 2014 10:21:10 uri via Digitalmars-d-learn wrote: Hi All, Do you guys use @property much, or is it largely ignored/avoided? @property is used rather freuently - e.g. some of the functions in the range API are required to be properties. Typically, @property is used when you'd use a getter or setter in another language (or when you need to emulate a variable). Using get* or set* would generally not be considered idiomatic D and is not typically done. @property functions are used instead. Now, because the parens are optional on functions with no arguments, there are plenty of cases where functions are called without parens when they're not properties, but property functions are quite common. we all waiting for property enforcement fixes (which i already integrated, heh), so delegate properties can be used as propeties, omiting the annoying '()'. as this can break some invalid code (the code where people using properties as functions) i assume that we'll live with half-backed properties forever. signature.asc Description: PGP signature
Re: repack ubyte[] to use only 7 bits
Your comments would be reasonable if this were destined for a library,
but I haven't even finished checking it (and probably won't since I've
switched to a simple zero elimination scheme). But this is a bit
specialized for a library...a library should probably deal with
arbitrary ints from 8 to 64 or 128 [but I don't think that the 128 bit
type is yet standard, only reserved]. I just thought that something
like that should be available, possibly along the lines of Python's pack
and unpack, and wondered where it was and what it was called.)
Additionally, I'm clearly not the best person to write the library
version, as I still have LOTS of trouble with D templates. And I have
not successfully wrapped my mind around D ranges...which is odd, because
neither Ruby nor Python ranges give me much trouble. Perhaps its the syntax.
As for pure, @safe, and nothrow ... I'd like to understand that I
COULD use those annotations. (The in I agree should be applied. I
understand that one.)
As for size_t for indexes...here I think we disagree. It would be a bad
mistake to use an index that size. I even considered using short or
ushort, but I ran into a comment awhile back saying that one should
never use those for local variables. This *can't* be an efficient
enough way that it would be appropriate to use it for a huge array...but
that should probably be documented if it were for a library. (If I were
to use size_t indexing, I'd want to modify things so that I could feed
it a file as input, and that's taking it well away from what I was
building it for: converting input to a redis database so that I could
feed it raw serial data streams without first converting it into human
readable formats. I wanted to make everything ASCII-7 binary data,
which, when I thought about it more, was overkill. All I need to do is
eliminate internal zeros, since C handles various extended character
formats by ignoring them.
I'm not clear what you mean by a final switch. fBit must adopt
various different values during execution. If you mean it's the same as
a nest of if...else if ... statements, that's all I was really
expecting, but I thought switch was a bit more readable.
Binary literals would be more self-documenting, but would make the code
harder to read. If I'd though of them I might have used them...but
maybe not.
Output range? Here I'm not sure what you're suggesting, probably
because I don't understand D ranges.
The formatting got a bit messed up during pasting from the editor to the
mail message. I should have looked at it more carefully. My standard
says that unless the entire block is on a single line, the closing brace
should align with the opening brace. And I use tabs for spacing which
works quite well in the editor, but I *do* need to remember to convert
it to spaces before doing a cut and paste.
Thanks for your comments. I guess that means that there *isn't* a
standard function that does this.
Charles
On 12/06/2014 03:01 PM, bearophile via Digitalmars-d-learn wrote:
Charles Hixson:
byte[]x8to7 (ubyte[] bin)
Better to add some annotations, like pure, @safe, nothrow, if you can,
and to annotate the bin with an in.
intfByte, fBit;
It's probably better to define them as size_t.
switch (fBit)
I think D doesn't yet allow this switch to be _meaningfully_ a final
switch.
b=bin[fByte] 0x7f;
D allows binary number literals as 0b100110010101.
b~=(b1 | b2);
Perhaps an output range is better?
if(b == 0)bout~= 0x80;
elsebout~=b;
fBit=fBit + 7;
if(fBit 7)
{fByte++;
fBit -=7;
The formatting seems a bit messy.
Bye,
bearophile
