Sorry for the delay, I found the problem though; the rlwrap manpage says that for commands that already use readline, you need to add -a. So, to make rlwrap work with hc, use:

`rlwrap -a hc`

Thanks a lot! Now this will not only help me with hc, but other math programs I used for which I had the same problem. Many thanks . Also thanks for the update to hc.

[Edit] But tabbing twice to obtain the list of functions does not work with rlwrap. Any other helpful suggestions are welcome . [/Edit]

]]>`rlwrap -a hc`

Also, I just posted the new version, 4.0, in AUR, the changes in this version are pretty much some minor adjustments to graphs and addition of graphvalues() to draw a table of values; in statistics, I added linreg() to do a linear regression of data; and finally, I added some functional programming concepts, for now there are lambda functions and map() (check http://houbysoft.com/hc/fnp.php for usage).

As always, feedback and thoughts are welcome!

]]>Anyway, I'll check it out in more detail later this week if I have some time.

]]>Thanks a ton for this! It seems most calculator creators ignore people who run all of their programs in a terminal, typically those with tiling WM's.

I'm glad you find it useful

livibetter wrote:

Thanks for explanation, y27!

I wonder if anyone has tried:

`ones(1000)`

I got a segmentation fault, then I saw a working buffer `tmp` is capped to size `MAX_EXPR`, which is 16384 bytes. Around 400-500 is enough to cause segmentation fault.

I don't expect seeing it getting fixed or graceful warning message, but seeing a new design of HC, because `ones(10000)` took 2+ seconds and `ones(20000)` took 8+ seconds. It's not the generation of vector string takes that long but some others after the vector string being generated, I guess.

I think I just like pushing... ;p

Hmm, this was due to hc simplifying the resulting list which is not necessary for zeros() or ones(). Made an optimization that checks whether the resulting list needs simplifying; and if not, it doesn't do anything with it, so zeros() and ones() should now be much faster. Also, the limit is now higher (I tried doing zeros(5000) and it still works), because what happens when a list like [1,1,1] is simplified is that hc_result_() (note the underscore) is called, which does not do any final formatting "niceification" (for speed), so [1,1,1] becomes something like [1.00000,1.00000,1.00000] which takes more space than just [1,1,1].

In the latest commit, I also added a mechanism to check whether the list is too big, so it doesn't segfault now even for very big input (it should just print Error : Overflow).

Btw, if you really feel you need to generate even larger arrays, you can always increase MAX_EXPR in hc.h and recompile.

]]>I wonder if anyone has tried:

`ones(1000)`

I got a segmentation fault, then I saw a working buffer `tmp` is capped to size `MAX_EXPR`, which is 16384 bytes. Around 400-500 is enough to cause segmentation fault.

I don't expect seeing it getting fixed or graceful warning message, but seeing a new design of HC, because `ones(10000)` took 2+ seconds and `ones(20000)` took 8+ seconds. It's not the generation of vector string takes that long but some others after the vector string being generated, I guess.

I think I just like pushing... ;p

]]>The slower performance of the second version you posted is probably due to how hc evaluates

`y[k]+=x[j] * exp(dd*j);`

It first evaluates

`y[k] + (x[j] * exp(dd*j))`

for which it has to get the value of y[k], which takes longer than taking just a value of a simple variable like xk in the third version.

Then it does:

`y[k] = result of previous code`

for which it has to do some work again to find the kth element of y.

By the way, I've released HC v3.1, which pretty much includes the various changes and fixes livibetter suggested (thanks ) and a few other things.

Changelog:

```
- added more detailed syntax error messages
- fixes and enhancements to vectors; for example, it is now possible to use assignment by index (ie. v[2] = 3)
- on *NIX, it is now possible to use ~ in filenames and it will get properly expanded
- added zeros() and ones()
- bugfixes
```

@zeros:

Added, with the same functionality as your codeAlso added ones(), which does the same as zeros() but puts 1's in the array. This can be useful since it's then possible to generate an array containing any constant numbers (ie to generate a list of 3 42's, one can do ones(3) * 42).

Great job!

TIme to update the fft()!

Previous ~344ms:

```
fft(x)=for(k=0;N=length(x);y=[],k<N,k+=1,
for(j=0;dd=-2pi*k*0i1/N;xk=0,j<N,j+=1,
xk+=x[j] * exp(dd*j);
);
y=join(y,[xk]);
if(k==N-1,y);
)
print(fft([1,0,3i-3,4i5,51,0,3i-3,4i5,5,0,3i-3,4i5,51,0,3i-3,4i5,5]))
```

Fully use v[index] ~375ms:

```
fft(x)=for(k=0;N=length(x);y=zeros(N),k<N,k+=1,
for(j=0;dd=-2pi*k*0i1/N,j<N,j+=1,
y[k]+=x[j] * exp(dd*j);
);
if(k==N-1,y);
)
print(fft([1,0,3i-3,4i5,51,0,3i-3,4i5,5,0,3i-3,4i5,51,0,3i-3,4i5,5]))
```

For better performance ~344ms (same as first one):

```
fft(x)=for(k=0;N=length(x);y=zeros(N),k<N,k+=1,
for(j=0;dd=-2pi*k*0i1/N;xk=0,j<N,j+=1,
xk+=x[j] * exp(dd*j);
);
y[k]=xk;
if(k==N-1,y);
)
print(fft([1,0,3i-3,4i5,51,0,3i-3,4i5,5,0,3i-3,4i5,51,0,3i-3,4i5,5]))
```

Added, with the same functionality as your code

Also added ones(), which does the same as zeros() but puts 1's in the array. This can be useful since it's then possible to generate an array containing any constant numbers (ie to generate a list of 3 42's, one can do ones(3) * 42).

]]>I had some time, so I implemented the earlier request:

Also, we should be allowed to substitute any element of a vector, e.g. `v[2]=3`.

This is now possible in the latest git revision, please test

This is great. But I think we also need initialization functions, such as `zeros()` in MATLAB, though we can user-define one.

`zeros(n) = for(j=0,j<n,j+=1,if(j==0,y=[0],y=join(y,[0]);if(j==n-1,y)))`

And the `~` expansion is great, I have seen that `wordexp` but it requires a header inclusion and it's many feature we don't need, so I thought do it by self might be a better option. But my code is a mess.

]]>```
~ becomes user's home
~USERNAME becomes USERNAME's home
etc.
```

On WIN32, this is disabled.

]]>Also, we should be allowed to substitute any element of a vector, e.g. `v[2]=3`.

This is now possible in the latest git revision, please test

]]>