On Thursday, 17 August 2023 at 09:28:05 UTC, Joel wrote:
.map!(std.uni.toLower)
.sort!"aonlineapp.d(8): Error: none of the overloads of template
`std.algorithm.sorting.sort` are callable using argument types
`!("a
On Thursday, 17 August 2023 at 14:14:00 UTC, bachmeier wrote:
On Thursday, 17 August 2023 at 09:28:05 UTC, Joel wrote:
I get an compile time error with sort after using toLower,
putting in array before sort, didn’t work:
```d
void main() {
Import std;
"Ezra
On Thursday, 17 August 2023 at 09:28:05 UTC, Joel wrote:
I get an compile time error with sort after using toLower,
putting in array before sort, didn’t work:
```d
void main() {
Import std;
"EzraTezla"
.to!(char[])
.byCodeUnit
the two `toLower`
functions..
How do I get it to work?
I tried std.ascii.toLower. And using alias
toLower=std.ascii.toLower;
To elaborate more, `toLower` doesn't work because
function-scope aliases are not considered for UFCS.
```
alias toLower = std.ascii.toLower;
...
// So
On Tuesday, 15 August 2023 at 20:09:28 UTC, Joel wrote:
On Tuesday, 15 August 2023 at 16:54:49 UTC, FeepingCreature
wrote:
But does *not* import `std.ascii`! So there's no ambiguity
inside the `sort` string expression between the two `toLower`
functions..
How do I get it to work?
I tried
, these modules are imported for use in string
expressions:
```
import std.algorithm, std.conv, std.exception, std.math,
std.range, std.string;
import std.meta, std.traits, std.typecons;
```
And `std.string` itself publically imports:
```
public import std.uni : icmp, toLower, toLowerInPlace
expressions:
```
import std.algorithm, std.conv, std.exception, std.math,
std.range, std.string;
import std.meta, std.traits, std.typecons;
```
And `std.string` itself publically imports:
```
public import std.uni : icmp, toLower, toLowerInPlace, toUpper,
toUpperInPlace;
```
But does *not* import
On Tuesday, 15 August 2023 at 16:47:36 UTC, Joel wrote:
How come toLower works in the sort quotes, but not in the map?
```d
void main() {
import std;
"EzraTezla"
.to!(char[])
.byCodeUnit
.sort!"a.toLower c.toLower)
.writeln;
}
```
onlinea
On Tuesday, 15 August 2023 at 16:47:36 UTC, Joel wrote:
How come toLower works in the sort quotes, but not in the map?
```d
void main() {
import std;
"EzraTezla"
.to!(char[])
.byCodeUnit
.sort!"a.toLower c.toLower)
.writeln;
}
```
When yo
How come toLower works in the sort quotes, but not in the map?
```d
void main() {
import std;
"EzraTezla"
.to!(char[])
.byCodeUnit
.sort!"a.toLower c.toLower)
.writeln;
}
```
onlineapp.d(60): Error: `toLower` matches conflicting symbols:
/
On 2017-03-19 22:32, Nordlöw wrote:
Is there an in-place version of std.uni.toLower()
If not, how do I most elegantly construct one?
I would recommend against toLower and toUpper as in-place versions. Not
all letters can be converted in-place, i.e. they might require more storage
On 03/19/2017 10:32 PM, Nordlöw wrote:
Is there an in-place version of std.uni.toLower()
toLowerInPlace
Is there an in-place version of std.uni.toLower()
If not, how do I most elegantly construct one?
I'm trying to identify the preferred ways to lower case a string.
In std.uni there are two functions that return the lower case
form of a string: toLower() and asLowerCase(). There is also
toLowerInPlace().
I'm having trouble figuring out what the relationship is between
these, and when
On Sunday, 24 January 2016 at 20:56:20 UTC, Jon D wrote:
I'm trying to identify the preferred ways to lower case a
string. In std.uni there are two functions that return the
lower case form of a string: toLower() and asLowerCase(). There
is also toLowerInPlace().
toLower will allocate a new
On Sunday, 24 January 2016 at 21:04:46 UTC, Adam D. Ruppe wrote:
On Sunday, 24 January 2016 at 20:56:20 UTC, Jon D wrote:
I'm trying to identify the preferred ways to lower case a
string. In std.uni there are two functions that return the
lower case form of a string: toLower() and asLowerCase
On Thursday, 30 August 2012 at 05:26:52 UTC, Philippe Sigaud
wrote:
And with no UFCS ? Did you try s ~= toUpper(field) ~ , ;
Yeah with or without UFCS, the second one fails.
On 2012-08-30 02:13, cal wrote:
Given this code for CTFE on a string array:
enum E {one, two}
enum string[] fields = [EnumMembers!E].to!(string[]);
string print(string[] fields)
{
string s;
foreach(string field; fields)
{
s ~= field.toUpper ~ , ;
}
return s;
}
On 2012-08-30 08:28, Jacob Carlborg wrote:
It works for me. DMD 2.060 Mac OS X.
Oh, it does not. If I replace:
enum string[] fields = [EnumMembers!E].to!(string[]);
With:
enum string[] fields = [one, two];
It works.
--
/Jacob Carlborg
On Thursday, 30 August 2012 at 06:30:50 UTC, Jacob Carlborg wrote:
On 2012-08-30 08:28, Jacob Carlborg wrote:
It works for me. DMD 2.060 Mac OS X.
Oh, it does not. If I replace:
enum string[] fields = [EnumMembers!E].to!(string[]);
With:
enum string[] fields = [one, two];
It works.
On Thursday, 30 August 2012 at 17:38:48 UTC, cal wrote:
On Thursday, 30 August 2012 at 06:30:50 UTC, Jacob Carlborg
wrote:
Replacing string[] with dstring[] for EnumMembers triggers a DMD
bug, so I guess the CTFE interpreter is buggy even in the
string[] case.
Filed
Given this code for CTFE on a string array:
enum E {one, two}
enum string[] fields = [EnumMembers!E].to!(string[]);
string print(string[] fields)
{
string s;
foreach(string field; fields)
{
s ~= field.toUpper ~ , ;
}
return s;
}
pragma(msg, print([one, two]));
On Thu, Aug 30, 2012 at 2:13 AM, cal callumena...@gmail.com wrote:
Given this code for CTFE on a string array:
enum E {one, two}
enum string[] fields = [EnumMembers!E].to!(string[]);
string print(string[] fields)
{
string s;
foreach(string field; fields)
{
s ~=
Am Sun, 22 Apr 2012 09:23:45 +0200
schrieb Jay Norwood j...@prismnet.com:
On Sunday, 22 April 2012 at 06:26:42 UTC, Jonathan M Davis wrote:
You can look at the code. It checks each of the characters in
place. Unlike
toLower, it doesn't need to generate a new string. But as far
On Mon, 23 Apr 2012 16:43:20 +0100, Steven Schveighoffer
schvei...@yahoo.com wrote:
While dealing with unicode in my std.stream rewrite, I've found that
hand-decoding dchars is way faster than using library calls.
After watching Andrei's talk on generic and generative programming I have
, by doing a byte comparison (no dchar
decoding) until it finds a difference. That might be a huge
speedup. Right now, all dchars are being decoded, and translated
to the toLower counterpart. It may have an opposite effect,
however, if there are a lot of strings that are equivalent when
On Tuesday, 24 April 2012 at 14:54:48 UTC, Steven Schveighoffer
wrote:
On Tuesday, 24 April 2012 at 11:24:44 UTC, Regan Heath wrote:
After watching Andrei's talk on generic and generative
programming I have to ask, which routines are you avoiding ..
it seems we need to make them as good as the
On Tuesday, April 24, 2012 12:24:44 Regan Heath wrote:
On Mon, 23 Apr 2012 16:43:20 +0100, Steven Schveighoffer
schvei...@yahoo.com wrote:
While dealing with unicode in my std.stream rewrite, I've found that
hand-decoding dchars is way faster than using library calls.
After watching
On Sat, 21 Apr 2012 19:24:56 -0400, Jay Norwood j...@prismnet.com wrote:
While playing with sorting the unzip archive entries I tried use of the
last example in http://dlang.org/phobos/std_algorithm.html#sort
std.algorithm.sort!(toLower(a.name)
toLower(b.name
On Monday, 23 April 2012 at 11:27:40 UTC, Steven Schveighoffer
wrote:
I think using std.string.icmp is the best solution. I would
expect it to outperform even schwartz sort.
-Steve
icmp took longer... added about 1 sec vs 0.3 sec (for
schwartzSort ) to the program execution time.
bool
On Mon, 23 Apr 2012 09:49:50 -0400, Jay Norwood j...@prismnet.com wrote:
On Monday, 23 April 2012 at 11:27:40 UTC, Steven Schveighoffer
wrote:
I think using std.string.icmp is the best solution. I would expect it
to outperform even schwartz sort.
-Steve
icmp took longer... added about 1
On Sunday, 22 April 2012 at 02:29:45 UTC, Jonathan M Davis wrote:
Regardless of whether it's the Big(O) complexity or the
constant factor that's
the problem here, clearly there's enough additional overhead
that it's causing
problems for Jay's particular case. It's also the sort of thing
that
://dlang.org/phobos/std_string.html#icmp
Technically, icmp(r1, r2) is equivalent to
cmp!std.uni.toLower(a) std.uni.toLower(b)(r1, r2).
You can look at the code. It checks each of the characters in place. Unlike
toLower, it doesn't need to generate a new string. But as far as the
comparison goes
On Sunday, 22 April 2012 at 06:26:42 UTC, Jonathan M Davis wrote:
You can look at the code. It checks each of the characters in
place. Unlike
toLower, it doesn't need to generate a new string. But as far
as the
comparison goes, they're the same - hence that line in the docs.
- Jonathan M
On 22.04.2012 5:43, Ali Çehreli wrote:
On 04/21/2012 04:24 PM, Jay Norwood wrote:
While playing with sorting the unzip archive entries I tried use of the
last example in http://dlang.org/phobos/std_algorithm.html#sort
std.algorithm.sort!(toLower(a.name)
toLower(b.name
On 2012-04-22 01:24, Jay Norwood wrote:
While playing with sorting the unzip archive entries I tried use of the
last example in http://dlang.org/phobos/std_algorithm.html#sort
std.algorithm.sort!(toLower(a.name)
toLower(b.name),std.algorithm.SwapStrategy.stable)(entries);
It was terribly slow
On Saturday, 21 April 2012 at 23:24:57 UTC, Jay Norwood wrote:
While playing with sorting the unzip archive entries I tried
use of the last example in
http://dlang.org/phobos/std_algorithm.html#sort
std.algorithm.sort!(toLower(a.name)
toLower(b.name),std.algorithm.SwapStrategy.stable
On Sunday, 22 April 2012 at 00:36:19 UTC, bearophile wrote:
Performing the toLower every time the cmp function is called
doesn't change the O complexity. In Phobos there is an
alternative sorting (Schwartzian sorting routime) that applies
a function to each item before sorting them, usually
While playing with sorting the unzip archive entries I tried use
of the last example in
http://dlang.org/phobos/std_algorithm.html#sort
std.algorithm.sort!(toLower(a.name)
toLower(b.name),std.algorithm.SwapStrategy.stable)(entries);
It was terribly slow for sorting the 34k entries in my
On Sunday, April 22, 2012 01:24:56 Jay Norwood wrote:
While playing with sorting the unzip archive entries I tried use
of the last example in
http://dlang.org/phobos/std_algorithm.html#sort
std.algorithm.sort!(toLower(a.name)
toLower(b.name),std.algorithm.SwapStrategy.stable)(entries
not sure how much more
expensive - it might cost less than sort such that it actually doesn't
matter as for as Big(O) goes though).
Performing the toLower every time the cmp function is called doesn't change
the O complexity.
Yes it does. It adds a loop to each comparison (two loops
the conversion only once is still more expensive
than not converting, but I'm not sure how much more expensive - it
might cost less than sort such that it actually doesn't matter as
for as Big(O) goes though).
Performing the toLower every time the cmp function is called doesn't change
the O
On 04/21/2012 04:24 PM, Jay Norwood wrote:
While playing with sorting the unzip archive entries I tried use of the
last example in http://dlang.org/phobos/std_algorithm.html#sort
std.algorithm.sort!(toLower(a.name)
toLower(b.name),std.algorithm.SwapStrategy.stable)(entries);
Stealing
On Saturday, 21 April 2012 at 23:54:26 UTC, Jonathan M Davis
wrote:
Yeah. toLower would be called on both strings on _every_
compare. And since
that involves a loop, that would make the overall call to sort
an order of
magnitude worse than if you didn't call toLower at all. I'm not
sure
On Sunday, April 22, 2012 03:47:30 Jay Norwood wrote:
On Saturday, 21 April 2012 at 23:54:26 UTC, Jonathan M Davis
wrote:
Yeah. toLower would be called on both strings on _every_
compare. And since
that involves a loop, that would make the overall call to sort
an order of
magnitude
On Saturday, April 21, 2012 18:43:23 Ali Çehreli wrote:
On 04/21/2012 04:24 PM, Jay Norwood wrote:
While playing with sorting the unzip archive entries I tried use of the
last example in http://dlang.org/phobos/std_algorithm.html#sort
std.algorithm.sort!(toLower(a.name)
toLower
On Saturday, April 21, 2012 18:26:42 H. S. Teoh wrote:
Actually, I don't think the nested loops affect Big-O complexity at all.
The O(l) complexity (where l = string length) is already inherent in the
string comparison str otherStr. Adding more loops over the strings
doesn't change the Big-O
47 matches
Mail list logo
