Yes it will raise an error, as in Octave. The code will also check
Double is indeed the norm in Scilab. You can have an exemple of this
with the factorial()
function in Scilab. This integer in essence function does not even
accept integers as input !
Le 06/02/2014 20:20, William S Fulton a
What do you plan to happen when you call
Presumably this will error out? If it silently loses precision,
then I don't know that your approach is a good one and I can't see
overloading working. If on the other hand you can reliably detect
and extract a true integer out of a double in Scilab, then using
doubles as the Scilab type everywhere seems reasonable. It sounds
a bit inefficient and slower to me, but if this is the norm in
Scilab, then fine.
On 05/02/14 10:10, Simon Marchetto wrote:
Once we agree on the principles, I will
write a full and precise
specification, that should be included in the documentation.
Le 05/02/2014 10:57, Simon Marchetto a écrit :
In your mail of 10/03/2013, you proposed me to model the
"Python is usually a good reference, but it does separate out
and floating point values, so a cast from a number that is a
point number must be cast to an integral, eg:
short smethod(short d); // C code
# Python code
print smethod(int(22.0)) # Okay
print smethod(22.0) # Runtime error
print smethod(22) # Okay
Modelling on Octave ought to be a better fit where
Why do you want an option to add in casting like in Python?
just make life easier for users by modelling it instead on the
module. Given the similarities between Octave, Matlab and
would be a good thing to have them working similarly."
That was a good idea to be consistent on what is done for
languages that are close to Scilab, as Octave is.
In Scilab as in Octave, the double type is the mostly used
barely use integers.
So Swig Scilab should convert in intput/output integer from/to
We have this behavior in Octave. I have just tested it now:
converts from double to integer in input, and from integer to
At first, I thought as a developer, and so was a bit scared to
theses automatic conversions. But I find no use cases where an
should be returned as this to Scilab, as Scilab can deal with
everywhere, but can have some troubles with integers.
Le 02/02/2014 20:58, William S Fulton a écrit :
This isn't clear to me what you will be doing. I think you
write a more precise specification. It seems to me that for
a given C
numeric type as input, the marshalling should try its
convert the Scilab type (be it a boolean, signed or unsigned
type or double) into the given C numeric type. If it can't
should give some sort of overflow error. With regard to
then if the C type is a signed integer type it should be
into a signed Scilab integer. I don't see why you want to
convert a C
int in output to a Scilab double, you should use the closest
size and sign to the C integer type. I suggest you next make
complete table of C types and Scilab types that you will
and from. This should form part of the documentation too.
On 30/01/14 09:47, Simon Marchetto wrote:
OK, I agree.
So are we going on the following behavior ?
- Scilab double or integer in input => C int
- C int in output => Scilab double
- C unsigned int <=> Scilab unsigned integer
(same for short, and long).
It is the behavior you proposed last time, and which is
in Octave, if I remembered what you told me ?
Maybe there are some use cases in which we want absolutely
signed integer returned, but in fact I can't see anyone
We'll see on using.
About bool: there is a Scilab boolean type, mapping should
Le 29/01/2014 23:40, William S Fulton a écrit :
Your plan sounds reasonable. Definitely any fine tuning
such as memory
leak fixes can be done in later releases. Indeed the
for primitives should work correctly. Also basic STL
should work reasonably well, at the minimum generating
even if they cannot be usefully used from Scilab. In
test-suite should pass if these basics are all ready.
SWIG is very
forgiving and can easily generate compilable code even
if all types
are practically unusable and this is the minimum
From what I recall of the Scilab test-suite you were
until something went wrong in the primitive typemaps and
What precisely do you mean by the Scilab integers will
only be used if
the wrapped function specified signed or unsigned
integers in C are either signed or unsigned, they can't
else! If you are thinking that 'signed' or 'signed int'
differently to 'int', then I will contest that. Surely
you mean all
integer types will convert to an equivalent Scilab
without exception and the only 'other cases' are
floating point types,
which of couse should map to a Scilab double? What about
On 29 January 2014 17:09, Simon Marchetto
I am back on SWIG ! I During the time I have been
away, I could
think about the initial tasks planned below. I
decided to revise
some of them:
- We dont need a SWIG feature to set the behavior
typemaps (conversion to/from double or not). The
and unsigned) integers will be used only if the
signature specifies signed or unsigned integers. In
we convert from/to Scilab double, if possible. It
is simpler. By
the way that was the initial behavior, but it still
needs to be
fixed. The code of Scilab typemaps still need some
- Code generation : I wanted to optimize the
generated code, to
reduce its size, and increase its performance. But
it can wait
- Review of C/C++ features support. It will take
too much time. I
will review the most important unit tests, fix them
and add a few
if needed. I will do a complete review later.
- STL support : I will fix only the case of
have to discuss about it) and a few other things (I
and probably clean the support of
vector<enum>). I let away other
features of STL: iterators...
But I keep the task of finishing the documentation,
which is one
of the most important tasks.
Also a generated code is not usable if it has huge
do not think it will have any, but if I have time,
I will do some
checks on memory management.
I hope I can finish all this soon.
Le 20/12/2013 21:26, William S Fulton a écrit :
I don't think you need go overboard on the
acceptance into master. So long as the
test-suite passes and
you have a few runtime tests (you already have
I'll merge it into master. You can add
All I think you need to do is get the primitive
working as these are fundamental.
With regard to checklists for C/C++ features
test-suite compiles and your tests include
things like enums,
global functions and variables, static and
methods and variables, you'll find that you'll
have a lot
covered as a lot of the detail is handled in
the core. Adding
in stl wrappers etc can come later.
On 20/12/13 08:30, Simon Marchetto wrote:
Yes unfortunately I was away from SWIG. My
aim is also to
add Scilab in
the major version SWIG 3.
I am not sure if it is still possible now,
if we want to
keep high quality.
My planned tasks were:
- finish the C++ support: fix the
maybe a few small
- fix primitive type typemaps, mostly about
double. I would
like to introduce a SWIG feature that sets
typemaps: either convert automatically int
Octave does, or keep integers as integers.
- finish the documentation
- check memory management
- some refactoring : the generated code
maybe or more
- also, and what is the most important to
me : I do not
have a clear
and complete view on what is supported or
not by SWIG
Scilab. I would
like to build a check list of support
status for all C or
For this, I need to analyze also all the
unit tests, and
maybe I need to
add some tests too.
Each of these task may be not so long to
take a couple of weeks.
Le 18/12/2013 01:21, William S Fulton a
What is the latest status for Scilab?
it wrong, but
not much development has happened
recently and we are
now in the final
stages for putting out SWIG 3 and
really I'd like
Scilab support added
for this release.
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common
Read the Whitepaper.
Swig-devel mailing list