Project

General

Profile

Design #1018

Interpreter: limit range for ".." operator

Added by Anna Maria Bigatti about 7 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
John Abbott
Category:
Parser/Interpreter
Target version:
CoCoA-5.2.0 spring 2017
Start date:
02 Mar 2017
Due date:
% Done:

100%

Estimated time:
1.44 h
Spent time:
1.40 h

Description

Currently there is no check for the arguments of ..
Limit the input!
for example upper-lower < ???

History

#1 Updated by John Abbott almost 7 years ago

  • Status changed from New to Feedback
  • % Done changed from 10 to 90
  • Estimated time set to 1.01 h

In fact this has already been implemented: there is an arbitrary upper limit of 10^8 elements in the result.
Perhaps this limit is too high?
NOTE on my machine 1..100000000 produces a result which occupies about 9Gbytes!

I am not entirely happy with imposing an arbitrary limit on .. (DOTDOT), but I suppose it is safer than not doing so.

#2 Updated by Anna Maria Bigatti almost 7 years ago

sounds good to me

#3 Updated by John Abbott almost 7 years ago

I have added a note to the man page about "range operator".

I wonder whether a limit of 10^7 would be better than 10^8?
Already 10^7 implies about 1Gbyte of memory, and if you are creating such a long list there might well be a better way to achieve what you want...

What do you think?

#4 Updated by Anna Maria Bigatti almost 7 years ago

John Abbott wrote:

I have added a note to the man page about "range operator".

I wonder whether a limit of 10^7 would be better than 10^8?

Yes. I wanted to thes the limit, but then remembered I do not have so much RAM ;-)

#5 Updated by John Abbott almost 7 years ago

  • Status changed from Feedback to Closed
  • % Done changed from 90 to 100
  • Estimated time changed from 1.01 h to 1.44 h

I have changed the code (Interpreter.C:3643) so that the limit is 10^7 values; also changed the error message and the documentation. Will check in shortly.

Closing.

Also available in: Atom PDF