Le mercredi 23 septembre 2015 à 07:38 -0700, Páll Haraldsson a écrit :
> Yes,
>
> What prompted my question was Tim Holy: "String is not a concrete
> type. Consider ASCIIString or UTF8String." Maybe ok in this case. If
> he meant it as a general advise, I thought maybe a Union of the UTF
> encodings (and ASCII?) would be needed to be general. Or not, as you
> say (and I), this may never really be a speed bottleneck. At least
> the convert system takes care of any UTF concreat type works.
If you need your type to support any kind of string, you can
parameterize in on the concrete string type. For example
type MyType{S<:String}
s::S
end
instead of these two type-unstable variants:
type MyType
s::String
end
or of
type MyType
s::Union(UTF8String,UTF16String)
end
Regards
> On Wednesday, September 23, 2015 at 2:03:22 PM UTC, Milan Bouchet
> -Valat wrote:
> > Le mercredi 23 septembre 2015 à 05:15 -0700, Páll Haraldsson a
> > écrit :
> > >
> > >
> > > On Monday, September 21, 2015 at 12:18:12 AM UTC, Daniel Carrera
> > > wrote:
> > > >
> > > > On 21 September 2015 at 01:36, Páll Haraldsson <
> > > > [email protected]> wrote:
> > > > > I know about @devec but wander how close Julia is also able
> > to
> > > > > match the speed of its looks with more condensed code or
> > MATLAB
> > > > > -like or functional programming language style. What are the
> > most
> > > > > interesting issue numbers to look at, if you were to try to
> > help?
> > > > > I'm guessing its not one of the easier "up-for-grabs" issues,
> > for
> > > > > relative newbies like me..
> > > > >
> > > > Sorry, I don't understand what you are trying to ask.
> > > >
> > > I really just meant, with the loop, the code goes from 2 to 6
> > lines.
> > > Is three times LOC a drawback of Julia to get speed (note you do
> > not
> > > *have to* expand if speed isn't critical, and much code isn't).
> > > Compared to C/C++ that is competetive, but may not be against say
> > > MATLAB. The code was already fast there and didn't need a loop. I
> > > assume/understand this is a temporary situation, and maybe I or
> > > anyone can help fix it.
> > > >
> > > >
> > > > > Another thing I saw:
> > > > > "String is not a concrete type. Consider ASCIIString or
> > > > > UTF8String. "
> > > > >
> > > > > This would not apply in Python, UTF8, UTF16 etc. could be in
> > a
> > > > > type (a new one that can hold the others through
> > composition?)
> > > > > that "just works" [fast]? Windows uses UTF16 and then
> > choosing
> > > > > UTF8String there would be bad?
> > > > >
> > > > No, that's not what it means. UTF8String will be fast too. In
> > Julia
> > > > there are two kinds of types: concrete types, and abstract
> > types. A
> > > > concrete are things like:
> > > >
> > > Thanks for answering. I knew about abstract vs. concrete. What I
> > > meant here, "UTF8String will be fast" yes, but if you are on
> > Windows
> > > the API uses UTF16 and I assume you'll be converting needlessly
> > back
> > > and forth. That might not be a problem, you are maybe I/O
> > -limited.
> > > But if not, will Windows always be second class platform, for
> > code
> > > that assumes UTF8 (or wise versa..)? Will Julia at least compete
> > will
> > > with Python for string handling..?
> > This has been discussed a few times already. Passing strings to the
> > OS
> > isn't usually a bottleneck. For example, after listing the contents
> > of
> > a directory, converting the paths from UTF-16 to UTF-8 for display
> > is
> > much cheaper than the I/O operations involved.
> >
> > In use cases where it really matters, UTF16String will work fine.
> > After
> > all, in Julia, there are no built-in types: all custom string types
> > can
> > work as well and as fast as the default one.
> >
> >
> > Regards
