:03 PM UTC-4, Tamas Papp wrote:
I think it is implied that you can do this: there are quite a few
examples in the manual, eg
https://julia.readthedocs.org/en/latest/manual/types/#value-types
Best,
Tamas
On Tue, Apr 21 2015, Scott Jones scott.pa...@gmail.com javascript:
wrote:
Ah
Just what does it mean, if there is a type but no formal parameter name, in
a function definition?
I tried to find it in the documentation, but nothing came up...
Thanks,
Scott
that the argument doesn't get a local name but the method is only
called if the argument in that position matches the type on the RHS of the
::
On Tue, Apr 21, 2015 at 11:37 AM, Scott Jones scott.pa...@gmail.com
javascript: wrote:
Just what does it mean, if there is a type but no formal parameter
yet.
On Sat, Apr 25, 2015 at 12:31 PM, Stefan Karpinski ste...@karpinski.org
javascript: wrote:
Scott, I'm not really understanding your problem. Can you give an
example?
On Sat, Apr 25, 2015 at 11:53 AM, Scott Jones scott.pa...@gmail.com
javascript:
wrote
The compiler can't determine that there are no conflicts in the case where
the method uses a type that is local to the module?
That is the *only* case where I am saying that it should not be necessary
to have an import Base.bar or import Foo.bar if I
want to export a function and have it
down.
On Sat, Apr 25, 2015 at 4:24 PM, Scott Jones scott.pa...@gmail.com
javascript: wrote:
On Saturday, April 25, 2015 at 3:58:16 PM UTC-4, Jeff Bezanson wrote:
I think this is just a different mindset than the one we've adopted.
In the mindset you describe, there really
a
piece of code does.
On Sat, 2015-04-25 at 22:24, Scott Jones scott.pa...@gmail.com
javascript: wrote:
On Saturday, April 25, 2015 at 3:58:16 PM UTC-4, Jeff Bezanson wrote:
I think this is just a different mindset than the one we've adopted.
In the mindset you describe
semantics. The only options I see are my options
1 and 2: (1) move to a common interface, or (2) specify A.connect or
B.connect in client code, because the interfaces aren't compatible.
On Sat, Apr 25, 2015 at 5:55 PM, Scott Jones scott.pa...@gmail.com
javascript: wrote:
The problem
be
only one interface: if I write code that's supposed to work for any
`x`, and I say `connect(x, address, port)`, like it or not my code
only works for one of A and B, not both.
On Sat, Apr 25, 2015 at 6:25 PM, Scott Jones scott.pa...@gmail.com
javascript: wrote:
No, not at all.
I
work, right?
What is a good reason for it not to work?
Scott
On Sat, Apr 25, 2015 at 3:27 PM, Scott Jones scott.pa...@gmail.com
javascript: wrote:
My point is, if I have been careful, and export methods that always
reference at least one of type defined locally in my module, so
On Sunday, April 26, 2015 at 1:18:40 AM UTC-4, Jeff Bezanson wrote:
Scott-- yes! If BetterA imports and extends a function from A, it is
exactly the same function object. A.func and BetterA.func will be
identical. Problems only enter if A and BetterA were developed in
total isolation,
implement different methods of
the same function object, inherited from a common namespace. These methods
should dispatch on a connection object that determines who's method to use.
On Apr 25, 2015, at 8:02 PM, Scott Jones scott.pa...@gmail.com
javascript: wrote:
I think you are again
wrote:
I find something contradictory :
http://docs.julialang.org/en/latest/manual/variables/#stylistic-conventions
*Names of functions and macros are in lower case, without underscores.*
On Saturday, April 25, 2015 at 3:07:46 PM UTC+2, Scott Jones wrote:
Umm... the style guide
Ah, but that is NOT the situation I've been talking about... If the writer
of a module wants to have a function that takes ::Any, and is not using any
other types that are local to that package, then, from the rules I'd like
to see, they *would* have to explicitly import from Base (or whichever
That is up to the user to make their code readable.
I don't think this makes that necessarily any harder.
My example:
using GlobalDB
globalDBManager = GlobalDB.Manage()
myGlobal = connect(globalDBManager, mynamespace, myglobal)
myGlobal[12345.566] = A numeric subscript
using SQLDB
...@gmail.com wrote:
On Sunday, April 26, 2015 at 7:23:02 PM UTC+10, Scott Jones wrote:
Ah, but that is NOT the situation I've been talking about... If the
writer of a module wants to have a function that takes ::Any, and is not
using any other types that are local to that package, then, from
I agree - although I worry about the direction being taken currently to
prevent modules from using the same name unless they know in advance about
each other, and create some joint module that they can both import from in
order to extend the generic function.
I think this would unfortunately
Yes... I also would that explicit qualification would be a very good thing.
(I also wish Julia also had explicit exception handling, a la CLU...
exceptions in CLU didn't cost more than a normal return because of that
rule, and
it really helped when trying to figure out a clusters correctness)
Umm... the style guide for Julia says *to* use underscore for longer names,
*not* camelcase:
- modules and type names use capitalization and camel case:module
SparseMatrix, immutable UnitRange.
- functions are lowercase (maximum()
. I'm not a fan of conventions that involve judgment calls without an
especially compelling reason.
On Sat, Apr 25, 2015, 9:07 AM Scott Jones scott.pa...@gmail.com
javascript: wrote:
Umm... the style guide for Julia says *to* use underscore for longer
names, *not* camelcase
A problem I'm running into is the following (maybe the best practice for
this is documented, and I just to stupid to find it!):
I have created a set of functions, which use my own type, so they should
never be ambiguous.
I would like to export them all, but I have to import any names that
On Monday, April 27, 2015 at 6:40:50 PM UTC-4, ele...@gmail.com wrote:
On Sunday, April 26, 2015 at 8:24:15 PM UTC+10, Scott Jones wrote:
Yes, precisely... and I *do* want Julia to protect the user *in that
case*.
If a module has functions that are potentially ambiguous, then 1
One place where I'd like to see this used is with the JSON parser... the
current JSON parser can't represent all numbers, it's a potentially lossy
transformation from JSON numbers to
binary floats... although Javascript only has the equivalent of Float64 for
all numbers, the good JSON parsers
Another thought... would it be possible to get DecimalFloatingPoint, and
maybe the 3 types Dec32, Dec64, and Dec128 moved to Base?
Not the implementation, but rather just the types, which would be the same
no matter what Decimal floating point package you use...
Then I could add the packed types
To avoid name conflict problems, like I've been concerned about elsewhere? ☺
Sent from my iPhone
On Apr 29, 2015, at 8:40 AM, Steven G. Johnson stevenj@gmail.com wrote:
On Wednesday, April 29, 2015 at 8:16:57 AM UTC-4, Scott Jones wrote:
Another thought... would it be possible
:38 AM, Steven G. Johnson stevenj@gmail.com wrote:
On Wednesday, April 29, 2015 at 8:08:48 AM UTC-4, Scott Jones wrote:
handle all numbers without losing information (this is why I'd also like to
see a wrapper for the decNumber package, it supports all 6 fixed with
formats
People who might realize, after becoming acquainted with Julia, for general
computing, or maybe for some light usage of the math packages, might much
rather have understandable names available, so they don't always have to
run to the manual...
With decent code completion in your editor, I don't
On Sunday, April 26, 2015 at 1:41:24 PM UTC-4, Jeff Bezanson wrote:
I keep getting accused of insisting that every name have only one
meaning. Not at all. When you extend a function there are no
restrictions. The `connect` methods for GlobalDB and SQLDB could
absolutely belong to the
On Monday, April 27, 2015 at 3:27:07 AM UTC-4, Christoph Ortner wrote:
A comment in **strong support** of the Julia naming convention: these are
just my personal impressions:
I think in much of numerical analysis (and to some but lesser extent
scientific computing) overly short variable
part.
On Sunday, April 26, 2015 at 6:24:15 AM UTC-4, Scott Jones wrote:
Yes, precisely... and I *do* want Julia to protect the user *in that
case*.
If a module has functions that are potentially ambiguous, then 1) if the
module writer intends to extend something, they should do
On Monday, April 27, 2015 at 8:27:59 AM UTC-4, Tamas Papp wrote:
On Mon, Apr 27 2015, Scott Jones scott.pa...@gmail.com javascript:
wrote:
How is `cholfact` completely clear to the general programming community?
I bet most people, just seeing the name, would think it was some fact
On Monday, April 27, 2015 at 11:01:06 AM UTC-4, Yuuki Soho wrote:
On Monday, April 27, 2015 at 4:21:11 PM UTC+2, Kevin Squire wrote:
Just a note, Matlab-style [a b] concatenation has been deprecated in
Julia v0.4
On Monday, April 27, 2015 at 9:50:10 AM UTC-4, Yuuki Soho wrote:
There's one argument for * over +. That string concatenation is not
commutative, and that + main property is to be commutative.
And most people think of * as being commutative also...
I would be strongly against overloading
AM UTC-7, Scott Jones wrote:
I just remembered, it is the inequality operator in SQL... probably not a
good idea to use it!
You don't like have `[]` as an infix operator? (not `[a b]`!)
Scott
On Monday, April 27, 2015 at 10:36:27 AM UTC-4, François Fayard wrote:
Couldn't we use
On Monday, April 27, 2015 at 10:21:11 AM UTC-4, Kevin Squire wrote:
Just a note, Matlab-style [a b] concatenation has been deprecated in
Julia v0.4 https://github.com/JuliaLang/julia/pull/7998. See the
linked issues for details. The main issue is that this functionality makes
it
,
in such a way that those cannot be used for the core language,
(without breaking those packages)
(if they overload it ONLY using their own types, that's another issue
entirely, as the compiler could still disambiguate)
Scott
On Monday, April 27, 2015 at 4:54:52 PM UTC+2, Scott Jones wrote:
I just
Changing to + would still run into the problems where you are using vectors
of UInt8, UInt16, UInt32 (or Char), for mutable strings.
Not good either.
Add [] for general concatenation, (i.e. like vcat on vectors/arrays), and
and add a compiler warning for * suggestion replacing with [], and
On Monday, April 27, 2015 at 10:09:23 AM UTC-4, François Fayard wrote:
That's a point. One should see * as a monoid operator rather than
multiplication in the number meaning. I get it.
But I still believe that we are going way too far. I thought that all
those algebra stuff for everyone
On Monday, April 27, 2015 at 9:50:10 AM UTC-4, Yuuki Soho wrote:
There's one argument for * over +. That string concatenation is not
commutative, and that + main property is to be commutative.
Personally I don't mind * for string concatenation. If anything I would
prefer to have matlab
means not equal to in some languages, but that may not be that
important, and if it is familiar to the a lot of the current Julia
community, it could be a good choice.
On Monday, April 27, 2015 at 10:36:27 AM UTC-4, François Fayard wrote:
Couldn't we use for concatenation like in
I just remembered, it is the inequality operator in SQL... probably not a
good idea to use it!
You don't like have `[]` as an infix operator? (not `[a b]`!)
Scott
On Monday, April 27, 2015 at 10:36:27 AM UTC-4, François Fayard wrote:
Couldn't we use for concatenation like in Mathematica?
Why can't we have our cake and eat it too?
I'd suggest that all of these methods be given maximally understandable
names...
such as sparse_random_normal for sprandn.
Can't you then simply define sprandn as an alias for sparse_random_normal?
Would there be maybe a to have only the long names
On Wednesday, April 29, 2015 at 11:36:15 PM UTC-4, MA Laforge wrote:
*Scott and Michael:*
I am pretty certain I understand what you are saying, but I find your
examples/descriptions a bit confusing. I think (hope) I know why Stafan is
confused.
*Stefan:*
I think Scott has a valid
On Friday, May 1, 2015 at 9:16:43 AM UTC-4, Tim Holy wrote:
On Friday, May 01, 2015 03:19:03 AM Scott Jones wrote:
As the string grows, Julia's internals end up having to reallocate the
memory and sometimes copy it to a new location, hence the O(n^2) nature
of
the code.
Small
On Friday, May 1, 2015 at 12:10:32 AM UTC-4, Jeff Bezanson wrote:
On Thu, Apr 30, 2015 at 5:26 PM, Scott Jones scott.pa...@gmail.com
javascript: wrote:
Maybe because it seems that a lot of the major packages have been put
into
Base, so it isn't a problem, as MA Laforge pointed out
I should be clear, I didn't mean that all strings should be immutable, but
rather that I also want to have mutable strings available... There is a package
for that, but 1) I think it's incomplete (I may need to contribute to it), and
2) I think that they do belong in the base language...
CLU
Papp wrote:
consider
let io = IOBuffer()
write(io,rand(10))
takebuf_array(io)
end
IOBuffer() is not specific to strings at all.
Best,
Tamas
On Sun, May 03 2015, Scott Jones scott.pa...@gmail.com javascript:
wrote:
Because you can have binary strings and text strings
On Sunday, May 3, 2015 at 6:10:00 PM UTC-4, Kevin Squire wrote:
One thing I was confused about when I first started using Julia was that
things that are done with strings in other languages are often done
directly with IO objects in Julia.
For example, consider that, in Python, most
IOBuffer is the only
solution that has been given here… and it doesn’t handle what I need to do
efficiently...
If you have a better solution, please let me know…
Scott
On Mon, May 04 2015, Scott Jones scott.paul.jo...@gmail.com
mailto:scott.paul.jo...@gmail.com wrote:
I wasn't trying to say
On May 4, 2015, at 7:56 AM, Tamas Papp tkp...@gmail.com wrote:
On Mon, May 04 2015, Scott Jones scott.paul.jo...@gmail.com wrote:
On May 4, 2015, at 3:21 AM, Tamas Papp tkp...@gmail.com wrote:
I think you misunderstand: IOBuffer is suggested not for mutable string
operations in general
On Thursday, April 30, 2015 at 6:34:23 PM UTC-4, Páll Haraldsson wrote:
Interesting.. does that mean Unicode then that is esp. faster or something
else?
800x faster is way worse than I thought and no good reason for it..
That particular case is because CPython (which is the standard C
On Thursday, April 30, 2015 at 7:20:22 PM UTC-4, Páll Haraldsson wrote:
[Thanks for this addition..! I've been putting this off as I didn't really
need this personally. Just Wrapped PyDecimal as an exercise..]
As far as I know, numbers in JSON are defined to be binary floating
point..
On Thursday, April 30, 2015 at 8:01:05 PM UTC-4, Páll Haraldsson wrote:
Mixed operations involving decimal and binary floating-point or integer
types are supported (the result is promoted to decimal floating-point).
Is that really advised?
I meant for binary only. Mixing with integer is
On Apr 30, 2015, at 9:58 PM, Tim Holy tim.h...@gmail.com wrote:
Strings have long been a performance sore-spot in julia, so we're glad Scott
is hammering on that topic.
Thanks, Tim! I was beginning to think I’d be banned from all Julia forums, for
being a thorn in the side of
the Julia
On Thursday, April 30, 2015 at 5:03:52 PM UTC-4, Stefan Karpinski wrote:
On Wed, Apr 29, 2015 at 9:08 PM, Scott Jones scott.pa...@gmail.com
javascript: wrote:
Your restrictions are making it very hard to develop easy to use APIs
that make sense for the people using them…
That’s why so many
computing environments to be batteries included and to just work without
having to install additional stuff.
On Thu, Apr 30, 2015 at 5:26 PM, Scott Jones scott.paul.jo...@gmail.com
mailto:scott.paul.jo...@gmail.com wrote:
Maybe because it seems that a lot of the major packages have been put
included and to just work without
having to install additional stuff.
On Thu, Apr 30, 2015 at 5:26 PM, Scott Jones scott.paul.jo...@gmail.com
mailto:scott.paul.jo...@gmail.com wrote:
Maybe because it seems that a lot of the major packages have been put into
Base, so it isn't a problem, as MA
Yes... Python will win on string processing... esp. with Python 3... I
quickly ran into things that were 800x faster in Python...
(I hope to help change that though!)
Scott
On Thursday, April 30, 2015 at 6:01:45 PM UTC-4, Páll Haraldsson wrote:
I wouldn't expect a difference in Julia for
On Friday, May 1, 2015 at 1:23:40 PM UTC-4, Steven G. Johnson wrote:
On Friday, May 1, 2015 at 1:12:00 PM UTC-4, Steven Sagaert wrote:
That wasn't what I was saying. I like the philosophy behind julia. But in
practice (as of now) even in julia you still have to code in a certain
style
On Friday, May 1, 2015 at 3:27:38 PM UTC-4, Jeff Bezanson wrote:
I know, I was just having some fun with the That is life outside of
academia! comment.
That was really my envy speaking! ;-)
On Friday, May 1, 2015 at 11:48:21 AM UTC-4, Tim Holy wrote:
On Friday, May 01, 2015 08:03:31 AM Scott Jones wrote:
Still, same issue as I described above... probably better to increase by
2x
up to a point, and then by chunk sizes, where the chunk sizes might
slowly
get larger
On Friday, May 1, 2015 at 12:42:57 PM UTC-4, Steven G. Johnson wrote:
On Thursday, April 30, 2015 at 6:10:58 PM UTC-4, Scott Jones wrote:
Yes... Python will win on string processing... esp. with Python 3... I
quickly ran into things that were 800x faster in Python...
(I hope to help
Python julia
performance comparisons.
On Friday, May 1, 2015 at 3:10:14 PM UTC+2, Scott Jones wrote:
On May 1, 2015, at 8:23 AM, Steven Sagaert steven@gmail.com wrote:
On Friday, May 1, 2015 at 12:26:54 PM UTC+2, Scott Jones wrote:
On Friday, May 1, 2015 at 4:25:50 AM UTC-4, Steven
On Friday, May 1, 2015 at 12:38:33 PM UTC-4, Jeff Bezanson wrote:
Steven -- I agree and I find it very refreshing that you're willing to
judge a language by more than just performance. Any given language can
always be optimized better, so ideally you want to compare them by
more robust
to your product.
On Fri, May 1, 2015 at 10:35 AM, Scott Jones scott.pa...@gmail.com
javascript: wrote:
On Friday, May 1, 2015 at 12:10:32 AM UTC-4, Jeff Bezanson wrote:
On Thu, Apr 30, 2015 at 5:26 PM, Scott Jones scott.pa...@gmail.com
wrote:
Maybe because it seems
On Friday, May 1, 2015 at 1:25:41 AM UTC-4, Jeff Bezanson wrote:
It is true that we have not yet done enough to optimize the worst and
worse performance cases. The bright side of that is that we have room
to improve; it's not that we've run out of ideas and techniques.
Tim is right that
On Friday, May 1, 2015 at 4:25:50 AM UTC-4, Steven Sagaert wrote:
I think the performance comparisons between Julia Python are flawed.
They seem to be between standard Python Julia but since Julia is all
about scientific programming it really should be between SciPi Julia.
Since SciPi
I just read through all of that very interesting thread on exceptions... it
seems that Stefan was trying to reinvent the wheel, without knowing it.
Everybody interested in exception handling should go look up CLU... Julia
seems to have gotten a lot of ideas from CLU (possibly rather indirectly,
On Wednesday, April 29, 2015 at 4:41:38 PM UTC-4, Stefan Karpinski wrote:
Tom, this is a very legitimate concern. A simple solution is to have a
coding standard not to use `using` when writing packages. Google has
created coding standards for both C++ and Python, which are now widely used
On Apr 29, 2015, at 6:19 PM, Stefan Karpinski ste...@karpinski.org wrote:
On Wed, Apr 29, 2015 at 6:07 PM, Scott Jones scott.paul.jo...@gmail.com
mailto:scott.paul.jo...@gmail.com wrote:
I think this is easier to solve than you think.
The compiler should see this call as having
On Apr 29, 2015, at 10:55 AM, Steven G. Johnson stevenj@gmail.com wrote:
On Wednesday, April 29, 2015 at 8:51:49 AM UTC-4, Scott Jones wrote:
To avoid name conflict problems, like I've been concerned about elsewhere? ☺
If it really became important to use both simultaneously
On Wednesday, April 29, 2015 at 3:10:03 PM UTC-4, Simon Danisch wrote:
I haven't read the full discussion, but I think there is a very elegant
solution for these problems (pretty sure it has been mentioned somewhere).
Just internally use very Julian functions which make the best of multiple
On May 1, 2015, at 8:23 AM, Steven Sagaert steven.saga...@gmail.com wrote:
On Friday, May 1, 2015 at 12:26:54 PM UTC+2, Scott Jones wrote:
On Friday, May 1, 2015 at 4:25:50 AM UTC-4, Steven Sagaert wrote:
I think the performance comparisons between Julia Python are flawed
Great! +1 This will solve a lot of my problems about trying to maintain
good software engineering practices with Julia, (but not all, it doesn't
address being able to keep the implementation separate from the
abstraction...
I really don't want others to have the ability to play with my private
What if the job is a general job, but where Julia knowledge expertise is a
big ++?
(that sort of posting might in the the works for some people I know ;-) )
On Friday, March 6, 2015 at 1:51:16 PM UTC-5, Keno Fischer wrote:
I think if they are julia job postings they're fine. General data
I started contributing (and driving the core team to distraction) two weeks
ago, by finding things where I had a small amount of expertise in an area
that hadn't received maybe as much attention as other areas that I know
little about (those guys live in the clouds, IMO, way over my head!).
So
(N bytes allocated for
M objects), since the performance cost is likely more directly correlated to
the number of allocations rather than their cumulative size. It would also
probably be a good up for grabs-type project.
On Wed, May 6, 2015 at 10:55 PM Scott Jones scott.paul.jo
Ah, good to know! I was a bit confused!
I'd planned on installing IJulia on his laptop, but I'm not sure about the
state of IJulia with 0.4
(I like to live on the bleeding edge), and I was also going to install 0.4
on his laptop (so he gets his daddy's
string/char fixes ;-)
Have any of you
(N bytes allocated
for M objects), since the performance cost is likely more directly
correlated to the number of allocations rather than their cumulative size.
It would also probably be a good up for grabs-type project.
On Wed, May 6, 2015 at 10:55 PM Scott Jones scott.pa...@gmail.com
I'd say so... (I don't know if you saw my message on LinkedIn, but I was
serious about there maybe being a job for a C/C++ programmer where Juila
skills would be a big ++, in India).
PM UTC+2, Scott Jones wrote:
Has anybody had any experience teaching Julia to kids?
This is *not* a joke, my almost 9 year old son has a science project due
next week.
He knows some Lua (which he originally learned from the ComputerCraft mod
in MineCraft, and then using the Codea
app
+1, yes, definitely!
On Friday, May 1, 2015 at 8:28:17 PM UTC-4, Stefan Karpinski wrote:
Maybe we should include bytes freed as well.
On May 1, 2015, at 8:15 PM, ele...@gmail.com javascript: wrote:
On Saturday, May 2, 2015 at 2:45:16 AM UTC+10, cormu...@mac.com wrote:
Yes, that makes
I actually don't think it is really that hard... for the most part, Julia
needs better performance and better compatibility in some areas, that
haven't received as much attention as of yet... (strings, decimal floats,
database access). None of these things will take anything away from what
Already have my tickets ;-)
However, I was concerned about the following:
- Jake Bolewski https://github.com/jakebolewski, *TBC (Invited)*
- Jeff Bezanson https://github.com/JeffBezanson, *TBC (Invited)*
- Keno Fischer https://github.com/Keno, *TBC (Invited)*
- Are Jake,
:56 AM UTC-4, Viral Shah wrote:
Please do tweet, post, share about JuliaCon tickets.
-viral
On 11-May-2015, at 5:08 pm, Scott Jones scott.pa...@gmail.com
javascript: wrote:
Already have my tickets ;-)
However, I was concerned about the following:
• Jake Bolewski, TBC
Because you can have binary strings and text strings... there is even a
special literal for binary strings...
b\xffThis is a binary\x01\string
This is a \u307 text string
Calling it an IOBuffer makes it sound like it is specific to I/O, not just
strings (binary or text) that you might never do
That's just the garbage collector kicking in every so often... hence the
95.18% gc time and 96.16% gc time during the two slow runs...
On Saturday, May 9, 2015 at 5:24:08 PM UTC-4, Adam Check wrote:
Hi,
I'm sorry if this issue has been addressed before, but if so, I haven't
been able to
I also read this article this
morning:
http://economictimes.indiatimes.com/small-biz/startups/julia-founders-commercialise-language-create-new-startup/articleshow/47211869.cms
I had been a bit concerned, that after Wednesday, Jeff might have to go
find a job out in the real world, and would
Well, I spent many years doing nothing but proprietary development... all
trade secrets, etc. even though the language/database system was based on
an ANSI standard language. Now I'm consulting for a small startup, and we
are also trying to balance open source vs. proprietary development.
So
The one thing where I think you should change a bit, is that I think you
should be looking at the big picture already when making language design
decisions... (for example, the operator for string concatenation ;-), using
up back tic for commands, or ~ for DataFrames...).
It doesn't mean you
On Thursday, December 4, 2014 at 5:24:18 PM UTC-5, Simon Danisch wrote:
Actually, I opened this thread:
https://groups.google.com/forum/?fromgroups=#!topic/julia-users/IjG2ERHVjz0
when I needed to revisit prolog and first order logic for my AI exam...
I think Julia can be great for DSLs!
PL/1 (actually Cornell's PL/C, which had a simple REPL) was my very first
programming language, back in 1973. At the time, for commercial
programming, it was much nicer (IMO) than either Fortran or COBOL... It
supported binary floating point like Fortran and decimal floating point
like
I would like to get the performance of string handling in Julia improved
(and also correct a number of flaws in handling Unicode).
Currently, many of the operations are very slow (because of the way strings
are represented, and also simply
because the algorithms used were not as fast as they
for children, etc.
Best,
Tamas
On Thursday, May 7, 2015 at 2:00:30 PM UTC+2, Scott Jones wrote:
Has anybody had any experience teaching Julia to kids?
This is *not* a joke, my almost 9 year old son has a science project due
next week.
He knows some Lua (which he originally learned from
Things like this are why I avoid Windows like the plague these days...
Do you need to check both the 8-bit and Unicode environments then to set the
environment variable so R can see it?
About Julia Computing, is Stefan also going to be working full time for
Julia Computing? As the second largest contributor (and most vocal!), I
think
that would be critical (and would be greatly reassuring to people betting
on Julia...).
His GitHub shows him living in NYC, but that he's an MIT
, so that everything is clear and in one
place.
-viral
On 13-May-2015, at 7:42 pm, Scott Jones scott.pa...@gmail.com
javascript: wrote:
Yes, it was clear that you were also a cofounder of Julia Computing,
what was not clear, just from your GitHub info, if you were actively
Yes, it was clear that you were also a cofounder of Julia Computing, what
was not clear, just from your GitHub info, if you were actively working for
JC, or for MIT, or splitting your time between them.
I do hope there’s enough funding so that you’ll be able to work full time
on the language.
On Saturday, May 16, 2015 at 8:50:12 AM UTC-4, ele...@gmail.com wrote:
If Module A has connect(value::Any), and I add a module B with
connect(value::TypeB), I don't see a problem with calls to connect with
something of TypeB changing the behavior
of Module A by not letting it grab *all*
On Friday, May 15, 2015 at 3:14:22 AM UTC-4, Viral Shah wrote:
Hi everyone,
Some more details on NumFocus. When we joined NumFocus, Stefan joined
their board. In addition, 5 people represent the Julia project in the
NumFocus Fiscal Sponsorship Agreement - Tim Holy, Steve Johnson, John
1 - 100 of 473 matches
Mail list logo
