No, I don't take hardly anything personally [my problem is that expect others to do the same]. I just want to understand Julia as best as possible, and improve her if I can... and I think reasoned debates about the technical issues (as opposed to... I just like this better, I think that looks ugly, or I'd rather do things how I'm already familiar with) is great, and I learn a lot.
On Friday, May 1, 2015 at 12:52:04 PM UTC-4, Steven Sagaert wrote: > > Scott, > You shouldn't take my reply personal. It wasn't really about the specific > string case you mentioned but more in general about 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 <[email protected]> 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. >>>> 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 uses much of the same underlying libs in Fortran/C the >>>> performance gap will be much smaller and to be really fair it should be >>>> between numba compiled SciPi code & julia. I suspect the performance will >>>> be very close then (and close to C performance). >>>> >>> >>> Why should Julia be limited to scientific programming? >>> I think it can be a great language for general programming, >>> >> >> I agree but for now & the short time future I think the core domain of >> julia is scientific computing/data science and so to have fair comparisons >> one should not just compare julia to vanilla Python but especially scipi & >> numba. >> >> >> I stated that my comparisons were of string processing… what’s unfair >> about that? I have no expertise to compare Julia to any scientific >> computing system, I’ll leave that to the people here that do (and there are >> many, very highly qualified). >> Also, even in technical computing, the performance issues I raise may be >> of some importance, for example, issues about performance connection to a >> database… I assume that sometimes you need to read scientific data from a >> database, and store results to one? >> >> Scott >> >>
