On mið 23.sep 2015 15:34, Daniel Carrera wrote:
To match MATLAB in
speed, Julia code should typically be about the same length.
That is good enough for me (to match MATLAB and Python's length and at
least not be slower) and then no big concern there. C/C++ doesn't even
have real macros, and I'm not even sure those can come close to the
shorter code, defaulting to loops.
I just
happen to like loops better because I feel I have more control over the
detailed steps.
Now I see, I kind of assumed loops might have been a requirement. [I'm
familiar with similar, for SQL, declarative, sometimes the query
optimizer isn't clever enough and you have to bend over backwards to get
it to behave..]
What is a temporary situation? Sorry, I'm not trying to be obtuse, but
I'm having a hard time understanding your concerns.
This part is why I e-mail you directly. There may be no temporary
situation. I didn't want to take over this thread. Thanks for replying.
If the macros (I assume you mean @devec possibly others) work (as I
thought) then they are a trivial addition to siz (maybe not length..) of
code.
Why would Julia convert anything? A string is just a sequence of bytes
in memory.
If you are right, then there is no point for me to respond (by posting
about this to the mailing list). I may have the wrong idea about APIs,
but I think if you choose the concrete type UTF8 in your code, then that
encoding is used for the string of bytes in Julia internally. Then when
you call the Windows API (not some non-operating system API) then it
requires the different UTF16 encoding.
Even if you are right and I am wrong about this, this is not a huge
deal, at least for me, to highjack a thread over..
There is no connection to any Windows internal. In fact, you
don't even know how Windows stores strings. Just because the API uses
UTF16 doesn't mean that the internal representation in Windows is UTF16.
[Side issue: I understand, at the time, the Windows API had to be
duplicated for UTF16. I assume the older then only handles ASCII, and
while we do not know for sure I would think Windows uses UTF16
internally and the old API would have to convert on the inside.]
A API is just a way to talk to a library. It means almost nothing.
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..?
Windows *IS* *NOT* a second-class platform. You are imagining a
limitation that doesn't exist. The Windows API has nothing to do with
how Julia runs.
Between API calls. "second class platform" was probably too strong a
language. I'm not sure if UTF8 is preferred anywhere in Julia (in Base).
It might or might not be in some libraries, that would then be more
Linux centric (or vice versa..) or just in your own code. I just can't
see any way around it, if these two encodings are used "at the same
time" then you must convert between and the platform with the code where
you do not have to will be slightly faster. Maybe I'm right and you
don't see it as it is an almost non-issue.. Or someting is just missing
from my understanding of Julia. Thanks for trying to clear up. It's not
like you have to do it. Or even respond further.
--
Palli.
