"sel 0" bug?
I find it bizarre that passing any floating point number 0.
On the other hand, "route 0" does what I would expect.
-Matt
If you put an integer as an argument sel expects and integer as an input. If you feed it a float it will convert that to an integer which explains what you are seeing - It is not a bug. If you want to give sel a float input then put 0. as an argument and you will get the behavior you expect to see.
best,
john.
Hey Matt,
You need a "sel 0." (float), otherwise value gets truncated, which is
why it is always true.
David
On Aug 2, 2007, at 1:19 PM, Matt Wright wrote:
>
> I find it bizarre that passing any floating point number 0.
> 1. to "sel 0" puts a bang out the left outlet:
>
sel 0 != sel 0.
sel 0 is looking for an INT, not a float.
On Aug 2, 2007, at 4:19 PM, Matt Wright wrote:
>
> I find it bizarre that passing any floating point number 0.
> 1. to "sel 0" puts a bang out the left outlet:
>
>
> #P window setfont "Sans Serif" 9.;
> #P window linecount 3;
> #P comment 187 39 60 196617 Anything over 1 works.;
> #P comment 97 44 60 196617 These don't do what I expect;
> #P window linecount 1;
> #P message 212 82 37 196617 1.234;
> #P message 181 82 23 196617 1.;
> #P message 125 84 23 196617 0.7;
> #P message 98 84 23 196617 0.5;
> #P message 40 81 14 196617 0;
> #P flonum 109 189 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P flonum 87 127 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P button 87 188 15 0;
> #P newex 87 158 32 196617 sel 0;
> #P comment 20 61 60 196617 This works;
> #P connect 9 0 3 0;
> #P connect 8 0 3 0;
> #P connect 7 0 3 0;
> #P connect 6 0 3 0;
> #P connect 5 0 3 0;
> #P connect 1 1 4 0;
> #P connect 1 0 2 0;
> #P connect 3 0 1 0;
> #P window clipboard copycount 12;
>
>
>
>
> On the other hand, "route 0" does what I would expect.
>
> -Matt
>
v a d e //
www.vade.info
abstrakt.vade.info
At 1:19 PM -0700 8/2/07, Matt Wright wrote:
>I find it bizarre that passing any floating point number 0.
Well, comparing a float to an int is a little strange. It's doing pretty much what I'd expect: truncating the float to the integer portion and comparing that.
What did you want it to do?
Does "sel 0." do what you expect?
-C
--
Chris Muir | "There are many futures and only one status quo.
cbm@well.com | This is why conservatives mostly agree,
http://www.xfade.com | and radicals always argue." - Brian Eno
Yes, I understand the difference between 0 and 0. (See, that period is a pun.)
Max's general convention about integer versions of objects truncating incoming floats makes sense if the object does arithmetic, but I think it's a misfeature in the case of "sel". (And that's why I think "route 0" behaves correctly by passing 0.1 out the right outlet.)
Let me put it this way---does anyone have an example of a case where "sel 0" behaving like "split 0. 0.999999" (with a button on the left outlet) is useful or more clear? I think of select and route as being for selecting specific values, not numeric ranges.
-Matt
p.s. I don't think it's strange to compare a float to an int, and if you did so in C or any number of other programming languages it would do what I expect:
int i = 123;
float f = 123.456;
if (i==f) {
printf("I'll eat my hat.n");
} else {
printf("good thing C doesn't work like Max.n");
}
At 3:11 PM -0700 8/2/07, Matt Wright wrote:
>Max's general convention about integer versions of objects truncating incoming floats makes sense if the object does arithmetic, but I think it's a misfeature in the case of "sel". (And that's why I think "route 0" behaves correctly by passing 0.1 out the right outlet.)
Are you sure that "route 0" is doing what you think it is? When I send floats to a "route 0", it seems to want to send _everything_ out the right output.
>Let me put it this way---does anyone have an example of a case where "sel 0" behaving like "split 0. 0.999999" (with a button on the left outlet) is useful or more clear? I think of select and route as being for selecting specific values, not numeric ranges.
And it will select a specific value, if you type it properly. Is this a philosophical disagreement or a practical one? Is there anything in your patch that would break if you were using "sel 0."?
I'm totally willing to entertain an abstract argument, I just thought that your original query was posed as a practical question.
-C
--
Chris Muir | "There are many futures and only one status quo.
cbm@well.com | This is why conservatives mostly agree,
http://www.xfade.com | and radicals always argue." - Brian Eno
You bracket very strangely.
b
On Aug 2, 2007, at 3:11 PM, Matt Wright wrote:
>
> Yes, I understand the difference between 0 and 0. (See, that
> period is a pun.)
>
> Max's general convention about integer versions of objects
> truncating incoming floats makes sense if the object does
> arithmetic, but I think it's a misfeature in the case of "sel".
> (And that's why I think "route 0" behaves correctly by passing 0.1
> out the right outlet.)
>
> Let me put it this way---does anyone have an example of a case
> where "sel 0" behaving like "split 0. 0.999999" (with a button on
> the left outlet) is useful or more clear? I think of select and
> route as being for selecting specific values, not numeric ranges.
>
> -Matt
>
> p.s. I don't think it's strange to compare a float to an int, and
> if you did so in C or any number of other programming languages it
> would do what I expect:
>
> int i = 123;
> float f = 123.456;
>
> if (i==f) {
> printf("I'll eat my hat.
> ");
> } else {
> printf("good thing C doesn't work like Max.
> ");
> }
Barry Threw
Media Art and Technology
San Francisco, CA Work: 857-544-3967
Email: bthrew@gmail.com
IM: captogreadmore (AIM)
http:/www.barrythrew.com
Quote: Leafcutter John wrote on Thu, 02 August 2007 14:39
----------------------------------------------------
> If you put an integer as an argument sel expects and integer as an input. If you feed it a float it will convert that to an integer which explains what you are seeing - It is not a bug. If you want to give sel a float input then put 0. as an argument and you will get the behavior you expect to see.
>
> best,
>
> john.
----------------------------------------------------
:)
i think he knows why it technically happens - but why
is it implemented like that?
he is poinitng out correctly that [route 0] does not
accept floats.
it is clear that there is a significant difference between
route and select: route outputs numbers, so int/float
conversion (or not conversion) is an issue to it.
[route 0] routes "0.77" correctly to the right outlet -
because "0.77" is not "0", but [select 0] claims it would
be, because it does not round it just truncates the float
to int with a pair of scissors.
otoh we could also start a discussion about possible
misbehaviour of the route object:
[route 0] is a [route] object in float mode, don
> >I think of select and route as being for selecting specific values, not numeric ranges.
>
yes - but see, they behave different, that what it is
all about. :)
wouldnt it be useful sometimes when [select 0] would bang
left ONLY when it recieves "INT 0"?
i fully understand matt
try this and you will se whats wrong with [select].
[route] is able to interpret floats correctly as floats even when the first argument is an int.
[select ] is not.
funny thing about it is that they use
[select 1 bob 30 20 55.6]
in the help file, which works.
if you do
[select 55 bob 30 20 55.6]
it stops working.
:)
that means that you have to start with your floats when using select.
but when using route you can mix stuff as you want.
-110
At 7:46 PM -0600 8/2/07, Roman Thilenius wrote:
>try this and you will se whats wrong with [select].
>
>[route] is able to interpret floats correctly as floats even when the first argument is an int.
I don't think this is what's happening. "route 0" doesn't match any float, so it never routes anything to its left output.
-C
--
Chris Muir | "There are many futures and only one status quo.
cbm@well.com | This is why conservatives mostly agree,
http://www.xfade.com | and radicals always argue." - Brian Eno
I wonder if much of this sort of confusion would disappear if Max treated all numerical input as floats (as does Pd), rather than maintaining a typed distinction between integers and floats. Or would this sacrifice some cherished functionality? (Yes, I realize a lot of objects would need to be rewritten.)
Eric
> Not only the objects, some patches would have to be rewritten too.
I must say, I don't find that a compelling argument. Patches sometimes have to get rewritten when the functionality of an object evolves, the alternative being a static universe. Assuming that in a future float-centric Max, integer number boxes in older patches get automatically replaced with float number boxes, can you come up with an example of a patch that would still have to be rewritten? (I'm also assuming that integer-centric objects such as ubumenu, would be updated to accept floats.)
Eric
Interesting thread, Mattijs, thanks! Though it does drift off a bit into "why isn't Max a tofu steak garnished with parsley and truffle oil?" territory. I'm on the fence about how and where to impose typing discipline. My instinct is to favor whatever is most transparent, intuitive, and trouble-free to the end user. Good luck getting three programmers to agree on what that might be! But I do think that the int/float distinction is awkward and unnecessary both at the programmer and the user level.
As a user, do I really want to spend time thinking about whether to grab an int or a float number box?
And as a programmer do I really want to write two different methods to handle input depending on whether it's float or int?
Eric
I'm assuming that you work with neither MIDI nor serial data?
2.999978 != 3.
jb
Am 03.08.2007 um 15:45 schrieb Eric Lyon:
> As a user, do I really want to spend time thinking about whether to
> grab an int or a float number box?
>
> And as a programmer do I really want to write two different methods
> to handle input depending on whether it's float or int?
Quote: Jeremy Bernstein wrote on Fri, 03 August 2007 09:52
----------------------------------------------------
> I'm assuming that you work with neither MIDI nor serial data?
> 2.999978 != 3.
>
> jb
----------------------------------------------------
i couldnt agree more! i use reaktor alot, and its lack of integers makes some things pretty tricky. i know its nowhere near as advanced as max or pd, but its still an annoying limitation (it DOES use int's in its super-low-level core mode, this cant interface with the outside world, though).
im doing software for the monome company (monome.org) and for my app and the OSX app that im emulating, we had to add an overload of the OSC input method that converts floats to ints, just because of reaktor.
Quote: Eric Lyon wrote on Fri, 03 August 2007 15:45
----------------------------------------------------
> Interesting thread, Mattijs, thanks! Though it does drift off a bit into "why isn't Max a tofu steak garnished with parsley and truffle oil?" territory. I'm on the fence about how and where to impose typing discipline. My instinct is to favor whatever is most transparent, intuitive, and trouble-free to the end user. Good luck getting three programmers to agree on what that might be! But I do think that the int/float distinction is awkward and unnecessary both at the programmer and the user level.
>
> As a user, do I really want to spend time thinking about whether to grab an int or a float number box?
>
> And as a programmer do I really want to write two different methods to handle input depending on whether it's float or int?
>
> Eric
>
----------------------------------------------------
I definitly see benefits of floats and ints being contracted into 'numbers'.
Personally I see a more general problem with datatyping.
I believe this very discussion also existed in Macromedia's first meetings about the design of Actionscript. By choosing for untyped variables they unwillingly introduced quite some confusion and inconsistencies for the people that wanted to do just a little bit more than the tutorials. A few versions later they did introduce explicit typing commands. All 'untyped' languages have to deal with problems that mess up the initial idea of being transparent and user friendly.
With this I don't want to say that untyped variables are wrong per se but when discussing the handling of datatypes one -really- has to know what he's doing. These are not new concepts, to take a correct decision about this we'd have to research all existing cases where untyped variables were introduced. Max doesn't pretend to have untyped data, but relies heavily on implicit type casting. And as we have seen this results in a variety of problems regarding intuitivity and consistency.
Btw in the end this results in the question what the actual target group is for max. Programmers or artists..? etc etc. I could go on about this for ages. But I won't, I think I promised Jeremy B some time ago ;)
Mattijs
I must have made some hefty promises to get you to agree to that.
I slightly agree and mostly disagree about implicit datatyping being
a problem. On one hand, it can lead to confusion. On the other hand,
in many cases, it's what the user would and arguably should expect.
Take the following C code.
int d;
float f;
f = 3.5;
d = f;
This is completely legal and 100% desirable, and if you're not paying
attention, you might not realize that you've just lost the .5. But
that's because you weren't paying attention. I certainly think it's
better than
d = (int)f;
or, *cough*
d = reinterpret_castf;
There are certain points in coding where less is is a whole lot more,
and I think that the automatic casting of int and float input to the
correct type based on the context helps a lot more than it hurts.
We're not talking about classes or pointers to complex data types,
but numbers. Obviously, you need to know that you're changing your
float into an int, and there might be things that we could do to make
that change more obvious. I don't believe that's arriving to a new
Max version near you anytime soon, though...
jb
Am 03.08.2007 um 16:25 schrieb Mattijs Kneppers:
> I could go on about this for ages. But I won't, I think I promised
> Jeremy B some time ago ;)
Actually, 'route' does some bizarre stuff too.
The examples in this thread have used floats by themselves (a match results in a bang); in fact, floats (& ints) match differently when they're sent with additional items (ie, the typical usage of 'route').
Anyone care to explain this one to me?
Quote: Jeremy Bernstein wrote on Fri, 03 August 2007 16:45
----------------------------------------------------
> Am 03.08.2007 um 16:25 schrieb Mattijs Kneppers:
>
> > I could go on about this for ages. But I won't, I think I promised
> > Jeremy B some time ago ;)
>
> I must have made some hefty promises to get you to agree to that.
Indeed, we agreed to meet in person and discuss it over a(nother) beer ;)
>
> I slightly agree and mostly disagree about implicit datatyping being
> a problem. On one hand, it can lead to confusion. On the other hand,
> in many cases, it's what the user would and arguably should expect.
> Take the following C code.
>
> int d;
> float f;
>
> f = 3.5;
> d = f;
>
> This is completely legal and 100% desirable, and if you're not paying
> attention, you might not realize that you've just lost the .5. But
> that's because you weren't paying attention. I certainly think it's
> better than
>
> d = (int)f;
>
> or, *cough*
>
> d = reinterpret_castf;
I agree, implicit typecasting is better in this case. But note that literally this example made me eat my hat several times (and not only me). Late nights of debugging to finally find out there was a float to int conversion somewhere messing up a complex algorithm. One has to learn by making mistakes, nothing wrong with that. But it is a sensitive point. If you add some extra inconsistencies, the costs can suddenly outweigh the benefits.
>
> There are certain points in coding where less is is a whole lot more,
> and I think that the automatic casting of int and float input to the
> correct type based on the context helps a lot more than it hurts.
> We're not talking about classes or pointers to complex data types,
> but numbers.
In the case of route and select we're talking about numbers and even here we appearantly run into some misunderstanding.. by Matt Wright even, who I suspect not to be an inexperienced programmer. But it only gets worse for symbols and lists, which too are implicitly casted in many cases within max.
> Obviously, you need to know that you're changing your
> float into an int, and there might be things that we could do to make
> that change more obvious.
That would be great.
> I don't believe that's arriving to a new
> Max version near you anytime soon, though...
As long as I'm not in charge of the priority list at cycling '74 this is something I don't dare to value ;)
Mattijs
>
> jb
>
> I'm assuming that you work with neither MIDI nor serial data?
> 2.999978 != 3.
>
I don't work with figured bass either :)
Seriously, MIDI seems to work fine in Pd despite lack of integers as an input type. Could you post a simple Max patch that demonstrates how the lack of an integer number box and/or integer number inlet could make the user despondent? (Assume that utility objects like floor, ceil, and round would be available if necessary.)
Cheers,
Eric
At 2:20 PM +0100 8/3/07, Eric Lyon wrote:
>(I'm also assuming that integer-centric objects such as ubumenu, would be updated to accept floats.)
So what should ubmenu do if it received a 1.1415? What should switch do? gate? (and a jillion other objects)
-C
--
Chris Muir | "There are many futures and only one status quo.
cbm@well.com | This is why conservatives mostly agree,
http://www.xfade.com | and radicals always argue." - Brian Eno
> So what should ubmenu do if it received a 1.1415? What should
> switch do? gate? (and a jillion other objects)
>
What should ubumenu do if it receives a -7? Sending an object an inappropriate message is user error. That said, I think it's pretty obvious that ubumenu, gate and friends should internally round an incoming float to the nearest integer, so sending it 1.1415 would have the same effect as sending it 1.
Incidentally, sending ubumenu 1.0 from a float number box (unlike 1 from an integer number box) has no effect at present, which I suggest is counterintuitive.
Eric
I guess my take on this is that some things are inherently
integer-based: menu selection, MIDI data, gate section selection, etc.
If all numbers are floats, there will still have to be truncation at
the inputs of many objects that are intrinsically integer-based.
This would be a large change to Max, and I don't really see that
there's enough benefit to warrant it, but that's just my opinion.
-C
--
Chris Muir | "There are many futures and only one status quo.
cbm@well.com | This is why conservatives mostly agree,
http://www.xfade.com | and radicals always argue." - Brian Eno
Here's another bizarre one:
Apparently Maximum, even with a float argument, looks at the first element of the incoming list of numbers to decide whether to treat the entire list as integers. But then after it's thrown away my .9 it turns the integer wrong answer back into a float because I gave it a float argument!
-Matt
my 2 cents.
Don't "think in C" when learning a new language. Max, albeit much higher level, is its own entity with its own rules.
Quote: Eric Lyon wrote on Fri, 03 August 2007 06:20
----------------------------------------------------
> > Not only the objects, some patches would have to be rewritten too.
>
> I must say, I don't find that a compelling argument.
----------------------------------------------------
I definitely agree with Eric here. It's not like Cycling74 has to change all the existing objects and break everyone's patches in the next major release. There is a right way to do this kind of change: phase in a new set of objects and do some planned deprecation. It happens all the time on long-lived software platforms.
Take for example the change from StringBuffer to StringBuilder when upgrading to Java 5. Java remains backward compatibility, but introduces new and improved objects for people building new software or reworking existing software.
-Adam
> Actually, 'route' does some bizarre stuff too.
>
> The examples in this thread have used floats by themselves (a match results in a bang); in fact, floats (& ints) match differently when they're sent with additional items (ie, the typical usage of 'route').
>
> Anyone care to explain this one to me?
i agree with you that it is the typical use
of route/select to process lists with them.
as it seems in a list route does not make
a difference between 0 float and 0 int.
so in lists (select does it the same way btw)
route sees 0 only as number and not as number
of a certain type like it does when it recieves
only a number.
this would be exactly the types it supports
for sorting:
[route int float list bang]
when it cannot sort lists by type "start with int"
vs. "starts with float" it can also not sort such lists
according to number type.
i know that this is not an explanation ... maybe
max does not want to you start lists with floats when you organize your data streams? :)
normally messages to objects start with symbols, isnt it?
(frgb 255 255 255, Q 440., enable 0 ... )
-110
Quote: adamj wrote on Fri, 03 August 2007 14:42
----------------------------------------------------
> Quote: Eric Lyon wrote on Fri, 03 August 2007 06:20
> ----------------------------------------------------
> > > Not only the objects, some patches would have to be rewritten too.
> >
> > I must say, I don't find that a compelling argument.
> ----------------------------------------------------
>
> I definitely agree with Eric here. It's not like Cycling74 has to change all the existing objects and break everyone's patches in the next major release. There is a right way to do this kind of change: phase in a new set of objects and do some planned deprecation. It happens all the time on long-lived software platforms.
>
----------------------------------------------------
At the very least I would like to be able to set the default behavior of all math objects to floats globally. I acknowledge the utility of floats in circumstances such as MIDI.
The amount of time I've spent helping students find bugs where objects without an argument default to an int is huge, and the frustration for them is non-productive. (Line gets people quite often, too, although not a math object.) If there's an option, then old school int-ists can have it their way, while newer programmers can get what they expect more often.
That being said, Matt's bug is *not* about the existence of typecasting. Select is an object to "Send bang out an outlet that matches the input." Anybody who has read this much of this thread knows that ints are not floats. 0. does not "match" integer 0 (.) 0.3 certainly does not match integer 0 (.) I agree that if you are trying to select an integer zero, sel shouldn't bang unless that's what it gets.
Look at the opposite case:
[sel 0.] does not recognize "0" as a match, because it is not a match. I argue that select's definition of match is internally inconsistent. 0. should never match 0, but if it does, then it should *always* match.
Is this case, select is also not consistent with the math objects, which "promote" ints to floats if an int argument is specified.
I realize this isn't a big problem for heavy Max users. But these kind of things really take people out of the zone, and make learning Max needlessly difficult.
mz
For what its worth, PD only uses floats. No casting issues there.
On Aug 3, 2007, at 9:04 PM, mzed wrote:
>
> Quote: adamj wrote on Fri, 03 August 2007 14:42
> ----------------------------------------------------
>> Quote: Eric Lyon wrote on Fri, 03 August 2007 06:20
>> ----------------------------------------------------
>>>> Not only the objects, some patches would have to be rewritten too.
>>>
>>> I must say, I don't find that a compelling argument.
>> ----------------------------------------------------
>>
>> I definitely agree with Eric here. It's not like Cycling74 has to
>> change all the existing objects and break everyone's patches in
>> the next major release. There is a right way to do this kind of
>> change: phase in a new set of objects and do some planned
>> deprecation. It happens all the time on long-lived software
>> platforms.
>>
> ----------------------------------------------------
>
>
> At the very least I would like to be able to set the default
> behavior of all math objects to floats globally. I acknowledge the
> utility of floats in circumstances such as MIDI.
>
> The amount of time I've spent helping students find bugs where
> objects without an argument default to an int is huge, and the
> frustration for them is non-productive. (Line gets people quite
> often, too, although not a math object.) If there's an option, then
> old school int-ists can have it their way, while newer programmers
> can get what they expect more often.
>
> That being said, Matt's bug is *not* about the existence of
> typecasting. Select is an object to "Send bang out an outlet that
> matches the input." Anybody who has read this much of this thread
> knows that ints are not floats. 0. does not "match" integer 0 (.)
> 0.3 certainly does not match integer 0 (.) I agree that if you are
> trying to select an integer zero, sel shouldn't bang unless that's
> what it gets.
>
> Look at the opposite case:
>
> #P button 222 114 15 0;
> #P window setfont "Sans Serif" 9.;
> #P number 277 100 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P number 212 36 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P window linecount 1;
> #P newex 228 60 35 196617 sel 0.;
> #P connect 0 0 3 0;
> #P connect 0 1 2 0;
> #P connect 1 0 0 0;
> #P window clipboard copycount 4;
>
>
> [sel 0.] does not recognize "0" as a match, because it is not a
> match. I argue that select's definition of match is internally
> inconsistent. 0. should never match 0, but if it does, then it
> should *always* match.
>
> Is this case, select is also not consistent with the math objects,
> which "promote" ints to floats if an int argument is specified.
>
> I realize this isn't a big problem for heavy Max users. But these
> kind of things really take people out of the zone, and make
> learning Max needlessly difficult.
>
> mz
>
>
>
> --
> || michael f. zbyszynski -- molecular gastronimist
> || http://www.cnmat.berkeley.edu/
> || http://www.mikezed.com/
>
>
>
v a d e //
www.vade.info
abstrakt.vade.info
Quote: jamez wrote on Fri, 03 August 2007 23:38
----------------------------------------------------
> my 2 cents.
>
> Don't "think in C" when learning a new language. Max, albeit much higher level, is its own entity with its own rules.
----------------------------------------------------
But the question is what these rules should be. The current set of rules has some deficiencies, which results in an urge to look for a better set. When looking for a solution to a problem I think it is never a bad idea to look at how others solved their version of it.
Mattijs
also, with float only system, you are limited to 24 bit resolution with 'integer' values. not always a big deal, but can be annoying if you are packing lots of 4 or 8 values into an int (or using an int as bitflags, you get 8 less flags).
also, BitOps in general would require internal converting to and from integer anyways.
> also, with float only system, you are limited to 24 bit
> resolution with 'integer' values. not always a big deal, but can
> be annoying if you are packing lots of 4 or 8 values into an int
> (or using an int as bitflags, you get 8 less flags).
I don't know if this would be a problem. I doubt it, but there is a simple way you can test it: connect a floating point number box to an integer number box to whatever bitwise operation you want to do. Then type your integer number into the float box, and see if you get a different result than if you type your number directly into the integer box. Please let us know if you find a difference in the result.
Eric
> > also, with float only system, you are limited to 24 bit
> > resolution with 'integer' values. not always a big deal, but can
> > be annoying if you are packing lots of 4 or 8 values into an int
> > (or using an int as bitflags, you get 8 less flags).
>
>
I wrote too soon - you are correct that the Max float number boxes only represent single precision floats, thus you do only get 24 bit (significand) precision, compared with 32 bit precision in the integer boxes. This surprised me, because individual Max floating point arguments are passed internally as double precision floats, which would give you 53 bits of precision. But, for whatever reason, the number boxes only do single precision. And the float part of Max atoms is currently defined as single precision float, which would also have to change to double precision in a float-only system. Thus, I must concede that moving to a float-only system would be more complicated than I initially thought. It could still work, but would require that all numerical arguments be defined as double precision floats throughout, and that the float number box be rewritten.
Thanks for pointing out that limitation.
Having said all that, I still think it would be a good idea to make all operations that are not inherently integer-based be floating point by default.
Eric
Perry Hoberman schrieb:
> Actually, 'route' does some bizarre stuff too.
>
> Anyone care to explain this one to me?
I would call this a bug
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
Jeremy Bernstein schrieb:
> int d;
> float f;
>
> f = 3.5;
> d = f;
>
> This is completely legal and 100% desirable, and if you're not paying
> attention, you might not realize that you've just lost the .5. But
> that's because you weren't paying attention. I certainly think it's
> better than
>
> d = (int)f;
I don't agree,
d = (int)f is very certainly better than d = f. It's only legal in C and
there is a reason that better languages don't think its desirable...
I guess your compiler, if its smart, will print a warning. Without that
warning (Max does not warn) there is practically no chance to find that
little bug in a bigger code base, and only because you didn't pay attention?
Its better to be forced to convert floats to ints (not necessary the
other way around...) than having a program which seems to work at first
sight, but later you realise there is somthing wrong. Then its often too
late and you have to rewrite the whole code because searching for this
little precision oversight takes even longer...
In a Max patch its not that hard to find it, but still...
When I wanted to switch from Modula to C, I gave up, because this
explained all the so called "software crisis" "unmaintainable code"
problems immediately... I wanted to switch to something better than
Modula, and found Max, but Max does carry some disadvantages of C
unfortunately, probably because its written in C...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
> > I must say, I don't find that a compelling argument. Patches
> > sometimes have to get rewritten when the functionality of an object
> > evolves, the alternative being a static universe.
>
> I don't agree. If I have a patch still in active developement, then yes,
> it would be better to adjust to the evolving environment. But in Max
> there are a lot of patches which are kind of finished, they work, and
> nobody would want to touch them ever again, but there remains the wish
> they should still work. Its harder to maintain old versions of the Max
> application than relying on backward compatibility and just live with
> its drawbacks...
>
In principle I agree, but in practice there are some cases where you have to choose between backwards compatibility and improvement. For example, your external has a bug, and older patches have come to rely on the presence of that bug for their behavior. In that case I would fix the bug, even if it causes backwards compatibility problems.
> I don't like the idea of getting rid of integers by the way...
> To avoid type problems by getting rid of types doesn't solve a problem.
>
As you can see from following this thread, my view on this has evolved somewhat. I see the use for integers in a few cases. But I would describe myself as an integer minimalist. In other words, do numerical calculations in floating point (ideally double-precision), unless you have a really good reason not to. A few really good reasons have been pointed out earlier in this thread.
While there is something to be said for the conservative Max veteran's approach that you advocate, I think it is worth considering the newbie experience as well. Consider the Max "*" object. A new user grabbing a "*" object, sending floating point values into it and observing the results is likely to be surprised, because in all likelihood, s/he is used to using the same symbol "*" to multiply floats as to multiply integers. The fact that floating point multiplication does not work with "*" by default is an artifact of Max typing, and the way it was coded into that particular object.
This is not an insurmountable problem, The "*" object could easily be rewritten such that it would give correct results due the specific types at the inlets, without requiring a user-supplied argument to force the desired kind of multiplication. If two integers are sent in, you get integer multiplication, otherwise floating point multiplication.
So that's my solution: rewrite objects that regularly confuse people unnecessarily.
Eric
Eric Lyon schrieb:
> This is not an insurmountable problem, The "*" object could easily be
> rewritten such that it would give correct results due the specific
> types at the inlets, without requiring a user-supplied argument to
> force the desired kind of multiplication. If two integers are sent
> in, you get integer multiplication, otherwise floating point
> multiplication.
I agree to that idea, and even backward compatibility could be
maintained by having a mode for all objects, which will be the old
version when just loaded with an existing old patcher, but if you
instantiate a new * box, it will be in "automatic type mode". It would
need some extra color coding though, because you would not be able to
see the "old mode" in an old patch which could lead to some confusion...
> So that's my solution: rewrite objects that regularly confuse people
> unnecessarily.
Yes, but do it smart...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
that would make the [*] object slower.